Cloudflare has added post-quantum DNSSEC validation to its 1.1.1.1 public DNS resolver using ML-DSA-44, a digital-signature algorithm standardized by the U.S. National Institute of Standards and Technology. The company announced the production deployment on September 10, saying 1.1.1.1 can now validate DNSSEC signatures created with the post-quantum algorithm. The move extends Cloudflare’s broader migration toward cryptography designed to remain secure against future quantum computers.
DNSSEC protects the Domain Name System by attaching cryptographic signatures to DNS records, allowing validating resolvers such as 1.1.1.1 to check that responses are authentic and have not been modified. Existing deployments primarily rely on classical algorithms including RSA, ECDSA and Ed25519. A sufficiently capable quantum computer could eventually threaten several of those public-key systems, creating pressure to develop post-quantum alternatives before such machines become practical.
ML-DSA is one of the post-quantum signature standards selected by NIST, with ML-DSA-44 representing its smallest standardized parameter set. The algorithm is defined in FIPS 204 and is intended to resist attacks from both classical and cryptographically relevant quantum computers. Cloudflare has increasingly favored ML-DSA-44 for early deployments because it provides post-quantum authentication while carrying lower computational and bandwidth costs than the larger ML-DSA variants.

Those bandwidth costs are still considerable compared with today’s DNSSEC signatures. An ML-DSA-44 public key occupies 1,312 bytes, while each signature is 2,420 bytes, according to the current IETF proposal defining ML-DSA-44 for DNSSEC. By comparison, commonly used classical signatures can be far smaller, making packet size and network compatibility significant considerations when adding post-quantum cryptography to DNS.
Cloudflare engineer Bas Westerbaan and Google’s Sophie Schmieg have been working on an Internet-Draft describing how ML-DSA-44 can be represented in DNSKEY and RRSIG records. The draft assigns the algorithm an experimental DNSSEC identifier and lays out how its large public keys and signatures are encoded and validated. It remains an active Internet-Draft rather than a finalized Internet standard, meaning the technical specification may still evolve.
Downgrade attacks are another challenge. A domain may eventually be signed with both a post-quantum algorithm and a classical algorithm during the transition period, allowing older resolvers to continue validating it. The current IETF draft warns that a validator accepting any valid signature path could potentially be tricked into ignoring the ML-DSA-44 path and accepting a forged classical signature if quantum attacks against that older algorithm become viable.
One proposed defense is for post-quantum-aware resolvers to require a valid ML-DSA-44 signature whenever the DNS chain of trust indicates that one should be present. That prevents an attacker from simply stripping the post-quantum records and forcing validation back onto a weaker classical algorithm. Cloudflare specifically highlighted downgrade risks when announcing the new 1.1.1.1 capability, showing that deployment involves more than simply adding another signature verifier.
The update fits into Cloudflare’s wider post-quantum roadmap. The company has already deployed hybrid post-quantum key agreement across parts of its network and recently added ML-DSA support for authenticating connections between Cloudflare and customer origin servers. Cloudflare has said it is targeting full post-quantum security across its product portfolio by 2029, with authentication considered one of the more difficult parts of that transition.
For ordinary 1.1.1.1 users, the change does not require a new app or configuration. Its significance is primarily at the infrastructure level, giving Cloudflare’s resolver the ability to recognize and validate a new class of DNSSEC signatures as operators begin experimenting with them. With standards work still underway and post-quantum DNSSEC adoption at an early stage, the deployment is best viewed as an important step toward making the DNS authentication layer ready for a future in which classical public-key cryptography can no longer be assumed secure.

