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

[David Blacka]

On Feb 27, 2008, at 9:45 AM, Paul Vixie wrote:

>> I don't agree with Paul's solution of allways going for the root  
>> resolution
>> path when a record expires.  The reason being that it is more  
>> expensive.
>
> really, it's not.
>
>> A resolver then needs to do 3 itterative lookups, where in 99% of  
>> the time
>> it can do with 1.
>
> nope.  let me clarify.  for every NS RRset in a recursive server's  
> cache,
> store two new attributes: referring zone, and referring zone ttl.   
> do not
> update these from zone apex information, only from zone ancestor  
> data.  if,
> when fetching something from the cache for use in an answer,  
> authority, or
> additional data section of some response, you cross an name  
> containing an
> NS RRset whose referring zone ttl has ticked down to zero, then stop  
> what
> you're doing and go re-issue a query for the name/class/type you're  
> trying
> to access from your own cache, against the closest ancestor  
> nameservers
> above the NS RRset you're trying to cross on your way to that data.   
> when
> you get resolution (could be a refresh of the delegation, could be  
> RCODE=3)
> then restart the processing of your original query.

I'm guessing that there is an implicit assumption that when looking up  
something in the cache, and ancestor NS rrset nodes are always  
traversed ("you cross a name...")?

Is this substantially different from trimming the TTLs of cache  
entries to the TTL of the parent-side NS rrset?  Or not trimming the  
the original TTL exactly, but trimming to the expiration time of the  
parent-site NS rrset?

--
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/20080227/be23a062/attachment.bin>