* DNSSEC bakes a hierarchical PKI controlled at the roots by world governments into the core of Internet connectivity, in a way that can't be policy-controlled by users.
* DNSSEC has a poorly-thought-out interaction with Internet security and security policy; when TLS validation fails, users get a click-through that allows them to proceed to the site anyways. No similar state machine is built into the overwhelming majority of programs that do DNS lookups. As a result, if anything goes wrong with your DNSSEC configuration, you will more or less vanish from the Internet. "gethostbyname()" doesn't include a popup dialog feature.
* Mainstream deployments of DNSSEC are based on 1990s crypto, including PKCS#1v1.5 RSA padding; at exactly the moment when the rest of the Internet is transitioning away from crappy old RSA protocols, DNSSEC doubles down on it.
* DNSSEC leaks internal hostnames to the Internet because the designers of the protocols prioritized authenticated denials (availability) over confidentiality. NSEC3 is a great illustration of how slapdash the protocol design is: in an attempt to plug that leak, the IETF standardized what is in effect a password hash (and a bad one) to help obscure internal hostnames. When challenged on why the Internet should adopt a 1990s password hash as an Internet core protocol security mechanism, DNSSEC proponents say, "well, well-managed domains make domain cuts carefully to solve this problem", as if any commercial network in the world actually does that.
* DNSSEC creates yet another huge amplifier for DDoS attacks, allowing trivially small requests to elicit gigantic responses from servers.
Now, two fun things to know about all these problems:
1. They are, unlike your citation of crappy CAs, baked in design flaws in the protocol. You can evict a CA that misbehaves or isn't careful about validation. The EFF or ACLU could run a program that would allow people to subscribe to a trusted subset of CAs. None of that is possible in DNSSEC, because DNSSEC's problems aren't implementation or deployment problems, but rather fundamental attributes of the system.
* For all its flaws, DNSSEC doesn't actually protect queries from end systems to servers: it is a server-to-server system that leaves end-user DNS queries unprotected and spoofable.
I don't think this system is something we need "yesterday".
I have a lot of random opinions and thoughts about things, including security things, that I come to because discussions in places like HN prompt me to develop those opinions. DNSSEC is not one of those things. I've been following DNSSEC standardization since... well, since DNSSEC was an effort of TIS Labs, which was owned by my employer, where I was building DNS security testing tools. I've particularly followed namedroppers since the early 00's, when the list drove Daniel Bernstein away from DNS standardization.
* DNSSEC bakes a hierarchical PKI controlled at the roots by world governments into the core of Internet connectivity, in a way that can't be policy-controlled by users.
* DNSSEC has a poorly-thought-out interaction with Internet security and security policy; when TLS validation fails, users get a click-through that allows them to proceed to the site anyways. No similar state machine is built into the overwhelming majority of programs that do DNS lookups. As a result, if anything goes wrong with your DNSSEC configuration, you will more or less vanish from the Internet. "gethostbyname()" doesn't include a popup dialog feature.
* Mainstream deployments of DNSSEC are based on 1990s crypto, including PKCS#1v1.5 RSA padding; at exactly the moment when the rest of the Internet is transitioning away from crappy old RSA protocols, DNSSEC doubles down on it.
* DNSSEC leaks internal hostnames to the Internet because the designers of the protocols prioritized authenticated denials (availability) over confidentiality. NSEC3 is a great illustration of how slapdash the protocol design is: in an attempt to plug that leak, the IETF standardized what is in effect a password hash (and a bad one) to help obscure internal hostnames. When challenged on why the Internet should adopt a 1990s password hash as an Internet core protocol security mechanism, DNSSEC proponents say, "well, well-managed domains make domain cuts carefully to solve this problem", as if any commercial network in the world actually does that.
* DNSSEC creates yet another huge amplifier for DDoS attacks, allowing trivially small requests to elicit gigantic responses from servers.
Now, two fun things to know about all these problems:
1. They are, unlike your citation of crappy CAs, baked in design flaws in the protocol. You can evict a CA that misbehaves or isn't careful about validation. The EFF or ACLU could run a program that would allow people to subscribe to a trusted subset of CAs. None of that is possible in DNSSEC, because DNSSEC's problems aren't implementation or deployment problems, but rather fundamental attributes of the system.
* For all its flaws, DNSSEC doesn't actually protect queries from end systems to servers: it is a server-to-server system that leaves end-user DNS queries unprotected and spoofable.
I don't think this system is something we need "yesterday".
I have a lot of random opinions and thoughts about things, including security things, that I come to because discussions in places like HN prompt me to develop those opinions. DNSSEC is not one of those things. I've been following DNSSEC standardization since... well, since DNSSEC was an effort of TIS Labs, which was owned by my employer, where I was building DNS security testing tools. I've particularly followed namedroppers since the early 00's, when the list drove Daniel Bernstein away from DNS standardization.