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

[David Blacka]

On Feb 26, 2008, at 6:45 PM, Mark Andrews wrote:

>
>>
>> --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.

OK, so that is what *bind* does, but how would any other implementer  
know to do this?

> 	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.

Now I'm not sure I understand what issue you are referring to.   
Surely, with BIND, the situation I described above would resolve  
itself after the example.com NS TTL expired?  What else is going on?

--
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/4e5c2199/attachment.bin>