Comment by tptacek
5 hours ago
In case the post is fuzzy: what's changed is that as of March 2026, CAs are required to validate DNSSEC if it's enabled when doing DCV or CAA. Previously, it was technically the case that a CA could ignore DNSSEC if you had it set up on your domains, though LetsEncrypt has (as I understand it) been checking DNSSEC pretty much this whole time.
If you own and host your own domain, it's probably very easy to have your DNS provider enable DNSSEC for you, maybe just a button click. They'd sure like you to do that, because DNSSEC is itself quite complicated, and once you press that button it's much less likely that you're going to leave your provider. DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
There's a research project, started at KU Leuven, that attempts an unbiased "top N" list of most popular domains; it's called the Tranco List. For the last year or so, I've monitored the top 1000 domains on the Tranco list to see which have DNSSEC enabled. You can see that here:
There's 2 tl;dr's to this:
First, DNSSEC penetration in the top 1000 is single digits % (dropping sharply, down to 2%, as you scope down to the top 100).
Second, in a year of monitoring and recording every change in DNSSEC state on every domain in this list, I've seen just three Tranco Top 1000 domains change their DNSSEC state, and one of those changes was Canva disabling DNSSEC. (I think, as of a few weeks ago, they've re-enabled it again). Think about that: 1000 very popular domains, and just 0.3% of them thought even a second about DNSSEC.
DNSSEC is moribund.
That’s a fun list, the only hits in the top 100 are actually Cloudflare, for whom automatic DNSSEC is a feature, and would be a bad look not to dogfood it.
(I did a lot of the work of shipping that product in a past life. We had to fight the protocol and sometimes the implementers to beat it into something deployable. I am proud of that work from a technical point of view, but I agree DNSSEC adds little systemic value and haven’t thought about it since moving on from that project almost 10 years ago. It doesn’t look like DNSSEC itself has changed since, either.)
Then a few government sites, which have mandated it. The first hit after those is around #150.
What's your replacement if DNSSEC is moribund?
It seems to me like it actually solves a problem, what is the solution to "I want/need to be able to trust the DNS answer" without DNSSEC?
Largely, DNS integrity has been addressed by making it harder to spoof dns responses without visibility.
Resolvers have put in the effort to use most of the range of source ports and all of the range of request ids, as well as mixed caps, so predicting queries is difficult and blind spoofing requires an unreasonable number of packets.
Additionally, commercial DNS services tend to be well connected anycast. This means most queries can be served with a very low round trip time; reducing the spoofing window. Additionally, there's less opportunity to observe requests as they traverse fewer networks and less distance.
Generally, traffic has moved to certificate authenticated protocols. CAs are required to verify domain control from multiple locations, so an attacker asserting domain control would need to do so for the victim as well as multiple other locations in order to get a certificate issued.
Further; if we assume you plan to assert domain control by taking over or MITMing the IP of a DNS server, it seems likely you could do the same for the IP of an application server. DNSSEC doesn't help very much in that case. (DNSSEC with DANE could help in that case, but to a first approximation, nothing supports that, and there doesn't appear to be any movement towards it)
Port randomization helps against blind spoofing, but once an attacker is on-path or owns a resolver, it stops mattering.
5 replies →
It seems pretty clear to me that the industry, and particularly the slice of the industry that operates large, important sites and staffs big security teams, doesn't believe this is a meaningful problem at all.
I agree with them.
Would this article not be evidence the part of the industry that makes up the CA/B Forum (i.e. CAs and Browsers) disagree?
11 replies →
Big sites don't have the same concerns as individual end users, in this case specifically about centralized servers surveilling DNS queries.
DNSSEC zone signing lets one resolve records without having to directly go through trusted (ie centralizing) nameservers. (If you run your own recursive resolver this just changes the set of trusted servers to the zones' servers).
I've made this argument in the context of your poo-pooing DNSSEC before, and I don't expect you to be receptive to it this time. Rather I just really wish I could get around to writing code to demonstrate what I mean.
It will change as soon as one of them gets meaningfully DNS hijacked.
Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
> If you own and host your own domain, it's probably very easy to have your DNS provider enable DNSSEC for you
It isn't that easy on AWS.
It also generally is not that easy if your domain registrar is not the same as your dns host, because it involves both parties. And some registrers don't have APIs for automatic certificate rotation, so you have to manually rotate the certs periodically.
I have a setup with separated dns and domain since 2021. Using a CSK with unlimited lifetime, I never had to rotate. And could easily also migrate both parts (having a copy of the key material)
Register only has public material
The master is bind9, and any semi-trusted provider can be used as slave/redundency/cdn getting zonetransfers including the RRsigs
> Using a CSK with unlimited lifetime
Well in cases where I have had to deal with DNSSEC, I've had to rotate the KSK annually for compliance reasons.
> DNSSEC is moribund.
You’ve clearly put a lot of effort into limiting adoption. I’d really value your thoughts on this response to your anti-DNSSEC arguments:
https://easydns.com/blog/2015/08/06/for-dnssec/
I'm sure you can find several of those using the search bar. The argument has gotten a lot grimmer since 2015 --- DNSSEC lost deployment in North America over the last couple years. It didn't simply plateau off and stop growing: people have started turning it off. That corresponds with the success of CT in the WebPKI, with multi-perspective lookup, with the failure of DANE stapling in tls-wg, and with domain hijacking through registrar fixing.
[flagged]
2 replies →
> DNSSEC
And NTP, which is basically a dependency for DNSSEC due to validity intervals too;
From https://news.ycombinator.com/item?id=47270665 :
> By assigning Decentralized Identifiers (like did:tdw or SSH-key DIDs) to individual time servers and managing their state with Key Event Receipt Infrastructure (KERI), we can completely bypass the TLS chicken-and-egg problem where a client needs the correct time to validate a server's certificate.
> To future-proof such a protocol, we can replace heavy certificate chains with stateless hash-based signatures (SPHINCS+, XMSS^MT) paired with lightweight zkSNARKs. If a node is compromised, its identity can be instantly revoked and globally broadcast via Merkle Tree Certificates and DID micro-ledgers, entirely removing DNS from the security dependency chain.
The system described there I think could replace NTP NTS, DNS, DNSSEC, and maybe CA PKI revocation; PQ with Merkle Tree certificates
Was wondering how long it'd take you to come in and trash talk DNSSEC. And now with added FUD ("and once you press that button it's much less likely that you're going to leave your provider").
At least you're consistent.
This is a topic I obviously pay a lot of attention to. Wouldn't it be weirder if I came here with a different take? What do you expect?
I don't think I'm out on a limb suggesting that random small domains should not enable DNSSEC. There's basically zero upside to it for them. I think there's basically never a good argument to enable it, but at least large, heavily targeted sites have a colorable argument.
Actually I think it probably is suspicious to have the exact same opinion after studying something over a long period of time. My opinions are more likely to remain consistent, rather than growing more nuanced or sophisticated, if all I've done is trot out the same responses over a longer period of time.
I've struggled to think of an especially unexamined example because after all they tend to sit out of conscious recall, I think the best I can do is probably that my favourite comic book character is Miracleman's daughter, Winter Moran. That's a consistent belief I've held for decades, I haven't spent a great deal of time thinking about it, but it's not entirely satisfactory and probably there is some introduced nuance, particularly when I re-examined the contrast between what Winter says about the humans to her father and what her step-sister Mist later says about them to her (human) mother because I was writing an essay during lockdown.
It would make them more secure and less vulnerable to attacks. But lazy sysadmins and large providers are too scared to do anything, in no small part due to your ... incorrect arguments against it.
10 replies →
> I don't think I'm out on a limb suggesting that random small domains should not enable DNSSEC.
Why? I can see this argument for large domains that might be using things like anycast and/or geography-specific replies. But for smaller domains?
> There's basically zero upside to it for them.
It can reduce susceptibility to automated wormable attacks. Or to BGP-mediated attacks.
Its not like its just tptacek with this take, i would say its the majority view in the industry.
That doesn't make it correct. Imagine if someone had said, "We don't need to secure HTTP, we'll just rely on E2E encryption and trust-on-first-use". I would really like it if we had a way to automatically cryptographically verify non-web protocols when they connect.
But there is no money in making that a solution and a TON of money in selling you BS HTTPS certs. There is a lot of people spreading FUD about it. It's a shame.
6 replies →
You're not providing any explanation for why I wouldn't trust OP on DNSSEC. And the FUD is pretty reasonable if you've had a lot of experience setting up certificate chains, because the chain of trust can fail for a lot of reasons that have nothing to do with your certificate and are sometimes outside of your control. It would really suck to turn it on and have some 3rd-party provider not implement a feature you're relying on for your DNSSEC implementation and then suddenly it doesn't work and nobody can resolve your website anymore. I've had a lot of wonky experiences with different features in EG X.509 that I've come to really mistrust CA-based systems that I'm not in control of. When you get down to interoperability between different software implementations it gets even rougher.
Which is exactly what happened to Slack, and took them offline for most of a business day for a huge fraction of their customers. This is such a big problem that there's actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that addresses it: tactically disabling DNSSEC at major resolvers for the inevitable cases where something breaks.
7 replies →
> DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
DNS mistakes take your entire domain off the Internet, as if it had never existed.
I'm preparing a proposal to add an advisory mode for DNSSEC. This will solve a lot of operational issues with its deployment. Enabling it will not have to be a leap of faith anymore.
I haven't had to edit the DNS zones for most of my domains in many years. DNSSEC adds an expiring, rotating key change regime to it. If you screw it up, the screwup is cached everywhere, and the failure mode isn't like HTTPS, where you get an annoying popup: you just get NXDOMAIN, as if your domain never existed.
This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.
I run DNSSEC (to facilitate DANE) and with regards to DNSSEC I haven't had to manually edit my zones in years either. Unlike yourself I don't consider DNSSEC deployment or ZSK rotation / KSK roll-over scary or complex, and seeing an adept technician dole out warnings on the level of "don't run with scissors" is pretty peculiar.
Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliable. Not to keep treating it as a fragile Ming Dynasty vase.
In particular, the long TTL of DNS records itself is a historic artifact and should be phased out. There's absolutely no reason to keep it above ~15 minutes for the leaf zones. The overhead of doing additional DNS lookups is completely negligible.
> This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.
So has the TLS cert expiration. And while you can (usually) click through it in browsers, it's not the case for mobile apps or for IoT/embedded devices. Or even for JS-rich webapps that use XMLHttpRequest/fetch.
And we keep making Internet more fragile with the ".well-known" subtrees that are served over TLS. It's also now trivial for me to get a certificate for most domains if I can MITM their network.
Edit: BTW, what is exactly _expiring_ in DNSSEC? I've been using the same private key on my HSM for DNSSEC signing for the last decade. You also can set up signing once, and then never touch it.
11 replies →