On 2012-04-15 4:20 PM, Stephan Lagerholm wrote: > ... However, the open resolvers that don't support DNSSEC are a bigger > "issue" since the Service Providers' customer instantly can get what > he believes is a better working resolver by switching to one of those. > If we could convince 8.8.8.8 (208.67.222.222 and 4.2.2.1) to turn on > DNSSEC validation, then there would not be any need for NTAs. ...
dnssec makes dns less reliable. that's because it's a security technology not a resiliency technology. security makes things harder to use and makes failures more apparent. in the real world if you put a lock on your house or your car then you're at risk for forgetting or losing your key and not being able to enter or use your own property. you could mitigate that risk by removing the lock but then you'd have other risks. what's unique about dnssec is that if you lose your key or use the wrong key or forget to re-sign your zones then it's not you (the property owner) who cannot enter or use the zones, but rather, everybody else. i don't think that asymmetry of cost changes the fundamentals. the operators of 8.8.8.8 and so on (from the above examples) may have done a cost:benefit analysis leading them to not deploy dnssec validation at this time. that will make their systems more reliable in the eyes of end users. that's true and that's inevitable. i'm imagining that some NTA-using party notices via their syslogs that validation is failing for some zone, and believing that access to this zone in an unsecure way has a better cost:benefit ratio to them and to their own customers than letting the failure propagate and so enters the zone into the NTA... only to have it turn out later that there was a key compromise and the failure was due to a credential or key or system attack rather than due to someone forgetting or losing their key. people who sign their zones must be told, early and often, that adds risk. they will have to re-sign their zones before signatures expire, they will have to carefully coordinate key changes with their parent zone, they will have to keep their signing key under secure but redundant control... and any failure by them to do any of those things will make their zones unreachable by a large and growing audience. if they sign anyway then any resulting failures have to be laid at their doorstep, not at validating server operators' doorsteps. if a secure application knows that a zone is supposed to be signed (because there are DS RRs in the parent and the parent is signed) then an upstream NTA will just look like a signature-stripping attacker. let us not imagine that there will never be secure applications other than recursive name servers (and here i'm thinking of DANE), and let us also not imagine that every secure application (here i'm again thinking of DANE) will have to subscribe to a trusted NTA. dnssec is end to end, including dnssec failures, which are statistically inevitable. i'd tell validator operators who think they need NTA's in order to control the risks posed by zone owner errors, "if you can't stand the heat then stay out of the kitchen." see also <http://www.circleid.com/posts/defense_in_depth_for_dnssec_applications/>. paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
