this is getting pretty good. anyone who stopped reading before now, may
want to delve back in at this point.
Ted Lemon wrote:
no. it's not an interoperability matter.
If it's not an interoperability matter, then there shouldn't really
beany normative language.
i think hop-by-hop interoperability (which is what ietf normally
measures, since the bits on the wire have senders and receivers) is the
wrong way to understand end-to-end utility and correctness in the dns.
an authority server operator experiencing a PRSD DDoS might wish to add
a zone cut or even remove a name in order to manage their defense costs.
when they hand out authoritative content to recursive servers, they will
find that some recursive servers will honor the clarified subdomain
semantics of nxdomain and others will not. this is not an
interoperability problem, but it's a very real problem well deserving
our attention here.
however, how you'd go about justifying the removal of all rrsets at some
name when you learn that this name does not exist, without also removing
all rrsets of all subdomains, will be interesting.
if i had rrsets cached at a name, and then i heard an nxdomain for that
name, and then that nxdomain expired, i would not "feel alright about"
answering with the old rrsets. why would subdomains be different?
This is all certainly true as far as it goes. However, if every
NXDOMAIN requires a full cache traversal, as it will for any hashed
cache with the restriction you've proposed, then NXDOMAIN suddenly
becomes a _really_ powerful DoS attack. ...
you're distracting me. i used to be a programmer and this is an
interesting problem. as others have pointed out up-thread, you don't
have to do the purge at nxdomain time; you can purge lazily when you are
responding on an affected qname; or you can purge never and just send
the nxdomain instead of the unreachable content, and let the unreachable
content expire naturally (TTL or LRU or whatever.) or you can refactor
your cache to be a hierarchy of hash tables rather than a flat hash table.
however, back to the topic at hand, the implementation costs are not
germane to system correctness. if nominum CNS and/or nlnetlabs Unbound
can't implement the clarified nxdomain semantics, then they just won't.
your customers and your investors can decide what this means to them.
note that interposing a new zone cut should ideally also cause a purge,
either real or effective. this is nowhere written down, but has the same
reasoning: a new authority ought to be given a fresh chance to populate
caches. this is related to, and similar to, but not the same as the
ns-rrset reverification logic proposed in resimprove-00, and will cause
very similar implementation problems for flat-hash caches.
It is worth noting that there's a generally accepted principle,
which has been tossed in my face one or two times on this mailing
list, that the DNS is not required to be consistent. ...
inconsistency is in that sense a known hazard, but not a benefit. we
call the system "best efforts" because we know it won't be consistent
but we want everyone involved to do their best anyway.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
