Even DNS goes post-quantum: Cloudflare validates ML-DSA-44 on 1.1.1.1
A DNSSEC signature today weighs 64 bytes. With the post-quantum algorithm Cloudflare just started validating on 1.1.1.1, it weighs 2,420 — nearly 40 times as much. That's not a footnote: it's enough to break the assumptions DNS's UDP transport is built on, and how Cloudflare solved the problem says a lot about what "crypto-agility" actually means in practice.
On September 10, 2026, Cloudflare announced that its public resolver 1.1.1.1 now validates DNSSEC signatures generated with ML-DSA-44, one of three post-quantum algorithms standardized by NIST in August 2024 (alongside ML-KEM and SLH-DSA). It's the first declared step toward a goal of full post-quantum security by 2029 — and the technical problem this first step exposes is more interesting than the announcement itself.
Why DNSSEC is a target, and why it isn't "harvest now, decrypt later"
DNSSEC adds authenticity and integrity to DNS responses: it digitally signs records so a resolver can verify a response hasn't been tampered with along the way. The algorithms in use today — RSA and ECDSA — rely on mathematical problems considered intractable for classical computers at deployed key sizes. A sufficiently powerful quantum computer could break them, allowing an attacker to forge signatures and redirect users to malicious sites.
It's a technical distinction worth making explicit: DNSSEC guarantees authenticity, not confidentiality. It is therefore not exposed to the "harvest now, decrypt later" attacks that threaten key-exchange protocols like TLS instead — there, an adversary can record encrypted traffic today and decrypt it in the future. For DNSSEC the risk is different: an attacker with a quantum computer could forge signatures at the time of the attack, not decrypt signatures already issued in the past.
The problem nobody puts in the headlines: signature size
The real technical obstacle in this migration isn't cryptographic, it's transport. The comparison is stark:
- ECDSA P-256: 64 bytes
- RSA-2048/SHA-256: 256 bytes
- ML-DSA-44: 2,420 bytes — roughly 38 times larger than ECDSA
DNS over UDP was historically limited to 512 bytes; with the EDNS(0) extension the limit is negotiable, but RFC 9715 recommends a practical maximum of 1,400 bytes. A single ML-DSA-44 signature exceeds this limit on its own, before even counting the actual DNS data to be transmitted. Sending a response of this size as fragmented UDP is unreliable and should be avoided: the practical consequence is that authoritative servers return truncated responses, forcing the client to retry over TCP.
Cloudflare already has the infrastructure to absorb this change without significant operational disruption: on 1.1.1.1 about 85% of queries arrive over UDP, but across its broader DNS platform ("Big Pineapple") roughly 60% use UDP and 40% already rely on TCP, DoT or DoH. For anyone running a less modern DNS setup, this shift to TCP as a systematic fallback isn't a given — and it's the first thing to check before considering post-quantum signature adoption.
Downgrade protection: the detail that makes this a serious implementation
During the transition period, zones must publish both classical and post-quantum signatures, to stay compatible with resolvers that don't yet validate ML-DSA-44. This creates a subtle security problem: RFC 6840 allows validators to accept "any single valid path" among those available. If a classical algorithm were compromised in the future, an attacker could forge responses valid only on the ECDSA path — and a permissive validator, accepting the first path that verifies correctly, would accept them anyway, even though the post-quantum algorithm is available and uncompromised.
Cloudflare chose a stricter validation policy: when the parent zone's authenticated DS record set includes a post-quantum algorithm, 1.1.1.1 requires the ML-DSA-44 path to be valid — it doesn't settle for an ECDSA path that merely passes verification. This is the mechanism that prevents a "break once, forge everywhere" scenario against the root zone — breaking a single compromised algorithm undermining the entire trust chain for anyone willing to accept the first valid path.
What this means in practice, and for whom
Dual-signing means larger DNSKEY responses and added complexity in managing key rollovers — a real operational cost for anyone administering DNS zones, not just for public resolvers. For an organization running its own DNS infrastructure, or depending on PKI and certificate providers, this announcement isn't news to share and file away: it's a signal that the window to plan for crypto-agility — the ability to swap out a cryptographic algorithm without redesigning the entire infrastructure — is narrowing.
ISO/IEC 27001:2022 already covers this under control A.8.24 — Use of cryptography: a policy on the use of cryptography that includes managing the algorithm lifecycle, not just its initial selection. For NIS2 subjects running DNS services or related infrastructure, this translates into a concrete operational question: if a DNS/PKI provider announced tomorrow the end of support for a classical algorithm, would the transition be planned, or improvised?
Sources
- Cloudflare Blog, "1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it", September 10, 2026.
Is your infrastructure ready for the post-quantum transition?
We run technical training on cryptography and crypto-agility and support IT teams in assessing NIS2/ISO 27001 readiness on algorithms, certificates and key management — before migration becomes an emergency.
Talk to us →