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

[Mark Andrews]

> 
> --Apple-Mail-43-275667451
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	format=flowed;
> 	delsp=yes
> Content-Transfer-Encoding: 7bit
> 
> 
> On Feb 26, 2008, at 5:14 PM, Mark Andrews wrote:
> 
> >
> >>> So I'm curious where this behaviour originates from, so I have a  
> >>> stick to
> >>> beat the ISP's to delete old authoritative zones.
> >
> > 	The cache is only doing what it is designed to do.  Cache
> > 	the responses.  In this case it's caching the authoritative
> > 	part of the response.  Each time it gets a answer it gets
> > 	a new copy of the NS RRset for the zone and it caches it.
> >
> > 	The caching server assumes that correct management practices
> > 	are being followed.  That old server will serve the current
> > 	zone content (which is what should happen for a period) or
> > 	that the old server is not serving the zone.
> 
> I'm not quite following this discussion, I suspect, but I'm wondering  
> if this particular issue suggests a different behavior from the cache?
> 
> Let me see if I understand the issue.
> 
> * example.com moves from ns1.bar.com to ns1.foo.com.
> * Caching resolver 'A' previously cached the NS RRset for example.com  
> (example.com 86400 NS ns1.bar.com, say)
> * Prior to timing this out, does a new lookup for mail.example.com at  
> ns1.bar.com.
> * The response contains the old NS RRset.
> * 'A' refreshes the example.com NS entry, resetting the TTL back to  
> 86400 (say)
> 
> So, as long as 'A' can continue to query ns1.bar.com for stuff in  
> example.com, and as long as it does so at least once per NS TTL, it  
> will never see that the delegation changed to ns1.foo.com.
> 
> So, I'm wondering if this suggests that caches shouldn't update the  
> TTL unless the data changed (i.e., it was actually a new RRset)?  That  
> is, certainly retain the ability to replace lower-credibility and  
> older versions of an RRset with the new RRset, but refuse to only  
> reset the TTL.

	Which is what we do.

	The problem is that people expect caches to recover from
	every possible misconfiguration and they can't.  Zone
	administators have to take some responsablity for the
	management of their zones.  This includes parent zone
	administators.

	People also expect nameservers to detect every possible
	configuration problem.  This is impossible to do.

	Mark
> --
> David Blacka                          <davidb at verisign.com>
> Sr. Engineer    VeriSign Infrastructure Product Engineering
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org