That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then.
DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents.
We have since committed entirely to transport security in the form of DoH and friends. It solves the vast majority of problems we actually have.
DoH only secures the connection between the DoH provider and the client, not the response from the authoritative DNS server. It also isn't sufficient for DANE or similar. So DoH doesn't completely solve the problems DNSSEC tried to.
Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.
TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.
This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.
And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.
The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.
”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.
It is not surprising that European registrars have added millions of new names nobody is ever going to visit, all of them signed by default at their registrars. That's not meaningful.
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
Yupp. Which is why using bit.ly is a terrible idea unless you live in Lybia
Did you read the article? It's saying that DNSSEC as an implementation to prevent MITM is flawed; other solutions that protect against MITM are proposed.
We found deSEC to be the only affordable DNS supplier in the EU that complies with state of the art secure DNSSEC.
I mean, if your definition of "affordable" is free, then sure.
But for the record there are other affordable EU suppliers who do DNSSEC:
- Bunny DNS[0] is "free" – i.e. only subject to their minimum $1/month account spend fee.
- RcodeZero is very affordable[1] plus added bonus it is run by the `.at` registry so the infrastructure is solid – business customers only, no private individuals
- Netnod (only via resellers[2] unless you are a big company or government) – Netnod host the I Root Servers and their public hosting DNSSEC service will soon feature HSM-bound DNSSEC keys
I happen to run an affordable EU supplier who does DNSSEC, and also AXFR (incoming and outgoing). I offer a free plan from time to time, but not at the moment to preserve resources for paying customer.
We have a support ticket at Bunny that has been open for months precisely because they don’t provide state-of-the-art DNSSEC. We had to move to another provider, as we have a deadline to comply with at the end of this month. I don’t know what the issue is off the top of my head.
Netnod.se uses a DNSKEY that is too small on their main domain.
Sure: zonemaster[1] is the tool we use [2]. It checks for keylengths and other things and allows policies to be defined on them. It comes with a fairly well defined / modern policy but in our Dutch .foundation article you can read that one should be a bit stricter. However, the default policy of zonemaster warns about the keylength of netnod.se [3]
Internet.nl does not look at DNSSEC that extensively, allowing poorer quality configurations to pass. You can see what they check in the explanations of both DNSSEC metrics [4]. See [5] for discussions about keylength.
Verisign does check for key validity but not for key strength / length as seen in your link.
Comments
We found deSEC to be the only affordable DNS supplier in the EU that complies with state of the art secure DNSSEC. Highly recommended.
DNSSEC support is an anti-feature, it is dead/dying and the faster we can unburden ourselves from it the faster we can move on to better solutions.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
Rebuttal: <https://easydns.com/blog/2015/08/06/for-dnssec/>
That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then.
DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents.
We have since committed entirely to transport security in the form of DoH and friends. It solves the vast majority of problems we actually have.
DoH only secures the connection between the DoH provider and the client, not the response from the authoritative DNS server. It also isn't sufficient for DANE or similar. So DoH doesn't completely solve the problems DNSSEC tried to.
Exactly. And now there's <https://datatracker.ietf.org/doc/html/rfc9539> that allows encrypted DNS between authoritative and recursive servers as well.
That provides privacy, but not authentication.
Authentication was never the problem, transport security was.
This is why we pushed to deploy TLS everywhere instead of focusing on a scheme to PGP sign every webpage on the internet.
Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.
TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.
This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.
And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.
The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.
”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.
You don't seem to be sharing any of the modern rebuttals. I think it's telling that the old criticisms still basically stand.
You don’t seem to be giving any up-to-date criticism. I think it’s telling that the old rebuttals still basically stand.
Which of the criticisms in that article don't stand? What's changed? Adoption of DNSSEC has barely budged since I wrote it.
Which of the rebuttals in the link I gave don’t stand?
According to this graph, DNSSEC adoption seems to now be roughly 16×, i.e. 1600%, of what it was when you wrote it:
https://www.verisign.com/resources/dnssec-tools/dnssec-score...
See the comment from 'dsl upthread.
As for stats: https://dnssecmenot.fly.dev/
It is not surprising that European registrars have added millions of new names nobody is ever going to visit, all of them signed by default at their registrars. That's not meaningful.
Such as? And do those solve the same thing? The post lists 8 headlines why it should be abolished.
So DNS should be open to MITM attackers?
Even with DNSSEC, it still is. Example: https://blog.cloudflare.com/de-tld-outage-dnssec/
Did you read the article? It's saying that DNSSEC as an implementation to prevent MITM is flawed; other solutions that protect against MITM are proposed.
I mean, if your definition of "affordable" is free, then sure.
But for the record there are other affordable EU suppliers who do DNSSEC:
[0] https://bunny.net/dns/ [1] https://www.rcodezero.at/solutions/enterprise [2] https://www.netnod.se/dns/find-a-partnerI happen to run an affordable EU supplier who does DNSSEC, and also AXFR (incoming and outgoing). I offer a free plan from time to time, but not at the moment to preserve resources for paying customer.
https://www.ptrdns.net/
Are you aware that the child zone A(AAAA) records for danube.ns.ptrdns.net differs from the parent zone A(AAA) glue records for danube.ns.ptrdns.net?
Looks like it's the glue records that point to the actual server?
Thanks for letting me know!
This is fixed now, I'll look into why the monitoring tools didn't catch this one as they should have.
We have a support ticket at Bunny that has been open for months precisely because they don’t provide state-of-the-art DNSSEC. We had to move to another provider, as we have a deadline to comply with at the end of this month. I don’t know what the issue is off the top of my head.
Netnod.se uses a DNSKEY that is too small on their main domain.
Rcodezero.at might indeed be something. Thanks.
We donate to deSEC, so it’s not free for us.
Interesting, could you expand on that ?
I ran netnod.se through the Verisign[1] and internet.nl[2] and it passes DNSSEC tests ?
[1] https://dnssec-analyzer.verisignlabs.com/netnod.se [2] https://internet.nl/site/netnod.se
Sure: zonemaster[1] is the tool we use [2]. It checks for keylengths and other things and allows policies to be defined on them. It comes with a fairly well defined / modern policy but in our Dutch .foundation article you can read that one should be a bit stricter. However, the default policy of zonemaster warns about the keylength of netnod.se [3]
Internet.nl does not look at DNSSEC that extensively, allowing poorer quality configurations to pass. You can see what they check in the explanations of both DNSSEC metrics [4]. See [5] for discussions about keylength.
Verisign does check for key validity but not for key strength / length as seen in your link.
[1] https://zonemaster.se [2] https://internetcleanup.foundation/2026/04/bijgewerkte-dnsse... [3] https://zonemaster.se/en/result/cf3ef2fc83f27eb6/ [4] https://internet.nl/site/internet.nl/4280424/#control-panel-... [5] https://github.com/internetstandards/Internet.nl/issues/1176
Super, thanks. zonemaster added to my bookmarks !
Also have a look at gonemaster, the modern replacement: https://gonemaster.evilbit.de/
One who doesn't is frustratingly Hetzner.