Cloudflare's 1.1.1.1 begins validating post-quantum ML-DSA-44 DNSSEC signatures

What Cloudflare enabled

Cloudflare's public resolver, 1.1.1.1, now validates DNSSEC signatures created with ML-DSA-44, a post-quantum signature algorithm standardized by NIST. According to the Cloudflare blog, this is a first step toward preparing DNSSEC for a future in which today's algorithms are no longer secure, and part of Cloudflare's goal of reaching full post-quantum security by 2029. The company says it is preparing for the possibility that a quantum computer powerful enough to break deployed RSA and ECDSA keys could exist by 2030.

DNSSEC signs DNS records so a validating resolver can follow a chain of signed records from the DNS root down to the requested domain and confirm an answer is authentic. Without it, an attacker who forges a response can redirect users to an address of their choosing. Nearly all algorithms in use today rely on mathematical problems that quantum computers are expected to eventually solve, letting an attacker recover private keys and produce signatures validators would accept.

Cloudflare points out that DNSSEC provides authenticity rather than confidentiality, so it is not exposed to "harvest now, decrypt later" attacks. The reason to start now is coordination: migrating DNSSEC requires changes across authoritative servers, registries, registrars, and validating resolvers, and it must eventually reach the DNS root, where a compromised signing key would let an attacker forge a validation path to every zone beneath it.

A signature that does not fit in the packet

The central engineering obstacle is size. An ML-DSA-44 signature is 2,420 bytes and its public key is 1,312 bytes, compared with a 64-byte signature and 64-byte key for ECDSA P-256. Classic DNS over UDP capped messages at 512 bytes; many implementations today advertise a conservative 1,232-byte limit to fit within IPv6's 1,280-byte minimum MTU, and RFC 9715 recommends a 1,400-byte maximum. An ML-DSA-44 signature alone exceeds all of those budgets before the signed records, domain names, headers, and other DNSSEC data are added.

Cloudflare's position is that sending such responses as fragmented UDP is unreliable and should be avoided. Instead, an authoritative server should return a truncated response that prompts the resolver to retry over another transport, usually TCP. The pressure point is DNSKEY responses, which carry the keys a resolver needs: with ML-DSA-44, they hold both a 1,312-byte key and a 2,420-byte signature. During the transition, zones will keep publishing conventional keys and signatures for older validators, and key rollovers can add still more, making these responses larger again.

Transport fallback is already routine for Cloudflare. Radar data cited in the post shows roughly 85% of queries to 1.1.1.1 arrive over UDP. The platform behind the resolver, Big Pineapple, also powers other services including Gateway DNS, and across all of them about 60% of queries come over UDP, with the remaining 40% using TCP, DNS over TLS, or DNS over HTTPS. Those figures describe how clients reach Cloudflare, not how 1.1.1.1 communicates with authoritative servers, where large responses may still drive extra TCP retries.

Closing the downgrade path

The second challenge is that old algorithms cannot simply be removed. A zone that publishes only ML-DSA-44 becomes unvalidatable for resolvers that do not support it, so the practical path is publishing conventional and post-quantum signatures side by side, likely for years. But RFC 6840 specifies that validators should accept any single valid path. Once conventional algorithms such as ECDSA are broken, that rule becomes a downgrade path: an attacker could forge an ECDSA-only answer that a resolver accepts even though it supports ML-DSA-44.

1.1.1.1's answer, per the Cloudflare blog, is to use DS records published by the parent zone as an authenticated signal. When the authenticated DS RRset contains a record for a supported post-quantum algorithm, 1.1.1.1 deliberately applies a stricter local policy: at least one valid post-quantum validation path is required, and a conventional path alone is no longer sufficient. If no ML-DSA-44 path validates, validation fails. Cloudflare notes this is not yet standard DNSSEC behavior, but RFC 4035 allows local resolver policy to decide whether additional signatures must be checked and how conflicts are handled.

Why it matters

This is more than a laboratory demonstration. 1.1.1.1 is one of the largest public resolvers in the world, so enabling ML-DSA-44 validation gives the DNS ecosystem operational data on two open questions: whether much larger responses can be carried reliably, and whether compatibility with older resolvers can be preserved without weakening protection for newer ones. Cloudflare's earlier work on post-quantum TLS showed that larger messages expose hidden assumptions and bugs in network software, and that widespread client adoption took years. Starting the DNSSEC migration now, well ahead of the 2030 threat scenario Cloudflare sketches, gives registries, registrars, and resolver operators time to find those failures early, before the algorithm change has to reach the root of the DNS hierarchy.