Why do we need DNSSEC?

I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously.

You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. You then use that specific control to get a CA to forge a certificate for you (and if the CA is capable of using any information to detect that this might be a forgery, the attack breaks).

And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking--impersonating somebody to the nameserver and getting the account switched over to them.

That quote is interesting because all of the period reporting I’ve seen says that the attackers did NOT successfully get an HTTPS certificate and the only people affected were those who ignored their browsers’ warnings.

https://doublepulsar.com/hijack-of-amazons-internet-domain-s...

https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/

DNSSec has caused so many outages at this point it's a joke.

You have to be so insanely careful and plan everything to the nth degree otherwise you break everything: https://internetnz.nz/news-and-articles/dnssec-chain-validat...

The idea is important. What it aims to protect is important. The current implementation is horrible, far too complex and fraught with so many landminds that no one wants to touch it.

If Geoff Huston is suggesting it might be time to stick a fork in DNSSec because it's done, then IMHO it's well cooked. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/

There are two things mixed up. "We need secure DNS" != "we need DNSSEC".

There is a huge demand for securing DNS-related things, but DNSSEC seems to be a poor answer. DoH is a somehow better answer, with any shortcomings it may have, and it's widely deployed.

I suspect that a contraption that would wrap the existing DNS protocol into TLS in a way that would be trivial to put in front of an existing DNS server and an existing DNS client (like TLS was trivial to put in front of an HTTP server), might be a runaway success. A solution that wins is a solution which is damn easy to deploy, and not easy to screw up. DNSSEC is not it, alas.

> It is important. This is unfortunate rhetoric that is harming the safety of the internet.

DNSSEC was built for exactly one use case: we have to put root/TLD authoritative servers in non-Western countries. It is simply a method for attesting that a mirror of a DNS server is serving what the zone author intended.

What people actually want and need is transport security. DNSCrypt solved this problem, but people were bamboozled by DNSSEC. Later people realized what they wanted was transport security and DoH and friends came into fashion.

BGP attacks change the semantic meaning of IP addresses themselves. DNSSEC operates at a level above that. The one place this matters in a post-HTTPS-everywhere world is at the CAs, which are now all moving to multi-perspective validation.

The argument counter dnssec is that if you are trying to find some random A record for a server, to know if it is the right one, TLS does that fine provided you reasonably trust domain control validation works i.e. CAs see authentic DNS.

An argument for DNSSEC is any service configured by SRV records. It might be totally legitimate for the srv record of some thing or other to point to an A record in a totally different zone. From a TLS perspective you can't tell, because the delegation happened by SRV records and you only know if that is authentic if you either have a signed record, or a direct encrypted connection to the authoritative server (the TLS connection to evil.service.example would be valid).

So it depends what you expect out of DNS.

Related:

- ECC vs. non-ECC memory and bitsquatting when people said "oh, it doesn't matter and it's too expensive for no benefit."

- http:// was, for years, normalized pre-PRISM.

- Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge spoofing and metadata collection threat surface.

As a joke, it’s not easily distinguishable from trolling and since IPv6 is approaching half of all traffic, more in many areas, the humor value is limited.

We very definitely do have IPv6. I'm using IPv6 right now. Last numbers I saw, over 50% of North American hits to Google were IPv6. DNSSEC adoption in North America is below 4%, and that's by counting zones, most of which don't matter --- the number gets much lower if you filter it down to the top 1000 zones.

If you want the net to support end to end connectivity we need IPv6. Otherwise you'll end up with layers and layers of NAT and it will become borderline impossible.

A lot of protocols get unstable behind layers of NAT too, even if they're not trying to do end to end / P2P. It adds all kinds of unpredictable timeouts and other nonsense.

In this case, there's an avalanche of money and resources backing up the problem domain DNSSEC attempts to make contributions in, and the fact that it's deployed in practically 0% of organizations with large security teams is telling.