DNSSEC has been standardized since 2005, and the root zone has been signed since 2010. The original analysis reported 4.27% of names with a parent DS record among 240.3 million delegations in a February 2026 corpus. A separate July calculation reported 5.22%. These are historical corpus observations, with the measurement and provenance limits below.
The reported counts raise a useful operational question: what makes DNSSEC easier to deploy and maintain? They do not establish why a particular domain lacks a parent DS record, or how many domains successfully validate end to end.
How I Measured This
The original analysis reported 240,337,821 names from files dated February 14, 2026 and counted DS records at parent delegations. A DS declares a link to a child key; it does not prove that the key, signatures, and full chain validate successfully. A signed child without a parent DS can also exist. These figures therefore describe reported parent-DS presence, not a measurement of all signed zones or working end-to-end DNSSEC. RFC 4035 distinguishes secure, insecure, and bogus data.
Provenance limit (September 2026): The original publication date precedes the stated February 14 snapshot. The file manifest, extraction code, and explanation of the 1,929-zone scope are not published here, so the chronology and corpus cannot yet be independently reconstructed. The IANA root-zone database identifies TLD entries; a count of files alone does not establish the number of distinct delegated TLDs. The historical dates and figures are retained as reported; do not treat this update as a fresh measurement.
The result: 10,256,892 delegations with a DS record, 230,080,929 without. A reported parent-DS presence rate of 4.27%.
Update, July 2026
The July 2026 update reported 276,515,965 delegations across 1,109 TLDs with published DNSSEC data, with roughly 14.4 million parent-DS-bearing delegations, a rate of 5.22%. This is a second reported calculation, not a fresh September measurement or a verified longitudinal adoption rate.
Two caveats before you read that as a clean time series. The corpora are not identical: the February run reported 1,929 zone files of unresolved scope, while this recomputation covers the TLDs for which the current dataset publishes DNSSEC figures, so some of the movement is composition rather than adoption. And 5.22% is domain-weighted. The unweighted mean of per-TLD rates is 9.21%, about 1.8 times the domain-weighted rate, because the small, heavily signed ccTLDs like .se and .ch count the same as .com in that calculation. These reported statistics weight the observations differently, and quoting one as the other is the single easiest way to get DNSSEC statistics wrong.
The discussion that follows uses the historical February figures as context. The proposed explanations are hypotheses; the dataset does not isolate their effects.
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
Provider automation is one possible contributor to deployment. Comparing TLD-level DS rates alone cannot separate provider defaults from registry policy, registrar behavior, or the types of domains in each zone.
The historical report lists .page at 35.72%, .zip at 28.32%, .dad at 26.59%, and .ovh at 38.66%. These are parent-DS ratios within particular TLDs. A registry operator is not necessarily the authoritative DNS host or registrar for every name in its zone, so these figures are not provider-specific success rates.
The report lists lower parent-DS ratios for .top (0.34%), .xyz (0.87%), and .shop (0.21%). Identifying why they differ requires matched domain, provider, policy, and time data beyond these aggregate counts.
Automation can reduce manual key and DS maintenance, but domain owners and registrars still have roles in deployment. This analysis does not show that provider defaults alone determine adoption.
Automated certificate issuance offers an analogy for reducing administrative work. It does not supply a measured forecast for DNSSEC: the deployment paths and validation requirements differ.
The Invisible Benefit Problem
Browsers expose HTTPS connection information and warnings, but do not generally provide a DNSSEC status indicator for the name resolution used by a page.
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
- A browser visit alone does not report DNSSEC validation status to the domain owner
That limited visibility can make the benefit harder to explain to business stakeholders. It does not mean DNSSEC has no operational or business value, and this dataset did not measure purchasing decisions.
DNSSEC authenticates DNS data where a valid chain exists. That benefit should be evaluated alongside the monitoring and rollover work required to maintain it.
The Chicken-and-Egg Problem
Protection requires both a signed chain and a resolver that validates it. A deployment gap on either side reduces coverage. This dataset counts parent DS records; it does not measure the share of users behind validating resolvers or prove that either group delays deployment because of the other.
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.
DNSSEC configuration errors can make validating resolvers reject otherwise reachable names. Other security controls can also fail closed: DMARC enforcement can cause mail rejection, and HSTS prevents clicking through TLS certificate errors. These are operational tradeoffs, not a unique DNSSEC property. See DMARC and HSTS error handling.
Key rollovers, algorithm migrations, and DS/DNSKEY mismatches need monitoring because errors can break validation. The corpus does not quantify incident frequency or show that operational fear caused the reported DS ratios.
Automation can reduce manual work. RFC 8078 describes CDS/CDNSKEY-based delegation trust maintenance, and RFC 8901 describes multi-signer DNSSEC models. Neither removes the need to verify the chain during a change.
Signing isn't entirely free of side effects, though. The original NSEC record used for authenticated denial of existence can let an attacker enumerate every name in a signed zone, a technique I break down in my piece on DNS zone walking. NSEC3 was designed to make this harder, and at the TLD level it's a real consideration, but for the typical signed domain the privacy exposure is minor compared to the authentication it buys.
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%.
The reported .bank and .insurance ratios are about twelve times the February corpus-wide parent-DS ratio. fTLD’s security requirements include DNSSEC, but this cross-sectional comparison does not isolate the effect of that policy.
A figure below 100% does not identify the cause of the gap. The corpus may include different domain states, and a DS count is not an audit of policy compliance. There is no before-and-after experiment here showing a change from 4% to 50%.
Deployment Options to Evaluate
These are proposals to evaluate, not effects measured or ranked by this dataset:
1. Registrar Opt-Out Instead of Opt-In
Registrar and DNS-provider automation could make signing and DS maintenance easier. Estimating its effect would require adoption and validation measurements before and after a rollout; this corpus cannot support a prediction that global adoption would triple within a year. Provider defaults remain relevant to the concentration of DNS services.
2. Browser Signals for DNSSEC
A browser indicator is a possible product idea, but it would need trustworthy resolver validation status and usability testing. The data here cannot establish that a badge would cause domain owners to deploy DNSSEC.
3. ICANN Mandates for High-Risk TLDs
Sector-specific requirements are another policy option. Their benefits, deployment costs, and effectiveness would need separate evaluation; the reported TLD ratios alone do not prove the effect of a mandate.
What This Means for Security
The reported 95.73% without parent DS records should not be described as a count of unsigned or demonstrably vulnerable domains. Without an authenticated DNSSEC chain, DNSSEC cannot authenticate the answer, but other protections still matter. Resolver reply matching, network defenses, TLS verification, and certificate-issuance controls affect whether an attack succeeds.
A DS record is only one link in that chain. Monitor the actual validation result and operational dependencies as well as the presence of records.
For the current TLD-by-TLD DNSSEC adoption rates, see the DNSSEC rankings. For TLDs with critically low adoption, see the DNSSEC gaps analysis.