> no. it's not an interoperability matter. If it's not an interoperability matter, then there shouldn't really be any normative language.
> 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. The best part is that there don't even have to be any entries in the cache to prune: every time you get an NXDOMAIN you're going to have to traverse the whole hash. So all I have to do to bring a server to its knees is send it a bunch of queries for names in .COM that don't exist. This is _seriously_ not a good idea. 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. A zone's contents for any serial number are expected to be the same, but caches don't cache zones--they cache answers. At the level of answers, as opposed to zones, consistency is always on a best-effort basis. Arguing that not pruning the tree when you get an NXDOMAIN is inelegant isn't sufficient to justify the proposed normative language, true though it may be. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
