Generated by Codex with GPT 5.6 Sol XHigh

Replacing a cryptographic algorithm is rarely just a cryptography project. In DNSSEC, a stronger signature changes packet sizes, transport behavior, compatibility rules, and the meaning of a successful validation. Cloudflare’s first production step toward post-quantum DNSSEC is therefore less about dropping a new primitive into a library than about making the surrounding protocol migration safe enough to observe at Internet scale.

The official Cloudflare Blog published the post on September 10, 2026. It explains how the 1.1.1.1 resolver added validation for ML-DSA-44, the first NIST-standardized post-quantum signature algorithm assigned a DNSSEC algorithm number, and why Cloudflare also adopted a stricter local rule to prevent conventional signatures from becoming a downgrade path.

One signature changes the packet path

DNSSEC authenticates DNS answers through a chain of signed records. A validating resolver starts from a trusted root key, follows Delegation Signer records through parent zones, and checks the signatures protecting the requested data. Today’s common algorithms, including RSA and ECDSA, rely on mathematical problems that a sufficiently capable quantum computer is expected to break. If an attacker recovered a signing key high in the DNS hierarchy, the attacker could forge the delegations and records beneath it.

Unlike encrypted traffic, DNSSEC signatures do not expose old secrets to a “harvest now, decrypt later” attack. The urgency comes from deployment time. Updating DNSSEC requires coordinated support from cryptographic libraries, authoritative servers, registrars, registries, recursive resolvers, and eventually the DNS root. Cloudflare’s earlier work on post-quantum TLS showed that large messages can uncover hidden assumptions and middlebox failures, and broad client adoption can take years. Resolver support creates a way to discover those problems before the quantum threat becomes immediate.

ML-DSA-44 makes the systems problem visible in bytes. An ECDSA P-256 signature is 64 bytes; an ML-DSA-44 signature is 2,420 bytes, and its public key is another 1,312 bytes. Many DNS implementations advertise a 1,232-byte UDP payload limit so a response fits inside IPv6’s minimum 1,280-byte MTU, while newer guidance recommends no more than 1,400 bytes over UDP. The post-quantum signature alone exceeds either budget before adding names, headers, signed records, or other DNSSEC material.

Fragmenting the response across UDP packets would be unreliable. The safer path is for the authoritative server to mark the UDP response as truncated so the resolver retries over TCP or another stream transport. DNSKEY answers are especially large because they carry both the public keys and the signatures covering them. During a rollover they may include still more keys, and throughout the compatibility period they will often contain both conventional and post-quantum material.

This does not mean DNS suddenly becomes a TCP-only protocol. Cloudflare reports that about 85% of queries reaching 1.1.1.1 use UDP, while its broader Big Pineapple resolver platform already handles a substantial share over TCP, DNS over TLS, and DNS over HTTPS. The operational change is on the resolver-to-authoritative path: ML-DSA-44 answers will trigger more retries, consume more bandwidth, and exercise code paths that small conventional signatures touched less often. Enabling validation in a large public resolver makes those costs measurable under real traffic.

Compatibility is also a downgrade surface

The harder security problem comes from the years when old and new algorithms must coexist. A zone that publishes only ML-DSA-44 would become unverifiable to resolvers that do not yet support it. Publishing both ML-DSA-44 and a conventional signature preserves compatibility, but ordinary DNSSEC validation permits a resolver to accept any one valid authentication path. Once the conventional algorithm becomes breakable, an attacker could strip or replace the post-quantum material and present a forged conventional-only answer.

Cloudflare closes that path by treating the parent’s authenticated DS records as a capability signal. If the DS record set advertises a post-quantum algorithm that 1.1.1.1 supports, the resolver requires at least one valid post-quantum chain. A valid RSA or ECDSA path is no longer sufficient by itself. Older resolvers can continue using the conventional records, while post-quantum-aware resolvers refuse to silently fall back after the parent has declared that stronger validation should be available.

That rule is stricter than normal DNSSEC behavior, but the protocol allows a resolver to apply additional local validation policy. More importantly, the signal must itself be protected all the way to the trust anchor. A post-quantum signature on a leaf zone does not help if an attacker can forge a conventional key or delegation in a parent zone. Complete protection ultimately requires ML-DSA-44 adoption through each level of the hierarchy and a post-quantum root trust anchor.

The design illustrates a general migration principle: dual operation needs an authenticated preference for the stronger mode. Supporting a new algorithm is not enough if an attacker can force every upgraded participant back onto the old one. Compatibility should remain available to legacy clients without letting modern clients mistake compatibility for security.

Turn deployment into an experiment

Cloudflare has enabled ML-DSA-44 validation by default in 1.1.1.1, so users do not need to change their resolver settings. Existing zones continue validating as before, and the stronger policy activates only when the authenticated delegation advertises the post-quantum algorithm. A public test zone demonstrates the expected transport behavior: the initial 1,232-byte UDP exchange is truncated, the client retries over TCP, and the resolver returns an authenticated answer carrying an algorithm-18 signature.

The rollout is deliberately incomplete. Resolver validation supplies one side of the ecosystem, but authoritative servers still need to sign zones, registrars must accept the new DS records, registries must publish them, and the root must eventually anchor the chain. Cloudflare says its next steps are ML-DSA-44 signing in Authoritative DNS and matching registrar support. It also plans background probes on a small fraction of Challenge Pages to test whether real client networks can resolve and reach an ML-DSA-44-signed domain.

Those probes and production resolver traffic can reveal the engineering costs that standards documents cannot settle alone: signature-verification load, extra bandwidth, TCP retry rates, latency, fragmentation bugs, and incompatible network equipment. The point of shipping early is to replace speculation with operational evidence while failure is still a migration problem rather than a cryptographic emergency.

The broader lesson is that algorithm agility is an end-to-end systems property. A post-quantum primitive can be mathematically sound and still fail in production if its messages do not fit the dominant transport, its compatibility mode permits downgrade, or one link in the trust chain remains forgeable. Cloudflare’s approach combines three pieces that belong together: deploy the new verifier, authenticate the decision to require it, and instrument the packet-level consequences. That is how a cryptographic standard becomes infrastructure that can survive the transition it was designed for.