In message <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=odly...@mail.gmail.com> , =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes: > > On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <e...@isc.org> 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.
Guess what, resolvers do not work like that. They are not required to work like that. They are however required to search if CD=0. SERVFAIL should be a rare event. SERVFAIL that gets fixed with CD=1 and then validates successfull should be a even much rarer event. We know that there are cases where some of the authoritative servers broken DNSSEC wise yet you want to optimise for the bad time / trust anchor in the recursive server. > 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 > > --001a11c2a20c040b1504f60880b6 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">= > On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <span dir=3D"ltr"><<a href=3D"= > mailto:e...@isc.org" target=3D"_blank">e...@isc.org</a>></span> wrote:<b= > r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= > 1px #ccc solid;padding-left:1ex"> > On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:<br> > > DNSSEC is a mitigation against spoofed responses, man-in-the-middle<br= > > > > interception-and-rewriting and cache compromises. These threats are<br= > > > > endpoint and path specific, so it's entirely possible that one of = > your<br> > > resolvers (or its path) has been compromised, but not others. If all o= > f<br> > > your paths have been compromised, then there is no recovery; only<br> > > detection. But that is always true for DNSSEC.<br> > <br> > Consider the scenario in which one authoritative server for a zone<br> > has been compromised and the others have not, and that one happens to<br> > have the lowest round-trip time, so it's favored by your resolver.=A0</= > blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= > der-left:1px #ccc solid;padding-left:1ex"> > <br> > If you query with CD=3D0, a validating resolver detects the problem<br> > and tries again with another auth server. =A0It doesn't give up until<b= > r> > the whole NS RRset has failed.=A0</blockquote><blockquote class=3D"gmail_qu= > ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= > "> > <br> > If you query with CD=3D1, you get the bogus data and it won't validate.= > <br></blockquote><div>=A0</div><div>I don't think this makes much sense= > for a coherent resolver. If I were writing a resolver, the behaviour would= > instead be; =A0try really hard to find a valid response, exhaust every rea= > sonable possibility. If it can't get a valid response, then if CD=3D1 i= > t's ok to pass back the invalid response and its supposed signatures - = > maybe the stub will no better, at least fail open. If CD=3D0, then SERVFAIL= > , fail closed.=A0</div> > <div><br></div><div>Although CD means "checking disabled", I woul= > dn'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 preser= > ve effectiveness as a cache, and pass on what's needed to validate even= > the failure cases.=A0</div> > <div><br></div></div><div><br></div>-- <br>Colm > </div></div> > > --001a11c2a20c040b1504f60880b6-- > > > --===============8417192190596279555== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --===============8417192190596279555==-- > -- 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