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 reason is not the cryptography but the packet. 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 quietly hardened around. The current IETF work is therefore less about picking an algorithm and more about making large signatures survivable on a transport built for small ones.
Source: S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy.
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, historically an EDNS buffer around 1232 bytes.
- Classical DNSSEC signatures (RSA, ECDSA, Ed25519) are small. Post-quantum ones are large: ML-DSA runs roughly 2420 to 4627 bytes and SLH-DSA runs roughly 7856 to 49856 bytes, so a single signature can exceed the whole packet budget.
- Oversized answers force a fallback from UDP to TCP or risk IP fragmentation, both of which degrade DNS reliability and speed at the scale the root and top-level zones operate.
- The IETF work splits into two tracks: shrinking or amortizing signatures through special modes (SLH-DSA in Merkle Tree Ladder mode), and evaluating newer small-signature algorithms from the NIST signature onramp (MAYO, SNOVA).
- DNSSEC is a signature problem, not a key-exchange one, so it is Non-HNDL: nothing is harvested for later decryption, and the pressure is authenticity and operational feasibility rather than a harvesting clock.
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 an EDNS UDP buffer size of 1232 bytes, chosen because the IPv6 minimum MTU is 1280 bytes and subtracting the IPv6 and UDP headers leaves 1232, so responses at or under that size avoid IP fragmentation on nearly all networks. That figure is the practical size budget a DNSSEC answer wants to stay inside.
Against that budget, the standardized post-quantum signatures are enormous. ML-DSA signatures run roughly 2420 to 4627 bytes depending on parameter set, and SLH-DSA signatures run roughly 7856 to 49856 bytes, so even the smallest post-quantum signature is about twice the entire recommended packet budget, and a single signed record can carry more than one signature. A signed NSEC or NSEC3 denial-of-existence response, which proves that a name does not exist, can include two or three signatures at once, multiplying the overrun. The result is that a straightforward drop-in of a post-quantum signature would routinely produce answers several times the size DNS transports comfortably.
| Signature scheme | Approx. signature size | Versus the ~1232-byte DNS UDP budget |
|---|---|---|
| ECDSA P-256 (classical) | ~64 bytes | Fits comfortably |
| Ed25519 (classical) | ~64 bytes | Fits comfortably |
| RSA-2048 (classical) | ~256 bytes | Fits comfortably |
| ML-DSA | ~2420 to 4627 bytes | Exceeds the whole budget |
| SLH-DSA | ~7856 to 49856 bytes | Many times the budget |
Source: DNS Flag Day 2020, dnsflagday.net/2020 (recommended EDNS buffer 1232 bytes, based on IPv6 minimum MTU 1280 minus 48 bytes of headers); S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy (post-quantum signature-size figures).
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:
- UDP fragmentation. When a UDP answer exceeds the path MTU, IP fragments it into multiple packets that must all arrive and reassemble. Fragmented DNS is unreliable in the modern internet: many firewalls and middleboxes drop IP fragments, and fragmentation has its own security concerns, which is exactly why the ecosystem moved to the conservative 1232-byte budget to avoid it.
- TCP fallback. When an answer will not fit UDP, the resolver retries over TCP, which adds a connection setup round trip and far more per-query state on the authoritative servers. At the query volumes of the root and the large top-level domains, a broad shift from UDP to TCP is a real capacity and latency cost, not a rounding error.
So the binding constraint on post-quantum DNSSEC is an operational one rather than a cryptographic one. The algorithms are secure; the problem is that their outputs overflow the pipe DNS was built to run through, and forcing them through it degrades the reliability and speed that make DNS usable. That framing is why the standards work targets the size and the transport rather than reaching for a different security guarantee.
Source: S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy.
How is the IETF approaching post-quantum DNSSEC?
The strategy draft proposes running two categories of algorithm together, so DNS gets both a resilient conservative option and a lower-overhead routine option during the transition. The two tracks:
- Conservative, size-mitigated algorithms. These are established hash-based and lattice schemes used in a mode that reduces their operational footprint. The draft names SLH-DSA in Merkle Tree Ladder mode, Falcon, XMSS, and LMS, and pairs them with modes of operation that amortize a large signature across many DNS responses rather than shipping it whole every time.
- Low-impact drop-in algorithms. These are newer small-signature schemes under evaluation in the NIST signature onramp, named in the draft as MAYO and SNOVA, chosen for minimal operational impact even though their mathematical foundations are less battle-tested than the conservative set.
The dual-track logic is a hedge. The conservative algorithms carry more confidence but need size-mitigation machinery to be practical in DNS, and the low-impact algorithms fit the transport more naturally but rest on younger security assumptions, so running both keeps a resilient fallback available while the smaller schemes mature. The draft is authored by researchers at Verisign Labs, Virginia Tech, and NLnet Labs, which are exactly the operators and researchers who run and study the DNS at scale.
Source: S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy-01, April 2026, datatracker.ietf.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, defining the key formats, signature structures, algorithm numbers, and an EDNS 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 most responses carry a condensed signature, which is a compact Merkle-tree inclusion proof that verifies against a periodically issued ladder, and only occasionally carry the full signature that anchors the ladder. Because the per-response object is usually the small proof rather than the whole signature, MTL mode both shrinks what travels on the wire for a typical answer and reduces the signature data an authoritative server has to hold in its zone database or cache. It converts a scheme with very large signatures into one whose common-case response is small enough to be workable in DNS.
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 2026, datatracker.ietf.org.
Is post-quantum DNSSEC urgent, and what should you do now?
It is real but not on the harvest-now clock, so the honest posture is to track the standards and keep your DNSSEC signing agile rather than to rush a migration that the specifications have not settled. DNSSEC provides authenticity, not confidentiality: it proves an answer is genuine, and it does not encrypt anything, so there is no recorded traffic that a future quantum computer decrypts. That makes it Non-HNDL, and it means the pressure is the day a capable quantum computer could forge a DNSSEC signature live, not a window that is already open.
The practical read for an operator has three parts:
- No profile to deploy yet. The algorithms and size-mitigation modes are still in IETF drafts, so there is no stable post-quantum DNSSEC profile to adopt today, and moving early would mean betting on a specification that can still change.
- Prepare with agility. The sensible preparation is crypto-agility in your DNSSEC signing pipeline, meaning the ability to roll to a new signing algorithm and a new key without re-architecting, so you can adopt whichever profile wins.
- Plan the capacity if you run large zones. For high-value or high-volume zones, the size and transport effects, the shift toward TCP and the MTU sensitivity, are capacity-planning inputs to raise with your DNS provider now, because they land on infrastructure rather than on application code.
Source: S. Sheth, T. Chung, B. Overeinder, “Post-Quantum Cryptography Strategy for DNSSEC,” draft-sheth-pqc-dnssec-strategy.
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 fragmentation or TCP fallback at scale. The whole difficulty is making large signatures survivable on DNS transport, which is why special modes and small-signature candidates are being developed.
- “The problem is that post-quantum signing is slow.” The binding constraint is size on the wire and the transport effects it triggers, not signing or verification speed. A signature that is secure and fast is still a problem if it does not fit the packet.
- “There is a post-quantum DNSSEC standard to deploy today.” The algorithms and size-mitigation modes are active IETF drafts, so there is no settled profile yet. The right move now is agility in the signing pipeline, ready to adopt the profile that standardizes.
Questions people ask
Why is DNSSEC harder to make post-quantum than TLS? Because DNS answers are expected to fit a small UDP packet, historically around 1232 bytes, 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 roughly 2420 to 4627 bytes and SLH-DSA signatures run roughly 7856 to 49856 bytes, against a recommended DNS UDP budget near 1232 bytes, and a denial-of-existence answer can carry two or three signatures at once.
What happens if a DNSSEC answer is too big for UDP? It either gets IP-fragmented, which many middleboxes drop and which carries its own risks, or the resolver retries over TCP, which adds a round trip and far more server state. At root and top-level-domain query volumes, a broad shift to TCP is a real capacity and latency cost.
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 must store.
Do I need to migrate my DNSSEC now? Not yet. The algorithms and modes are still in IETF drafts, and DNSSEC is Non-HNDL, so nothing is being harvested. The useful step now is keeping your DNSSEC signing agile so you can adopt the standardized profile cleanly when it lands.
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 what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.