You should also note that a validating stub resolver (or anything talking through a validating resolver) should be prepared to send *both* DO and DO+CD queries. There are different error conditions / threats that are mitigated by each of these settings and only by trying the other on error can you ensure that you have mitigated both.
If the validating resolver is being sent spoofed/erroneous traffic DO will filter that traffic out of the response stream. DO+CD works around bad time/trust-anchors in the validating resolver. Mark > On 7 Oct 2021, at 10:47, Eric Rescorla <[email protected]> wrote: > > Hi folks, > > We've been trying to take some measurements of the success of endpoint > DNSSEC validation and run into some confusion about the implications > of the DO and CD bits. Sorry if these are dumb questions. > > In the section on stub resolvers RFC 4035 says: > > A validating security-aware stub resolver MUST set the DO bit, > because otherwise it will not receive the DNSSEC RRs it needs to > perform signature validation. (S 4.9.1) > > and: > A validating security-aware stub resolver SHOULD set the CD bit, > because otherwise the security-aware recursive name server will > answer the query using the name server's local policy, which may > prevent the stub resolver from receiving data that would be > acceptable to the stub resolver's local policy. (S 4.9.2) > > > And then in S 5, says: > When a resolver indicates support for DNSSEC (by setting the DO bit), > a security-aware name server should attempt to provide the necessary > DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). > > > 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? > > Reading the above text, I infer that this signal is the DO bit. This > should cause the recursive to deliver the right RRsets (if available) > (I note that this text just says "name server" from which I'm > inferring that it applies to both authoritative and recursive). Is > this correct? If so, is the fact that this is "should" and not > "SHOULD" telling me something"? > > Finally, as I understand it, the function of the CD bit is to tell the > recursive resolver to return records even it if cannot validate them > itself. However, it does *not* tell the recursive resolver to send the > RRsets in the first place, as that's the function of CD. > > > Summarizing all this, I have the following table of what the stub > should expect to receive if the recursive is a validating resolver and > it asks for an A record (just as an example) > > > Bits set Records valid Records invalid > ----------------------------------------------------- > None A + ??? Error > DO A + DNSSEC Error > CD A + ??? A + ??? > DO + CD A + DNSSEC A + DNSSEC > > Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???" > means "A + maybe some DSNSSEC records depending on what the recursive > wants". > > Thanks in advance, > -Ekr > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
