On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <[email protected]> wrote: > On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote: > > DNSSEC is a mitigation against spoofed responses, man-in-the-middle > > interception-and-rewriting and cache compromises. These threats are > > endpoint and path specific, so it's entirely possible that one of your > > resolvers (or its path) has been compromised, but not others. If all of > > your paths have been compromised, then there is no recovery; only > > detection. But that is always true for DNSSEC. > > Consider the scenario in which one authoritative server for a zone > has been compromised and the others have not, and that one happens to > have the lowest round-trip time, so it's favored by your resolver.
> If you query with CD=0, a validating resolver detects the problem > and tries again with another auth server. It doesn't give up until > the whole NS RRset has failed. > If you query with CD=1, you get the bogus data and it won't validate. > I don't think this makes much sense for a coherent resolver. If I were writing a resolver, the behaviour would instead be; try really hard to find a valid response, exhaust every reasonable possibility. If it can't get a valid response, then if CD=1 it's ok to pass back the invalid response and its supposed signatures - maybe the stub will no better, at least fail open. If CD=0, then SERVFAIL, fail closed. Although CD means "checking disabled", I wouldn't actually disable checking, simply because that's stupid (I don't mean to be impolite, but I don't have a better word to use here). But by preserving the on-the-wire semantics of the CD bit, I'd preserve effectiveness as a cache, and pass on what's needed to validate even the failure cases. -- Colm
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
