DNSSEC has had about twenty-five years and it is still, by any honest measure, a rounding error. APNIC’s 2025 numbers put resolver-side validation around 36% — that part is quietly winning — but the zones actually being signed sit near 7% of delegations. Under 5% of .com is signed. The standard everyone agrees is the right answer to DNS spoofing is deployed almost nowhere.
The stock explanation is that DNSSEC is too complicated. Key algorithms, RRSIG records, chains of trust from the root down. Scary stuff.
I don’t buy it. The cryptography is not the wall. The wall is an org chart.
It Takes Two Companies
Turning on DNSSEC is two jobs owned by two different vendors.
Job one: your DNS operator signs the zone and publishes a DNSKEY. Most managed DNS providers will do this with a toggle. That part is easy and it’s not where adoption dies.
Job two: the parent zone — reached through your registrar, then the registry — has to publish a matching DS record so validating resolvers can build the chain of trust down to you. And your registrar is usually not your DNS host. So the last step of enabling DNSSEC is a human being copying a hash out of one company’s dashboard and pasting it into a second company’s dashboard, correctly, by hand.
That is the whole barrier. Not Merkle trees. A copy-paste between two vendors who have never heard of each other.
The One Step That Can Delete Your Domain
Here’s why that copy-paste is uniquely poisonous, and why even the people who complete it are afraid of DNSSEC forever after.
Get almost anything else in DNS wrong and you get degraded service. Get the DS record wrong — stale hash, mismatched key, a rollover the parent didn’t follow — and validating resolvers don’t serve a warning or a fallback. They return SERVFAIL. Your domain doesn’t look broken; it looks gone, and only to the third of the internet that validates, which is the worst possible failure to debug because half your users swear the site is fine.
Then it happens again at every key rollover, forever. So the manual handshake isn’t just annoying to set up. It’s a standing liability you re-arm every time you rotate a key. A rational operator looks at “small security upside, whole-domain outage as the downside” and leaves it off. They’re not being lazy. They’re doing the math.
Where One Company Owns Both Sides, It Just Works
The clean proof that the crypto was never the problem: look at what happens when a single company is both your registrar and your DNS operator.
Cloudflare runs both. It supports CDS/CDNSKEY scanning and, for domains on its own registrar, submits the DS record itself — no dashboard-to-dashboard copy-paste, because there’s only one dashboard. Adoption in that arrangement isn’t 7%. It’s near-total and it’s invisible to the user.
Same cryptography. Same rollovers. The only thing that changed is that the two parties who have to talk are now one party. When you remove the handshake, adoption stops being a problem. That tells you the handshake was the problem.
The Fix Shipped Years Ago
This is the part that should embarrass the industry: the mechanism to automate the handshake has been a published standard for over a decade.
RFC 7344 (2014) defined CDS and CDNSKEY — records the child publishes to signal its desired DS to the parent, so the parent can pull it automatically instead of waiting for a human to paste it. RFC 8078 (2017) put it on the standards track and, crucially, covered turning DNSSEC on and off in-band. The one thing 7344 couldn’t solve was the very first insertion — before any DS exists there’s nothing to authenticate the signal with, a genuine chicken-and-egg. RFC 9615, published in July 2024, closes exactly that gap with authenticated bootstrapping: the DNS operator publishes signed signaling records the parent can cryptographically verify before the first DS ever exists.
None of this is theoretical. The .ch and .cz registries already scan child zones for CDS and publish the DS themselves. PowerDNS shipped RFC 9615 bootstrapping in 2026. ICANN’s own security committee spent SAC126 (2024) telling registries and registrars to automate DS provisioning. The bridge is built. Most of the industry just hasn’t walked across it.
Turn It On by Default — With One Precondition
Opt-in had its run. Twenty-five years of “enable DNSSEC if you know what you’re doing” produced single-digit signing. Opt-in is how you get 7%. The only lever that moves a security default from 7% to 70% is flipping the default itself, and the European ccTLDs that clear 70% got there by making signing the path of least resistance rather than a treasure hunt.
So the position is simple: every provider that operates both DNS and a registrar should sign and submit the DS by default. Every registry should scan CDS/CDNSKEY. Every registrar should honor it. The rollover-breaks-my-domain fear is real — but it’s a fear of the manual version. Automated, monitored rollovers driven by CDS are precisely how single-operator setups already run DNSSEC without anyone losing sleep.
There’s one honest precondition, and it matters. Default-on is only safe when one operator controls both the signing and the DS submission end to end. A “default” that signs your zone but leaves DS insertion to a registrar that doesn’t scan CDS is worse than doing nothing — you’ve built half a bridge and invited people to drive across it. So the rule isn’t “flip the switch.” It’s “automate the entire handshake, then flip the switch.” That’s a real engineering bar. It’s also exactly the bar RFC 7344, RFC 8078, and RFC 9615 already cleared.
The reason your domain isn’t signed isn’t that DNSSEC is hard to understand. It’s that turning it on has always required two companies to talk, and the protocol that makes them talk without a human in the middle has been sitting in an RFC since 2014. The excuse expired a long time ago. Ship the default.