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

[Paul Vixie]

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