Skip to content

Quantum Observer

Cloudflare’s 1.1.1.1 Resolver Begins Validating ML-DSA-44 Signatures for DNSSEC

An ML-DSA-44 signature is 2,420 bytes, larger than many DNS implementations allow in one UDP packet. Cloudflare's engineers wrote that signing servers, registrars, registries, and the DNS root must all adopt the algorithm too.

Illustration: A large yellow envelope with an embossed seal cannot fit through a narrow mail slot.
Illustration: Quantum Observer (AI-generated)

Cloudflare’s 1.1.1.1 public DNS resolver now validates DNSSEC signatures made with ML-DSA-44, a post-quantum signature algorithm, by default, the company said on September 10, 2026. Cloudflare engineers Sebastiaan Neuteboom and Bas Westerbaan described the change in a blog post and wrote that people who use the resolver do not need to change anything.

DNSSEC is an extension of the Domain Name System under which the owner of a domain attaches digital signatures to its DNS records. With it, a resolver, the server that looks up internet addresses for users’ devices, can confirm that the domain’s owner signed a record and that nobody altered it in transit.

Cloudflare’s resolver can now check post-quantum signatures, but a domain gains that protection only after the servers that sign its records, its registrar, its registry, and the DNS root adopt ML-DSA-44, the engineers wrote. Cloudflare has not yet added ML-DSA-44 signing to its own authoritative DNS service. An authoritative server is the machine that publishes a domain’s DNS records and answers queries about them.

NIST published ML-DSA, formerly CRYSTALS-Dilithium, as FIPS 204 in August 2024. ML-DSA-44 is the smallest of the three versions, or parameter sets, that NIST specified.

Signatures larger than a DNS packet

An ML-DSA-44 signature is 2,420 bytes and a public key 1,312 bytes, the engineers wrote. The signature is almost 38 times the size of the 64-byte signature produced by ECDSA P-256, an elliptic-curve algorithm used in DNSSEC today.

About 85% of queries to 1.1.1.1 arrive over UDP, according to Cloudflare Radar data cited in the post. UDP carries each message as one datagram, without the connection setup that TCP requires, and a response too large for the network path is split into fragments or resent over TCP.

Many DNS implementations use a conservative UDP payload limit of 1,232 bytes, the engineers wrote. The Internet Engineering Task Force (IETF) recommended a maximum of 1,400 bytes for DNS over UDP in RFC 9715, published in January 2025. A single ML-DSA-44 signature is larger than both limits.

When an answer is too large for UDP, the engineers wrote, the authoritative server should return a truncated response, the signal for a resolver to retry over another transport, usually TCP. Cloudflare reported no measurements of the operational overhead in the post. The engineers wrote that the company will measure the operational cost of signature verification, the additional bandwidth, and the increased use of TCP.

A rule against downgrades

A zone is a portion of the DNS, such as a single domain, that one operator manages. During a transition, a zone’s operator can publish both ECDSA and ML-DSA-44 signatures so that resolvers without post-quantum support can still validate the zone’s records. Under RFC 6840, “Validators SHOULD accept any single valid path.”

Once ECDSA is no longer secure, the engineers wrote, “the same behavior creates a downgrade path.” In a downgrade attack, an attacker strips the stronger signatures from an answer and presents only weaker signatures that the attacker can forge. An attacker with a sufficiently large quantum computer running Shor’s algorithm could forge RSA and ECDSA signatures.

A delegation signer (DS) record is an entry in a parent zone, such as .com, that contains a cryptographic hash of a key belonging to the zone below it. When the authenticated DS records for a zone include a supported post-quantum algorithm, 1.1.1.1 now requires at least one valid post-quantum validation path. “If no ML-DSA-44 path validates, validation fails,” the engineers wrote.

The engineers acknowledged that the rule is not yet normal DNSSEC validation behavior and cited RFC 4035, under which a resolver’s operator can decide, as local policy, whether additional signatures must be checked.

The chain above the resolver

The engineers summed up the risk in the DNS hierarchy as “break once, forge everywhere.” An attacker who recovers a root zone signing key could forge validation paths to every zone below it, they wrote.

The engineers listed the remaining steps toward post-quantum DNSSEC. Authoritative servers must sign zones with ML-DSA-44, registrars must accept and submit the matching DS records, and registries must publish them in parent zones.

The DNS root zone, at the top of the hierarchy, must adopt ML-DSA-44 as well, the engineers wrote. The root’s post-quantum key must become a trust anchor for validating resolvers, they added. A trust anchor is a key that a validating resolver is configured to trust from the outset.

The Internet Assigned Numbers Authority (IANA) has given ML-DSA-44 the DNSSEC algorithm number 18. IANA lists the algorithm in its registry as MAY for implementing and using it in both signing and validation. In IETF terminology, MAY means optional.

Westerbaan and Sophie Schmieg of Google wrote the Internet-Draft on using ML-DSA-44 in DNSSEC. No IETF working group has adopted the draft, an individual submission with no formal standing in the IETF standards process.

What Cloudflare plans next

Cloudflare said its next step is adding ML-DSA-44 signing to Cloudflare Authoritative DNS, along with matching DS record support in Cloudflare Registrar. The engineers wrote that this will be available to all customers for free but gave no date.

The company published a test page where operators can check whether their resolvers validate ML-DSA-44. Cloudflare has set a target of full post-quantum security, including authentication, across its products by 2029.