Weird to see this here, but OK! I keep debating writing a follow-up post called "Stick A Fork In It", declaring DNSSEC finally dead and buried, and (wisely) have decided not to call it quite yet. Factors motivating "Stick A Fork In It":

* The increasing salience of multi-perspective verification at CAs (LetsEncrypt won't depend on a single DNS response to domain-validate a certificate request, but will distribute that request to resolvers around the world and make sure they agree with each other).

* The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates --- instead of doing a weird DNS dance, you can just ask the registrar directly.

* The design and deployment of MTA-STS, the HSTS-style TLS continuity protocol for SMTP; SMTP is basically the final use case for DNSSEC, where DNSSEC can serve as a signaling mechanism to ensure that SMTP connections actually use TLS and aren't negotiated down to plaintext by a MITM. MTA-STS was designed specifically to replace DNSSEC for this use case, by the major email providers.

* The ironic increase in domain takeover attacks --- ironic because they're overwhelmingly (probably universally?) done by compromising registrar accounts rather than playing games with the DNS protocol, such that even after a forklift upgrade to enable DNSSEC, we'd still mostly have the same DNS security problem.

* The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS security that (unlike DNSSEC) protects the "last mile" between browsers and the DNS servers they talk to; in a world where most users talk to just a couple trusted DNS resolvers, all of which speak DoH, DoH might be all the DNS security we need?

* The rise in BGP4 takeover attacks, which completely bypass name resolution altogether; as these attacks continue to mainstream, they too strike right at the heart of the problem DNSSEC was supposed to solve.

* The incredibly bad track record DNSSEC has for reliability; for instance, Slack had a multi-hour total sitewide outage earlier this year that came from attempting to turn it on. This was predicted --- it's predicted in the "Against DNSSEC" post! --- and it's come to pass: DNSSEC is easy to screw up, easier than TLS, and when you screw DNSSEC up, your site falls of the entire Internet without warnings.

* The success of Certificate Transparency and CA surveillance in the WebPKI, to the point where the largest and most commercially important CAs were actually ripped out of browsers after surveillance systems detected misissuance. Also, the most trusted CA on the Internet in 2022 is... free? The WebPKI of 2022 is just not the WebPKI of 2015.

Against this backdrop, the important thing to know about DNSSEC is that it is simply not widely deployed; you can quickly measure this by taking any list of the top domains (the "Moz 500" is an easy-to-download version) and then feeding it through dig:

for DOMAIN in $(cat list); do
dig ds $DOMAIN +short
done

That DNSSEC isn't widely deployed doesn't, of course, mean it never will be. But it's important to get a sense of the costs we're talking about: it would be one thing if the work of rolling DNSSEC out had already been done, the costs had been sunk, and we were just trying to extract some value of it. But the opposite is true!

I see a much different (and worse) opportunity cost to DNSSEC: if we stick a fork in it, we can get to work on something better. I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Maybe DNS is worth protecting anyways! Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.

At any rate: I feel like the ~8 years since I wrote this post have pretty much totally vindicated my argument. I felt a little like I was going out on a limb when I wrote it. Now I feel like the argument is pretty banal. :)