Subject: [dnsop] Delegation inconsistency clarification

From: John Kristoff <[email-masked]>
Date: Mon, 24 Apr 2006 16:48:33 -0500

I'm hoping someone can clue me in on the issues involving delegation
inconsistency of TTLs.  Here is an example zone as seen from the
TLD:

  ;; ANSWER SECTION:
  king.com.               172800  IN      NS      ns.fjordnetwork.com.
  king.com.               172800  IN      NS      ns.midasplayer.com.

then each authoritative server shows the following:

  ;; ANSWER SECTION:
  king.com.               300     IN      NS      ns.fjordnetwork.com.
  king.com.               300     IN      NS      ns.midasplayer.com.

  ;; ADDITIONAL SECTION:
  ns.fjordnetwork.com.    3600    IN      A       62.80.210.14
  ns.midasplayer.com.     300     IN      A       217.212.244.66

First, the NS RRset has differing TTL values at the parent and child.
Strictly speaking I thought this was a configuration error.  Is it?
If so, what are the potential issues in such a TTL mismatch that may
cause problems with this zone?

Second, strictly speaking I thought the TTL mismatch for the TTLs in
A records as shown in the additional section is not a configuration
error.  Is that the case?  What if any issues might result from that
configuration?

John
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 24 Apr 2006 19:57:12 -0400

>Strictly speaking I thought this was a configuration error.  Is it?
Don't believe so.

>cause problems with this zone?
None that I can think of.

If the delegation NS TTLs were so low that the records expire before an 
answer can be obtained from the delegated nameservers, then this might 
cause a problem, but that's not a _consistency_ problem, _per_se_, just 
a generic problem with TTLs that are too small.

Bear in mind that the apex NS records in the child are more "credible" 
and will therefore, if available, take precedence over the delegation 
NS'es. So under normal circumstances the delegation NS records are 
"ephemeral" anyway, and so the TTL on those records is not of critical 
importance.

>error.  Is that the case?  What if any issues might result from that
That isn't a configuration error either. ns.fjordnetwork.com/A and 
ns.midasplayer.com/A are completely different RRsets, so there is no 
"consistency" requirement between them. I can't think of any problems 
that would be caused by this inconsistency. Obviously the 300-second-TTL 
record is much more likely to have to be re-fetched more often than the 
3600-second-TTL record, in order to be used, but that's true for *any* 
relatively-low-TTL RRset, not just in the delegation/referral/glue context.

- Kevin

.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 25 Apr 2006 09:49:20 +0200

On Mon, Apr 24, 2006 at 04:48:33PM -0500,
 John Kristoff <[email-masked]> wrote 

>   king.com.               172800  IN      NS      ns.midasplayer.com.

You do not provide the value of the 'aa' flag (Authoritative Answer)
which is important here. The delegation NS (in the parent zone) are
not authoritative. If in doubt, believe what is in the delegated zone.
 
> First, the NS RRset has differing TTL values at the parent and
> child.  Strictly speaking I thought this was a configuration error.
> Is it?

For the value of the NS records, IMHO, yes, it would be an error, but
a common one. Some people change the zone without telling the "above"
registry and some registries are so slow/unreliable to change anything
that you sometimes do no care to tell them of a change.

For the TTL, I hesitate to label it as an error since no registry I
know allow the registrant to choose the TTL of the delegation
records... (RFC 3731 - EPP - or RFC 3632 - RRP - do not seem to allow
the client to set a TTL.)

Registry people can check the data model of their database: I believe
the TTL is always a global variable and never a per-domain variable.

> cause problems with this zone?

Not a lot, I hope so, because it is common :-)
 
.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Apr 2006 09:37:57 +0300

>   king.com.               300     IN      NS      ns.midasplayer.com.

If the upper answer is from an IP address that is not authoritative 
for king.com and the lower answer is, the lower answer will be 
credited with a higher trustworthy value (RFC 2181).

Such a "conflict" is common - you could see different TTLs in caches.

E.g.,

$ dig neustar.biz ns

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;neustar.biz.                   IN      NS

;; ANSWER SECTION:
neustar.biz.            1761    IN      NS      ns2.neulevel.biz.
neustar.biz.            1761    IN      NS      ns3.neulevel.biz.
neustar.biz.            1761    IN      NS      ns4.neulevel.biz.
neustar.biz.            1761    IN      NS      ns1.neulevel.biz.

;; SERVER: 193.0.8.2#53(193.0.8.2)

$ dig @ns4.neulevel.biz neustar.biz ns

;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; ANSWER SECTION:
neustar.biz.            1800    IN      NS      ns3.neulevel.biz.
neustar.biz.            1800    IN      NS      ns4.neulevel.biz.
neustar.biz.            1800    IN      NS      ns1.neulevel.biz.
neustar.biz.            1800    IN      NS      ns2.neulevel.biz.

;; SERVER: 209.173.57.84#53(209.173.57.84)

It's reasonable for the parent to have different TTLs than the child 
for the NS set.  RFC2181 takes care of any conflict.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html