DNSSEC Adoption in 2026: Only 0.47% of DNS Queries Are Actually Protected

Our analysis of Cloudflare Radar telemetry for Q1 2026 shows 8.11% of DNS queries reach domains signed with DNSSEC, yet only 0.47% are validated end-to-end by the resolver. That 17× gap — not the 8% headline — is the real DNSSEC story in 2026, and the one most industry reports miss.

What Is DNSSEC and How Does It Work?

DNSSEC — short for DNS Security Extensions — adds cryptographic signatures to DNS records so a resolver can prove a response came from the authoritative zone and wasn't tampered with in transit. It was first standardised in RFC 4033, 4034, and 4035 back in 2005, and it's been available in some form for close to 30 years. Without it, DNS is a trust-by-default protocol. You ask a resolver for example.com, it returns an IP, and you accept the answer. An on-path attacker or a poisoned cache can hand back anything they want, and your browser will happily connect.

The problem DNSSEC solves is real and old. Dan Kaminsky's 2008 cache-poisoning research showed how quickly an attacker can fill a resolver's cache with forged records. DNSSEC signs every authoritative record set so a validating resolver can detect that kind of forgery before passing the answer back to the client.

Keys, signatures, and the chain of trust

DNSSEC uses four main record types in practice:

• DNSKEY — the public keys used to sign records. Each zone typically has a Zone Signing Key (ZSK) for everyday record sets and a Key Signing Key (KSK) for signing the DNSKEY set itself. The KSK-over-ZSK split lets operators rotate the ZSK often without touching the parent.
• RRSIG — the digital signature attached to each record set. A resolver fetches the RRSIG alongside the answer and verifies it using the DNSKEY.
• DS — the Delegation Signer record. This lives in the parent zone (e.g., .com) and contains a hash of the child's KSK. It's how a parent vouches for its child.
• NSEC / NSEC3 — authenticated denial-of-existence, used to prove that a queried name doesn't exist without leaking the full zone contents.

The chain of trust runs from the root zone down. The root KSK is the anchor of trust. The root signs the .com DS record. .com signs the DS record for example.com. example.com signs its own A, AAAA, MX, and TXT records. A validating resolver follows this chain back up to the root, and if any signature in the chain fails, the response is thrown out with a SERVFAIL.

What DNSSEC actually protects against

DNSSEC is authentication, not encryption. It proves where a DNS answer came from. It does nothing to hide the fact that you queried a particular domain — that's what DNS over HTTPS (DoH) and DNS over TLS (DoT) handle. Think of the two as complementary: DoH/DoT keeps the question private from the network, and DNSSEC keeps the answer honest.

It's also worth being precise about what "protection" means in the DNSSEC model. A signed zone alone doesn't protect anyone. The resolver has to validate. If 91.9% of the world's resolvers accept unsigned answers, signing your zone helps only that small sliver of traffic running through validating resolvers. Hold onto that idea — it's the mechanical reason the next section's numbers look the way they do.

DNSSEC Adoption in Q1 2026: The Real Numbers

Our analysis of Cloudflare Radar public DNS telemetry pulls three distinct Q1 2026 measurements that together describe the state of DNSSEC. Each measures a different dimension of adoption, and they disagree with each other by more than an order of magnitude.

Signing: 8.11% of queries. In the January 1 to March 31, 2026 window, 8.11% of DNS queries resolved to domains with valid DNSSEC signatures (the SECURE class in the Radar summary/dnssec dimension). Another 0.096% had signatures that failed validation (INVALID), 12.51% returned OTHER responses (mostly non-A/AAAA queries or lookups where signing state couldn't be determined), and a large 79.29% were simply unsigned. So roughly 8 in every 100 queries hit a domain that bothered to sign its zone.

Resolver validation: 13.05% of queries. Over the same period, 13.05% of queries were handled by resolvers that actively perform DNSSEC validation (the dnssec_aware dimension). The remaining 86.95% of queries went through resolvers that do not validate. Cloudflare's 1.1.1.1 itself validates, as does Google's 8.8.8.8 and Quad9, so this figure understates what's possible if users switched resolvers — but it accurately captures what's actually happening today.

End-to-end protection: 0.47% of queries. The dnssec_e2e dimension is the one that actually matters. It counts queries where both sides are doing their jobs — the domain is signed and the resolver is validating. In Q1 2026 that number is 0.469%. Fewer than 5 queries in every 1,000 are actually protected by the cryptographic guarantees DNSSEC is supposed to deliver.

Add one more number to round out the picture. The global INVALID rate sits at 0.096% — responses where a signature exists but fails validation, meaning either the zone operator made a mistake or the chain of trust is broken somewhere upstream. That's small in aggregate but it's meaningful because INVALID responses represent outright authentication failures that non-validating resolvers would silently accept. If every resolver validated tomorrow, 0.096% of the internet would immediately break until those signing errors were cleaned up.

None of these three percentages are the "DNSSEC adoption rate." They're three different rates, and any article quoting just one of them is missing most of what's going on.

The Signing vs Validation Gap: Why the 8% Number Misleads

Here's the mechanical reason for the gap. Signing is a zone-operator decision. Validation is a resolver-operator decision. They happen at opposite ends of the DNS lookup. A signed domain without a validating resolver is no safer than an unsigned one — the forged response is accepted either way. A validating resolver asking for an unsigned domain has nothing to check. Both sides must cooperate for DNSSEC to deliver on its promise.

The Q1 2026 numbers show how badly that cooperation fails at global scale. Our read of Cloudflare Radar's end-to-end measurement puts the actual protection rate at 0.469% — 17 times smaller than the 8.11% signing rate. Put differently, out of every 100 queries that could have been protected (because the domain was signed), only about 6 were. The rest were wasted cryptographic work.

Sweden: the clearest example of the paradox

Sweden is the case study that makes the gap stop feeling abstract. Swedish domains sign 12.34% of queries — above the 8.11% global average and evidence of serious effort from the country's registrars and ISPs. But Sweden's end-to-end rate is 0.27%. That's a 45× gap between signing and protection. Sweden is pouring resources into signing zones that most Swedish resolvers then ignore.

Contrast that with India, which signs 8.63% of queries — barely above the global average — but achieves a 1.50% end-to-end rate, the highest in our 30-country dataset. India's resolvers are doing more of the validation work. The result is three times more real protection than Sweden, despite Sweden signing 43% more of its domains.

What this means for how "adoption" should be measured

The community has been using "DNSSEC adoption" loosely for years. Industry stats pages quote signing percentages because those numbers are easy to collect from zone files. Our read of Radar telemetry says that framing overstates the real security picture by more than an order of magnitude. If the goal is fewer DNS cache poisoning attacks and fewer forged responses reaching end users, the number that matters is end-to-end validation — and that number is 0.47%, not 8%.

APNIC's Geoff Huston made a similar argument in his 2024 essay questioning DNSSEC's practical utility. Our numbers support the mechanical part of his concern: the protocol works, but the two-sided market hasn't closed. It's the resolver side that's really stuck, and the domain side keeps signing into a system most resolvers ignore.

How DNSSEC Adoption Changed Across 2025

The gap is real, but it's closing. Our analysis of five consecutive quarterly windows on Cloudflare Radar shows end-to-end DNSSEC validation grew from 0.323% in Q1 2025 to 0.469% in Q1 2026 — a relative increase of 45% year-over-year. That's still a small absolute number, but the direction is clearly up and the pace picked up in the second half of 2025.

Quarter	End-to-end validated	Signing rate
Q1 2025	0.323%	7.28%
Q2 2025	0.325%	7.76%
Q3 2025	0.373%	8.05%
Q4 2025	0.388%	7.68%
Q1 2026	0.469%	8.11%

Two patterns stand out in this data. First, end-to-end growth accelerated sharply between Q3 2025 and Q1 2026 — the jump from 0.388% to 0.469% in one quarter is larger than the entire first-half movement. Second, signing rates moved much more slowly (7.28% to 8.11% over the same 15 months, an 11% relative gain). Signing is growing, but resolver-side validation is growing faster.

The resolver side is finally moving

Resolver support tells the same story. In full-year 2025, 12.02% of queries went through DNSSEC-aware resolvers. In Q1 2026, that hit 13.05% — a 1.03 percentage point jump in a single quarter and a relative gain of 8.6%. That's the fastest resolver-side growth we've seen in any comparable window of Radar data. Signing grew just 5.5% over the same year-over-quarter comparison.

This matters because the resolver bottleneck is what's kept end-to-end rates so low. A few big resolver operators flipping the validation switch moves the global number far more than thousands of domains signing their zones. Cloudflare's 1.1.1.1, Google's 8.8.8.8, and Quad9 already validate. The remaining headroom is in ISP-operated resolvers, corporate resolvers, and country-specific public resolvers — and the Q3 2025 to Q1 2026 acceleration suggests some of those operators finally flipped the switch.

What's driving the change

We can't see individual operator decisions in aggregate data, but three broad factors line up with the timing. Registrar-integrated DNSSEC automation has matured — Cloudflare announced automatic multi-signer provisioning as a default path, and similar tooling has improved across other managed DNS providers. Regulatory pressure has also increased — several European telecoms regulators tightened DNS authentication requirements in 2025. And the operational cost of validation has fallen as resolver software (BIND, Unbound, Knot Resolver, PowerDNS Recursor) has gotten noticeably better at handling signed responses at scale.

45% year-over-year isn't dramatic in startup terms, but for a 20-year-old protocol that was widely declared dead, it's a real signal that the two-sided market is starting to close.

Country-Level DNSSEC Leaders and Laggards

The 30-country breakdown shows just how unevenly DNSSEC adoption is distributed — and how often the leaders aren't the places you'd expect. The table below is our pull of the summary/dnssec and summary/dnssec_e2e dimensions for Q1 2026.

Rank	Country	End-to-end validated	Signed	INVALID
1	India	1.50%	8.63%	0.031%
2	Belgium	1.17%	16.60%	0.055%
3	Argentina	0.97%	7.32%	0.032%
4	South Korea	0.91%	10.00%	4.09%
5	Switzerland	0.89%	9.43%	0.063%
6	Japan	0.72%	9.51%	0.035%
7	Czech Republic	0.71%	13.11%	0.072%
8	Denmark	0.68%	11.16%	0.058%
9	Malaysia	0.67%	7.26%	0.058%
10	Portugal	0.67%	11.72%	0.048%
11	Germany	0.63%	7.46%	0.035%
12	France	0.59%	10.70%	0.035%
13	Norway	0.58%	15.76%	0.196%
14	Finland	0.57%	6.96%	0.019%
15	United Kingdom	0.56%	10.55%	0.065%
16	Australia	0.54%	11.06%	0.042%
17	Poland	0.52%	8.42%	0.046%
18	Austria	0.52%	8.90%	0.026%
19	Netherlands	0.51%	8.08%	0.066%
20	Brazil	0.49%	12.76%	0.029%
21	Ireland	0.49%	10.05%	0.053%
22	Canada	0.49%	8.82%	0.059%
23	Mexico	0.46%	5.02%	0.015%
24	Italy	0.42%	9.93%	0.032%
25	United States	0.37%	8.06%	0.107%
26	Spain	0.35%	13.38%	0.036%
27	Indonesia	0.34%	5.86%	0.063%
28	Sweden	0.27%	12.34%	0.239%
29	China	0.10%	2.20%	0.017%
30	Singapore	0.07%	5.46%	0.116%

The unexpected story at the top

India leads the 30-country sample at 1.50% end-to-end — more than triple the global average. That's surprising given India's sheer DNS query volume and its mix of small and large resolver operators. Belgium is second at 1.17% with the highest signing rate in the sample at 16.60%, more than double the worldwide 8.11%. Argentina's third-place 0.97% is genuinely unexpected; its signing rate is barely above the global average, which means Argentine resolvers are validating at an unusually high rate for a country at that infrastructure tier.

The middle band is thick

Nineteen of the 30 countries cluster between 0.40% and 0.75% end-to-end — most of Europe, most of North America, Japan, Australia, and Brazil. The differences here are small enough that small shifts in major resolver operators could re-rank the list quarter-to-quarter. Don't read too much into rank order within this band; read the trend instead.

The laggards have two different problems

Singapore (0.065%) and China (0.095%) sit at the bottom. Singapore signs 5.46% of its domains — below average but not terribly so — yet its end-to-end rate is less than one-fifteenth of that. The resolver side is the problem. China is different: only 2.20% of Chinese queries hit signed domains in the first place, roughly a quarter of the global signing rate. Both sides are underperforming.

Sweden is the standout paradox. Its 12.34% signing rate places it among the European leaders, but its 0.27% end-to-end rate puts it fourth from the bottom in our sample. Swedish zone operators are doing real work that Swedish resolvers are mostly ignoring.

South Korea's INVALID anomaly

South Korea earns a special mention for a 4.09% INVALID rate — 50× the global average of 0.096%. INVALID means the signature is there but the validation fails, which points to signing errors, stale DS records, or broken chains of trust somewhere in the Korean DNS hierarchy. This is the kind of metric that tells you where operational DNSSEC debt is piling up. On a country that's also in the top five for end-to-end validation, it's especially notable — Korea's resolvers are validating aggressively, and they're catching real signing mistakes that would pass silently in less rigorous environments.

Why DNSSEC Adoption Is Still Slow After 30 Years

The protocol was first published in 1997, re-specified in RFC 4033 in 2005, and has had working code in major DNS servers for at least 15 years. Why does it still sit at 0.47% end-to-end? Three things keep coming up when you look at the data.

Registrar automation is still patchy

Signing a zone is technically easy. Getting the DS record into the parent zone through your registrar is where most deployments die. Some registrars have clean DNSSEC APIs. Others require a support ticket. Others don't support DS submission at all for certain TLDs. APNIC's analysis of deployment friction puts this high on the list of blockers, and it matches what we see in the data: countries with dominant national registrars that handle DNSSEC cleanly (Belgium's .be, Norway's .no) show signing rates close to 16%, while countries where registrar support is fragmented stay below 10%.

Cloudflare's one-click DNSSEC and similar features across the major DNS providers have helped a lot in the last three years. But if you're not on a platform that hides the DS-submission step, you're still doing it by hand.

The resolver side moves slowly

Resolver operators — ISPs, corporate IT, mobile carriers — have no direct user-visible reason to turn on validation. It costs a small amount of CPU and adds a small amount of latency. It breaks DNS for any domain that's signed incorrectly (hence Korea's visible 4.09% INVALID rate). And the typical end user never notices the difference. The Internet Society's DNSSEC deployment tracker has been pointing at this asymmetry for years.

The Q1 2026 jump from 12.02% to 13.05% resolver support suggests some operators finally decided the cost-benefit math had shifted. But it's still 13%. That's the single largest choke point in the DNSSEC pipeline.

Operational complexity at scale

Even when signing and DS submission go smoothly, DNSSEC introduces operational surface area that unsigned DNS doesn't. Key rollovers have to be coordinated with TTL windows. NSEC3 parameters have to be chosen. Signature lifetimes have to be managed. When something breaks, the failure mode is usually "the domain goes dark," which is worse than most operators' day-one tolerance for the protocol.

Sweden's 12.34% signing rate alongside 0.24% INVALID (also well above the global average) hints at this — aggressive deployment without fully mature tooling produces visible signing errors. Norway shows a similar pattern at 15.76% signed and 0.20% INVALID. The gap between "turned it on" and "kept it working" is real.

None of these barriers are fatal. All three are slowly eroding. But three simultaneous slow-moving barriers compound, and that's why a 30-year-old protocol still protects less than 1% of traffic.

Is DNSSEC Still Worth Implementing in 2026?

The honest answer depends on who's asking. Here's how we'd break it down using the Q1 2026 data.

If you operate a domain that handles auth, payments, or anything with real cache-poisoning risk — yes, sign. The cost of signing through a modern managed DNS provider is minimal. Cloudflare DNS, Route 53, Google Cloud DNS, and NS1 all handle key management for you. The DS-submission step is usually a single API call or registrar checkbox. Even though only 13% of resolvers will validate your signature today, that number is growing, and signed zones are the pre-requisite for any future benefit — including DANE for email authentication and any post-quantum successor protocol.

If you operate a resolver — turn on validation. The marginal cost is small. The marginal benefit — catching forged responses for the 8% of queries hitting signed zones — is not zero and is growing. If you don't validate, signed zones provide zero protection to your users. That's the asymmetry the whole 0.47% number is describing.

If you're deciding between investing in DNSSEC or investing in DoH/DoT for your user base — do the encrypted transport first. DNSSEC and DNS over HTTPS solve different problems. DoH stops network-level DNS inspection and manipulation, which is a bigger practical threat for most end users than cache poisoning. DNSSEC proves the answer is authentic. In a layered architecture you want both. If budget forces a choice, DoH/DoT usually wins on user impact per engineering hour.

If you're operating a small personal site with no sensitive data — it's optional. The signing work is a real cost and the benefit is close to zero today. This is where APNIC's "calling time on DNSSEC" framing has some truth. For a brochure site or a static blog, the honest answer is that you can skip it without measurable risk increase.

The trend is the strongest argument

The 45% year-over-year growth in end-to-end validation is the most useful signal here. DNSSEC has been stuck at sub-1% for years. It's not stuck anymore. If Q1 2026's pace holds, end-to-end protection would double to roughly 1% by mid-2027 and hit 2-3% by 2028. That's still small, but it's the difference between a protocol that's irrelevant and one that's starting to matter. Signing now is cheap insurance against a future where that growth continues.

What Our Cloudflare Radar Analysis Reveals for SaaS Teams

For SaaS sales and security teams, the more interesting question is what DNSSEC adoption says about the prospects on your target list. Signed zones aren't randomly distributed. They cluster with other signals — DMARC enforcement, SPF coverage, modern CDN usage, and organised DNS operations. A company that's deployed DNSSEC cleanly is almost always a company that's made other mature infrastructure decisions. That pattern matters when you're trying to segment an account list by technical readiness.

Our DNS detection data at TechnologyChecker already captures signing status alongside DMARC, SPF, DKIM, and CDN provider for tens of millions of domains. Cross-referencing DNSSEC with those other signals is a surprisingly clean way to identify security-mature accounts — the kind that typically convert well for enterprise security tooling, compliance software, and zero-trust platforms. If your team wants to know which of your prospects have deployed DNSSEC (and the rest of their security stack), TechnologyChecker's detection covers 50M+ domains including DNS security signals. Pair that with the country-level patterns above and you get a ranked view of where your mature buyers actually live.

The other thing the data is useful for is timing. Resolver-side growth of 1.03 percentage points in a single quarter is the sort of shift that moves what "a secure prospect" means. Accounts that were unsigned in 2024 and are signed in 2026 are often in the middle of larger infrastructure modernisation projects — often adopting serverless compute like AWS Lambda at the same time. That's a buying signal. Pricing information for TechnologyChecker plans that include DNS-layer detection is available on our pricing page.

Methodology

All numbers in this post come from Cloudflare Radar's public DNS telemetry at radar.cloudflare.com/dns, queried through the Radar MCP get_dns_queries_data endpoint on 2026-04-15 (DATA_AS_OF). Radar measures query volumes to Cloudflare's 1.1.1.1 public resolver, which processes billions of queries per day across a globally distributed anycast network.

Time windows. Q1 2026 means the 90-day period from January 1, 2026 to March 31, 2026. Full 2025 means the 12-month period from January 1, 2025 to December 31, 2025. Quarterly breakdowns (Q1 2025 through Q1 2026) use the standard calendar quarters.

Dimensions pulled. Three Radar summary dimensions:

• summary/dnssec — classifies each query by the signing state of the authoritative zone (SECURE, INSECURE, INVALID, OTHER).
• summary/dnssec_e2e — classifies each query as POSITIVE (signed and successfully validated by a DNSSEC-aware resolver) or NEGATIVE.
• summary/dnssec_aware — classifies each query by whether the requesting resolver performs DNSSEC validation (SUPPORTED / NOT_SUPPORTED).

Country-level numbers came from the same three dimensions with a location filter applied across 30 major DNS markets.

Caveats. First, Radar measures query share, not domain share. A single popular unsigned domain can drag the aggregate down more than a thousand signed low-traffic domains pull it up. Signing-rate percentages in this analysis should not be interpreted as "% of registered domains" — they are "% of DNS queries." Second, 1.1.1.1's user base has its own geographic and demographic skew. Country-level resolver-support numbers reflect resolver choice among 1.1.1.1 users in that country, not the full national population. Third, a 90-day Q1 window smooths out short-term incidents but can mask rapid shifts within the quarter. Fourth, DNSSEC classification depends on Cloudflare's internal resolver behaviour for that query; a small amount of edge noise is unavoidable.

Reproducibility. The raw quarterly figures are published in the Radar dashboard under DNS → DNSSEC and are updated continuously. Anyone can verify the numbers by pulling the same endpoints for the same date windows. The 30-country table is our aggregation; the individual country pages on Radar show the same underlying values.

Frequently Asked Questions

What is the adoption rate of DNSSEC?

DNSSEC adoption depends on how you measure it. Our analysis of Cloudflare Radar data for Q1 2026 shows 8.11% of DNS queries resolve to domains with DNSSEC signatures, 13.05% of queries are handled by resolvers that validate signatures, and only 0.47% of queries are both signed and validated end-to-end. The end-to-end number is the one that reflects real protection. The 8% headline overstates effective adoption by about 17×.

Is DNSSEC outdated?

It's old, not outdated. The protocol was first proposed in the 1990s and re-specified in RFC 4033 in 2005, so the cryptographic primitives are aging, but DNSSEC is still actively supported by all major DNS vendors and is a prerequisite for newer standards like DANE. Post-quantum successors are being discussed at the IETF but aren't deployed. End-to-end validation grew 45% year-over-year in our data, which isn't the trajectory of a dead protocol.

What are the downsides of DNSSEC?

Three downsides keep coming up in operator reports. Operational complexity — key rollovers and DS-record coordination have to be done right or the domain goes dark. Signing errors become visible — Korea's 4.09% INVALID rate in our data shows how broken zones suddenly break queries once resolvers validate. And asymmetric payoff — if resolvers don't validate, your signing effort delivers zero security benefit to those users. Signing without resolver validation is essentially security theatre.

Should I enable DNSSEC on Cloudflare in 2026?

For most domains, yes. Cloudflare handles key generation, signing, and DS submission automatically for domains on their managed DNS. The operational cost is close to zero, and signing today is a prerequisite for benefiting from future resolver-validation growth. The main reason to hold off would be if your registrar doesn't support DS submission or if you run your own signing infrastructure that hasn't been tested for key rollover under load.

Is there any reason not to enable DNSSEC?

Yes, a few. If you run a small personal site with no login or payment flow, the benefit today is near-zero. If your registrar doesn't automate DS submission for your TLD, the operational risk of a misconfigured rollover can outweigh the benefit. If you operate your own DNS infrastructure without mature signing tooling, the INVALID failure mode can take your domain offline. For most commercial domains on a managed DNS provider, none of these apply.

How does DNSSEC work technically?

DNSSEC attaches a cryptographic signature (RRSIG record) to every record set in a signed zone. A validating resolver fetches the RRSIG alongside the answer, looks up the zone's public key (DNSKEY), and verifies the signature. The zone's key itself is vouched for by a DS record in the parent zone, which is signed by the parent's key, and so on up to the root zone. If any signature in this chain of trust fails, the resolver rejects the answer and returns SERVFAIL. The mechanism is defined across RFCs 4033, 4034, and 4035.