Post-Quantum DNSSEC: Cloudflare 1.1.1.1 and ML-DSA-44
Cloudflare’s 1.1.1.1 resolver now validates DNSSEC signatures made with ML-DSA-44. This is a real production deployment on the resolver side, but it does not mean DNSSEC as a whole is post-quantum secure or that the ML-DSA mapping is an approved IETF standard.
Two facts must remain separate:
- ML-DSA-44 is standardized by NIST in FIPS 204.
- The use of ML-DSA-44 in DNSSEC is defined by an individual Internet-Draft. The draft is work in progress, has no formal IETF standards status and can change.
Cloudflare deployed validation support early to measure operational behavior. Domain operators cannot assume that every authoritative provider, registrar, registry or resolver can publish and validate the same records today.
What Cloudflare deployed
Cloudflare enabled ML-DSA-44 signature validation by default on the 1.1.1.1 recursive resolver. When a signed zone publishes the experimental DNSSEC records needed for this algorithm, 1.1.1.1 can validate them. Existing DNSSEC zones using classical algorithms continue to work as before.
If you use 1.1.1.1 as a client, Cloudflare says no configuration change is required. This is resolver capability, not a user-facing switch.
The deployment does not yet provide a normal production path for Cloudflare customers to sign their own zones with ML-DSA-44. Cloudflare identifies authoritative DNS signing and registrar DS-record support as next steps. Until those pieces exist across the delegation path, resolver support alone cannot create an end-to-end post-quantum chain of trust.
Current status by DNSSEC layer
| Layer | Current status | Why it matters |
|---|---|---|
| ML-DSA-44 algorithm | NIST standard, FIPS 204 | Defines the signature algorithm and parameters |
| ML-DSA DNSSEC mapping | Individual Internet-Draft | Defines DNSKEY, RRSIG and DS handling, but is not an RFC |
| Cloudflare 1.1.1.1 validation | Production support | A major recursive resolver can validate experimental ML-DSA-44 records |
| Cloudflare authoritative signing | Planned | Zones still need a supported signer and publishing path |
| Cloudflare Registrar DS support | Planned | Parent delegation must carry the required DS relationship |
| DNS root trust anchor | Not migrated | A full post-quantum chain requires protection up to the root |
This is meaningful deployment evidence, not ecosystem completion.
Why the 2,420-byte signature matters
An ML-DSA-44 signature is 2,420 bytes. Its public key is 1,312 bytes. The signature alone is much larger than the traditional DNS UDP size limit and larger than the common 1,232-byte response size used to reduce IP fragmentation risk.
DNS has mechanisms for responses that do not fit into one UDP exchange. A resolver can retry over TCP after receiving a truncated response. But larger records affect more than raw bandwidth:
- more responses can require TCP fallback;
- packet loss and latency can have a larger effect;
- middleboxes may mishandle uncommon sizes or fallback behavior;
- authoritative servers and resolvers process more bytes per validation chain;
- denial-of-service and amplification analysis must account for larger signed responses;
- caches hold larger DNSKEY and RRSIG records.
Cloudflare’s deployment is useful precisely because laboratory support cannot answer every operational question. Resolver-side measurements can show the bandwidth, CPU and TCP effects at real scale.
The PQC algorithm reference lists the exact ML-DSA key and signature sizes. Teams should use those sizes in capacity tests instead of treating post-quantum signatures as drop-in ECDSA records.
Resolver support is not a complete chain of trust
DNSSEC authenticates a chain from a trust anchor through parent and child zones. A post-quantum signature at one level does not protect a classical link elsewhere in that chain. If an attacker can forge a classical signature at a higher delegation point, the lower ML-DSA signature does not repair that break.
Cloudflare notes that the DNS root would eventually need an ML-DSA-44 key that resolvers trust. Registries and registrars would also need compatible DS handling, authoritative signers would need to publish the records, and validating resolvers would need to understand them.
This is why “1.1.1.1 supports post-quantum DNSSEC” is accurate only when scoped to validation capability. “DNS is now quantum-safe” is false.
Standardization status
The current mapping is draft-westerbaan-dnssec-mldsa-04, dated August 11, 2026. It specifies:
- ML-DSA-44 from FIPS 204;
- a 1,312-octet public key in DNSKEY records;
- a 2,420-octet signature in RRSIG records;
- pure ML-DSA with an empty context string;
- IANA DNSSEC algorithm number 18, with the mnemonic
MLDSA44.
IANA registration makes the code point usable and unambiguous; it does not turn the document into an RFC or complete the IETF standards process. The Datatracker still identifies the mapping as an active Internet-Draft with intended Standards Track status. IANA currently marks signing, validation and implementation as MAY, not RECOMMENDED. Implementers should continue tracking draft changes.
A separate individual draft, draft-kaizer-dnsop-ml-dsa-mtl-dnssec-01, explores ML-DSA-44 with Merkle Tree Ladders to reduce storage and response overhead. It has no formal IETF standards standing and is not the mechanism Cloudflare says 1.1.1.1 currently deploys.
FIPS 204 standardizes ML-DSA. It does not by itself standardize every protocol mapping that carries ML-DSA signatures. The distinction is the same one migration teams must make for TLS, certificates, code signing and other systems.
What domain operators need to do today
Most domain owners should not attempt a production DNSSEC algorithm migration yet. The complete provider and delegation workflow is not broadly available, and the mapping is still a draft.
A practical response is:
- Inventory DNSSEC ownership. Record the registrar, registry, authoritative provider, signer, key-management system and validating resolvers used internally.
- Ask vendors about roadmap and interoperability. Request exact support for signing, DS publication, rollover, monitoring and rollback.
- Test in an isolated zone. Do not begin with a critical production domain.
- Measure UDP, fragmentation and TCP behavior. Include enterprise firewalls, load balancers and restrictive networks.
- Keep classical validation working during experiments. Do not create an unplanned outage while testing an experimental algorithm mapping.
- Track draft changes. Pinning production tooling to draft version 00 without an upgrade plan creates migration debt.
- Define evidence per layer. Resolver validation, authoritative signing and parent delegation are separate checkpoints.
Add this work to the post-quantum migration checklist and vendor inventory. The broader crypto-agility guide explains how to avoid hard-coding one experimental algorithm identifier into application and infrastructure logic.
What security teams should not claim
Avoid these statements in security reports:
- “Our DNS is quantum-safe because employees use 1.1.1.1.”
- “ML-DSA DNSSEC is an IETF standard.”
- “Cloudflare zones can all be signed with ML-DSA-44 today.”
- “One post-quantum RRSIG protects a chain that still depends on classical signatures.”
- “DNSSEC prevents harvest-now-decrypt-later attacks.”
DNSSEC provides authenticity and integrity, not DNS query confidentiality. Harvest-now-decrypt-later primarily concerns encrypted traffic whose confidentiality can be broken later. A future quantum attack on classical DNSSEC signatures would instead enable forgery.
For TLS confidentiality and origin authentication, see the separate Cloudflare post-quantum setup guide. Do not merge TLS key agreement and DNSSEC signature validation into one migration status.
Actionable takeaway
Treat Cloudflare’s deployment as a signal to start DNSSEC interoperability testing, not as a signal to switch critical zones immediately. Add resolver algorithm support and response-size behavior to your PQC test plan. Track the Internet-Draft, authoritative-signing roadmap, registrar support and root trust-anchor work separately.
The useful milestone is not “one resolver understands ML-DSA-44.” It is a tested chain in which every required signer, delegation and validator supports the selected standard without an unnoticed classical downgrade.
FAQ
Does 1.1.1.1 validate ML-DSA-44 DNSSEC today?
Yes. Cloudflare says its 1.1.1.1 recursive resolver now validates DNSSEC signatures made with ML-DSA-44 by default.
Is ML-DSA DNSSEC an IETF standard?
No. ML-DSA is standardized by NIST in FIPS 204, but its DNSSEC mapping is currently an individual Internet-Draft, not an RFC or approved IETF standard.
Can I enable ML-DSA-44 signing for my Cloudflare zone now?
Cloudflare’s announcement describes resolver validation as deployed and authoritative signing plus registrar support as upcoming work. Do not assume the complete customer signing workflow is available until the relevant product documentation confirms it.
Why are ML-DSA-44 DNS signatures difficult to deploy?
Each signature is 2,420 bytes and the public key is 1,312 bytes. These sizes increase bandwidth and can trigger more TCP fallback, expose middlebox problems and raise operational costs.
Does this make the DNS ecosystem quantum-safe?
No. A complete DNSSEC chain includes the root, parent delegations, authoritative zones and validating resolvers. Classical links remain downgrade or forgery points in a future quantum threat model.
Sources
- Cloudflare: 1.1.1.1 now supports post-quantum DNSSEC
- IETF Datatracker: current draft-westerbaan-dnssec-mldsa
- IANA DNSSEC Algorithm Numbers — algorithm 18 / MLDSA44
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- IETF Datatracker: ML-DSA with Merkle Tree Ladders for DNSSEC