DNSSEC is a PKI run by governments. If DNSSEC had been deployed and used to run the TLS PKI a couple years ago, Ghadafi would have effectively controlled Bit.ly's SSL keys.
DNSSEC is a debacle. Reprising an older comment:
* Amazingly, contrary to everything you'd expect about "secure DNS", DNSSEC does not in fact secure DNS queries from your machine. Instead, it delegates securing DNS to DNSSEC-enabled resolver servers. For securing the actual queries your computer makes, your browser is on its own. There's a whole different protocol, TSIG, intended to address that problem.
* DNSSEC has zero successful real-world deployments, and no existing integration with any TLS stack. DNSSEC obviously does nothing to secure your actual traffic; all it does is try to protect the name lookup. TLS protects both.
* DNSSEC does nothing to address all the other intercepts, from ARP to BGP4, that real traffic has to contend with. Once you go from name to IP address (or "cert" in the fairytale world where DNSSEC has replaced the CAs), you're on your own. TLS addresses all of these issues except for CA configuration.
* DNSSEC actually reduces the security of DNS in some ways: in order to authenticate "no such host", DNSSEC publishes a sort-of-encrypted list of all your hosts. There's a whole other standards group drama surrounding the proposals to resolve this problem (NSEC3, whitelies, etc).
* DNSSEC fails badly compared to TLS. When keys inevitably get screwed up in TLS, you get a browser click-through. There is no API support to recover from a "gethostbyname()" failure caused by DNSSEC. This sounds like a reliability problem, but it's actually a security problem, in the same sense as "the little blue key icon isn't big enough" is a security problem for SSL. We just don't know what the exploit is, because nobody has designed the "solution" for this problem.
* TLS has 15+ years of formal review (it is the most reviewed cryptosystem ever published). We still find things in it. DNSSEC has received nothing resembling the same scrutiny. It's ludicrous to believe we won't find horrible problems with it. You'd be asserting that a protocol co-designed by Paul Kocher will eventually fare worse than one designed by the IETF DNS working group. The IETF DNS working group would basically have to crush some of the smartest practical crypto people in the world.
* TLS is at least configurable (virtually all TLS problems are in fact user interface and configuration problems, not problems with the underlying system). You can nuke untrustworthy CAs. There is no clean way to opt in or out of different DNSSEC policies, as the drama surrounding DLV illustrates.
In the '90s, we designed web security to assume that DNS was insecure. That was a smart decision. "Security" means different things to different people. It's a policy decision. The end-to-end argument strongly suggests that it's something that can't be baked into the lower parts of the stack. DNSSEC is a step backwards. I think you can already see the indications of the problems it will cause just by looking at the places it already falls down.
What we need is a concerted effort to solve the security UI and policy problems that browsers have.
If you're looking for protocol-level remediation for TLS's current CA policy problem, you want to pay attention to TACK:
DNSSEC is a debacle. Reprising an older comment:
* Amazingly, contrary to everything you'd expect about "secure DNS", DNSSEC does not in fact secure DNS queries from your machine. Instead, it delegates securing DNS to DNSSEC-enabled resolver servers. For securing the actual queries your computer makes, your browser is on its own. There's a whole different protocol, TSIG, intended to address that problem.
* DNSSEC has zero successful real-world deployments, and no existing integration with any TLS stack. DNSSEC obviously does nothing to secure your actual traffic; all it does is try to protect the name lookup. TLS protects both.
* DNSSEC does nothing to address all the other intercepts, from ARP to BGP4, that real traffic has to contend with. Once you go from name to IP address (or "cert" in the fairytale world where DNSSEC has replaced the CAs), you're on your own. TLS addresses all of these issues except for CA configuration.
* DNSSEC actually reduces the security of DNS in some ways: in order to authenticate "no such host", DNSSEC publishes a sort-of-encrypted list of all your hosts. There's a whole other standards group drama surrounding the proposals to resolve this problem (NSEC3, whitelies, etc).
* DNSSEC fails badly compared to TLS. When keys inevitably get screwed up in TLS, you get a browser click-through. There is no API support to recover from a "gethostbyname()" failure caused by DNSSEC. This sounds like a reliability problem, but it's actually a security problem, in the same sense as "the little blue key icon isn't big enough" is a security problem for SSL. We just don't know what the exploit is, because nobody has designed the "solution" for this problem.
* TLS has 15+ years of formal review (it is the most reviewed cryptosystem ever published). We still find things in it. DNSSEC has received nothing resembling the same scrutiny. It's ludicrous to believe we won't find horrible problems with it. You'd be asserting that a protocol co-designed by Paul Kocher will eventually fare worse than one designed by the IETF DNS working group. The IETF DNS working group would basically have to crush some of the smartest practical crypto people in the world.
* TLS is at least configurable (virtually all TLS problems are in fact user interface and configuration problems, not problems with the underlying system). You can nuke untrustworthy CAs. There is no clean way to opt in or out of different DNSSEC policies, as the drama surrounding DLV illustrates.
In the '90s, we designed web security to assume that DNS was insecure. That was a smart decision. "Security" means different things to different people. It's a policy decision. The end-to-end argument strongly suggests that it's something that can't be baked into the lower parts of the stack. DNSSEC is a step backwards. I think you can already see the indications of the problems it will cause just by looking at the places it already falls down. What we need is a concerted effort to solve the security UI and policy problems that browsers have.
If you're looking for protocol-level remediation for TLS's current CA policy problem, you want to pay attention to TACK:
http://tools.ietf.org/html/draft-perrin-tls-tack-00
This is Trevor Perrin and Moxie Marlinspike.