[dns-operations] caches only resetting TTL? was Re: Where to find "DNS resolution path corruption"?

Roy Arends roy at dnss.ec
Tue Feb 26 21:56:18 UTC 2008

On Feb 26, 2008, at 4:25 PM, Paul Vixie wrote:

>> You'll get the NS RRSet twice, once as referral and then very  
>> likely as
>> supplement to the authoritative response to the subsequent query.   
>> This time
>> in the authority section with a TTL determined by the (child) zone
>> maintainer and that TTL might be higher than the delegation NS  
>> RRSet TTL.
> i have here a private label (non-BIND) caching recursive nameserver  
> with the
> special ability to validate the entire NS chain on every response,  
> such that
> if any delegating (ancestor) NS TTL ticks down to zero, then  
> iteration will
> be re-started from that point, which effectively clamps the  
> authoritative-in-
> child NS TTL to be no greater than the zone-cut-in-parent NS TTL.  i  
> also
> prune entire trees when an authority SOA comes in with a higher  
> serial# or
> when an authority NXDOMAIN is received for a name i had records or  
> children
> for.
> experience to date has been good -- it doesn't hit this logic path  
> often, but
> no harm has been seen, and it avoids the problem described  
> hereabove.  should
> i write this up as an internet draft rather than sitting on it?  (is  
> it a
> dnsop@ thing, since it's optional full-resolver behaviour which  
> changes
> nothing on the wire, or is it a namedroppers@ thing, since it  
> changes the
> treatment of stuff that comes in over the wire?)

I'd like to have it written up, regardless of venue.

One observation is that the private label (non-BIND) caching recursive  
nameserver (paul, do you have any shorthand name for it ?) you refer  
to will encounter some domains like co.uk, com and net with a high  
frequency of changing SOA serials. The high frequency, plus the high  
level domain the frequency applies to, makes the nameserver to prune a  
lot. Would it, in those case, be configurable to not cache for these  
domains at all? Do you have any statistics on how often that logic  
path is hit ?



More information about the dns-operations mailing list