# 1.1.1.1 starts testing post-quantum DNSSEC

> Cloudflare's public resolver can now validate ML-DSA-44 signatures, an early infrastructure step whose 2,420-byte signatures expose the harder problem: moving much larger DNS answers reliably.

_Source: Cloudflare engineering announcement, checked against NIST FIPS 204, the IANA DNSSEC algorithm registry, RFC 9715, and independent technical coverage · 2026-09-11 · 6 min read · Verified against primary sources_

Canonical: https://iyu.app/e/cloudflare-post-quantum-dnssec

## The 60-second version

Cloudflare says 1.1.1.1 now validates ML-DSA-44 DNSSEC signatures, giving the Internet a large-scale resolver test bed for post-quantum migration.

**Key points**

- NIST standardized ML-DSA and IANA lists ML-DSA-44 as DNSSEC algorithm number 18, currently optional for signing and validation.
- A 2,420-byte ML-DSA-44 signature is almost 38 times larger than ECDSA P-256 and exceeds common DNS-over-UDP response targets by itself.
- Oversized answers can trigger a retry over TCP, making bandwidth, latency and middlebox compatibility central deployment questions.
- A complete chain still requires authoritative servers, registrars, registries and the DNS root to adopt post-quantum signing and downgrade protection.

**Verdict.** A meaningful resolver-side milestone and a useful stress test, but not evidence that DNSSEC as a whole is quantum-safe.

## Full explainer

Cloudflare says its **1.1.1.1 public resolver now validates ML-DSA-44 signatures in DNSSEC**. The algorithm is standardized by [NIST](https://csrc.nist.gov/pubs/fips/204/final) and listed by [IANA](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml) as DNSSEC algorithm 18. This is a real resolver upgrade, not a completed quantum-safe DNS migration.

> **⚑ Caveat:** The deployment status, traffic shares and 2029 roadmap are **Cloudflare's own reports**. NIST independently confirms the ML-DSA standard and IANA confirms the DNSSEC registration; neither source independently audits 1.1.1.1's production operation.


### The change — What the resolver can do now

DNSSEC signs DNS records so a resolver can verify that an answer belongs to an authenticated chain from the DNS root to the requested domain. Common deployed algorithms rely on RSA or elliptic-curve cryptography, which a sufficiently powerful future quantum computer could threaten.

ML-DSA uses a different, lattice-based design. NIST finalized it in FIPS 204 in 2024, and IANA's registry now assigns the ML-DSA-44 variant algorithm number 18. Cloudflare has added the validation side to 1.1.1.1: when a zone publishes the necessary records, the resolver can check them automatically.

> **i** Quantum computers capable of this attack do not exist today. DNSSEC authenticates public records rather than encrypting secret data, so it is not exposed to harvest-now-decrypt-later collection. Starting early matters because coordinated infrastructure migrations are slow.


### Packet pressure — Why 2,420 bytes changes the transport

- **2,420 B** — one ML-DSA-44 signature
- **1,312 B** — ML-DSA-44 public key
- **64 B** — ECDSA P-256 signature for comparison

An ML-DSA-44 signature is almost 38 times the size of an ECDSA P-256 signature. It also exceeds [RFC 9715](https://www.rfc-editor.org/rfc/rfc9715.html)'s general 1,400-byte recommendation for DNS-over-UDP responses before the response contains domain names, headers, keys or other DNSSEC records.

- **Small UDP answer:** Usually travels in one datagram with low overhead.
- **Oversized signed answer:** The server can mark the UDP reply truncated, prompting the resolver to retry over TCP.
- **Operational cost:** More bytes, more state and potentially more latency must be tested across middleboxes and DNS implementations.

TCP fallback is normal DNS behavior, not a failure. The concern is frequency and reliability at scale. Cloudflare says enabling validation lets it measure signature-verification cost, bandwidth and additional TCP use before adoption becomes widespread.


### Migration trap — Old and new signatures must coexist

A zone cannot simply remove its conventional signature while many resolvers do not understand ML-DSA-44. Publishing both preserves compatibility, but it can create a future downgrade path: a post-quantum-capable resolver might accept a forged conventional path after that older algorithm becomes breakable.

Cloudflare says 1.1.1.1 uses an authenticated DS record in the parent zone as a signal to require at least one valid post-quantum path. That is useful only where the chain itself is protected. Any unprotected parent, registry or root remains a place where downgrade resistance can break.


### Reality check — What is still missing

- **Resolver support:** 1.1.1.1 can validate algorithm 18, but other resolvers and software need their own implementations.
- **Authoritative signing:** DNS operators must be able to publish ML-DSA-44 keys and signatures reliably.
- **Delegation support:** registrars and registries must accept and publish the corresponding DS records.
- **Root adoption:** complete protection requires a post-quantum trust anchor and protected delegations from the root downward.
- **Operational evidence:** operators still need measurements for response size, fallback rates, latency, failure modes and rollover behavior.

> One resolver learning a new signature is the start of the migration, not the finish line.


### For users — No setting needs to change

People already using 1.1.1.1 do not need to enable anything. Existing DNSSEC zones continue to validate as before, and ML-DSA-44 validation applies when a zone publishes the new records. The practical takeaway is to watch adoption across authoritative DNS, registrars, registries and the root rather than treating a resolver announcement as proof that the whole system is quantum-safe.


## Primary sources

- [Cloudflare: 1.1.1.1 now supports post-quantum DNSSEC](https://blog.cloudflare.com/post-quantum-dnssec-1111/)
- [NIST FIPS 204: Module-Lattice-Based Digital Signature Standard](https://csrc.nist.gov/pubs/fips/204/final)
- [IANA DNS Security Algorithm Numbers registry](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml)
- [IETF Datatracker: ML-DSA for DNSSEC Internet-Draft](https://datatracker.ietf.org/doc/draft-westerbaan-dnssec-mldsa/)
- [RFC 9715: DNS Transport over TCP implementation requirements](https://www.rfc-editor.org/rfc/rfc9715.html)
- [PPC Land: independent technical coverage](https://ppc.land/cloudflares-1-1-1-1-now-validates-2-420-byte-quantum-safe-dns-signatures/)

---
_Published by iyu (https://iyu.app) — the day's AI news, checked against primary sources and rewritten in plain language. Free to quote with attribution and a link to the canonical URL._