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

[Paul Vixie]

> You'll get the NS RRSet twice, once as referral and then very likely as
> supplement to the authoritative response to the subsequent query.  This time
> in the authority section with a TTL determined by the (child) zone
> maintainer and that TTL might be higher than the delegation NS RRSet TTL.

i have here a private label (non-BIND) caching recursive nameserver with the
special ability to validate the entire NS chain on every response, such that
if any delegating (ancestor) NS TTL ticks down to zero, then iteration will
be re-started from that point, which effectively clamps the authoritative-in-
child NS TTL to be no greater than the zone-cut-in-parent NS TTL.  i also
prune entire trees when an authority SOA comes in with a higher serial# or
when an authority NXDOMAIN is received for a name i had records or children
for.

experience to date has been good -- it doesn't hit this logic path often, but
no harm has been seen, and it avoids the problem described hereabove.  should
i write this up as an internet draft rather than sitting on it?  (is it a
dnsop@ thing, since it's optional full-resolver behaviour which changes
nothing on the wire, or is it a namedroppers@ thing, since it changes the
treatment of stuff that comes in over the wire?)