Ted Lemon wrote:
so whenever i hear words like "that'll be slow for flat-hash dns caches"
it reminds me of the joke that begins "doctor, it hurts when i do $this"
and ends with "well, then don't do $this".
This sounds like a really good rejoinder until you realize that we
are talking about an optimization that is likely to produce very
little actual benefit in practice other than in the presence of
certain kinds of PRSD attacks. So the current draft makes an
algorithm which apparently works well for several implementations
work less well in order to get a benefit the magnitude of which is
unclear, but likely small.
i figured that if the perceived cost of implementing it (e.g., multiple
hash table lookups using label stripping) it is high, and the perceived
benefit of having implemented it (e.g., resistance to certain PRSD
attacks) then it won't be implemented.
a non-implementing recursive will likely not care that nxdomain applies
to both the qname and all possible subdomains, but i see no harm in
clarifying the specification in that way, nor in pointing out the
possible optimization, which each implementer will have to evaluate.
As a matter of principle, of course, what you are saying is true.
However, remember that what we are debating here is not whether to
clarify the rules for handling NXDOMAINs, but rather whether to add
normative language strongly urging implementations to do this
optimization. ...
i have no desire to defend that normative language. but my reason for
lacking that desire has nothing to do with cache data structures.
rather, it's my view that normative language should be as rare as it can be.
... We all, I think, agree that the clarification is good. By
your argument, we should not add the normative language--we should
just clarify the spec, and then see what happens.
i think the document should point out the possibility of the
optimization, and not just leave this as an implication for the reader
to discover. but that possibility need not be worded prescriptively nor
as a recommendation. rather, a normal cost:benefit analysis should be
assumed, and the benefit of this optimization stated clearly.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
