Cloudflare Tests Post-Quantum DNSSEC on 1.1.1.1

Cloudflare has enabled ML-DSA-44 validation on its 1.1.1.1 public resolver, creating a large-scale test of post-quantum signatures in DNSSEC. The change is an early infrastructure step: domain owners do not need to change their DNS settings today.

What Cloudflare changed

Cloudflare announced on September 10, 2026 that 1.1.1.1 can now validate DNSSEC signatures created with ML-DSA-44. The algorithm is designed to resist attacks from future quantum computers and has been standardized by the U.S. National Institute of Standards and Technology.

This is resolver-side support. When a DNS zone publishes the necessary records, 1.1.1.1 can check the ML-DSA-44 signature as part of DNSSEC validation. Existing DNSSEC zones continue to work as before, and people who use 1.1.1.1 do not need to change a setting to receive the new validation behavior.

Why this is an experiment rather than a completed migration

DNSSEC creates a chain of signed DNS data from a domain toward the root of the Domain Name System. A post-quantum algorithm can protect that chain only when the required support exists across authoritative DNS servers, registrars, registries, validating resolvers and the DNS root.

That complete chain does not exist yet. The use of ML-DSA-44 in DNSSEC is still described by an Internet-Draft, while IANA currently assigns it DNSSEC algorithm number 18 with “MAY” values for signing, validation and implementation. Cloudflare’s deployment gives the industry a way to test resolver behavior and operational costs before broader adoption.

Large signatures are the immediate technical challenge

An ML-DSA-44 signature is 2,420 bytes. Cloudflare compares that with a 64-byte ECDSA P-256 signature commonly used in DNSSEC today. The post-quantum signature can therefore exceed a conservative DNS response size before the response contains the signed records, domain names and other DNSSEC data.

Large responses may need a retry over TCP or another transport instead of fitting into a normal UDP response. That is one reason early deployment matters: DNS operators can measure extra bandwidth, TCP use, compatibility and validation cost before post-quantum DNSSEC becomes widely used.

What domain owners should do now

For ordinary domain owners, there is no post-quantum DNS setting to enable today. Do not replace nameservers, change DS records or alter a working DNSSEC configuration merely because a resolver has begun this test.

Continue to treat DNSSEC as a coordinated setup between the authoritative DNS provider, registrar and registry. If DNSSEC is already enabled, keep the current keys and delegation maintained through the provider responsible for them. If you are evaluating DNSSEC, confirm the exact procedure with your DNS provider before making changes.

You can also use the NicNames domain lookup to understand whether a public registration result reports a signed delegation. That result is useful context, but it does not prove that every DNSSEC response validates correctly.

Keep this separate from the October root key rollover

Post-quantum algorithm testing and a DNSSEC key rollover are different changes. The planned October 11 root Key Signing Key transition changes the active root key while continuing to use established cryptography. Cloudflare’s ML-DSA-44 work tests a possible future signature algorithm and the larger responses it creates.

Operators of validating resolvers should still review the separate October root key rollover guidance. Website and domain owners who do not run validating resolvers generally do not need to take action for that rollover.

Cloudflare’s 1.1.1.1 change is valuable because it moves post-quantum DNSSEC from a specification into real operational testing. It is not a signal to modify a working domain configuration. For help reviewing a NicNames-managed domain or its current DNSSEC status, contact NicNames Support.