Ted Lemon wrote:
i took the words "at or below" to mean "in-bailiwick". caches that are
not organized as tree-like data structures still have to be able to find
the closest encloser, which means they do know ancestor/descendent
relationships, even if the data structure itself is otherwise flatishly
hashlike.
The most straightforward way to implement this is to say
"FOO.BAR.COM"'s closest encloser is BAR.COM, and then look BAR.COM up
in the cache. Which is fine when you _need_ to do that. It's not fine
to do it on every query even when it otherwise would not have been
necessary (which would be the vast majority of cases). But to
implement this algorithm you need to start at the room, so first look
at ".", then at "COM", then at "BAR.COM". That's three hash lookups
if there's a cached NXDOMAIN, and four if there isn't. Blech.
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."
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".)
If an implementation doesn't perform this optimization, then for names
below X, it will forward queries to an authority, who WILL answer with
NXDOMAIN unless the name-below-X has actually been created in the time
since the NXDOMAIN for X itself was received.
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.
There is a specification clarification here: QUERY for an empty
non-terminal name must yield response RCODE=0 ANCOUNT=0 even for
QTYPE=255. I've always interpreted RFC 1034+1035 that way but not every
implementer did. This clarification is nec'y for the optimization being
described, since otherwise an empty non-terminal could hide all of its
subdomains from implementations of the optimization under discussion.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
