DNSSEC suffers from the zone exposure problem because its design was, for many intents and purposes, nailed down in the 1990s based on assumptions about cryptography from the 1990s. Specifically:<p>* DNSSEC was designed to assume that keys would be kept offline, because online signatures were thought not to be performant enough†.<p>* DNSSEC was designed to provide authenticated denial, because it was designed during a time when support protocol maintainers believed they needed built-in countermeasures for high-level DOS attacks.<p>The assumption behind these design goals are both dubious, but particularly noxious when combined.<p>There is more wrong with DNSSEC than NSEC3, for whatever it's worth; for instance, start with the fact that it's based on RSA PKCS1v15; until recently (last time I checked, within the last 18 months), the <i>root</i> of the hierarchy used 1024 bit keys.<p>These are, of course, technical issues. There's a fundamental Internet design problem with DNSSEC, too, which is that the roots of the DNS hierarchy are overwhelmingly controlled by world governments. DNSSEC is, at bottom, a centralized PKI dominated by the US Government.<p>But don't worry, this is only what DNS advocates want you to store your TLS keys in.<p>The entire security model for the Internet has been tuned for the last 15 years <i>not to assume the DNS was secure</i>. DNSSEC does not in any meaningful way exist today. If your most important adversary is the kind of online criminal that might employ DNS redirection to steal your credit cards, the risk/reward for DNSSEC might arguably make sense (I think you'd lose that argument, though). If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC's absence.<p>† <i>(this believe has since been retconned into a belief that keeping keys online is "insecure", which is Rosencrantz and Guildernstern-style amusing given that DNSSEC controls only hostname mappings and that virtually every other system that protects</i> content <i>does keep keys online)</i>
Design by committee generally leads to poor results. A much better approach is the competition method, where e.g. the public is asked for proposals to secure DNS as in the AES, eSTREAM, PHC, and CAESAR competitions.<p>DNSSEC was not "design by committee" -- it was "design by multiple committees, all stuck in the 1990s." And this is what we get.<p>Personally I say: DNSCurve > DNS > DNSSEC. I would support a DNS security competition, even if DNSCurve (which I've deployed) were not selected. DNSSEC wouldn't stand a chance in a public competition.
I've been pretty down on DNSSEC due to the "baroque" nature of the whole thing (which this blog post shows); also, giving extra power to country-level ccTLDs vs. the slightly-more-independent SSL/x509 CAs.<p>However, DANE makes DNSSEC make sense in some cases, especially when you start using it for things other than web traffic. DNSSEC/DANE for STARTTLS SMTP would be a good improvement over the "no cert checking at all, and even cert failures are ignored" model today.