Defaults.Exposed › Reports

Broken DNSSEC: 157,064 Domains Are Invisibly Down

Published 2026-08-18

Figures as of 16 August 2026 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: 157,064 domains are down and don’t know it

Across 376.9 million graded domains in our August 2026 census, 157,064 have a broken DNSSEC chain — which means every validating resolver on the internet refuses to resolve them at all. Not a warning. Not a degraded page. SERVFAIL, the DNS equivalent of a dial tone that never connects. For a large share of the world’s internet users, these domains simply do not exist.

The cruelty of the failure mode is that the owner usually can’t see it. Query the domain through a resolver that doesn’t validate DNSSEC and everything works: website loads, mail flows, monitoring stays green. Query it through one that does validate — and that includes the biggest public resolvers on the planet — and the answer is a hard failure. A domain with broken DNSSEC is a shop whose front door only jams for some customers, and the owner always happens to use the side entrance.

That is why we call this cohort worse than nothing. An unsigned domain gets none of DNSSEC’s protection but works everywhere. A correctly signed domain gets the protection and works everywhere. A domain with a broken chain gets no protection and is unreachable for every user behind a validating resolver. It has paid the operational cost of DNSSEC and collected a penalty instead of a benefit.

Key numbers

• 157,064 graded domains have a broken DNSSEC chain — a hard SERVFAIL for every validating resolver (August 2026 census, 376.9M graded domains).
• 1 in 709 signed domains is broken: 157,064 of 111,517,232 domains with DNSSEC material are in a failed state (0.14%).
• Only 29.6% of graded domains are signed at all — 111.5M of 376.9M carry DNSSEC (from validated chain checks).
• .com hosts the biggest pile: 124,176 broken chains, the majority of the global broken cohort.
• .ovh has the worst breakage rate we measured at scale: 12.1% of its signed domains fail validation.
• High-adoption ccTLDs break least: .cz signs 63% of its domains and breaks only 0.60% of them; .nl signs 54% and breaks 0.77%.

What does “broken DNSSEC” actually mean?

DNSSEC is a chain of cryptographic vouching. The parent zone (say, .com) publishes a DS record that says “this domain’s keys are legitimate,” and the domain itself publishes DNSKEY records that must match. A validating resolver walks that chain on every lookup. If the links agree, the answer is proven authentic. If a link is missing or mismatched — a DS record pointing at keys that no longer exist is the classic case — the resolver is required to treat the whole answer as forged and return SERVFAIL. (DNSSEC’s validation rules date to RFC 4033–4035, published in 2005 — industry context, not census data.)

The design is deliberate. A validator that shrugged and served the answer anyway would defeat the entire point, because an attacker could just strip the signatures. So the failure mode is absolute by specification: broken chain, no answer, no exceptions.

How do domains get here? Almost always by half-finishing a change. The most common script: a domain is signed at one DNS provider, then migrates to a new provider that doesn’t sign — and nobody removes the DS record at the registrar. The parent zone keeps vouching for keys that vanished with the old provider. From that moment, the domain is down for every validating resolver, and it will stay down until someone deletes a record most owners have never heard of.

Who actually sees the failure?

Everyone behind a validating resolver — and that is a lot of people. Google Public DNS (8.8.8.8), Cloudflare’s 1.1.1.1 and Quad9 all validate, as do many large ISP resolvers; APNIC’s long-running measurement has put the share of internet users behind validating resolvers at roughly a third worldwide, and far higher in parts of Europe. (Industry context; our census measures domains, not user populations.)

So the practical translation of “broken DNSSEC” is: a substantial, geographically uneven slice of your customers gets a connection error with no explanation, while your own checks pass. Email is often the first casualty anyone notices, because a sending server behind a validating resolver can’t look up your MX records and mail starts bouncing — days or weeks after the DNS change that caused it, which makes the cause genuinely hard to find.

How big is the cohort, and where does it live?

The census gives a clean global answer. Of 376,928,781 graded domains, 111,517,232 carry DNSSEC material — 111,360,168 validate correctly and 157,064 are broken. Two ways to read that:

• As a share of the whole graded web, broken DNSSEC is small: 0.04%.
• As a share of domains that actually attempted DNSSEC, it is not small at all: 0.14%, or one signed domain in every 709.

The second number is the one that matters if you run a signed domain, and it is the one the per-TLD split illuminates. Here are the TLDs carrying the largest broken populations from our latest census measurement:

(August 2026 census. “Signed” = dnssec_valid + dnssec_broken for that TLD.)

Two patterns jump out.

First, .com is the volume story. Its 124,176 broken chains are the majority of the entire global cohort, and its 1.89% breakage rate is well above the rates in the mature DNSSEC ccTLDs. DNSSEC in .com is mostly an opt-in minority pursuit, and opt-in minorities are exactly where half-finished migrations accumulate.

Second, breakage tracks culture, not size. The Northern and Central European ccTLDs where DNSSEC is normal — .cz signs 63% of its graded domains, .se 65%, .dk 66%, .nl 54% — post the lowest breakage rates: 0.60% to 1.31% of signed domains. The TLDs where signing is rare post the highest: .online breaks 3.68% of its signed domains, .store 5.06%, and .ovh a remarkable 12.08% — roughly one broken chain for every seven signed domains. Where registrars and registries automate DNSSEC end-to-end (often with financial incentives for registrars, as several of those ccTLD registries have run — industry context), the chain gets maintained. Where a minority of owners switch it on by hand, it rots.

We’ve written before about the adoption side of this picture — see the DNSSEC adoption report — and about why the strongest argument against deploying DNSSEC is the damage a botched deployment does, in the DNSSEC paradox. This cohort is that argument, counted.

Is there a bigger grey zone behind the 157,064?

Yes, and honesty requires showing it. Alongside the confirmed-broken figure, our raw DS/DNSKEY probe data records the response status of each query pair. In 1,993,870 cases, the DS query answered normally while the DNSKEY query returned SERVFAIL — and SERVFAIL on a DNSKEY lookup is precisely the symptom a broken or misbehaving DNSSEC deployment produces. A further 107,982 domains answered the DS query but REFUSED the DNSKEY query, and 61,859 returned NXDOMAIN for DNSKEY.

We do not add these to the headline number, for a strict reason: a query status is not a record inventory. A DS query can return NOERROR with an empty answer (no DS record exists, nothing at stake), and a DNSKEY SERVFAIL can have causes other than a broken chain — an overloaded authoritative server, a transient network fault at scan time. The 157,064 figure counts only domains where our per-check evaluation confirmed an actual broken state between parent and child. Treat the ~2.0 million DNSKEY-SERVFAIL pairs as the outer boundary of the problem’s shadow, not as a measurement of the problem.

Why doesn’t anyone notice?

Because every signal the owner watches is generated from the working path.

The owner’s own browser probably sits behind a non-validating resolver, or one that has cached the domain from before the break. Uptime monitors typically resolve through whatever their host provides, which frequently doesn’t validate. The registrar’s control panel shows a DS record that looks perfectly healthy — it is healthy; it just vouches for keys that no longer exist. Meanwhile the failures land on other people’s screens as a generic “site can’t be reached,” which no visitor reports and no analytics package records, because the visit never reached the server.

The result is a failure that can persist for months. Nothing in the default toolchain of a small-business domain owner ever renders the words “your DNSSEC chain is broken.” That is the awareness gap this census series exists to close: the fix is typically a single record deletion or a re-signing at the current DNS provider — free, and minutes of work — but you cannot fix a problem that nothing you look at will show you.

How we measured this

• Population and denominator: 376,928,781 graded domains from the August 2026 census round (432 million scanned), methodology v9, figures as of 16 August 2026. Registrable domains only, one row per domain.
• Signed cohort: a domain counts as signed when its DS/DNSKEY evidence shows DNSSEC material: 111,517,232 domains (dnssec_valid 111,360,168 + dnssec_broken 157,064).
• “Broken” definition: the census DNSSEC check flags a domain as broken when the parent/child chain is in a failed state — DS material present with DNSKEY material missing or unusable, and mixed states of the same kind. It is a chain-state evaluation, not a full cryptographic validation of every signature; a domain with valid-looking material but a subtly wrong signature could grade as valid here. The 157,064 figure is therefore best read as a floor on true breakage.
• The ~2.0M grey zone: the DS-NOERROR/DNSKEY-SERVFAIL pairs come from raw query statuses. Statuses do not prove record presence (NOERROR can carry an empty answer) and SERVFAIL has non-DNSSEC causes, so we report this figure separately and do not add it to the broken cohort.
• Vantage: all measurements from our EU scanning infrastructure at capture time, one census round. A transient authoritative-server fault at scan time can misclassify an individual domain in either direction; at 376.9M domains, such noise is immaterial to the aggregates.
• User-impact framing: claims about which resolvers validate, and the approximate share of users behind validating resolvers, are industry context (public resolver documentation; APNIC measurement), not census data.
• Aggregate only. We publish TLD-level and global aggregates. We never name, grade or publish data about an individual registrant’s domain.
• Data is stored and processed within the EU.

FAQ

What happens to a domain with broken DNSSEC? Every validating resolver returns SERVFAIL for it — the domain is unreachable, and mail to it undeliverable, for all users behind those resolvers. Non-validating resolvers serve it normally, which is why owners rarely notice. As of the August 2026 census, 157,064 graded domains were in this state.

How common is broken DNSSEC? Rare against the whole web (0.04% of 376.9M graded domains) but meaningful within the signed population: 0.14% of the 111.5M signed domains, one in 709. In the worst TLD we measured at scale, .ovh, 12.1% of signed domains had broken chains.

How do I check whether my domain’s DNSSEC is broken? Query your domain through a validating resolver such as 8.8.8.8 or 1.1.1.1 — a SERVFAIL there, combined with a normal answer from a non-validating resolver, is the signature symptom. Public DNSSEC-analysis tools will walk the chain and show the exact broken link. Our own domain check includes DNSSEC chain state among its 34 checks.

How do I fix a broken DNSSEC chain? Almost always one of two moves: remove the stale DS record at your registrar (right after a DNS-provider change that dropped signing), or re-sign the zone at your current DNS provider so the published keys match the DS record. Both are free; the usual barrier is knowing the problem exists at all.

Is it safer to skip DNSSEC entirely, given this failure mode? Skipping it avoids this specific outage risk but forfeits protection against DNS spoofing — and the census shows maintained DNSSEC is the norm among signers: 99.86% of signed domains validate correctly, and in high-automation TLDs like .cz the breakage rate is 0.60%. The real lesson is to let your registrar/DNS provider automate the chain rather than managing keys by hand, and to remember the DS record whenever you change DNS providers.

What causes DNSSEC to break in the first place? The most common cause is a DNS provider migration where the new provider does not sign the zone but the registrar’s DS record — which vouches for the old provider’s keys — is never removed. The moment the old keys vanish, every validating resolver starts returning SERVFAIL. The fix is simple (delete the DS record at the registrar), but the problem is invisible to the domain owner who looks only at tools that use non-validating resolvers.

Why do high-adoption TLDs like .cz have lower breakage rates? Because end-to-end automation makes all the difference. In TLDs where registries and registrars have built automated DNSSEC workflows — including automatic DS record management during provider changes — the chain stays intact. In .com and gTLDs where DNSSEC is an opt-in minority practice configured by hand, half-finished migrations are the norm. Automation is the best prevention; awareness is the fallback.

What this means

For IT managers and security teams, broken DNSSEC is a particularly dangerous failure mode because it is completely invisible from the inside. Your monitoring stack, your own browser, and your registrar’s control panel will all show a healthy domain. The failure lands exclusively on your customers, partners, and incoming mail — people whose error messages you don’t see. If your domain is signed and you have changed DNS providers in the last year without explicitly removing and re-adding the DS record, verifying your DNSSEC chain should be treated as an urgent check, not a routine task.

For business owners, the key practical implication is about DNS migrations. Every time you move a domain from one DNS provider to another, there is one record at your registrar — the DS record — that must be removed before the migration and re-added after. Skipping this step is the cause of the vast majority of broken DNSSEC incidents. Hosting providers and registrars increasingly handle this automatically, but if any part of your DNS management is manual, this step needs to be on your migration checklist with the same priority as updating your nameservers.

For security-conscious organisations considering DNSSEC adoption, the data here argues for automation over manual management, not against DNSSEC itself. The 99.86% of signed domains that validate correctly, and the near-zero breakage rates in TLDs with automated end-to-end workflows, demonstrate that maintained DNSSEC is achievable at scale. The risk concentrates in manual, hand-configured deployments — especially in .com, where DNSSEC is an opt-in practice without the registry-level automation common in European ccTLDs. If your registrar and DNS provider both support automated DS management, use it.

Data to cite

• “157,064 graded domains have a broken DNSSEC chain, making them invisible to every validating resolver on the internet — a hard SERVFAIL with no warning to the domain owner.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “1 in 709 signed domains has a broken DNSSEC chain — 0.14% of the 111.5 million domains carrying DNSSEC material in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “.com accounts for 124,176 broken DNSSEC chains — the majority of the global broken cohort — at a breakage rate of 1.89% of its signed domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “.ovh has a broken DNSSEC rate of 12.08% among its signed domains — roughly one broken chain for every seven signed.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “High-automation ccTLDs break far less: .cz signs 63% of its domains and breaks only 0.60% of them; .nl signs 54% and breaks 0.77%.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “99.86% of signed domains validate correctly — broken DNSSEC is a preventable failure of migration hygiene, not an inherent risk of the protocol.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

A broken DNSSEC chain is invisible from the inside and free to fix. Our census grades real, live domains across 34 externally observable security checks — DNSSEC chain state included — and most of what a failing domain is missing costs nothing to repair; the barrier is almost never cost, it’s that nobody told the owner it mattered. You can check your domain privately and free, and see exactly which checks you pass.

Check your domain free at defaults.exposed — see instantly whether your DNSSEC chain validates correctly or is silently serving SERVFAIL to a third of your potential visitors. Takes 30 seconds. No account needed.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). Broken DNSSEC: 157,064 Domains Are Invisibly Down. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/the-broken-dnssec-cohort

Academic: defaults.exposed. (2026, August 18). Broken DNSSEC: 157,064 Domains Are Invisibly Down. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/the-broken-dnssec-cohort

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=111,517,232 signed domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Aggregate data only. Data stored and processed in the EU.