DNSSEC also does not press your suit or iron your shirt. How is this a criticism against DNSSEC? A security technology can not possibly solve all problems, and not solving some specific problems should never be a strike against it.
> * DNS Amplification DDoS
Not really; with SPF, huge TXT records are all over the place, and can be used instead of having to use RRSIG records.
> * DNS server denial of service (on-the-fly signing or validating signed responses adds non-trivial overhead)
People said this about HTTPS, too. They were wrong.
> * Zone enumeration (NSEC and NSEC3 are hilarious)*
Firstly, NSEC5. Secondly, no secret data should be in DNS. It’s not designed for it.
> * DNS server compromise through RCE exploits (not exclusive to DNSSEC, but handling signed responses adds a lot of complexity to servers and almost all DNS RCE exploits we've seen recently have been in the DNSSEC handling part)*
Not on the authoritative server side, surely? Sounds like a DNS resolver problem.
One of the ways you can tell that DNSSEC advocates are operating in bad faith is by catching them attempting to argue that nothing in the DNS is secret to begin with. First, that's obvious gaslighting; disabling public zone transfers has been a security best practice since the mid-1990s, and no network security audit would fail to flag you for enabling them. Second, if the DNSSEC advocates actually believed that, they wouldn't have done NSEC3, whitelies, and (now, apparently, at some point in the distant future, NSEC5).
Can't have it both ways on this.
Later
I edited this slightly to make clear that I'm characterizing a trope, not an HN thread.
Yes it is. Here I am, making it. It’s not even about DNSSEC; it has been the truth ever since the DNS itself was designed. Having secret data in DNS is doomed to fail in any number of ways, since DNS was never designed for it.
And you can’t get away with claiming “Oh, I wasn’t calling you a bad faith gaslighter, only other people. Who are making the same argument as you. And I am saying this in a reply to your comment for no reason in particular.”
Since you are doubling down on calling my argument a bad faith argument, I have no recourse but to leave it at that.
Anecdotally, NSEC3 was known at its inception to be insufficient but done anyway to hush privacy advocates.
Thus providing an interesting foundation to build upon, for example DANE or SSHFP. Not very known or common things, but they show the potential of what is possible when there's a way to publish cryptographically authenticated records in DNS.
If my CA misbehaves? I can use a different CA. Not trivial, but doable. What if my TLD operator misbehaves or TLD changes ownership (like the .org case a few years ago) - change my domain?
That already happens all the time. And when it does happen, the new owner can get a legitimate certificate for it.
DANE was never limited to browsers. Example:
https://ssl-tools.net/mailservers/proton.me
Though support in that space is very patchy as well and maybe going nowhere. In any case, it serves as an example that DNSSEC can be built upon, even if the new ideas don't necessarily make it.
And even this part is also mostly solved by DoH. (Unless someone can mitm you and spoof certificates, which means you're targeted by some organisations with serious resources...)
Anyone can set up DNSSEC and run it without applying for authorisation from another party. But DoH requires a certificate signed by a CA trusted globally.
Only for clients that do DNSSEC validation. Ignoring the additional latency it comes with, virtually no home routers nor operating systems do.
It's wild that we're even considering rolling more of this out in 2023.
Clients absolutely do get RRSIGs (and relevant NSEC/NSEC3) however they don't necessarily validate them.