Hacker News Reader

> MitM upstream from resolver

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...)

The problem with DoH is that it reinforces the certificate hegemony.

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.

And those certificates are so expensive!

> * Resolver cache poisoning > * MitM upstream from resolver

Only for clients that do DNSSEC validation. Ignoring the additional latency it comes with, virtually no home routers nor operating systems do.

This is a super important point! The parent post, which is quite good, forgets the qualifier that in practice DNSSEC is exclusively a server-to-server protocol: it's what your DNS server uses to attempt to authenticate records from other servers. But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures".

It's wild that we're even considering rolling more of this out in 2023.

> But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures".

Clients absolutely do get RRSIGs (and relevant NSEC/NSEC3) however they don't necessarily validate them.

> That's it. That is all that DNSSEC does.

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.

DANE isn't happening. Browsers tried a decade ago and gave up: https://www.imperialviolet.org/2015/01/17/notdane.html

> DANE isn't happening. Browsers tried a decade ago and gave up

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.

The major mail vendors came up with MTA-STS specifically to avoid having to roll out DNSSEC.

In both cases what it boils down to is that "it's an alternative to the current CA system". Sure, alternatives are good, but why does it need to be coupled to DNS? If I have a .ly domain, do I really want to be forced to trust the Libyan government for my security?

What do think a ccTLD is, if not a TLD controlled by a country, meaning the government of that country? In what world would it be reasonable for you to have a .ly domain and not trust the Libyan government not to do whatever they like to your domain? Like, you know, everybody already does with every .com and the U.S. government?

But that is exactly the point: in the world we are in right now, I DON'T have to trust the TLD operator to make sure my services are secure. Sure, there is a risk that the TLD operator will shut down my domain completely, but that is a different risk from the TLD operator MitM-ing my services.

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?

> 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.

Under today's CA system the gov't can't MiTM without getting noticed on the certificate transparency logs. There's no equivalent for DNSSEC.

> made worse by DNSSEC:

> * 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.

NSEC5 is a research paper, not a deployed standard. But thanks for calling this out, because it gives us an opportunity to reflect on the fact that, confronted with the problem of enumerable sensitive DNS labels, the best cryptographic minds of the IETF DNS working group came up with a 1990s password file.

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.

> they wouldn't have done NSEC3

Anecdotally, NSEC3 was known at its inception to be insufficient but done anyway to hush privacy advocates.

Definitely seems like a super good-faith effort.

I am simply not going to respond to accusations that I am arguing in bad faith and gaslighting. Please do better.

"DNS names aren't supposed to be secret" is not a good faith argument. It's not your argument: it is a popular trope of DNSSEC advocates. I don't mean to imply anything about you personally --- you're an anonymous abstraction to me, so there's nothing I could reasonably say about you as a person. But the argument you're making is what it is, and I've characterized it, I believe, accurately.

Later

I edited this slightly to make clear that I'm characterizing a trope, not an HN thread.

> "DNS names aren't supposed to be secret" is not a good faith argument.

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, incredibly, doubling down on calling my argument a bad faith argument (instead of responding to it), I have no recourse but to leave it at that.

I'm comfortable with the thread as it stands as well.

> Meanwhile, here's some attacks or concerns that are actually seen in the real-world and which DNSSEC does nothing for:

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.