Cloudflare's 1.1.1.1 resolver now validates DNSSEC signatures using ML-DSA-44, a post-quantum signature algorithm, the company said today. Cloudflare says the change lets it test at Internet scale whether those bigger responses travel reliably and whether resolvers can be kept from falling back on conventional signing. DNSSEC is the system that signs DNS records so a validating resolver can follow a chain of trust from the root zone down to the answer it returns.
The practical problem is size. An ML-DSA-44 signature runs 2,420 bytes, while an ECDSA P-256 signature is 64 bytes, making the post-quantum option almost 38 times larger. The public keys are bigger too: 1,312 bytes for ML-DSA-44 against 64 bytes for ECDSA P-256 and 260 bytes for RSA-2048/SHA-256. DNS was originally built around UDP messages of no more than 512 bytes, and many implementations still cap UDP responses at a conservative 1,232 bytes, a figure chosen to fit inside IPv6's 1,280-byte minimum MTU. RFC 9715 recommends a maximum of 1,400 bytes for DNS over UDP, and fragmented UDP is considered unreliable and best avoided.
That matters because most traffic to 1.1.1.1 arrives over UDP: around 85% of queries. Cloudflare's Big Pineapple platform, which also powers Gateway DNS, sees about 60% of queries over UDP, with the remaining 40% using TCP, DoT, or DoH. When a response will not fit, an authoritative server is supposed to send a truncated reply that prompts the resolver to retry over TCP.
The transition is awkward for another reason. Publishing only ML-DSA-44 keys would break resolvers that do not support the algorithm, so the migration path publishes conventional and post-quantum keys and signatures side by side. But that opens a downgrade route: an attacker could forge an ECDSA-only answer that a resolver accepts. RFC 6840 says "validators SHOULD accept any single valid path". Cloudflare's answer is to treat parent-zone DS records as an authenticated downgrade signal and to require at least one valid post-quantum validation path, failing validation when no ML-DSA-44 path checks out. The company notes this restrictive policy is not yet normal DNSSEC validation behavior, though RFC 4035 allows local resolver policy on additional signatures and conflicts.
Cloudflare frames the stakes bluntly: a root zone key compromise could let an attacker forge a validation path to any zone beneath it, a scenario the company sums up as "break once, forge everywhere". RSA and ECDSA DNSSEC algorithms are vulnerable to future quantum computers, and Cloudflare says it is preparing for the possibility of a machine capable of breaking keys in 2030. Such computers do not exist today. DNSSEC provides authenticity rather than confidentiality, so there is no harvest-now-decrypt-later risk here.
The company has been working on post-quantum cryptography for years, starting with TLS key agreement experiments in 2019 and enabling post-quantum TLS for all customers in 2022. It aims for full post-quantum security by 2029. Two days ago it announced automatic key exchange for post-quantum secure origin handshakes, a change it said covered 45 billion daily connections. IANA recently assigned ML-DSA-44 the DNSSEC algorithm number 18, and its use in DNSSEC is described in an Internet-Draft.
Migration still requires coordination across authoritative servers, registries, registrars, and resolvers, and ML-DSA-44 cannot fully replace conventional signing until it is widely supported. Key rollovers can add more keys and enlarge responses further. Downgrade protection is only post-quantum secure if it extends through every delegation, and rotating zone keys more often does not fix that problem.
