Is DNSSEC ready for quantum computers?

16 September 2026 · Grace

"Is your DNS post-quantum secure?" is a question that has started appearing in security questionnaires. The honest answer, from every authoritative DNS provider on the internet today, is no — and the reasons are worth understanding, because they also explain why this is less alarming than it sounds.

What is signed today, and what breaks it

DNSSEC signs records so a resolver can verify that an answer is the one the zone's owner published. The signing algorithms in production use are RSA, ECDSA and Ed25519. Almost every signed zone today uses ECDSA P-256 — small signatures, universally validated, and the current best practice.

All of them are broken by Shor's algorithm on a sufficiently large quantum computer. That is not a weakness in any particular implementation; RSA and elliptic-curve cryptography both rest on mathematical problems a quantum computer solves efficiently. When such a machine exists, a signature it produces is indistinguishable from a genuine one.

So the question is fair. The answer is just that nobody can do anything about it yet.

There is no post-quantum DNSSEC algorithm

NIST has finalised post-quantum signature standards — ML-DSA (from Dilithium) and SLH-DSA (from SPHINCS+), with FN-DSA (Falcon) still in progress. Those are real, standardised algorithms you can use today in other protocols.

None of them is standardised for DNSSEC. There is no algorithm number assigned for production use, no resolver validating them outside experiments, and no registry accepting a DS record for one. The IETF has active work — the post-quantum DNSSEC strategy draft is the one to watch — but a draft is not something a provider can deploy.

A DNS host claiming post-quantum DNSSEC today is either describing an experiment or describing something else entirely.

The blocker is size, not mathematics

This is the part most summaries leave out, and it is the reason this is taking years rather than months.

DNS answers travel over UDP, and the practical ceiling is about 1232 bytes before fragmentation becomes a problem. Post-quantum signatures are large:

A single ML-DSA signature is roughly twice the entire practical UDP budget, and a DNS response often carries several. The consequences are not academic:

• Most answers fall back to TCP, which costs a round trip and scales far worse on a busy authoritative server.
• Amplification gets worse. A large answer to a small forged query is exactly the shape of a reflection attack.
• Fragmented UDP is unreliable, and has its own security history.

Falcon-512 at 666 bytes is the only candidate that plausibly fits the existing transport, which is why it attracts attention despite FIPS 206 not being final. The realistic path involves some combination of smaller signatures, more TCP, and changes to how denial-of-existence works — none of which is a switch anybody can flip.

Why this is less urgent than it looks

Here is the nuance that makes the difference between a reasonable answer and an alarmed one.

DNSSEC provides authentication, not encryption. It proves an answer is genuine. It does not conceal anything — DNS queries and answers are public by design, and a signed zone is no more confidential than an unsigned one.

That matters because the frightening part of quantum risk is "harvest now, decrypt later": an adversary records encrypted traffic today and decrypts it once the hardware exists. That threat is real for TLS, for VPNs, for stored data, for anything confidential in transit.

It does not apply to DNSSEC. There is nothing secret in a DNS answer to harvest, and a signature that verified correctly in 2026 does not become retroactively forgeable in a way that rewrites the past. The risk is forward-looking: at the point a quantum computer exists, an attacker could forge new signatures. Nothing you publish today is quietly accumulating exposure.

The practical consequence is that DNSSEC can migrate when a standard is ready, rather than needing to have migrated already. That is not true of encryption, where the clock started years ago.

Where post-quantum actually matters for you now

If you want to be genuinely ahead on this, the place to look is TLS, not DNS.

Modern browsers and servers already negotiate hybrid post-quantum key exchange — X25519MLKEM768 — on TLS 1.3 connections where both ends support it. That protects the confidentiality of a session against exactly the harvest-now-decrypt-later threat, and it is deployed and working today rather than being a draft.

So the useful checklist is:

1. TLS 1.3 everywhere, with hybrid post-quantum key exchange where your stack supports it. This is the one with a live threat model.
2. Know what your DNSSEC signs with. ECDSA P-256 is the right answer today.
3. Have an upgrade path, which in practice means using a provider that will roll the algorithm when one is standardised, rather than a zone signed once and forgotten.
4. Be sceptical of the label. "Post-quantum DNS" as a marketing phrase, in 2026, is not describing DNSSEC.

What we do

KumoDNS signs zones with ECDSA P-256 and NSEC3 on paid plans, and manages key rollover so the algorithm can be changed without you re-doing your registrar's DS record by hand. When a post-quantum algorithm is standardised for DNSSEC and validated by real resolvers, that rollover machinery is how it will arrive.

Until then, the accurate answer to the questionnaire is: DNSSEC uses ECDSA P-256; no post-quantum DNSSEC standard exists; the threat model is future forgery rather than recorded-traffic exposure; and post-quantum key exchange is handled at the TLS layer.

That answer is better than a claim, because it is true.