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

[David Blacka]

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.

--
David Blacka                          <davidb at verisign.com>
Sr. Engineer    VeriSign Infrastructure Product Engineering






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3899 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20080226/ee760360/attachment.bin>