2026-08-14 · RESEARCH · The Offensive Technology team

DNSSEC post-quantum readiness: 0% of the top 30,000 domains

DNSSEC post-quantum readiness across the top 30,000 domains is 0%. We read the public DNSKEY and DS records for the top 30,000 domains through validating resolvers, and of the 3,500 zones that are DNSSEC-signed, exactly zero use a post-quantum signature algorithm. The signed web runs on classical crypto: ECDSA P-256 leads at 76.6% of signed zones, RSA/SHA-256 accounts for 19.7%, and a stubborn 3.0% still sign with a deprecated SHA-1 algorithm. Overall only 11.7% of these domains are DNSSEC-signed at all, and about one in five of those has no parent DS record, so it cannot actually be validated. The headline is not that operators are lazy about post-quantum DNSSEC. It is that there is nothing for them to deploy: every standardized post-quantum signature is too large to fit in a DNS packet, so the migration that is already underway for TLS has not started for DNSSEC.

What we measured across the top 30,000 domains

We took a published top-sites list, the Tranco top 30,000, and asked a public resolver two questions about each domain: does it publish a DNSKEY record, and does its parent publish a DS record that chains it into the trust hierarchy. DNSKEY tells you a zone is signed and, in its wire format, which algorithm number it signs with. DS tells you the chain of trust actually reaches the zone, so a validating resolver can prove the records are authentic. Both are public DNS data, readable through any recursive resolver, so nothing here touches the domains themselves.

Of 29,999 domains that resolved, 3,500 (11.7%) were DNSSEC-signed. Only 2,733 (9.1%) had a full chain of trust, a DNSKEY plus a parent DS, which is the set a validating resolver can actually verify; the remaining fifth of signed zones are islands with keys but no anchor in the parent, so validation stops before it reaches them. When we asked the resolver to validate, it set the authenticated-data flag on 77.9% of the signed zones, matching the DS-backed set closely.

Then we read the algorithm number off every DNSKEY. Here is the full distribution across the 3,500 signed zones. A zone can appear under more than one algorithm during a key rollover, so the column sums slightly above 100%.

The bottom row is the finding. There is no post-quantum algorithm number in the IANA DNSSEC registry that a production zone can sign with, so the count is not small, it is zero, and it is zero by construction. Everything above it is a curve or a modulus that Shor's algorithm reduces to nothing the day a cryptographically relevant quantum computer exists.

The top domains skew ECDSA, not RSA

There is a second result buried in that table, and it matters for how you plan a migration. Population-wide DNSSEC censuses, which are dominated by the enormous tail of cheap and parked zones, report RSA as the most common algorithm by a wide margin. The public State of DNSSEC measurement, for example, puts RSA/SHA-256 first across millions of signed domains. Our slice is the opposite. Among the domains that see real traffic, the top 30,000, ECDSA and EdDSA together account for 76.9% of signed zones, and RSA appears in only 23.1%. The busy end of the internet has already moved to elliptic curve; the RSA-heavy picture is a property of the long tail, not the front page.

That flips the usual planning assumption. If you thought the DNSSEC post-quantum problem was mostly an RSA key-size problem, at the top it is really an ECDSA problem: small, fast, modern curves that are nonetheless completely classical. A post-quantum replacement has to beat ECDSA P-256 on the one axis it wins hardest, which is size, and that is exactly the axis where the post-quantum candidates are worst.

Post-quantum DNSSEC is 0%, and it is a size problem

The reason no one signs a zone with a post-quantum algorithm is not standards politics or inertia. It is that the signatures do not fit. DNS was built to answer over UDP in a single small packet, and after two decades of fragmentation-related attacks the operational consensus is to keep responses at or under roughly 1,232 bytes before a message risks IP fragmentation and has to retry over TCP. Now compare what each signature costs:

• ECDSA P-256: 64 bytes. The reason algorithm 13 won. A signed answer stays comfortably inside one packet.
• RSA-2048: 256 bytes. Larger, still workable, part of why heavy RSA zones lean on larger responses and TCP more often.
• ML-DSA-44 (FIPS 204): about 2,420 bytes. A single signature already exceeds the entire UDP budget, before you add the key, the record, and the rest of the response.
• SLH-DSA (FIPS 205): from about 7,856 bytes. Six times the whole packet budget for one signature.

A DNSSEC response often carries more than one signature, plus the DNSKEY set during a rollover. Dropping ML-DSA into that structure turns nearly every validated lookup into a truncated UDP answer followed by a TCP retry, which is slower, heavier on resolvers and authoritatives, and historically a fragile path. So the honest state of post-quantum DNSSEC is that the community is still trying to make the numbers fit. The main threads are Merkle Tree Ladder mode, which restructures hash-based signatures to amortize their size, and NIST's compact lattice signature FN-DSA (Falcon), which is still being standardized. Until one of them ships in both signers and resolvers, the census will keep reading 0%.

Why 0% is less alarming for DNSSEC than it sounds, and why it still matters

It is worth being precise about the threat, because DNSSEC is not TLS and the quantum risk is a different shape. TLS key exchange has a harvest-now-decrypt-later problem: an adversary records your encrypted traffic today and decrypts it once a quantum computer arrives. DNSSEC has no such problem, because DNSSEC signs, it does not encrypt. There is no confidential payload to harvest. The quantum risk to DNSSEC is forgery, not decryption: on the day a cryptographically relevant quantum computer can break P-256 and RSA-2048, an attacker can forge DNSSEC signatures and defeat the exact guarantee DNSSEC exists to provide, which is that the A record, the MX record, or the TLSA record you validated is authentic.

That difference buys DNSSEC time. You cannot harvest a signature today and use it after the quantum era, so there is no urgency to migrate before the machine exists, the way there is for confidentiality. But it does not make 0% safe. DNSSEC is a foundation other security controls are stacked on: DANE and SMTP transport security lean on it, and a forged chain of trust is a route to redirecting mail, defeating certificate pinning through DNS, and poisoning resolution at scale. A signed zone that is unforgeable today and forgeable the moment a quantum computer exists is a control with a hard expiry date, and right now the entire signed top 30,000 shares the same expiry.

The deprecated tail that is a problem right now

Quantum computers are a future risk. SHA-1 is a present one. 3.0% of the signed zones we measured still sign with a deprecated SHA-1 algorithm, RSASHA1 or RSASHA1-NSEC3, which RFC 8624 marks as must-not for signing. That is 104 of the most popular domains in the world validating against a hash that has been publicly broken for collision resistance for years. Separately, of the 806 RSA zones where we could read the key length off the DNSKEY, 35 (4.3%) used a key-signing key under 2,048 bits, below the current floor. Neither of these needs a quantum computer to worry about; they are legacy configurations that should have aged out already. If you run DNSSEC, the cheap win is not post-quantum, it is checking that you are not still in this 3%.

How we measured it, so a skeptic can trust the numbers

The dataset is our own, built from public records only, and reported in aggregate. We did not scan, probe, or connect to any of the domains. Everything here comes from reading public DNS records, DNSKEY and DS, through a validating recursive resolver, which is the same lookup any client on the internet performs billions of times a day. No host was touched, no zone was walked, and no information about any individual was collected. We name no domain; the numbers are counts and percentages over the population.

• The population. The Tranco top 30,000, a published, research-standard top-sites list, so the sample is reproducible and not cherry-picked. 29,999 resolved; 1 returned a hard error.
• Signed vs validatable. We counted a zone as signed if it published a DNSKEY, and as validatable if it also had a parent DS. We report both, because a DNSKEY with no DS is a common misconfiguration that looks signed but validates to nothing.
• The algorithm. The algorithm number is a field in the DNSKEY record itself, so the distribution is read directly off the wire, not inferred. We mapped each number to its IANA name and to RFC 8624's deprecation status.
• The post-quantum count. There is no allocated production algorithm number for a post-quantum scheme in the DNSSEC registry, so a zero here is a structural fact about the ecosystem, confirmed by every DNSKEY we read carrying a classical algorithm.

What this does not prove

A result without its limits is marketing, so here are the boundaries.

• One list, one moment. This is the top 30,000 domains on one day. A different list depth or a different day shifts the exact percentages, though the 0% post-quantum result is structural and will not move until the standards do.
• Server-level records only. We read DNSKEY and DS. We did not evaluate signature validity, NSEC versus NSEC3, key rollover hygiene, or resolver-side validation rates, each of which is its own measurement.
• Signed is not secure. A modern algorithm and a clean chain of trust say nothing about the rest of a domain's posture. DNSSEC authenticity is one property among many.
• Algorithm, not key strength for ECC. We read RSA key sizes where present, but the elliptic-curve share is judged by algorithm only; curve choice is fixed by the algorithm number.

Frequently asked questions

Is DNSSEC quantum safe?

No. Every DNSSEC signature algorithm in use is RSA or elliptic curve, and all of them fall to Shor's algorithm on a large quantum computer. In our census of the top 30,000 domains, 3,500 zones were signed and 0 used a post-quantum algorithm. Because DNSSEC authenticates rather than encrypts, the quantum risk is signature forgery, not harvest-now-decrypt-later decryption.

What signature algorithms does DNSSEC use?

Among the signed zones we measured, ECDSA P-256 (algorithm 13) led at 76.6%, RSA/SHA-256 (8) followed at 19.7%, and a tail used RSASHA1-NSEC3 (7), RSASHA1 (5), ECDSA P-384 (14), RSA/SHA-512 (10), and Ed25519 (15). About 3.0% still sign with a deprecated SHA-1 algorithm.

Why can't DNSSEC use post-quantum algorithms yet?

Signature size. ECDSA P-256 signs in 64 bytes; ML-DSA-44 needs about 2,420 bytes and SLH-DSA starts near 7,856. DNS responses are meant to stay under roughly 1,232 bytes over UDP before they fragment and fall back to TCP, so a single post-quantum signature already overflows the budget. That is why 0% of signed zones ship one.

How many domains use DNSSEC?

In the top 30,000, 11.7% published a DNSKEY and 9.1% had a full chain of trust with a parent DS. So about one in nine of the most popular domains is signed, and roughly one in five signed zones cannot be validated because it lacks a DS.

What percentage of DNSSEC domains are post-quantum ready?

0.00%. None of the 3,500 signed zones used a post-quantum algorithm, because there is no deployable one for DNSSEC yet. The migration has effectively not started.

When will DNSSEC move to post-quantum cryptography?

Not soon. The IETF is still working the size problem, with Merkle Tree Ladder mode and NIST's compact FN-DSA (Falcon) as the leading paths. Until one ships in signers and resolvers, the census stays at 0%.

Related reading

• Certificate transparency post-quantum: 43% of static-CT logs already sign with ML-DSA-44. The one signed surface that has already started its post-quantum migration, measured across every static-CT log.
• Does FIPS disable post-quantum TLS? The other half of the post-quantum story, measured on the TLS wire instead of in DNS.
• How many top domains restrict certificate issuance? The same passive, our-own-data method applied to the public certificate ecosystem.
• What the certs prove. Reading cryptographic assurances off public records instead of trusting the label.