DNSSEC has been standardized since 2005. The root zone has been signed since 2010. Every major resolver — Google Public DNS, Cloudflare, Quad9 — validates DNSSEC signatures. The protocol works. And yet, after more than two decades, I found that only 4.27% of domains are DNSSEC-signed when I analyzed 240.3 million domains across 1,929 TLD zone files.
That means for every domain that has implemented the one protocol designed to authenticate DNS responses, 22 domains have not. This isn't a story about a technology that hasn't been invented yet — it's a story about a technology that exists, works, and is almost universally ignored. I wanted to understand why.
How I Measured This
I used TLD zone files from February 14, 2026 — the same zone files that authoritative name servers use to resolve domains. For each of the 240,337,821 domains in the dataset, I checked for DS (Delegation Signer) records in the parent zone. A DS record means the domain owner has published DNSSEC keys and the registry has authenticated them. No DS record means no DNSSEC.
The result: 10,256,892 domains signed, 230,080,929 unsigned. An overall rate of 4.27%.
You can browse the full TLD-by-TLD breakdown on the DNSSEC adoption rankings page, which updates daily. This article focuses on the why behind those numbers.
The Registrar Default Problem
The single strongest predictor of DNSSEC adoption isn't domain owner security awareness, industry vertical, or TLD policy. It's whether the domain's DNS provider enables DNSSEC automatically.
Consider this: TLDs where Cloudflare has significant market share consistently show higher DNSSEC rates. Google-operated TLDs like .page (35.72%), .zip (28.32%), and .dad (26.59%) all cluster at the top. OVHcloud's eponymous .ovh leads all open-registration TLDs at 38.66%. What do these providers have in common? They handle DNSSEC key management automatically, with minimal or no user intervention.
Now look at the other end. Budget TLDs dominated by registrars with manual DNSSEC processes — .top (0.34%), .xyz (0.87%), .shop (0.21%) — sit near zero. These TLDs have millions of domains, and their low rates drag the global average down.
The data tells a clear story: DNSSEC adoption is a provider-side decision, not a user-side decision. Domain owners don't adopt DNSSEC — their providers adopt it for them, or they don't adopt it at all.
This is almost identical to the trajectory of HTTPS. Website operators didn't suddenly decide they wanted TLS certificates. Let's Encrypt made certificates free and automatic, and Cloudflare started issuing them for every domain on their platform. HTTPS adoption went from under 40% to over 90% in a few years. DNSSEC needs the same kind of intervention, and it hasn't gotten it.
The Invisible Benefit Problem
When a website uses HTTPS, visitors see a padlock icon. Browser address bars once turned green for EV certificates. The signal is immediate and visible — both to the site operator ("my site is secure") and to visitors ("this site is trustworthy").
DNSSEC provides no equivalent signal. When your domain is DNSSEC-signed and a resolver validates the chain:
- Nothing changes in the browser UI
- No certificate or badge is displayed
- The visitor has no idea DNSSEC was checked
- The domain owner gets no analytics about validation
This means DNSSEC has zero marketing value. A domain owner can't tell their customers "our domain is DNSSEC-protected" in any meaningful way. For the business stakeholders who control DNS budgets, spending time and accepting operational risk for an invisible improvement is a hard sell.
Compare this to HTTPS again. Before Let's Encrypt, people still paid for certificates because the padlock icon built customer trust. DNSSEC has no equivalent carrot — only the stick of "you might get cache-poisoned someday."
The Chicken-and-Egg Problem
Even when a domain owner signs their zone, the protection only works if the end user's DNS resolver validates DNSSEC signatures. Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) validate. Quad9 (9.9.9.9) validates. But many ISP resolvers — which serve the majority of residential internet users — still don't.
This creates a vicious cycle:
- Domain owners don't sign because most resolvers don't validate
- Resolver operators don't prioritize validation because most domains aren't signed
- Neither side moves because the other side hasn't moved
The HTTPS ecosystem broke this cycle with browsers: they started warning users about unencrypted connections regardless of server configuration. That forced every website to adopt HTTPS. No equivalent forcing function exists for DNSSEC.
The Operational Fear Factor
DNSSEC's worst failure mode is that it can make your domain completely unreachable. A misconfigured DNSSEC setup — expired signatures, botched key rollover, mismatched DS records — causes validating resolvers to return SERVFAIL rather than an insecure response. Your domain goes dark for everyone using Google DNS, Cloudflare, or Quad9.
This is a unique property of DNSSEC that other security protocols don't share. A misconfigured TLS certificate shows a browser warning but the site is still reachable (users can click through). A misconfigured SPF record might soft-fail email but doesn't block it entirely. Misconfigured DNSSEC is a hard failure with no override.
I've seen this happen. Key rollovers that go wrong. Algorithm migration failures. DS records that get out of sync with the zone's DNSKEY records. Each incident reinforces the industry narrative: "DNSSEC is too risky for production domains."
The fear is rational — but increasingly outdated. Modern DNS providers handle key management automatically. CDS/CDNSKEY automation (RFC 8078) allows the DNS provider to signal the registrar to update DS records without manual intervention. Multi-signer DNSSEC (RFC 8901) enables safe provider migrations. The tooling has caught up. The perception hasn't.
The Policy Exception: When Requirements Work
The most striking counterexample in the data comes from fTLD Registry Services, which operates .bank and .insurance. These TLDs impose strict security requirements on registrants, and their DNSSEC rates reflect it: .bank at 49.90% and .insurance at 49.20%.
That's roughly 10x the global average. And it's achieved not through superior tooling or education, but through policy — registrants are required to meet security baselines. The .bank TLD essentially proves that the DNSSEC adoption problem is solvable whenever the incentive structure changes.
It's worth noting that even .bank hasn't reached 100%. This suggests that even with requirements, operational complexity prevents universal adoption. But going from 4% to 50% with a single policy change is a powerful data point.
What the Data Says Would Actually Work
Based on the patterns in 240 million domains, I see three interventions that would meaningfully move adoption:
1. Registrar Opt-Out Instead of Opt-In
If the top 10 registrars by market share — GoDaddy, Namecheap, Tucows, IONOS, and others — enabled DNSSEC by default for new registrations using automated key management, the global rate could triple within a year. Cloudflare and OVH already prove this works. The infrastructure exists. What's missing is the default.
2. Browser Signals for DNSSEC
If Chrome and Firefox displayed a visual indicator for DNSSEC-validated connections — even a subtle one — domain owners would suddenly have a business reason to adopt. The browser vendors drove HTTPS adoption through increasingly aggressive warnings. A similar strategy for DNSSEC would create the demand-side pull that's currently absent.
3. ICANN Mandates for High-Risk TLDs
The fTLD model works. ICANN could require DNSSEC for TLDs that serve financial, healthcare, government, or other security-sensitive sectors. This wouldn't cover all 240 million domains, but it would establish a norm and build the ecosystem of tools and expertise needed for broader adoption.
What This Means for Security
The 95.73% of unsigned domains represents more than a missed best practice — it's a structural weakness in internet infrastructure. Without DNSSEC:
- DNS cache poisoning remains viable. An attacker who can inject forged responses into a resolver's cache can redirect traffic for any unsigned domain.
- BGP hijacks gain DNS authority. An attacker who announces a DNS provider's IP prefix via BGP can serve forged responses that resolvers treat as legitimate — for unsigned domains, there's no way to detect this.
- Certificate authorities can be tricked. DNS-01 validation for TLS certificates relies on DNS responses being authentic. Without DNSSEC, a poisoned cache or hijacked route can lead to fraudulent certificate issuance.
These aren't theoretical attacks — they've all been demonstrated in the wild. The question isn't whether DNSSEC is needed. It's why, after 20 years, the ecosystem still hasn't made it the default.
For the current TLD-by-TLD DNSSEC adoption rates, see the DNSSEC rankings. For TLDs with critically low adoption, see the DNSSEC gaps analysis.