1 now validates DNSSEC signatures made with ML-DSA-44 , a post-quantum signature algorithm standardized by the National Institute of Standards and Technology (NIST) . This is a first step toward preparing DNSSEC for a future in which today’s signature algorithms are no longer secure. Cloudflare plans to achieve full post-quantum security by 2029 .
Much of the work so far has focused on TLS, but public-key cryptography is used in many other systems, including DNSSEC. While we began experimenting with post-quantum key agreement in TLS in 2019 and enabled support for all customers in 2022, post-quantum signatures have not yet received comparable testing in DNSSEC. There is also some urgency.
Widespread client adoption of post-quantum TLS took years, partly because larger messages exposed assumptions and bugs in existing network software. That experience showed why early large-scale testing matters. We cannot wait until quantum computers become an immediate threat.
The problem is that post-quantum signatures are large. Each ML-DSA-44 signature is 2,420 bytes, exceeding common DNS-over- UDP limits before the response includes anything else. At the same time, zones will need to publish conventional signatures for older resolvers for years, creating a potential downgrade path if not validated correctly.
The challenge is carrying these much larger responses reliably, without allowing compatibility with older resolvers to weaken protection for newer ones. With ML-DSA-44 validation enabled, 1. 1.
- 1 lets us test both challenges at Internet scale: carrying larger DNS responses and preventing fallback to conventional signatures. Why post-quantum DNSSEC matters DNS responses are not authenticated by default.
An attacker who can forge a response may be able to redirect users to an address of their choosing. DNSSEC prevents this by signing DNS records. A validating resolver such as 1.
- 1 follows a chain of signed records from the DNS root to the requested domain, checking that the answer is authentic and has not been modified.
DNSSEC supports multiple signature algorithms, but nearly all of those used today are vulnerable to future quantum computers. RSA and ECDSA rely on mathematical problems that are believed to be infeasible for conventional computers to solve at deployed key sizes. We are preparing for the possibility that in 2030 a sufficiently powerful quantum computer could be built that breaks these keys.
An attacker could then recover the corresponding private key and create forged signatures that validators would accept. The attack path is shown below. Quantum computers capable of carrying out these attacks do not exist today.
DNSSEC provides authenticity rather than confidentiality, so it is not subject to “harvest now, decrypt later” attacks. The reason to begin now is that changing DNSSEC requires coordination across authoritative servers, registries, registrars, and validating resolvers. The migration must eventually reach the top of the DNS hierarchy, where a compromised key has the greatest impact.
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”. ML-DSA-44 gives that migration a standardized starting point, and supporting it in 1. 1.
- 1 lets us, and the DNS ecosystem at large, gain operational experience. Why replacing the algorithm is difficult DNSSEC was designed to support new algorithms.
In principle, supporting ML-DSA-44 means publishing its public key and teaching validators to verify its signatures. In practice, two properties make the transition difficult: the signatures are large, and the old algorithm cannot always be removed safely. A 2,420-byte signature changes the packet DNSSEC algorithms commonly used today produce relatively small signatures.
ECDSA P-256 , for example, produces a 64-byte signature. An ML-DSA-44 signature is 2,420 bytes, almost 38 times larger. That difference matters because many of the systems that send, carry, and receive DNS messages are sensitive to message size.
DNS originally restricted messages sent over UDP to 512 bytes . EDNS(0) later allowed a resolver to advertise the largest UDP response it is willing to accept from a nameserver. Many DNS implementations use a conservative UDP payload limit of 1,232 bytes , chosen to fit within IPv6’s minimum MTU (maximum transmission unit) of 1,280 bytes .
More recently, RFC 9715 recommended a maximum of 1,400 bytes for DNS over UDP. An ML-DSA-44 signature exceeds that budget on its own, before accounting for the signed RRset, domain names, DNS headers, and other DNSSEC records. Sending such a response as fragmented UDP is unreliable and should be avoided .
Instead, the authoritative server should return a truncated response, prompting the resolver to retry using another transport protocol, usually TCP. The effect is most visible in DNSKEY responses, which contain the keys a resolver needs to validate the zone. An ML-DSA-44 public key is 1,312 bytes, and the DNSKEY RRset also carries a 2,420-byte signature.
ML-DSA-44 cannot fully replace conventional signing algorithms until it is widely supported across the DNS ecosystem, a process likely to take years. Until then, DNSKEY responses may contain both conventional and post-quantum keys and signatures to remain compatible with older validators. Key rollovers can add still more keys, making these responses larger again.
Handling DNS over transports other than UDP is not itself unusual. Cloudflare Radar shows that around 85% of queries to 1. 1.
1 arrive over UDP. The platform behind 1.
- 1, Big Pineapple , also powers other DNS services, including Gateway DNS .
Across all services handled by Big Pineapple, around 60% of queries arrive over UDP. The remaining 40% use transports such as TCP, DNS over TLS (DoT), and DNS over HTTPS (DoH). Those figures describe how queries reach Cloudflare’s resolver services, not how 1.
Originally published at blog.cloudflare.com
