Hi Mark, Thanks for your response.
On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews <[email protected]> wrote: > 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. > Can you elaborate on this a bit? I.e., if I sent DO + CD, then won't I just get an unfiltered view and be able to sort it out locally? What am I missing? -Ekr 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
