Cloudflare's public DNS resolver, 1.1.1.1, began validating DNSSEC signatures produced with ML-DSA-44 on September 10, 2026, a post-quantum signature algorithm standardized by the United States National Institute of Standards and Technology. The change marks an early move to prepare the Domain Name System for a period in which the signature algorithms securing it today could be broken.

In Short

Cloudflare's free internet service that turns website names into addresses can now check a new kind of digital signature designed to survive future quantum computers. It matters because the signatures currently protecting that lookup could one day be forged if a powerful enough quantum machine gets built, letting attackers send people to fake websites. Nothing changes for anyone already using 1.1.1.1 - the checking happens on its own when a website starts publishing the new records.

Why the timing is deliberate

According to Cloudflare, the company aims to reach full post-quantum security across its systems by 2029. Most of that effort has centered on Transport Layer Security, the protocol behind the padlock in a browser, but public-key cryptography underpins many other systems, and DNSSEC is one of them.

The company began experimenting with post-quantum key agreement in TLS in 2019 and switched it on for all customers in 2022. Post-quantum signatures inside DNSSEC have not seen equivalent testing. According to Cloudflare, widespread client adoption of post-quantum TLS took years, in part because the larger messages involved exposed hidden assumptions and bugs in existing network software. That history is the stated reason for starting DNSSEC testing well ahead of any immediate threat.

Quantum computers able to carry out the relevant attacks do not exist today. DNSSEC provides authenticity rather than confidentiality, so it does not face the "harvest now, decrypt later" problem that pushes encrypted traffic onto an urgent replacement schedule. According to Cloudflare, the reason to begin now is different: changing DNSSEC requires coordination across authoritative servers, registries, registrars, and validating resolvers, and the migration must eventually reach the top of the DNS hierarchy, where a compromised key does the most damage. An attacker who recovered a root zone signing key with a quantum computer could forge a validation path to any zone beneath it, a scenario the company describes as "break once, forge everywhere."

The concern is dated. According to Cloudflare, the work anticipates the possibility that by 2030 a sufficiently powerful quantum computer could be built that breaks RSA and ECDSA keys at the sizes currently deployed, allowing an attacker to recover a private key and generate forged signatures that validating resolvers would accept.

Cloudflare has been a recurring reference point in DNS resolution coverage since it launched the 1.1.1.1 resolver in April 2018, positioning it on speed and privacy against Google Public DNS and OpenDNS. The security layer under discussion here, DNSSEC, has its own long history: ICANN issued a public call for full DNSSEC deployment in February 2019after a pattern of attacks that altered the delegation structure of domain names, a class of interference that only succeeds when DNSSEC is absent.

How DNSSEC works, and why the algorithm is hard to change

DNS responses are not authenticated by default. An attacker who can forge a reply may redirect a user to an address of their choosing. DNSSEC counters this by signing DNS records. A validating resolver such as 1.1.1.1 follows a chain of signed records from the DNS root down to the requested domain, checking at each step that the answer is authentic and unaltered.

The system was designed to accept new algorithms. In principle, supporting ML-DSA-44 means publishing its public key and teaching validators to verify its signatures. According to Cloudflare, two properties make the transition difficult in practice: the signatures are large, and the older algorithm cannot always be removed safely.

The size gap is stark. An ECDSA P-256 signature runs 64 bytes. An ML-DSA-44 signature is 2,420 bytes, almost 38 times larger. The algorithm's public key is 1,312 bytes, against 64 for ECDSA P-256. The figures published by Cloudflare place ML-DSA-44 at DNSSEC algorithm number 18, alongside RSA-2048/SHA-256 at number 8 with its 256-byte signature and ECDSA P-256 at number 13.

A 2,420-byte signature changes the packet

That difference matters because the systems that send, carry, and receive DNS messages are sensitive to message size. DNS originally capped messages sent over UDP at 512 bytes. EDNS(0) later let a resolver advertise the largest UDP response it would accept from a nameserver. According to Cloudflare, many implementations use a conservative UDP payload limit of 1,232 bytes, chosen to fit inside IPv6's minimum maximum transmission unit of 1,280 bytes. RFC 9715 more recently recommended a ceiling of 1,400 bytes for DNS over UDP.

An ML-DSA-44 signature exceeds that 1,400-byte budget on its own, before the response accounts for the signed record set, domain names, DNS headers, and other DNSSEC records. According to Cloudflare, sending such a response as fragmented UDP is unreliable and should be avoided. The authoritative server should instead return a truncated response, which prompts the resolver to retry over another transport, usually TCP.

The effect surfaces most visibly in DNSKEY responses, which carry the keys a resolver needs to validate a zone. According to Cloudflare, an ML-DSA-44 public key is 1,312 bytes and the DNSKEY record set also carries a 2,420-byte signature. Because ML-DSA-44 cannot fully replace conventional signing algorithms until it is widely supported, a process the company expects to take years, DNSKEY responses may carry both conventional and post-quantum keys and signatures at once to stay compatible with older validators. Key rollovers can add still more keys, enlarging those responses again.

Handling DNS over transports other than UDP is not itself unusual at Cloudflare's scale. According to Cloudflare, its Radar data shows that roughly 85 percent of queries to 1.1.1.1 arrive over UDP. The platform behind 1.1.1.1, named Big Pineapple, also powers other DNS services including Gateway DNS, and across all services it handles, around 60 percent of queries arrive over UDP, with the remaining 40 percent using TCP, DNS over TLS, and DNS over HTTPS. Those figures describe how queries reach Cloudflare's resolver services rather than how 1.1.1.1 talks to authoritative servers, where large ML-DSA-44 responses can still trigger additional TCP retries.

The company's own network data has previously placed transport shares in a similar frame. Reporting on Cloudflare's expanded top-level domain tracking on its Radar platform in October 2025 noted that the company handles over 60 million HTTP requests per second, with roughly 70 percent over TCP and 30 percent over QUIC/UDP, and that its 1.1.1.1 resolver processes approximately 6 million DNS requests per second. That same platform surfaces DNSSEC validation rates as a security-posture metric for individual domains.

Supporting two algorithms introduces a downgrade risk

Replacing an existing DNSSEC algorithm cannot happen in a single step. If a zone publishes only ML-DSA-44, resolvers that do not support it cannot validate the zone at all. The practical path is therefore to publish conventional and post-quantum keys and signatures together. According to Cloudflare, that preserves compatibility but does not deliver post-quantum security on its own.

The reason lies in a validation rule. According to Cloudflare, RFC 6840 specifies that validators should accept any single valid path, which lets a validator use whichever published algorithm it supports. Once a conventional algorithm such as ECDSA is no longer secure, the same behavior opens a downgrade path: an attacker could forge an ECDSA-only answer that a resolver accepts even though it supports ML-DSA-44.

Preventing that requires an authenticated signal that a zone should be validated with the post-quantum algorithm. According to Cloudflare, 1.1.1.1 uses DS records published by the parent zone for this purpose. If the authenticated DS record set contains a record for a supported post-quantum algorithm, the signal is present, and 1.1.1.1 then applies a deliberately stricter local validation policy, requiring at least one valid post-quantum validation path. A conventional path alone no longer suffices, and if no ML-DSA-44 path validates, validation fails.

According to Cloudflare, this is not yet standard DNSSEC validation behavior, but RFC 4035 allows local resolver policy to determine whether additional signatures must be checked and how conflicting results are handled. The protection has a boundary condition the company states plainly: the downgrade signal is only post-quantum secure if ML-DSA-44 deployment and downgrade protection extend from the trust anchor through every delegation. Rotating a zone key more often does not close the gap, because an attacker can target a vulnerable key higher in the chain and forge every delegation below it.

The stakes of DNS-layer integrity have surfaced in adjacent contexts. When NextDNS introduced a DNS-level bypass for age verification systems in August 2025, the described implementation set or overrode DNS responses for specific domains while maintaining DNSSEC validation for authenticity, an illustration of the resolver's dual role in both directing and verifying answers.

What the migration still requires

Adding a post-quantum algorithm to DNSSEC takes more than standardizing the mathematics. According to Cloudflare, it requires implementations in cryptographic libraries, an IANA-assigned DNSSEC algorithm number, support from authoritative servers and validating resolvers, and adoption throughout the delegation chain. ML-DSA-44 now has the initial prerequisites: NIST has standardized it, common cryptographic libraries implement it, its use in DNSSEC is described in the ML-DSA for DNSSEC Internet-Draft, and IANA recently assigned it DNSSEC algorithm number 18.

Adding validation to resolvers is one of the first steps, but it does not by itself create a complete post-quantum chain of trust. According to Cloudflare, authoritative servers must sign zones with ML-DSA-44, registrars must accept and submit the corresponding DS records, and registries must publish them in parent zones. That adoption must extend through every parent zone to the DNS root, the root must adopt ML-DSA-44, and its post-quantum key must become a trust anchor for validating resolvers. Any level without post-quantum protection remains a downgrade point.

According to Cloudflare, there is little value in signing a zone with ML-DSA-44 if no resolver validates its signatures, which is why enabling validation by default on 1.1.1.1 functions as an early step. The company states that the move lets it measure the operational cost of signature verification, the additional bandwidth, and the increased TCP use between resolvers and authoritative servers. As in earlier migrations, Cloudflare says it will also test real-world deployability using background probes on a small fraction of its Challenge Pages, checking whether clients can resolve and reach an ML-DSA-44-signed test domain across real networks. The company invited other DNS operators and implementers to begin testing the algorithm at scale.

According to Cloudflare, users of 1.1.1.1 do not need to change anything: ML-DSA-44 validation runs automatically when a zone publishes the necessary records, while existing DNSSEC zones continue to validate as before. The company describes the current work as covering the resolver side of DNS, with the next step being ML-DSA-44 signing support in Cloudflare Authoritative DNS and corresponding DS record support in Cloudflare Registrar, both to be offered to all customers at no cost. That combination, the company says, would let it test the complete path from generating signatures and publishing DNSKEY records through transporting and validating them.

A verification example published with the announcement showed a query for a test domain returning a truncated UDP reply and retrying over TCP, with the answer received at 2,563 bytes and validated in about 20 milliseconds. According to Cloudflare, the community is tracking ML-DSA-44 software support on GitHub.

Why this matters for the marketing and media community

The mechanics sit several layers below the advertising stack, but the dependency is direct. Every impression, tracking call, measurement beacon, and creative fetch begins with a domain name resolving to an address. DNSSEC is the layer that certifies that resolution has not been tampered with, and a forged resolution is a route to redirecting traffic, intercepting data, or impersonating a property that carries or measures advertising.

The transport shift documented here also has practical weight. A move that pushes more DNS responses off UDP and onto TCP touches latency, and latency in resolution compounds across the chain of calls that load an ad-supported page. Cloudflare's network measurements have consistently tracked the migration of security features into mainstream traffic. Reporting on Cloudflare's 2025 Year in Review in December 2025 recorded that post-quantum encryption reached 52 percent of TLS 1.3 traffic by year-end, up from the 13 percent that the prior year's review in December 2024 had logged at the end of November 2024, both accelerating after Google Chrome enabled post-quantum encryption by default in version 124 in April 2025. The DNSSEC step extends that same trajectory into a different part of the plumbing.

The broader industry framing was set out when Amazon's chief technology officer issued technology predictions for 2026 in November 2025, which noted that major technology companies have converged on NIST standards such as ML-KEM, with Microsoft, Apple, Google, and AWS each deploying post-quantum protections across their platforms. ML-DSA-44, the signature algorithm at the center of the DNSSEC work, comes from the same NIST standardization effort. What Cloudflare has added is a test at internet scale for the signature side of that effort in a system where message size, not confidentiality, is the binding constraint.

Timeline

Summary

Who: Cloudflare, through its public DNS resolver 1.1.1.1, building on the ML-DSA-44 algorithm standardized by the United States National Institute of Standards and Technology and assigned DNSSEC algorithm number 18 by IANA.

What: The resolver now validates DNSSEC signatures made with ML-DSA-44, a post-quantum signature algorithm whose signatures run 2,420 bytes, almost 38 times larger than an ECDSA P-256 signature. To prevent a downgrade to still-published conventional signatures, 1.1.1.1 applies a stricter local policy requiring at least one valid post-quantum path when a parent zone's DS records signal post-quantum support.

When: The validation was enabled on September 10, 2026, with a test query recorded the day before. Cloudflare targets full post-quantum security by 2029 and frames the work around the possibility of a code-breaking quantum computer existing by 2030.

Where: On the resolver side of Cloudflare's DNS infrastructure, running on the Big Pineapple platform that also powers Gateway DNS, with signing support for Cloudflare Authoritative DNS and Cloudflare Registrar named as the next step.

Why: DNSSEC secures the resolution of domain names against forged answers, and the algorithms protecting it today are vulnerable to future quantum computers. Because migrating DNSSEC requires coordination across the full delegation chain to the DNS root, Cloudflare states that early large-scale testing of the larger post-quantum signatures is needed well before quantum computers become an immediate threat.