On Apr 1, 2014, at 10:24 PM, Colm MacCárthaigh <[email protected]> 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, [email protected] full 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
