The 1.1.1.1 resolver now authenticates DNSSEC signatures generated using ML-DSA-44, a post-quantum cryptographic algorithm approved by the National Institute of Standards and Technology (NIST). This deployment represents an early phase in hardening DNSSEC against future quantum computing threats. Cloudflare has committed to achieving comprehensive post-quantum security across its infrastructure by 2029, with earlier efforts concentrating on TLS encryption rather than DNS authentication.
Post-quantum signature algorithms have received far less operational testing in DNSSEC contexts compared to their TLS counterparts, where Cloudflare began experimentation in 2019 and rolled out support to all users in 2022. The urgency stems from lessons learned during TLS migration: the larger message sizes inherent to post-quantum cryptography exposed latent bugs and assumptions in network infrastructure, making early, widespread testing essential before quantum computers pose an actual threat.
The core challenge lies in signature size. Each ML-DSA-44 signature occupies 2,420 bytes—substantially larger than conventional algorithms and exceeding standard DNS-over-UDP packet limits even before including the signed data itself. Zones must continue publishing traditional signatures for years to maintain compatibility with older resolvers, yet this dual-algorithm approach creates potential security gaps if not carefully managed. The technical hurdle is reliably transmitting these expanded responses without allowing backward compatibility to undermine protection for newer clients.
By enabling ML-DSA-44 validation on 1.1.1.1, Cloudflare can now test both operational challenges at Internet scale: transporting larger DNS responses reliably and preventing fallback attacks that exploit older signature algorithms.
Why post-quantum DNSSEC matters
DNS responses lack built-in authentication, leaving them vulnerable to attackers capable of forging answers and redirecting users to malicious destinations. DNSSEC mitigates this risk by cryptographically signing DNS records. A validating resolver like 1.1.1.1 verifies a chain of signed records from the DNS root down to the target domain, confirming authenticity and integrity.
Nearly all DNSSEC algorithms in current use—primarily RSA and ECDSA—depend on mathematical problems considered computationally infeasible for conventional computers at deployed key sizes. The concern is that a sufficiently advanced quantum computer, potentially available by 2030, could solve these problems, allowing attackers to extract private keys and forge signatures that validators would accept. Although such quantum computers do not yet exist, DNSSEC protects authenticity rather than confidentiality, so it faces no "harvest now, decrypt later" risk.
The case for beginning now rests on coordination requirements. Transitioning DNSSEC demands alignment across authoritative servers, registries, registrars, and validating resolvers, ultimately reaching the DNS root. A compromised root zone signing key would enable an attacker to forge validation paths to any subordinate zone—"break once, forge everywhere." ML-DSA-44 provides a standardized entry point for this migration, and supporting it in 1.1.1.1 allows Cloudflare and the broader DNS community to accumulate operational experience.
Why replacing the algorithm is difficult
Although DNSSEC was architected to accommodate new algorithms, two practical obstacles complicate the transition: the sheer size of post-quantum signatures and the inability to immediately retire older algorithms.
A 2,420-byte signature changes the packet
Contemporary DNSSEC algorithms generate comparatively compact signatures. ECDSA P-256, for instance, produces 64-byte signatures, whereas ML-DSA-44 generates 2,420-byte signatures—nearly 38 times larger.
This size differential matters significantly because DNS infrastructure exhibits sensitivity to message dimensions. DNS originally capped UDP-transmitted messages at 512 bytes. The EDNS(0) extension later permitted resolvers to advertise their maximum acceptable UDP response size. Most DNS implementations adopt a conservative 1,232-byte UDP payload ceiling, designed to stay within IPv6's minimum MTU (maximum transmission unit) of 1,280 bytes. RFC 9715 more recently recommended 1,400 bytes as the DNS-over-UDP maximum. An ML-DSA-44 signature alone exceeds these budgets before accounting for the signed RRset, domain names, DNS headers, and additional DNSSEC records. Fragmented UDP responses prove unreliable and should be avoided; instead, authoritative servers should send truncated responses, prompting resolvers to reconnect via TCP or another protocol.
DNSKEY responses—which carry the keys needed for zone validation—illustrate this problem most clearly. An ML-DSA-44 public key spans 1,312 bytes, and the DNSKEY RRset also includes a 2,420-byte signature. ML-DSA-44 cannot fully displace conventional signing until widespread DNS ecosystem support materializes, a process anticipated to span years. During the interim, DNSKEY responses must carry both conventional and post-quantum keys and signatures for backward compatibility with older validators. Key rollovers introduce additional keys, further inflating response sizes.
Operating DNS across non-UDP transports is routine rather than exceptional. Cloudflare Radar indicates roughly 85% of 1.1.1.1 queries arrive via UDP. The infrastructure powering 1.1.1.1, called Big Pineapple, also operates other DNS services including Gateway DNS. Across all Big Pineapple services, approximately 60% of queries use UDP, with the remaining 40% distributed among TCP, DNS over TLS (DoT), and DNS over HTTPS (DoH).
These percentages describe query arrival at Cloudflare's resolver services, not communication between 1.1.1.1 and authoritative servers. Oversized ML-DSA-44 responses can still trigger supplementary TCP retries in that direction, but handling DNS across multiple transports already constitutes standard operational practice for 1.1.1.1 at scale.
Supporting two algorithms introduces a downgrade risk
Swapping one DNSSEC algorithm for another cannot occur instantaneously. If a zone publishes exclusively ML-DSA-44, resolvers lacking support cannot validate it. The realistic migration strategy therefore involves publishing conventional and post-quantum keys and signatures simultaneously.
This approach maintains compatibility but does not inherently deliver post-quantum security. RFC 6840 specifies that "validators SHOULD accept any single valid path," permitting validators to employ whichever published algorithm they support.
Once a conventional algorithm like ECDSA becomes insecure, however, this same behavior creates a downgrade vulnerability. An attacker could construct an ECDSA-only answer that a resolver accepts despite supporting ML-DSA-44.
Blocking this downgrade requires an authenticated indication that ML-DSA-44 validation is mandatory. 1.1.1.1 leverages DS records published by parent zones for this signal. When the authenticated DS RRset includes a record for a supported post-quantum algorithm, the signal exists.
1.1.1.1 then enforces a stricter local validation policy. It mandates at least one valid post-quantum validation path; a conventional path becomes insufficient. If no ML-DSA-44 path validates, validation fails. This deviates from standard DNSSEC validation behavior but aligns with RFC 4035, which permits local resolver policy to dictate whether additional signatures must be verified and how conflicting outcomes are resolved.
Conventional signatures can persist for older resolvers without enabling post-quantum-capable resolvers to regress to them. The downgrade signal provides post-quantum security only if ML-DSA-44 deployment and downgrade protection span from the trust anchor through every delegation. Accelerating zone key rotation does not resolve the issue: an attacker can compromise a vulnerable key anywhere higher in the hierarchy and forge all subordinate delegations.
The road to post-quantum DNSSEC
Incorporating a post-quantum algorithm into DNSSEC extends beyond cryptographic standardization. It demands implementations in cryptographic libraries, an IANA-assigned DNSSEC algorithm identifier, support from authoritative servers and validating resolvers, and adoption throughout the DNS delegation hierarchy. ML-DSA-44 has now satisfied the initial prerequisites. NIST has standardized it, and mainstream cryptographic libraries support it. Its DNSSEC application is documented in the ML-DSA for DNSSEC Internet-Draft, and IANA recently assigned it DNSSEC algorithm number 18.
Adding ML-DSA-44 validation to resolvers constitutes one of the earliest deployment phases but does not establish a complete post-quantum trust chain. Authoritative servers must sign zones with ML-DSA-44, registrars must accept and submit corresponding DS records, and registries must publish them in parent zones.
This adoption must reach every parent zone up to the DNS root. The root must embrace ML-DSA-44, and its post-quantum key must serve as a trust anchor for validating resolvers. Any tier lacking post-quantum protection remains a downgrade vulnerability.
Signing a zone with ML-DSA-44 offers minimal value if no resolver validates its signatures. Activating ML-DSA-44 validation by default on 1.1.1.1 therefore represents a critical early step. It permits measurement of signature verification overhead, supplementary bandwidth consumption, and heightened TCP utilization between resolvers and authoritative servers.
Following the pattern of earlier migrations, Cloudflare will also evaluate real-world deployability via background probes on a limited set of Cloudflare Challenge Pages. These probes will assess whether clients can resolve and access an ML-DSA-44-signed test domain across diverse networks. Cloudflare invites other DNS operators and developers to commence ML-DSA-44 testing at scale. Collectively, these measurements will identify necessary adjustments as adoption accelerates.
What this means for you
1.1.1.1 users require no action. ML-DSA-44 validation activates automatically when zones publish the requisite DNSSEC records, while existing DNSSEC zones continue validating normally.
This initiative addresses the resolver component of DNS. The subsequent phase involves integrating ML-DSA-44 signing capabilities into Cloudflare Authoritative DNS and corresponding DS record functionality into Cloudflare Registrar, both available to all customers at no cost. This will enable testing the complete workflow, from signature generation and DNSKEY publication through transport and validation via 1.1.1.1.
To observe post-quantum DNSSEC in operation—encompassing all 2,420 bytes—query the dnstest.dev zone using 1.1.1.1:
$ dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec ;; WARNING: truncated reply from 1.1.1.1@53(UDP), retrying over TCP ;; ->>HEADER
You can also use Is your DNS resolver post-quantum ready? to evaluate your current resolver. The community documents ML-DSA-44 software support on GitHub.
Source: Cloudflare Blog