up:: In the Protocols MOC

PQC in DNSSEC

DNSSEC is the set of extensions that lets a DNS resolver verify that the address it received for a name is authentic and unaltered, by having each zone sign its records so a chain of signatures links the answer back to the root. It is one of the hardest protocols in the whole migration to make post-quantum, and the hard part is the packet rather than the cryptography. DNS answers are expected to fit inside a small UDP datagram, classical signatures like RSA and ECDSA were small enough to live inside that budget, and every standardized post-quantum signature is several times larger, which pushes signed answers past the size the DNS ecosystem hardened around.

An early deployment step landed in September 2026, when Cloudflare’s public resolver 1.1.1.1 began validating ML-DSA-44 signatures by default, and the work now has two problems to solve: carrying large signatures over a transport built for small ones, and stopping zones that publish both classical and post-quantum signatures from being downgraded to the classical ones.

Sources: S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy; S. Neuteboom and B. Westerbaan, “1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it,” Cloudflare, September 10, 2026, blog.cloudflare.com.

The short version:

• DNSSEC signs DNS records so resolvers can verify answers, and those signatures ride inside DNS responses that are expected to fit a small UDP packet, with 1,232 bytes as a common default EDNS buffer.
• Classical DNSSEC signatures are small (64 bytes for ECDSA P-256). Post-quantum ones are large: ML-DSA runs 2,420 to 4,627 bytes and SLH-DSA runs 7,856 to 49,856 bytes, so one signature overruns the whole budget and the answer comes back truncated, pushing the resolver to retry over TCP.
• In September 2026 Cloudflare’s 1.1.1.1 began validating ML-DSA-44 by default. IANA has assigned ML-DSA-44 DNSSEC algorithm number 18, and its use is specified in the “ML-DSA for DNSSEC” Internet-Draft. Signing support still has to reach authoritative servers, registrars, registries, and ultimately the root.
• Zones will publish classical and post-quantum signatures side by side for years, and RFC 6840 tells validators to accept any single valid path, which becomes a downgrade path once classical signatures can be forged. 1.1.1.1 closes it by requiring a valid ML-DSA-44 path whenever the parent’s DS records list the algorithm.
• DNSSEC is Non-HNDL because nothing is encrypted, so the threat is a forge-later attack on the chain of trust, where Cloudflare’s summary of a recovered root signing key is “break once, forge everywhere.”

Picture the postal service where every letter of proof has to fit on a single index card so it can travel through the fast automated sorters. For years the proof stamps were tiny and always fit. The new quantum-resistant proof stamps are the size of a full sheet of paper, and a full sheet overflows the card, so it either gets folded into several cards that have to be reassembled or diverted to the slow manual line. The message is still deliverable, and the fight is entirely about the size of the stamp against the size of the card.

Why is DNSSEC uniquely hard for post-quantum cryptography?

Because DNS was engineered around small answers delivered over UDP, and post-quantum signatures break that size assumption more severely here than almost anywhere else. DNS Flag Day 2020 recommended a default EDNS buffer size of 1,232 bytes, stating that it “will avoid fragmentation on nearly all current networks” and that it “is based on an MTU of 1280, which is required by the IPv6 specification, minus 48 bytes for the IPv6 and UDP headers.” RFC 9715, published in January 2025, later set a recommended maximum DNS/UDP payload size of 1,400 bytes. Either figure is the practical budget a DNSSEC answer wants to stay inside.

Against that budget, the standardized post-quantum signatures are enormous. The Sheth, Chung, and Overeinder strategy draft puts ML-DSA signatures at 2,420 to 4,627 bytes and SLH-DSA signatures at 7,856 to 49,856 bytes, so even the smallest post-quantum signature is about twice the entire recommended packet budget. Cloudflare’s own comparison puts the ML-DSA-44 signature at “almost 38 times larger” than the 64-byte signature of ECDSA P-256, which it gives as an example of the DNSSEC algorithms “commonly used today”. The Fregly et al. draft names signed NSEC and NSEC3 responses, the answers that prove a name does not exist, as a case where post-quantum signatures “may exceed UDP MTUs,” and adds that larger signatures could substantially increase memory needs for authoritative zone databases and resolver caches.

Algorithm	DNSSEC number	Public key	Signature	Versus a 1,232-byte UDP budget
RSA-2048 / SHA-256 (classical)	8	260 bytes	256 bytes	Fits comfortably
ECDSA P-256 (classical)	13	64 bytes	64 bytes	Fits comfortably
ML-DSA-44	18	1,312 bytes	2,420 bytes	One signature exceeds the whole budget
ML-DSA, all parameter sets			2,420 to 4,627 bytes	Exceeds the whole budget
SLH-DSA, all parameter sets			7,856 to 49,856 bytes	Many times the budget

Sources: DNS Flag Day 2020, dnsflagday.net/2020; K. Fujiwara, P. Vixie, “IP Fragmentation Avoidance in DNS over UDP,” RFC 9715, January 2025, rfc-editor.org (recommendation R5, maximum DNS/UDP payload size 1400); S. Sheth, T. Chung, B. Overeinder, draft-sheth-pqc-dnssec-strategy-01 §3.1 (ML-DSA and SLH-DSA size ranges); A. Fregly, J. Harvey, B. Kaliski, D. Wessels, draft-fregly-dnsop-slh-dsa-mtl-dnssec-06 §1 (NSEC/NSEC3 and memory); Cloudflare, September 10, 2026, blog.cloudflare.com (algorithm numbers, key and signature sizes for RSA-2048, ECDSA P-256, and ML-DSA-44). ML-DSA-44 sizes also match NIST FIPS 204 Table 2.

What actually breaks when the answer gets too big?

The transport degrades in two ways, and both hurt DNS at the scale where it has to be fast and universally reachable. The failure modes:

1. UDP fragmentation. When a UDP answer exceeds the path MTU, IP fragments it into multiple packets that must all arrive and reassemble. DNS Flag Day 2020 states that “IP fragmentation is unreliable on the Internet today, and can cause transmission failures when large DNS messages are sent via UDP,” and that even working fragmentation “may not be secure,” because parts of a fragmented message can in theory be spoofed. RFC 9715 goes further and tells UDP requestors to drop fragmented DNS responses without reassembly, to avoid cache poisoning.
2. Truncation and TCP fallback. The avoidance path is for the authoritative server to send a truncated response, which prompts the resolver to retry over another transport, usually TCP. Cloudflare’s own test query against its ML-DSA-44-signed zone shows exactly this: the tool reports “truncated reply from 1.1.1.1@53(UDP), retrying over TCP,” and the answer finally arrives as a 2,563-byte message over TCP. The strategy draft warns that post-quantum signature sizes risk “excessive TCP fallback, latency, and resolver performance degradation.”

So the binding constraint on post-quantum DNSSEC is an operational one. The algorithms are secure; their outputs overflow the pipe DNS was built to run through, and forcing them through it costs the reliability and speed that make DNS usable. That framing is why so much of the standards work targets size and transport.

Sources: DNS Flag Day 2020, dnsflagday.net/2020; RFC 9715 recommendation R6, rfc-editor.org; Cloudflare, September 10, 2026, blog.cloudflare.com (truncation and the dig output); draft-sheth-pqc-dnssec-strategy-01 §3.1.

Does any DNS resolver validate post-quantum DNSSEC today?

Yes. On September 10, 2026, Cloudflare announced that its public resolver 1.1.1.1 “now validates DNSSEC signatures made with ML-DSA-44,” with validation enabled by default. Cloudflare calls it “a first step toward preparing DNSSEC” for the day today’s signature algorithms can be broken, and says the purpose is to test two problems at Internet scale: carrying the larger responses, and preventing fallback to conventional signatures.

What makes that possible is that ML-DSA-44 now has the prerequisites an algorithm needs before anyone can deploy it in DNSSEC. NIST standardized it in FIPS 204, IANA’s DNSSEC algorithm registry lists it as number 18 with the mnemonic MLDSA44, and its encoding is specified in the Internet-Draft “Module-Lattice Digital Signature Algorithm for DNSSEC” by B. Westerbaan of Cloudflare and S. Schmieg of Google. The registry entry marks it MAY for signing and validation and cites revision -03 of that draft; revision -04 is dated August 11, 2026, lists its intended status as Standards Track, and remains an Internet-Draft rather than an RFC.

Validation is one link in the chain, and Cloudflare lists the rest: authoritative servers must sign zones with ML-DSA-44, registrars must accept and submit the matching DS records, registries must publish them in parent zones, and the adoption “must extend through every parent zone to the DNS root,” whose post-quantum key must become a resolver trust anchor. Its stated reason for starting with the resolver is that “there is little value in signing a zone with ML-DSA-44 if no resolver validates its signatures.”

Step on the path to a post-quantum chain of trust	Status as Cloudflare describes it, September 2026
Algorithm standardized (FIPS 204)	Done
IANA DNSSEC algorithm number	Assigned, number 18
Protocol specification	Internet-Draft, draft-westerbaan-dnssec-mldsa
Validating resolver	1.1.1.1 validates ML-DSA-44 by default
Signing at the authoritative server	Announced as Cloudflare’s next step for its Authoritative DNS
DS records at the registrar	Announced as Cloudflare’s next step for its Registrar
Every parent zone up to the root, and a post-quantum root trust anchor	Required, and still ahead

Cloudflare says the authoritative signing and registrar DS support “will be available to all customers for free,” and that it will also run background probes on “a small fraction of Cloudflare Challenge Pages” to test whether clients can resolve and reach an ML-DSA-44-signed test domain across real networks. Cloudflare operates the resolver and sells the authoritative DNS and registrar products involved, and one author of its post also co-authors the Internet-Draft, so the deployment claims above are Cloudflare’s own account of its own product.

Sources: Cloudflare, September 10, 2026, blog.cloudflare.com; IANA, “Domain Name System Security (DNSSEC) Algorithm Numbers,” last updated 2026-08-10, iana.org; B. Westerbaan, S. Schmieg, “Module-Lattice Digital Signature Algorithm for DNSSEC,” draft-westerbaan-dnssec-mldsa-04, August 11, 2026, datatracker.ietf.org.

How do you stop a downgrade when a zone publishes both classical and post-quantum signatures?

By giving the validator an authenticated reason to insist on the post-quantum signature, because the default DNSSEC rule lets it settle for either. A zone that published only ML-DSA-44 would leave every resolver without ML-DSA-44 support unable to validate it, so the practical migration publishes both algorithms together. That preserves compatibility and, on its own, adds no post-quantum security, because of how validators are told to treat multiple algorithms.

1. The default rule accepts any path. RFC 6840 §5.11 states that its signing rules “apply to servers, not validators,” and that “Validators SHOULD accept any single valid path. They SHOULD NOT insist that all algorithms signaled in the DS RRset work.”
2. That rule becomes the attack. The ML-DSA for DNSSEC draft names the consequence in its Downgrades section: such “lenient validators are vulnerable to a downgrade attack: if a zone is signed by ML-DSA-44 and a quantum-vulnerable algorithm, then a quantum attacker can strip the ML-DSA-44 signatures, and have the lenient validator accept the forged quantum-vulnerable signature.”
3. The parent’s DS records mark the zone. 1.1.1.1 treats the DS records published by the parent zone as the authenticated indication. If the authenticated DS RRset contains a record for a supported post-quantum algorithm, the resolver “requires at least one valid post-quantum validation path,” and “if no ML-DSA-44 path validates, validation fails.” The draft describes the same defense: a validator “that insists on the presence of a valid ML-DSA-44 RRSIG when the availability is advertised in the zones DS, also evades the downgrade.”
4. Local policy is what permits it. Cloudflare says this “is not (yet) normal DNSSEC validation behavior,” and grounds it in RFC 4035 §5.3.3, which says that when several RRSIGs cover an RRset, “the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts.”
5. It only holds end to end. Per Cloudflare, the protection “is only post-quantum secure if ML-DSA-44 deployment and downgrade protection extend from the trust anchor through every delegation,” and “any level without post-quantum protection remains a downgrade point.”

Conventional signatures therefore stay available for older resolvers while post-quantum-capable resolvers are prevented from falling back to them. This is the DNSSEC form of the rule taught in Downgrade and Rollback Attacks: offering the strong algorithm protects nobody until the verifier refuses the weak one when the strong one was promised.

Sources: S. Weiler, D. Blacka, “Clarifications and Implementation Notes for DNS Security (DNSSEC),” RFC 6840 §5.11, February 2013, rfc-editor.org; R. Arends et al., “Protocol Modifications for the DNS Security Extensions,” RFC 4035 §5.3.3, March 2005, rfc-editor.org; draft-westerbaan-dnssec-mldsa-04 §7.2, datatracker.ietf.org; Cloudflare, September 10, 2026, blog.cloudflare.com.

How is the IETF approaching post-quantum DNSSEC?

Three lines of work are in motion, and they answer the size problem in different ways.

1. Carry ML-DSA-44 directly. draft-westerbaan-dnssec-mldsa specifies ML-DSA keys and signatures in DNSSEC using the ML-DSA-44 parameter set from FIPS 204, and IANA has assigned it algorithm number 18. This track accepts the 2,420-byte signature and relies on truncation and TCP to carry it, which is what 1.1.1.1 is now measuring at scale.
2. Conservative, size-mitigated algorithms. The Sheth, Chung, and Overeinder strategy draft proposes deploying “currently standardized post-quantum secure algorithms that provide cryptographic confidence and resilient fallback,” naming SLH-DSA in Merkle Tree Ladder mode, Falcon, XMSS, and LMS, with MTL mode used to amortize signature size across many responses.
3. Low-impact drop-in algorithms. The same draft proposes newer schemes “that remain under NIST onramp evaluation or under consideration by other standards bodies,” naming MAYO and SNOVA, chosen for “routine performance with minimal operational impact” even though they “may leverage newer but less well-established mathematical concepts.”

The strategy draft’s dual-track logic is a hedge: the conservative algorithms carry more confidence but need size-mitigation machinery, and the low-impact algorithms fit the transport more naturally but rest on younger assumptions, so running both keeps a resilient fallback available while the smaller schemes mature. Its recommended next steps include evaluating “the impact of increased truncated responses and traffic over TCP” on resolvers and authorities, which is the measurement the ML-DSA-44 deployment is now producing. The strategy draft’s authors are at Verisign Labs, Virginia Tech, and NLnet Labs; the ML-DSA draft’s authors are at Cloudflare and Google.

Sources: S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy-01, April 17, 2026, §4 and §6, datatracker.ietf.org; draft-westerbaan-dnssec-mldsa-04, datatracker.ietf.org; IANA DNSSEC algorithm registry, iana.org.

What is Merkle Tree Ladder mode, and how does it help?

Merkle Tree Ladder (MTL) mode is a way of packaging a stateless hash-based signature so that most DNS responses carry a small proof instead of a full, oversized signature. The draft-fregly-dnsop-slh-dsa-mtl-dnssec document specifies applying SLH-DSA in MTL mode to DNSSEC, covering the DNSKEY and RRSIG code points, algorithm numbers, and an EDNS(0) option for retrieving signature data.

The core move is a dual-signature structure. Instead of attaching a full SLH-DSA signature to every record, MTL mode has RRSIG records “primarily comprised of ‘condensed signatures’ (Merkle proofs / authentication paths)” and “only occasionally comprised of ‘full signatures’” that include the signed ladder. Because the per-response object is usually the small proof, MTL mode shrinks what travels on the wire for a typical answer and reduces the signature data an authoritative server holds in its zone database or a resolver holds in its cache. The draft notes that other combinations, such as ML-DSA in MTL mode, are possible and would be described in separate documents.

Source: A. Fregly, J. Harvey, B. Kaliski, D. Wessels, “Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC,” draft-fregly-dnsop-slh-dsa-mtl-dnssec-06, March 30, 2026, §1, datatracker.ietf.org.

Is post-quantum DNSSEC urgent, and what should you do now?

It runs on the machine’s arrival clock, and the coordination it needs is long enough that the work starts now. DNSSEC proves an answer is authentic and encrypts nothing, so there is no recorded traffic for a future quantum computer to decrypt. Cloudflare puts it directly: DNSSEC “provides authenticity rather than confidentiality, so it is not subject to ‘harvest now, decrypt later’ attacks.” That makes it Non-HNDL, and the pressure is the day a capable quantum computer can recover a signing key and forge answers, which is a forge-later attack.

Two facts from the Cloudflare post set the stakes. The first is the blast radius at the top of the hierarchy: “An attacker who recovers a root zone signing key using a quantum computer could forge a validation path to any zone below it: ‘break once, forge everywhere’.” The second is that faster key rotation does not help, because “an attacker can target a vulnerable key anywhere higher in the chain and forge every delegation below it.” Cloudflare’s stated reason to begin now is that changing DNSSEC “requires coordination across authoritative servers, registries, registrars, and validating resolvers,” and it describes its planning assumption as “the possibility that in 2030 a sufficiently powerful quantum computer could be built,” alongside its company target of full post-quantum security by 2029.

The practical read for an operator has four parts:

1. The specification exists as a draft, and one major resolver validates it. ML-DSA-44 has an IANA algorithm number and an Internet-Draft, and 1.1.1.1 validates it by default. The draft is still an Internet-Draft, signing support is still arriving at authoritative providers and registrars, and the root has no post-quantum key, so there is no complete post-quantum chain to adopt yet.
2. Test before you need it. Cloudflare publishes an ML-DSA-44-signed test zone (valid.mldsa44.dnstest.dev) that can be queried through 1.1.1.1, which is a cheap way to see whether your own network path handles the truncated-then-TCP response. Cloudflare says 1.1.1.1 users need to change nothing, and existing DNSSEC zones continue to validate as before.
3. Prepare with agility. Build crypto-agility into your DNSSEC signing pipeline, meaning the ability to add a new signing algorithm and a new key without re-architecting, and make sure your registrar can publish DS records for new algorithm numbers.
4. Plan the capacity if you run large zones. More truncated responses and more TCP between resolvers and authoritative servers are capacity inputs to raise with your DNS provider now, and DNSKEY responses grow further during a transition, because Cloudflare notes they may carry both conventional and post-quantum keys and signatures, with key rollovers adding more.

Sources: Cloudflare, September 10, 2026, blog.cloudflare.com; draft-sheth-pqc-dnssec-strategy-01.

Common misconceptions

• “DNSSEC encrypts DNS, so it is a harvest-now-decrypt-later target.” DNSSEC signs DNS records for authenticity and encrypts nothing, so there is no recorded ciphertext to decrypt later. It is a signature problem, and confidentiality of DNS queries is a separate concern handled by DNS-over-TLS or DNS-over-HTTPS.
• “You can just swap RSA for ML-DSA in DNSSEC and be done.” A direct swap produces answers several times the recommended UDP packet budget, forcing truncation and TCP retries at scale, and a swap that removes the classical algorithm leaves every resolver without ML-DSA-44 support unable to validate the zone. The migration publishes both, which is why downgrade protection matters.
• “Publishing an ML-DSA-44 signature next to the ECDSA one makes my zone quantum-safe.” Under RFC 6840 a validator may accept any single valid path, so once ECDSA can be forged an attacker strips the post-quantum signature and presents a forged classical one. Protection comes from validators that require the post-quantum path when the parent’s DS records list it, and only when that holds at every level up to the trust anchor.
• “Rotating DNSSEC keys more often defends against a quantum forger.” Cloudflare notes that an attacker can target a vulnerable key anywhere higher in the chain and forge every delegation below it, so a fresh key in your zone leaves the parent’s classical key as the target.
• “The problem is that post-quantum signing is slow.” The binding constraint is size on the wire and the transport effects it triggers. A signature that is secure and fast is still a problem if it does not fit the packet.
• “Nothing validates post-quantum DNSSEC yet.” Since September 2026, Cloudflare’s 1.1.1.1 validates ML-DSA-44 (algorithm 18) by default. The chain is still incomplete above most zones, because signing, registrar support, and a post-quantum root key are still ahead.

Questions people ask

Why is DNSSEC harder to make post-quantum than TLS? Because DNS answers are expected to fit a small UDP packet, with 1,232 bytes as a common default, and post-quantum signatures are several times that size, so signed answers overrun the transport. TLS absorbs a large key exchange in a handshake, while DNSSEC has to carry large signatures inside size-constrained answers.

How big are post-quantum DNSSEC signatures? ML-DSA signatures run 2,420 to 4,627 bytes and SLH-DSA signatures run 7,856 to 49,856 bytes, against a recommended DNS UDP budget near 1,232 bytes. The ML-DSA-44 signature used in DNSSEC today is 2,420 bytes with a 1,312-byte public key, against 64 bytes each for ECDSA P-256.

Does 1.1.1.1 support post-quantum DNSSEC? Yes, as a validator. Since September 10, 2026, Cloudflare’s 1.1.1.1 validates DNSSEC signatures made with ML-DSA-44 by default. Cloudflare has announced ML-DSA-44 signing for its Authoritative DNS and DS record support for its Registrar as its next step.

What is DNSSEC algorithm 18? It is the IANA-assigned DNSSEC algorithm number for ML-DSA-44, mnemonic MLDSA44, specified in the Internet-Draft draft-westerbaan-dnssec-mldsa. RSA-2048 with SHA-256 is algorithm 8 and ECDSA P-256 is algorithm 13.

What happens if a DNSSEC answer is too big for UDP? The authoritative server returns a truncated response and the resolver retries, usually over TCP, which adds a round trip. Sending it as fragmented UDP instead is unreliable and exposed to spoofing, which is why RFC 9715 tells requestors to drop fragmented DNS responses.

Why does 1.1.1.1 refuse a valid ECDSA answer from a zone that also signs with ML-DSA-44? Because accepting it would open a downgrade. When the parent zone’s authenticated DS records list a supported post-quantum algorithm, 1.1.1.1 requires at least one valid ML-DSA-44 path, and if none validates, validation fails. RFC 4035 leaves that choice to local resolver policy.

What is Merkle Tree Ladder mode for? It packages SLH-DSA so most DNS responses carry a small Merkle inclusion proof instead of a full oversized signature, with the full signature sent only occasionally. That shrinks the common-case answer and reduces the signature data servers and caches must store.

Do I need to migrate my DNSSEC now? Start preparing now and deploy when your provider and registrar can carry it. DNSSEC is Non-HNDL, so nothing is being harvested, but the chain has to be post-quantum from the root down before a forger is locked out, and Cloudflare expects wide ecosystem support to be “a process likely to take years.” Keep your signing agile, confirm your registrar can publish DS records for new algorithms, and test your network path against an ML-DSA-44-signed zone.

---

Everything here is the map, given freely. When your team needs its DNS and DNSSEC dependencies inventoried and a post-quantum signing plan sequenced with your providers, that’s a working session with your team.

Last verified 2026-09-15 · Updated 2026-09-15 · Maintained by Addie LaMarr, LaMarr Labs.