Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
On Wed, Apr 2, 2014 at 2:40 PM, Mark Andrews wrote: > > 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. Nothing can compel any particular resolver to choose a particular implementation - but I take note of https://tools.ietf.org/html/rfc6840#section-5.9 and https://tools.ietf.org/html/rfc6840#appendix-B which recommends it (as a "SHOULD") and I generally agree with the good reasoning that's in the RFC. As I wrote, if it were me writing a validating stub resolver, I would always set CD=1 - and when acting as an intermediate resolver, I would always make a reasonable effort to find a validating response, even if CD=0 is on the incoming query. I'm certain that at least one resolver does work like this, and I suspect it's also how Google Public DNS works, based on some experimentation. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
In message , =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes: > > On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt 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 > > = > On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt < mailto:e...@isc.org"; target=3D"_blank">e...@isc.org> wrote: r> 1px #ccc solid;padding-left:1ex"> > 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 o= > f > > 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.=A0 blockquote> der-left:1px #ccc solid;padding-left:1ex"> > > If you query with CD=3D0, a validating resolver detects the problem > and tries again with another auth server. =A0It doesn't give up until r> > the whole NS RRset has failed.=A0 ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= > "> > > If you query with CD=3D1, you get the bogus data and it won't validate.= > =A0I 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 > 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 > -- Colm > > > --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.,
Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
On Apr 1, 2014, at 10:24 PM, Colm MacCárthaigh wrote: > > 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. The bigger problem is not the CD case, but getting the data at all to validate locally. A lot (and I mean a LOT) of NATs give a DNS proxy that doesn't understand or forward requests for DNSSEC information. Heck, even Apple (which in my opinion makes the best overall CPE) doesn't do this right. These NATs don't give the IP of the real recursive resolver, which often does support DNSSEC (and, in the case of Comcast, even validates). Which means you have to go around and do a full local fetch, starting at the root and going down from there to validate on the client. And then, to make matters worse, you have the hotspots and similar cases which force the user to use the configured recursive resolver. Fortunately, most of those support fetching DNSSEC records. But note that I said most, not all -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
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. If you try again, you'll get the same bogus data out of the cache. Use a different resolver, and if it happens to use the same auth server, then the same thing happens again. Your best chance of getting an answer that you can validate is to send CD=0 to a recursive resolver that is itself validating. If you get SERVFAIL, *then* you try with CD=1, and if the result validates, you know it was the resolver that was broken rather than the data. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
