[dns-operations] caches only resetting TTL? was Re: Whereto find "DNS resolution path corruption"?
davidb at verisign.com
Wed Feb 27 18:51:40 UTC 2008
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
>> path when a record expires. The reason being that it is more
> 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
> 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
> you're doing and go re-issue a query for the name/class/type you're
> to access from your own cache, against the closest ancestor
> above the NS RRset you're trying to cross on your way to that data.
> you get resolution (could be a refresh of the delegation, could be
> 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...
Size: 3899 bytes
Desc: not available
More information about the dns-operations