Ted Lemon wrote:
On Saturday, March 12, 2016 01:58, Paul Vixie wrote:
Ted, I think you're reading it wrong. The implementation doesn't matter
at all. As Co-Chair Woolf kindly and classily 2x4'd me last year, an RFC
should be of the form "if you want to do X, here's a way to do it
interoperably."
With all due respect, Paul, it is you who are reading it wrong, because the
spec doesn't do what you say Supreme Co-Chair Woolf said, to wit:
This specification should express the basic idea that after an NXDOMAIN
has been received from an authority server for name X, then the receiver
of that NXDOMAIN is allowed to (note: "allowed to"; this is optional,
and is just an optimization) treat it as also applying to any name that
is in-bailiwick for X. (Sometimes that will be expressed as "at or below
X" or "a subdomain of X".)
This is what the specification _should_ say, not what it _does_ say.
you've caught me out as to not having read drafts after -00. what i did
read was this:
http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00
which says:
3. Stopping Downward Cache Search on NXDOMAIN
3.1. In virtually all existing resolvers, a cached NXDOMAIN is not
considered "proof" that there can be no child domains underneath.
This is due to an ambiguity in RFC 1034 that failed to distinguish
empty nonterminal domain names from nonexistent names. For DNSSEC,
the IETF had to distinguish this case, but the implication on non-
DNSSEC resolvers wasn't fully realized.
3.2. When searching downward in its cache, an iterative caching DNS
resolver should stop searching if it encounters a cached NXDOMAIN.
The response to the triggering query should be NXDOMAIN.
3.3. When an iterative caching DNS resolver stores an NXDOMAIN in its
cache, all names and RRsets at or below that node should be deleted
since they will have become unreachable.
3.4. By implication, a stream of queries FOO.TLD, BAR.FOO.TLD where
FOO.TLD does not exist would normally cause both queries to be
forwarded to TLD's nameservers. Following this recommended practice,
the second query and indeed any other query for names at or below
FOO.TLD would not be forwarded.
my reason for quoting this here will be apparent below.
Like all other forms of negative caching, this is just a speedup, and if
a cache is implemented in a way that makes "is there a negative cache
element for whose owner name this qname is in-bailiwick?" too expensive,
then that negative caching implementation will probably not perform this
optimization.
If it's a speed hack, there shouldn't be any normative language
associated with implementing it. I'm objecting to the normative
language, not the clarification that allows the speed hack. I agree with
the clarification.
i argue that in resimprove-00 (which is superceded by the bortzmeyer
nxdomain work, as to this nxdomain topic), we ought to have written "can
be deleted" rather than "should be deleted", since deletion is a storage
optimization that has no on-the-wire effect.
as to the word "downward" in the face of modern caches which aren't
nec'ily hierarchical, i think i chose the right word, since 1034+1035
describe system properties by use of phrases like "search downward". the
hierarchical nature of the cache is not a necessary property of actual
caches, but the responder's behaviour is described that way. to fix this
would be awkward:
3.3 When searching its cache, an iterative caching DNS resolver should
discover any cached NXDOMAIN for which the QNAME is in-bailiwick, and in
this case, the response should be NXDOMAIN, even if there are other data
stored in the cache at owner subdomains of the cached NXDOMAIN.
what i'm urging here is great caution both for the authors and the
reviewers. improving the readability of this topic over what we wrote in
resimprove-00 seems necessary but is not a simple proposition.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
