# DNSSEC and PQC: Why Signature Size Is the Whole Problem **Source**: https://quantumsequrity.com/blog/dnssec-pqc **Category**: Network Protocols --- [← Back to Blog](../../blog.html) Network Protocols # DNSSEC and PQC: Why Signature Size Is the Whole Problem 12 min read DNSSEC is the cryptographic extension that lets DNS resolvers verify that the DNS records they receive are authentic. It is the difference between trusting that `example.com` resolves to a legitimate IP versus accepting whatever an on-path attacker injects. DNSSEC is deployed at the root, at every TLD, and at a substantial fraction of zones below. ICANN signs the root zone. Verisign signs `.com`. Major TLDs all sign their zones. DNSSEC is also one of the hardest places in the entire internet to migrate to post-quantum cryptography. Not because of computational cost — DNSSEC verification is already cheap in CPU terms. Not because of trust — DNSSEC's PKI is mature and well-understood. The problem is signature size. DNS messages traditionally fit in a single UDP datagram of 512 bytes. Modern EDNS0 extensions raise that to 1232 bytes for IPv6 friendly paths, sometimes 4096 bytes with relaxed assumptions. Post-quantum signatures are dramatically larger than the classical signatures DNSSEC was designed around. ML-DSA-65 produces 3,309-byte signatures. ML-DSA-87 produces 4,627-byte signatures. SLH-DSA signatures range from 7 KB to 50 KB. A DNSSEC-signed DNS response with PQC signatures simply does not fit in a UDP datagram, and that breaks an enormous amount of operational assumptions. This blog post walks through why this matters, what the IETF DNSOP working group is exploring, and where the migration goes from here. ## DNSSEC In One Paragraph DNSSEC is defined in RFC 4033, RFC 4034, and RFC 4035. Each DNS zone has a Zone Signing Key (ZSK) and a Key Signing Key (KSK). The ZSK signs all the resource records in the zone, producing RRSIG records. The KSK signs the DNSKEY record (which contains the ZSK), and the parent zone's DS record points to the hash of the KSK. Resolvers walk this chain from a trusted root down to the queried record, verifying signatures along the way. The signatures today are typically RSA-2048 with SHA-256 (algorithm 8) or ECDSA P-256 with SHA-256 (algorithm 13). RSA-2048 signatures are 256 bytes; ECDSA P-256 signatures are about 64 bytes. DNSSEC was sized around these. ## The 512-Byte Original Limit DNS was designed in 1987 with a 512-byte UDP message limit. The reasoning was that 512 bytes fit in a single IP packet under almost all path MTUs of the era. Larger DNS responses had to use TCP, which was considered expensive. Over time, this limit relaxed. EDNS0 (RFC 6891) lets resolvers advertise that they can accept larger UDP responses. The current operational sweet spot is 1232 bytes — small enough to avoid IPv6 fragmentation issues, large enough to fit most modern responses. But "most modern responses" assumes RSA-2048 or ECDSA-P256 signatures. With ML-DSA-65 signatures at 3,309 bytes, even a single signed answer overflows 1232 bytes. ## Why UDP Matters For DNS DNS could fall back to TCP whenever UDP responses don't fit. The TC bit in a DNS response tells the resolver "the answer was too large, try again over TCP." This works. But DNS over TCP is operationally heavy. Each query requires a 3-way handshake (or, with TCP fast open, at least the connection state). Caches and resolvers handling millions of queries per second cannot afford to pay TCP costs for every query. If PQC DNSSEC means every DNSSEC-validated query falls back to TCP, the operational impact on the global DNS infrastructure is enormous. Resolvers would need to scale TCP capacity dramatically. Authoritative servers would need to handle persistent TCP connections rather than stateless UDP responses. This is not impossible — DNS over TCP and DNS over TLS already exist and are widely deployed in some sectors. But it is a profound shift from the current operational model. ## The Stateful Hash Signature Option: LMS And HSS One alternative to ML-DSA for DNSSEC is stateful hash-based signatures. RFC 8554 specifies LMS (Leighton-Micali Signatures), and RFC 8554 / RFC 8696 also describe HSS (Hierarchical Signature System) which builds on LMS. LMS signatures are bigger than ECDSA but can be smaller than ML-DSA-65 in some configurations. More importantly, they are stateful: a signing key has a finite supply of one-time signatures, and the signer must track which have been used. Reusing a signature index breaks security entirely. For DNS, statefulness is awkward. Authoritative DNS servers are typically replicated across many instances, with multiple secondaries serving the same zone. Coordinating state across multiple signing instances is hard. But for some specific DNS use cases — particularly the root KSK and TLD KSKs, which are signed in a controlled ceremony rather than continuously — LMS is workable. The IETF has explored this as a possible PQC option for the highest tiers of DNSSEC. ## SLH-DSA: Stateless But Huge SLH-DSA (FIPS 205, formerly SPHINCS+) is a stateless hash-based signature scheme. It avoids the bookkeeping problem of LMS. But its signatures are dramatically larger than ML-DSA's: 7,856 bytes for SLH-DSA-128s, 49,856 bytes for SLH-DSA-256f. A 50 KB DNSSEC signature is a non-starter for normal DNS responses. Even with full TCP-only DNS, that much signature data per query is operationally crushing. SLH-DSA might play a niche role at the very top of the DNSSEC hierarchy — the root KSK or a small number of TLD KSKs — where the long-term, infrequently-rotated nature of those keys makes the cost tolerable. But it cannot be used for the millions of zone signing operations happening across the internet daily. ## Hybrid Approaches Are Less Useful Here For TLS, hybrid PQC (combining a classical algorithm with a PQC algorithm) is appealing because the cost of carrying both is small relative to the rest of the connection. For DNSSEC, hybrid PQC means doubling the already-too-large signature size. ML-DSA-65 + ECDSA-P256 = 3,373 bytes per signature, instead of just ML-DSA-65's 3,309. The marginal cost of "also classical" is small, but the absolute size is still way too big for UDP-friendly DNS. This means DNSSEC PQC migration is harder than network-protocol PQC migration. Hybrid is not a free lunch here. ## What The IETF Is Doing The DNSOP working group has been studying PQC DNSSEC for several years. The current draft work explores: - **Algorithm benchmark**: how each PQC algorithm performs on real DNS infrastructure. - **Operational scenarios**: what happens to caching, recursion, and load when signatures are 5-10x larger. - **Hybrid signature schemes**: combining ML-DSA with classical signatures, despite the size penalty. - **Compact signature schemes**: research into whether new lattice-based schemes might produce smaller signatures. - **Selective signing**: signing only some DNS records (popular ones, security-critical ones) and leaving others unsigned. None of these have reached consensus yet. The DNSOP WG is famously deliberate, and the operational stakes (you can take down significant fractions of the internet by getting this wrong) demand caution. ## The "Maybe DNSSEC Itself Is Wrong" Faction There is a substantial faction inside the DNS community that argues DNSSEC, in its current form, is the wrong tool for modern privacy and integrity needs. Their argument: - DNSSEC validates record integrity but not query confidentiality. Encrypted transport (DoH, DoT, DoQ) provides confidentiality, and the integrity needs can be met with simpler mechanisms. - The DNSSEC PKI is brittle and adoption is uneven. - The complexity of DNSSEC algorithms, key rotation, and zone signing has caused many operational outages. This faction would argue that PQC DNSSEC is solving the wrong problem. The right problem to solve is "make DNS queries private and authenticated end-to-end via TLS-class protections" — for which the [DNS-over-HTTPS PQC story](../../blog/dns-over-https-pqc.html) is the answer, inherited from TLS. The opposing faction argues DNSSEC is the only mechanism that authenticates the DNS data itself, regardless of which resolver returned it. Without DNSSEC, your security depends on trusting your resolver completely. With DNSSEC, even a malicious resolver cannot fabricate records. This debate predates PQC and is unlikely to resolve quickly. ## Practical State Today As of late 2025, no production DNSSEC deployment uses PQC signatures. The root zone uses ECDSA. The major TLDs (`.com`, `.net`, `.org`, etc.) use a mix of ECDSA and RSA-2048. The IETF has not standardized PQC algorithm numbers in DNSSEC. Operators of authoritative DNS infrastructure are watching the space but not making changes yet. The threat is theoretical: a quantum-capable adversary could derive private signing keys from public DNSKEY records in a future post-quantum era, but cannot retroactively forge records that were signed pre-break. The harvest-now-decrypt-later threat is muted for DNSSEC because DNS data is mostly public anyway. Knowing the IP address of `example.com` ten years from now does not require quantum computing — the IP address was published. The attacker value of breaking historical DNSSEC signatures is limited. What matters more is forward-looking impersonation: once classical signatures break, an attacker can derive the private key from the public DNSKEY and sign forgeries for `example.com` for as long as the DNSKEY is trusted. This is a real risk that needs to be addressed, but the timeline for "quantum computers can break ECDSA-P256" is sufficiently far out that DNSSEC PQC migration is not yet urgent. ## What QNSQY Recommends For DNSSEC operators today: 1. **Stay on ECDSA-P256.** Algorithm 13. It is the modern default and will be the easiest to migrate from when PQC algorithms are standardized. 2. **Plan for KSK rotation as the migration vehicle.** When PQC DNSSEC algorithms are standardized, the natural migration is during a KSK rollover. 3. **Do not switch to RSA-4096.** Some operators have mistakenly thought that increasing RSA key sizes provides quantum resistance. It does not. Stay with modern ECDSA. 4. **Watch the DNSOP WG.** Specifically `draft-ietf-dnsop-pqc-dnssec` and related drafts. For application developers and end users, DNSSEC PQC is something the DNS infrastructure will handle transparently when it eventually migrates. There is no client-side action needed. For QNSQY itself, our DNS records are signed with DNSSEC using ECDSA-P256. We will migrate to PQC when the standards are finalized and our DNS operator (Cloudflare) deploys the supported algorithms. ## Frequently Asked Questions **Q: Is DNSSEC quantum-vulnerable today?** The signing keys are, in the long-term sense. An attacker who derives the private key from a published DNSKEY can mint forged signatures for that zone. But there is no urgent threat — quantum capability sufficient to break ECDSA-P256 is not yet on the horizon. **Q: Will DNSSEC eventually fall back to TCP for everything?** Possibly. The DNSOP working group is exploring this as one of the migration paths. The operational impact would be significant but manageable. **Q: Does DNS-over-HTTPS (DoH) avoid the DNSSEC problem?** DoH provides transport-layer privacy and authenticity (you trust the resolver via TLS). DNSSEC provides record-layer authenticity (you trust the data via signatures). They are complementary, not substitutes. DoH PQC is much easier than DNSSEC PQC. **Q: Is there a smaller PQC signature scheme that might work for DNSSEC?** Falcon (FIPS 206 in development) produces signatures of around 666 bytes for Falcon-512. This would fit DNSSEC much better. The catch is implementation hazards — Falcon requires constant-time floating-point arithmetic, which is extremely tricky on real hardware. Falcon is not yet a finalized FIPS, but it is being watched closely for DNSSEC use. **Q: When will DNSSEC actually migrate to PQC?** Probably 2028-2032. The DNSOP WG is not in a rush, and the operational risks of getting it wrong are too large to move quickly. ## Sources 1. RFC 4033 — DNS Security Introduction and Requirements. https://datatracker.ietf.org/doc/html/rfc4033 2. RFC 4034 — Resource Records for the DNS Security Extensions. https://datatracker.ietf.org/doc/html/rfc4034 3. RFC 4035 — Protocol Modifications for the DNS Security Extensions. https://datatracker.ietf.org/doc/html/rfc4035 4. RFC 6891 — Extension Mechanisms for DNS (EDNS(0)). https://datatracker.ietf.org/doc/html/rfc6891 5. RFC 8554 — Leighton-Micali Hash-Based Signatures. https://datatracker.ietf.org/doc/html/rfc8554 6. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/204/final 7. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/205/final ## Related Articles - [What Is Post-Quantum Cryptography?](../../blog/what-is-post-quantum-cryptography.html) - [ML-DSA vs SLH-DSA](../../blog/mldsa-vs-slhdsa.html) - [DNS-over-HTTPS PQC](../../blog/dns-over-https-pqc.html) - [NIST FIPS Guide](../../blog/nist-fips-guide.html) - [Harvest Now, Decrypt Later](../../blog/harvest-now-decrypt-later.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)