Thanks for the explanation. That's super helpful. -Ekr
On Fri, Oct 8, 2021 at 1:19 PM Mark Andrews <[email protected]> wrote: > > > Yes it will be unfiltered but the point of DNSSEC is to filter out bad > answers (that is what the ignore bogus responses achieves) and if you are > behind a recursive server you need it to do the filtering of the answers it > gets as you aren’t in a position to wait for the good answer as they won’t > come to you nor are you in the position to ask the authoritatives > directly. It can wait for good answers by just rejecting the spoofed > answers and continuing to listen for the real answer. > > -- > Mark Andrews > > On 9 Oct 2021, at 06:12, Eric Rescorla <[email protected]> wrote: > > > 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
