On Apr 13, 2012, at 1:24 PM, Patrik Fältström wrote: > > On 13 apr 2012, at 22:09, Evan Hunt wrote: > >> On Fri, Apr 13, 2012 at 05:43:42PM +0000, Paul Vixie wrote: >>> i'm opposed to negative trust anchors, both for their security >>> implications if there were secure applications in existence, and for >>> their information economics implications. >> >> +1 > > +1
-1 Simply put, I'm not a huge believer of recursive resolver (rather than client) validation. But if you are going to do it... There are a few cases where it is valuable [1], but for every 'validate is the right answer', there are hundreds of cases, like the NASA case, where the authority is just screwing up. And in those cases, the economics are that DNSSEC is creating a DOS, and it is the one who's validating that's at least partially responsible because it is both validating and deciding that its clients should suffer. This is especially true for ISPs. If you want any other ISP to validate DNSSEC, they need a mechanism like this so they don't suffer through the problems that Comcast has already experienced. Because practice has shown that it is the recursive resolver, not the authority, that gets blamed. Lurk on the Google Public DNS mailing list, and you realize that even without DNSSEC, the resolver operator faces the blame for brokenness. Thus, at least for DNSSEC, resolver operators need to be able to override validation easily and efficiently. [1] And these cases require 'listen until you can get something that validates': Just accept then validate gives the wrong answer in these cases. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
