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 <e...@rtfm.com> wrote: > > Hi Mark, > > Thanks for your response. > > On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews <ma...@isc.org> 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 <e...@rtfm.com> 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 >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
