[dns-operations] caches only resetting TTL? was Re: Whereto find "DNS resolution path corruption"?
paul at vix.com
Wed Feb 27 19:02:57 UTC 2008
> > ... 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...")?
yes. one of the many ways in which the DHT people misunderstand the DNS is
to assume that the FQDN has a flat meaning rather than a hierarchical one.
in my personal work on DNS full resolvers, all lookups proceed from the root,
so that a later-acquired RCODE=3 can correctly annihiliate earlier-acquired
names and RRsets at/below the name whose existence is now denied. this also
gives me the benefit, if i reach the end of my downward traversal without
learning anything positive or negative about a name or rrset, of already
having learned the closest-enclosing NS RRset that i'll use to learn some
kind of positive or negative result that i can use in my answer processing.
> 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?
yes. if i've cached a large volume of data with TTL's measured in days or
weeks, but it was introduced to me by a zone cut whose TTL was measured in
seconds or minutes, then on the short schedule i only want to re-validate
the short-TTL information, and once this periodic revalidation is complete,
i want to then resume normal use of the long-TTL data under that delegation.
More information about the dns-operations