Beginning of 2026, CircleID ran a piece by Barbara Jantzen, in dialogue with ICANN’s Roy Arends, arguing that DNSSEC’s adoption problem isn’t really a technical one—it’s a storytelling one. Two decades of outages, hype cycles, and bad-tempered blog posts turned a useful protocol into a punchline, and the piece promised a second installment: one that would put those claims into perspective with up-to-date information.

That follow-up hasn’t landed yet. In the meantime, I’ve been sitting on a dataset that speaks directly to the question—not because the story doesn’t matter, but because there’s a second, less flattering possibility worth putting on the table alongside it: maybe adoption is low not because people don’t believe DNSSEC is useful, but because turning it on and keeping it on is still genuinely harder than it should be.

Both things can be true. Here’s what the numbers say, and then what the mechanics say.

The baseline everyone gets wrong

Ask most people in this industry what DNSSEC adoption looks like today, and you’ll hear a number in the 30s. That’s not wrong, exactly—it’s just the wrong metric for the question usually being asked.

Barbara Jantzen and Peter Thomassen, in a guest post on the APNIC Blog in February 2026, put it plainly: DNSSEC validation and secure delegation rates reached 36% and 7% respectively in 2025. Those are two different things. Validation measures how many end-user queries pass through a resolver that checks DNSSEC signatures—largely a function of which public resolver an ISP happens to point people at. Secure delegation measures whether a domain’s own zone is actually signed. It’s the number that reflects what a domain operator chose to do, not what their ISP chose on their behalf.

Seven percent, not thirty-six, is the number that answers “how many domains are actually doing this.”

Where twelve unrelated sectors land against that baseline

In August 2026, I finalized bulk-checking functionality and ran 309 domains—104 leading universities, 103 major museums, 102 global sports and outdoor brands—through NODA, a dual-axis DNS assessment methodology I built as an open, versioned specification (in the spirit of what SSL Labs did for TLS). That first pass was suggestive but narrow, so I expanded it: 596 more domains across nine additional sectors, chosen specifically to test whether technical sophistication predicts adoption—DNS/hosting infrastructure providers, financial services, cloud/SaaS at hyperscale, mid-market SaaS, government, healthcare, ISPs, VPS/hosting, and news media. 905 domains total, twelve sectors. Against the 36% figure, most of them look like laggards. Against the 7% figure—the one that actually measures the same thing NODA measures—the picture is a lot more interesting.

Two results here are worth sitting with, because they cut against the obvious story.

First, the hyperscalers. Cloud/SaaS-at-scale—AWS, Azure, GCP, and their tier—sits at 20.4%, nearly three times the global baseline. That’s respectable, and unsurprising: these are the companies with the deepest DNS engineering benches on the planet. But it’s not the top of the list. It’s fifth. A regulatory category with no comparable engineering headcount—non-US government domains, none of them operating under anything like the US .gov signing mandate—beats it by more than 13 points. And DNS/hosting infrastructure providers, the companies who build and sell DNSSEC automation to everyone else, sit second, ahead of every general-technology sector on this list. Technical sophistication correlates with adoption, but it isn’t the strongest predictor of it. Whatever government agencies and DNS specialists share that hyperscalers don’t—an institutional habit of treating this as baseline hygiene rather than a discretionary security investment, or the accumulated experience of having handled a KSK rollover before—matters more than raw capability.

Second, the floor. Sports brands sit alone below the global baseline, at less than half of even the lowest other sector. That’s not “behind the curve.” Nothing else in a twelve-sector, 905-domain sample is behind the curve. It’s a sector-specific gap that a general “the industry lags” narrative can’t explain, and a “nobody has the engineering capacity” narrative can’t explain either—this is a sector with real fraud teams, PCI compliance programs, and bot-mitigation budgets that simply never got applied here.

That’s the opposite of what a pure “storytelling and image” explanation would predict. If DNSSEC’s problem were mainly reputational—bad press, outage anecdotes, DNSSEC fatigue—you’d expect the gap to track how plugged-in a sector is to that discourse. Instead, engineering depth alone doesn’t explain the ranking (hyperscalers, fifth), reputational exposure alone doesn’t explain the floor (sports brands, a sector that lives and dies by public trust, dead last), and “under-resourced legacy infrastructure” doesn’t explain why universities and museums both beat the specialists who build DNSSEC tooling for a living. Something else is going on.

What “something else” actually looks like

Here’s the part that rarely makes it into DNSSEC coverage, because it’s not dramatic enough to be a headline and not simple enough to be a tweet: DNSSEC isn’t a feature you flip on. It’s a maintenance commitment you take on indefinitely, and every step of that commitment involves a decision that doesn’t have an obviously correct answer.

Start with the basic architecture. DNSSEC uses two keys, not one—a Key Signing Key (KSK) that signs the DNSKEY record set, and a Zone Signing Key (ZSK) that signs the actual records in your zone. They rotate on different schedules, carry different risk profiles, and—critically—only one of them stays entirely inside your own infrastructure. Rolling the ZSK is your problem alone. Rolling the KSK means updating a DS record at your registrar or registry, which means your timing now depends on someone else’s propagation behavior, not just your own TTLs. That’s the step that breaks things when it’s rushed, and it’s also the step a TLS certificate renewal has no equivalent of—there’s no DNSSEC version of “the browser vendor handles it.”

Even the rollover itself isn’t a single well-trodden path. The two common methods—Double-Signature, where you publish the new key and new signatures side by side and wait out a TTL before removing the old ones, versus Double-DS, where the new DS record goes up at the parent first—trade off differently. One temporarily doubles your zone size; the other adds a coordination step with the parent zone and a timing window you have to get right. Neither is obviously “the” right answer independent of your setup, your registrar’s tooling, and how much you trust your own monitoring to catch a problem mid-rollover.

Then there’s algorithm choice, which isn’t a one-time decision either. ICANN’s own DNSSEC and Security Workshop program committee—soliciting topics for the ICANN87 meeting in Bali this October—asks operators directly: “Do you use and support DNSKEY Algorithms 13–17?” Migrating from RSA to ECDSA, or to the newer EdDSA algorithms, is its own rollover project, with its own coordination and validation risks, not a config flag you flip during a maintenance window.

None of this is a criticism of the protocol’s design—the split-key model and the multi-step rollover process exist for good cryptographic reasons. But it does mean that “DNSSEC is important” and “DNSSEC is straightforward to run” are two separate claims, and only one of them is unambiguously true. If a domain operator fully believes the first claim and adoption is still low, the honest read isn’t that the story failed to land. It’s that the operational model asks a lot of whoever signs up to maintain it, indefinitely, with tooling and registrar support that varies wildly depending on where you sit in the DNS hierarchy.

The fix that exists, and the gap it hasn’t closed yet

The good news is that this problem has a known solution, and it’s not hypothetical—it’s running in production today. Authenticated CDS/CDNSKEY records let a child zone signal its desired DS records to the parent automatically, following the “old signs new” principle from RFC 7344, with newer refinements in RFC 9615 and RFC 9859. Several ccTLD registries—.ch, .cr, .cz, .li, .se, .uz, .za, and others, mostly in Europe—have implemented this kind of automation already, and by every account it works: low support-ticket volume, high customer satisfaction, none of the manual, error-prone key-juggling that makes rollovers risky in the first place.

The gap is that this same automation can’t be deployed across the gTLD space—.com, .net, .org, and everything else under ICANN’s direct purview—without ICANN’s approval. The stakes of that gap are easiest to see through .com alone: at 159.4 million domains, it comprises 42% of all domains worldwide on its own, and it’s just one gTLD among many still waiting on the same approval. That process is currently in motion: the Security and Stability Advisory Committee’s SAC 126 report identified the operational questions that needed answering, the IETF’s DNSOP working group turned those into a formal guideline draft, and that draft has since been published as RFC 10026 (BCP 246). The mechanism exists. It’s a matter of the largest and most consequential part of the domain namespace catching up to what smaller registries already proved works.

It’s worth being honest about what that approval process actually involves, too. Coordinating DNSSEC automation across every registrar and registry touching .com-scale infrastructure isn’t the same problem as one ccTLD registry rolling it out for its own namespace—it’s closer to standardizing a safety protocol across an entire industry simultaneously, where a misstep doesn’t stay contained to one operator’s zone. Walk a day in ICANN’s shoes on this one: getting that kind of consensus and testing right, at that scale, without breaking anything, is a genuinely large undertaking, and it’s reasonable that it takes the time it’s taking.

Where this actually leaves us

DNSSEC doesn’t need a better origin story or a funnier pecha kucha talk to fix its adoption curve, however much both of those things help morale inside the DNS community. What it needs is what RFC 10026 is already pointing toward: fewer manual decisions, fewer multi-week coordination windows with a parent zone, fewer places where a well-intentioned operator can get the sequencing wrong and cause an outage that then gets added to somebody’s public list of DNSSEC failures.

The twelve-sector data backs this up in an unglamorous but useful way. Engineering depth alone doesn’t predict the ranking—if it did, the hyperscalers would be first, not fifth. What separates the top of this list from the bottom looks less like a budget line and more like an institutional habit: government agencies and DNS specialists treat signing as baseline hygiene, something that gets done as a matter of course, the way patching or backups do. Hyperscalers, for all their engineering depth, appear to treat it as one discretionary security investment among many, competing for the same attention as everything else on a roadmap. And sports brands—with real security budgets but apparently no one whose job it is to own this specific maintenance commitment—sit at the bottom, below sectors with a fraction of their resources. That’s not what a pure image problem looks like. It’s closer to what a maintenance-burden problem looks like: unevenly absorbed by whoever happens to have made it someone’s job, largely independent of how much budget that organization has for security in general.

These are exactly the questions ICANN’s DNSSEC and Security Workshop is soliciting input on ahead of its October 21 session in Bali—key rollover practices, algorithm support, disaster-recovery review cadence, and whether operational statistics like these are being gathered and shared at all. DNSSEC isn’t cool. It was never going to be cool. It’s useful in the specific, unglamorous way that a smoke detector is useful—and like a smoke detector, adoption depends less on whether people believe in it and more on how much friction stands between “believing in it” and “it’s actually installed, and the battery is charged.”

Scored using NODA, a dual-axis DNS Health + Best Practice methodology (41 checks, 5 weighted categories). Full methodology and per-sector data: noda.marinadns.io/methodology.