Cloudflare has announced a major milestone in the ongoing effort to secure the internet against future technological threats, revealing that its flagship 1.1.1.1 public DNS resolver now validates Domain Name System Security Extensions (DNSSEC) signatures generated using ML-DSA-44. This post-quantum cryptographic signature algorithm was recently standardized by the National Institute of Standards and Technology (NIST). This implementation marks a foundational first step in preparing the global DNSSEC architecture for a future era in which today’s cryptographic signature algorithms will no longer be considered secure against advanced quantum computing hardware.
The deployment forms a critical component of Cloudflare’s broader roadmap, which targets achieving full post-quantum security across its infrastructure by the year 2029. While a significant portion of the cryptography industry’s early post-quantum transition work has historically focused on Transport Layer Security (TLS), public-key cryptography remains deeply embedded across numerous other vital internet protocols and systems, including the cryptographic mechanisms that underpin DNSSEC.
Back in 2019, Cloudflare began experimenting with post-quantum key agreement protocols within TLS, ultimately extending full support to all customers by 2022. However, post-quantum signatures have not yet undergone comparable large-scale operational testing within DNSSEC ecosystems. According to network architects, a sense of urgency surrounds this work. Widespread client adoption of post-quantum TLS protocols took several years to materialize, largely because larger network message sizes exposed hidden assumptions, protocol edge cases, and software bugs in existing network equipment and software implementations. That historical experience underscores the necessity of conducting early, large-scale deployments and testing rather than waiting until quantum computers evolve into an immediate and active threat.
The fundamental technical hurdle involves the physical size of post-quantum cryptographic signatures. Each individual ML-DSA-44 signature consumes 2,420 bytes of data. This size alone exceeds standard DNS-over-UDP payload limits before a server response can even include the requested DNS records, domain names, or standard headers. At the same time, domain name zones will be required to publish conventional, legacy signatures alongside new algorithms to maintain compatibility with older resolvers for years to come. This reality creates a complex potential downgrade path if systems fail to validate the configurations securely and correctly. The primary engineering challenge lies in transporting these significantly larger DNS responses reliably over the network, while ensuring that maintaining backwards compatibility with legacy resolvers does not inadvertently weaken cryptographic protections for newer, post-quantum-capable systems.
By enabling ML-DSA-44 validation on 1.1.1.1, Cloudflare is positioned to evaluate and test both core challenges at true internet scale: efficiently carrying substantially larger DNS responses across diverse network paths and effectively preventing malicious fallbacks to conventional, weaker signature algorithms.
Why Post-Quantum DNSSEC Matters
By default, standard DNS responses lack built-in authentication. An attacker capable of forging a DNS response can potentially redirect unsuspecting users toward a malicious or fraudulent IP address of their choosing. DNSSEC prevents this vulnerability by digitally signing DNS records. A validating resolver like 1.1.1.1 verifies a chain of cryptographically signed records originating from the authoritative DNS root down to the specific requested domain, ensuring that the returned answer is entirely authentic and has not been altered in transit.
While DNSSEC is engineered to accommodate multiple signature algorithms, nearly all algorithms actively deployed and used today remain mathematically vulnerable to future quantum computers. Traditional algorithms such as RSA and Elliptic Curve Digital Signature Algorithm (ECDSA) rely on complex mathematical problems—such as integer factorization and discrete logarithms—that conventional computers find computationally infeasible to solve at deployed key sizes. Engineers are actively preparing for the possibility that by 2030, threat actors could possess sufficiently powerful quantum computers capable of breaking these foundational keys. An attacker could theoretically recover a private key and forge valid signatures that standard validators would automatically accept.
Although quantum computers capable of mounting such large-scale attacks do not exist today, and DNSSEC guarantees data authenticity rather than confidentiality—meaning it is exempt from "harvest now, decrypt later" bulk decryption strategies—the migration requires proactive planning. Modifying DNSSEC requires complex coordination across the entire web ecosystem, spanning authoritative nameserver operators, top-level domain registries, domain registrars, and independent validating resolvers. This migration must eventually reach the absolute apex of the DNS hierarchy, where a compromised key carries the most catastrophic impact. An attacker who successfully recovers a root zone signing key using a quantum computer could theoretically forge a valid path of trust to any subordinate zone beneath it, resulting in a scenario where a single compromise permits pervasive forgery. The standardized starting point provided by ML-DSA-44 allows the industry to begin this transition, while its inclusion in 1.1.1.1 enables engineers and the broader DNS community to gather valuable operational experience.
Why Replacing the Algorithm Proves Difficult
Although DNSSEC was architecturally designed to support the introduction of new cryptographic algorithms, transitioning in practice presents unique hurdles. In principle, supporting ML-DSA-44 requires publishing its corresponding public key and teaching validating resolvers how to mathematically verify its signatures. In reality, two distinct technical properties complicate this migration: the massive size of the signatures and the inability to safely remove legacy algorithms immediately.
A 2,420-byte signature fundamentally alters network packets. Legacy DNSSEC algorithms commonly utilized today generate relatively compact signatures. For instance, ECDSA P-256 produces a signature of just 64 bytes. In contrast, an ML-DSA-44 signature is nearly 38 times larger, measuring 2,420 bytes, while an RSA-2048 signature sits at 256 bytes with a 260-byte public key. Meanwhile, ML-DSA-44 public keys measure 1,312 bytes.
This size differential creates complications because many network devices, middleboxes, and software systems involved in routing and processing DNS messages are highly sensitive to packet sizes. The original DNS specification restricted messages sent over UDP to a modest 512 bytes. The introduction of EDNS(0) later enabled resolvers to explicitly advertise the maximum UDP response size they were prepared to accept from a nameserver. Consequently, many modern DNS implementations rely on a conservative UDP payload limit of 1,232 bytes, a threshold intentionally chosen to safely fit within IPv6’s minimum Maximum Transmission Unit (MTU) of 1,280 bytes without triggering packet fragmentation. More recent standards have recommended a maximum limit of 1,400 bytes for DNS over UDP.
An ML-DSA-44 signature easily exceeds that budget on its own, well before factoring in the signed resource record sets, domain names, transport headers, and other necessary DNSSEC records. Transmitting such an oversized response using fragmented UDP is widely recognized as unreliable and is actively discouraged across modern network engineering practices. Instead, authoritative nameservers must return a truncated response, which instructs the querying resolver to immediately retry the request over a reliable connection-oriented transport protocol, typically TCP.
This limitation is most prominent in DNSKEY responses, which contain the cryptographic keys required by a resolver to validate a zone. Because ML-DSA-44 cannot immediately replace conventional signing algorithms before achieving universal ecosystem support—a multi-year endeavor—DNSKEY responses must contain both conventional and post-quantum keys and signatures simultaneously to ensure uninterrupted compatibility with older validators. Periodic key rollovers further increase the volume of data, expanding these responses even further.
Handling DNS traffic over alternative transport protocols is already standard practice. Traffic statistics from Cloudflare Radar indicate that approximately 85% of incoming queries to 1.1.1.1 arrive via UDP, while the underlying routing platform handles roughly 60% of queries over UDP across all integrated DNS services, with the remaining 40% relying on TCP, DNS over TLS, and DNS over HTTPS. Although large ML-DSA-44 responses may introduce additional TCP retries during upstream communication with authoritative servers, handling non-UDP traffic remains an established part of operating high-scale resolver infrastructure.
Addressing Downgrade Risks and Policy Enforcement
Replacing an existing DNSSEC algorithm cannot happen instantaneously. If a domain zone were to publish only ML-DSA-44 records, resolvers lacking software support would find themselves unable to validate the zone. Therefore, the practical migration path requires publishing conventional and post-quantum keys and signatures concurrently.
While this preserves operational compatibility, it does not provide standalone post-quantum security. Standard internet engineering guidelines specify that validators should accept any single valid cryptographic path, permitting validators to utilize whichever published algorithm they happen to support.
However, once a conventional algorithm like ECDSA is rendered obsolete and insecure, this permissive behavior introduces a dangerous downgrade path. An attacker could forge an ECDSA-only response that an unsuspecting resolver would willingly accept, despite the resolver having full software capability to support ML-DSA-44.
Preventing this specific downgrade vector requires an authenticated signal proving that a given zone must be validated using ML-DSA-44. To achieve this, 1.1.1.1 utilizes Delegation Signer (DS) records published by the parent zone. If the authenticated DS record set contains a valid record corresponding to a supported post-quantum algorithm, the security signal is confirmed.
Upon verification, 1.1.1.1 applies a more restrictive local validation policy, demanding at least one verified post-quantum validation path; a conventional path is no longer accepted as sufficient on its own. If an ML-DSA-44 path fails to validate, the entire validation process fails. While this behavior extends beyond traditional DNSSEC validation rules, existing internet standards explicitly permit local resolver policies to dictate whether additional cryptographic signatures must be checked and how conflicting validation results are managed.
This design ensures that conventional signatures remain available to support older, legacy resolvers without permitting post-quantum-capable resolvers to downgrade to weaker protections. The downgrade signal remains secure only if ML-DSA-44 deployment and strict downgrade protections extend unbroken from the primary trust anchor down through every subsequent zone delegation. Simply rotating zone keys more frequently fails to resolve the underlying vulnerability, as an attacker could target a vulnerable key situated higher in the chain of trust and successfully forge every delegation beneath it.
The Road Ahead for Post-Quantum DNSSEC
Integrating a post-quantum algorithm into the DNSSEC architecture requires extensive coordination across the industry. It demands native implementations within cryptographic libraries, an official IANA-assigned DNSSEC algorithm number, robust support from authoritative nameservers and validating resolvers, and widespread adoption across every tier of the DNS delegation hierarchy.
ML-DSA-44 now possesses the initial technical prerequisites for widespread deployment, having received formal standardization from NIST and integration into standard cryptographic libraries. Its practical application within DNSSEC is outlined in the specialized ML-DSA for DNSSEC Internet-Draft, and the Internet Assigned Numbers Authority (IANA) has formally assigned it DNSSEC algorithm number 18.
Adding ML-DSA-44 validation capabilities to public resolvers represents a foundational step, but it does not instantly establish a complete post-quantum chain of trust. Authoritative server operators must eventually sign their respective zones using ML-DSA-44, domain registrars must update their systems to accept and submit the corresponding DS records, and top-level registries must publish those records within parent zones.
This adoption lifecycle must extend continuously through every intermediary parent zone up to the absolute root of the DNS. Ultimately, the DNS root must adopt ML-DSA-44, and its post-quantum key must transition into a permanent trust anchor for validating resolvers worldwide, as any unpatched level in the hierarchy introduces a potential security downgrade point.
Because signing a zone with ML-DSA-44 yields limited security benefits if no resolvers validate those signatures, enabling ML-DSA-44 validation by default within 1.1.1.1 provides an essential mechanism to measure the real-world operational costs of signature verification, expanded network bandwidth, and increased TCP utilization between resolvers and authoritative nameservers.
In parallel with these software updates, engineers will continue evaluating real-world deployability via background probing across a fraction of Cloudflare Challenge Pages. These targeted probes examine whether clients can successfully resolve and communicate with test domains signed with ML-DSA-44 across varied real-world network conditions. Independent DNS operators and software developers are similarly encouraged to begin testing ML-DSA-44 at scale to ensure the broader infrastructure adapts smoothly as adoption scales upward over the coming years.
Leave a Reply