TLS isn't simply better than DNSSEC: DNSSEC still requires TLS. If you use just DNSSEC, and you stipulate that DNSSEC does what it's supposed to do (spoiler: it doesn't) then all you've done is protect your DNS lookup. So TLS is a non-optional component in the web stack even in the very unlikely event DNSSEC is deployed.
So the problems with DNSSEC then boil down to:
* TLS isn't designed to depend on the security of the DNS. How you know that is, TLS works today, and nobody uses DNSSEC. So if everything needs TLS anyways, why forklift in a new DNS when we could instead work on making TLS better?
* DNSSEC actually degrades the DNS. In a couple ways. First, DNSSEC changes the security model of DNS records; they're now signed, but also they're public. For a long time, DNSSEC advocates claims that DNS records were always public, but that's clearly not true; try to dump Bank of America's zone files. When the advocates lost the argument, they introduced a grotesque hack that turned DNS zones into crackable password files (this is "NSEC3"). That's just one example; there are better examples.
There is a proposed alternative to DNSSEC that I like: DNSCurve. DNSCurve gives up on the idea of signing DNS records and instead just allows any DNS client to create a secure connection to any DNS server. That's a totally sane improvement to the DNS which inexplicably isn't included in DNSSEC (your DNS lookups in a DNSSEC world are still unprotected!). We should do that instead of DNSSEC.
>So if everything needs TLS anyways, why forklift in a new DNS when we could instead work on making TLS better?
For one thing, not everything uses TLS (even if it should). TLS normally requires support by the application, securing DNS could be done in the OS. You could fix DNS and have at least that fixed even for all the legacy applications that nobody is ever going to update to use TLS. It would also make IPSec easier to deploy to the same effect because it would allow the DNS to be used for key distribution. And likewise for distributing ssh host keys.
I'll give you that DNSSEC is poorly designed, but I don't necessarily want "DNSSEC" in particular, I'm just looking for something that allows client devices to securely verify DNS query responses. Does DNSCurve do that? The Wikipedia entry doesn't clearly distinguish whether it's securing the connection to the server or the query response. In other words, does DNSCurve allow you to detect if your ISP's DNS resolver is compromised?
So the problems with DNSSEC then boil down to:
* TLS isn't designed to depend on the security of the DNS. How you know that is, TLS works today, and nobody uses DNSSEC. So if everything needs TLS anyways, why forklift in a new DNS when we could instead work on making TLS better?
* DNSSEC actually degrades the DNS. In a couple ways. First, DNSSEC changes the security model of DNS records; they're now signed, but also they're public. For a long time, DNSSEC advocates claims that DNS records were always public, but that's clearly not true; try to dump Bank of America's zone files. When the advocates lost the argument, they introduced a grotesque hack that turned DNS zones into crackable password files (this is "NSEC3"). That's just one example; there are better examples.
There is a proposed alternative to DNSSEC that I like: DNSCurve. DNSCurve gives up on the idea of signing DNS records and instead just allows any DNS client to create a secure connection to any DNS server. That's a totally sane improvement to the DNS which inexplicably isn't included in DNSSEC (your DNS lookups in a DNSSEC world are still unprotected!). We should do that instead of DNSSEC.