Hi, Disclaimer: I work for the Internet Society but am speaking for myself.
On Wed, Oct 06, 2021 at 04:47:32PM -0700, Eric Rescorla wrote:
Sorry if these are dumb questions.
They are not dumb questions, unfortunately.
Looking at things from the stub resolver's perspective, if the zone is signed, then the stub resolver must receive the necessary RRsets or fail the resolution. So, there needs to be an unambiguous way for the stub to tell the recursive to deliver them. Am I right so far?
You are right. The problem is that the protocol is exactly ambiguous enough, in my reading, that there isn't a way to ensure that happens. RFC 6840 attempted to clarify a number of things, but there are IMO two gaps in it. First of all, it is apparent that if a resolver maintains a unified cache in which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely break. The general wisdom appears to be that you need to maintain two caches, and only answer DO-set queries with DO-set cache (or go fetch); but if there's ever been explicit protocol requirement of this, I have forgotten it. The upshot is that it is entirely possible for a cache to have some but not all the DNSSEC data to answer a query, and to respond with what it has, and I know I have seen this in the wild. Much worse is the continued confusion around CD, which 6840 tried pretty hard to sort out but that seems to remain a dark corner of the protocol. The reality is that the SHOULD about setting CD in 6840 probably has to be a MUST or else stuff will almost certainly break. For some reason I now don't recall, some people wanted to be able to select a policy in which they didn't set CD even though it was the only way the validating stub would actually get everything it needed. This is laid out in some detail in Appendix B, but the result is still not that satisfying to someone who wants predictable behaviour our of the validated resolution system. Hope that's helpful, A -- Andrew Sullivan [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
