Ted Lemon wrote:
Oh, here's some text that our engineering team proposes:
A plain reading of the first paragraph of section 2, which section
5supports, is that *all* subsequent queries for information beneath the
NXDOMAIN name point SHOULD return NXDOMAIN. In particular, this includes
queries that would otherwise have been cache hits. It is this last bit
that I object to.
well, it's deliberate, so the objection is live.
you have to do the "rm -rf $qname" when you receive the nxdomain. once
that nxdomain expires, you're free to make new queries for subdomains of
the now-expired nxdomain. but having the nxdomain status of subdomains
change without authority action would violate the data model. if sub.dom
starts generating cached nxdomains because an nxdomain was received for
dom, then sub.dom should not be able to generate non-subdomains without
some newer result from the authority.
OLD:
When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache and all names and RRsets at or below
that node SHOULD then be considered to be unreachable. Subsequent
queries for such names SHOULD elicit an NXDOMAIN response."
NEW:
When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache. For the lifetime of the NXDOMAIN
negative cache entry, the resolver SHOULD NOT make queries to the
authoritative servers for cache misses involving names at or beneath the
owner name of the NXDOMAIN negative cache entry, and SHOULD return an
NXDOMAIN. The resolver MAY return NXDOMAIN for any query at or beneath
the NXDOMAIN owner name, i.e. already cached entries beneath the
NXDOMAIN owner name MAY become unreachable."
see above.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
