Cloudflare brings ML-DSA validation to DNSSEC

The announcement falls outside the familiar discussion about encrypting a browser connection. DNSSEC authenticates DNS data: the records that help software find a service must come from the right source. A signature protects that claim. It does not conceal the query or encrypt the answer. Our ML-DSA explainer describes this distinction between proving who signed something and keeping its contents private.

A signature cannot fit in the usual response budget

The ML-DSA DNSSEC draft specifies a 1,312 byte public key and a 2,420 byte signature. These are the encoded cryptographic values, before the surrounding DNS records and message headers. Choosing the smallest ML-DSA parameter set still leaves a substantial transport problem.

RFC 9715 recommends avoiding IP fragmentation and returning a truncated response when a reply cannot fit the applicable UDP limit. The resolver can then try another transport, usually TCP. Raising a buffer setting does not make the network path carry a larger packet intact. A packet split into fragments can be lost or filtered, leaving the application waiting for an answer.

TCP is already part of DNS. RFC 7766 requires it in a full DNS implementation and warns that blocking it can cause failed lookups or timeouts. It also recommends reusing connections so several queries can share the cost of establishing one. For an operator, that changes the question from whether TCP exists to whether it works under the expected load.

Two signatures need an explicit acceptance rule

Compatibility introduces a separate problem. RFC 6840 section 5.11 says validators should accept a single valid authentication path. Publishing signatures from several algorithms therefore does not automatically require a resolver to verify them all. That behavior helps systems continue working during an algorithm transition.

The DNSSEC draft identifies the future downgrade risk: if an attacker can forge a conventional signature, a permissive validator may accept it after the attacker removes the post-quantum signatures. This is a conditional attack model, not evidence that a quantum computer has forged deployed DNSSEC today. Adding a stronger signature achieves little if the acceptance rule still permits the broken alternative.

Cloudflare describes a stricter rule: an authenticated parent DS record advertising a supported post-quantum algorithm triggers a requirement for a valid post-quantum path. Failure cannot be rescued by a conventional signature. A DS record is the parent's reference to a child's signing key.

That policy choice has a place in the protocol. RFC 4035 section 5.3.3 leaves local resolver policy to decide whether additional signatures need checking and how conflicting results are handled. The important engineering question is which evidence activates the stricter rule, and whether that evidence is itself authenticated.

Resolver support is one part of the trust chain

The IANA registry assigns algorithm number 18 to ML-DSA-44. Its DNSSEC specification remains an Internet-Draft. The FIPS 204 algorithm standard and the protocol document are different things: a standardized signature does not turn every protocol that uses it into a finished standard.

RFC 4035 describes how a resolver works from a trust anchor through authenticated delegations to a zone's key. Applying that model to quantum resistance gives a practical limit: a protected leaf cannot compensate for a forgeable parent. An attacker able to replace a higher delegation can change what the resolver trusts below it. The deployment has to protect the path, including the starting trust anchor.

What to test before claiming readiness

For teams responsible for DNS infrastructure, our recommendation is to separate transport tests from validation tests. A successful lookup can show that a large reply arrived while saying little about which signature the resolver required. Conversely, a correct verifier is of no use when the network drops the reply. Record both outcomes.

• Exercise large signed responses across the actual firewall and resolver path, including truncated UDP replies and TCP retries. Measure failures and latency instead of assuming the signature size predicts them.
• In a controlled test zone, check valid, missing and invalid post-quantum signatures alongside conventional signatures. Confirm the expected result when the authenticated parent advertises ML-DSA.
• Map who controls each delegation and trust anchor. Ask authoritative DNS, registrar and resolver providers separately what they support and what evidence their validation policy requires.

Keep those dependencies in the cryptographic inventory and use them to shape the migration roadmap. We have updated the ML-DSA standards page with the DNSSEC integration and its limits. This review draws on protocol documents and the vendor's announcement; it does not report our own resolver benchmarks. The next useful evidence is whether a real deployment delivers the answer and rejects the fallback it promised to reject.

References

• Cloudflare: 1.1.1.1 now supports post-quantum DNSSEC, 10 September 2026. Deployment announcement and local validation policy.
• ML-DSA for DNSSEC, revision 04, 11 August 2026. Work in progress: encoding, sizes and downgrade considerations.
• IANA DNSSEC algorithm registry. Algorithm 18 and implementation status labels.
• RFC 9715: IP Fragmentation Avoidance in DNS over UDP. Response sizing and truncation guidance.
• RFC 7766: DNS Transport over TCP. TCP support and connection reuse.
• RFC 6840, section 5.11. Multiple algorithms and validator acceptance.
• RFC 4035, sections 5.2 and 5.3.3. Authentication paths and local signature policy.