Skip to content

CLOUDFLARE 2026-09-10 Tier 1

Read original ↗

1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it

Summary

Cloudflare's systems/cloudflare-1-1-1-1-resolver|1.1.1.1 resolver now validates DNSSEC signatures made with ML-DSA-44, the NIST-standardised (FIPS 204) post-quantum signature algorithm assigned IANA DNSSEC algorithm number 18. This is the resolver side of extending DNSSEC into the post-quantum era, and it lets Cloudflare test two hard problems at Internet scale: (1) carrying much larger DNS responses reliably — a single ML-DSA-44 signature is 2,420 bytes, ~38× an ECDSA P-256 signature and larger than common DNS-over-UDP payload budgets on its own — and (2) preventing a downgrade to conventional signatures while zones publish both classical and post-quantum keys for backward compatibility. It is an early, deliberately-resolver-first step: enabling validation now (by default, no user action) creates the operational runway and measurement data the DNS ecosystem needs before authoritative servers, registrars, registries, and ultimately the DNS root adopt ML-DSA. (Source: sources/2026-09-10-cloudflare-1111-post-quantum-dnssec)

Why post-quantum DNSSEC matters

  • DNS is unauthenticated by default. An attacker who can forge a response can redirect users. DNSSEC signs DNS records; a validating resolver like 1.1.1.1 walks a chain of signed records from the DNS root to the requested domain, checking authenticity.
  • Almost all deployed DNSSEC algorithms (RSA, ECDSA) fall to a CRQC. Cloudflare frames the concern as: if a sufficiently powerful quantum computer exists ~2030, an attacker could recover a private key and forge signatures validators accept.
  • DNSSEC is NOT subject to harvest-now-decrypt-later. DNSSEC provides authenticity, not confidentiality — there is nothing to capture-and-decrypt-later. Signature forgery is a live attack, so the threat only materialises at Q-Day. This is the DNSSEC instance of the PQ-authentication timeline: urgency is driven by migration coordination lead time, not by retroactive risk.
  • "Break once, forge everywhere." The migration must eventually reach the DNS root, where a compromised key has maximum impact — an attacker who recovers a root zone signing key with a CRQC could forge a validation path to any zone below it. This is the DNSSEC-specific shape of the long PQ-authentication dependency chain.

The two hard problems

Problem 1 — a 2,420-byte signature breaks the packet

Signature-size comparison (from the post's IANA-algorithm table):

Algorithm DNSSEC number Public key Signature
RSA-2048 / SHA-256 8 260 bytes 256 bytes
ECDSA P-256 13 64 bytes 64 bytes
ML-DSA-44 18 1,312 bytes 2,420 bytes

DNS message-size lineage that this collides with:

  • DNS originally restricted UDP messages to 512 bytes (RFC 1035).
  • EDNS(0) (RFC 6891) lets a resolver advertise the largest UDP response it will accept.
  • Many implementations use a conservative 1,232-byte UDP payload limit (fits within IPv6's 1,280-byte minimum MTU).
  • RFC 9715 more recently recommends a max of 1,400 bytes for DNS over UDP.

A single ML-DSA-44 signature (2,420 B) exceeds all of these before counting the signed RRset, domain names, DNS headers, and other DNSSEC records. Fragmented UDP is unreliable and to be avoided, so the correct behaviour is: the authoritative server returns a truncated response, prompting the resolver to retry over another transport, usually TCP — a transport-fallback cost. The effect is most visible in DNSKEY responses (they carry the 1,312-byte public key and the 2,420-byte signature), and during the multi-year transition DNSKEY RRsets may carry both conventional and post-quantum keys + signatures, with key rollovers adding still more.

Operational grounding (Cloudflare Radar / Big Pineapple traffic mix):

  • ~85% of queries to 1.1.1.1 arrive over UDP.
  • Across all services on Big Pineapple (which also powers Gateway DNS), ~60% of queries arrive over UDP; the remaining ~40% use TCP, DoT, and DoH.
  • Those figures describe client → resolver; the larger ML-DSA-44 responses can additionally cause more TCP retries on the resolver → authoritative side, but handling non-UDP transport is already normal at 1.1.1.1 scale.

Problem 2 — supporting two algorithms introduces a downgrade risk

  • Replacing a DNSSEC algorithm cannot happen atomically: a zone publishing only ML-DSA-44 is unvalidatable by resolvers that don't support it. So the migration path is to publish conventional + post-quantum together (algorithm coexistence).
  • But RFC 6840 §5.11 says "validators SHOULD accept any single valid path." Once a conventional algorithm (e.g. ECDSA) is no longer secure, that same rule becomes a downgrade path: an attacker forges an ECDSA-only answer that a resolver accepts despite supporting ML-DSA-44. This is the DNSSEC instance of the general PQ-downgrade problem — supporting PQ is not enough; the classical path must not be silently acceptable.
  • 1.1.1.1's mitigation: use the DS records published by the parent zone as an authenticated downgrade signal. If the authenticated DS RRset contains a record for a supported post-quantum algorithm, the signal is present, and 1.1.1.1 applies a more restrictive local validation policy: it requires at least one valid post-quantum validation path; a conventional path alone is no longer sufficient, and if no ML-DSA-44 path validates, validation fails. This is not (yet) standard DNSSEC behaviour, but RFC 4035 §5.3.3 explicitly allows local resolver policy to decide whether additional signatures must be checked and how conflicts resolve.
  • Caveat the post is explicit about: the downgrade signal is only post-quantum-secure if ML-DSA deployment + downgrade protection extend from the trust anchor through every delegation. Rotating the zone key more frequently does not help — an attacker targets a vulnerable key anywhere higher in the chain and forges every delegation below it (the "break once, forge everywhere" property again).

Key takeaways

  1. 1.1.1.1 validates ML-DSA-44 DNSSEC signatures by default, now — the resolver side of PQ DNSSEC. Users need to change nothing; existing DNSSEC zones keep validating as before. (Source: sources/2026-09-10-cloudflare-1111-post-quantum-dnssec)
  2. PQ signatures are large and break the DNS packet-size model. ML-DSA-44: 1,312-byte public key + 2,420-byte signature; ~38× ECDSA P-256's 64-byte signature. Exceeds the 512 / 1,232 / 1,400-byte UDP budgets → truncate → TCP retry, most visibly on DNSKEY responses that carry both key and signature (and, during transition, both classical and PQ material).
  3. Enabling PQ is not enough — you must prevent downgrade. RFC 6840's "accept any single valid path" becomes a downgrade vector once classical is breakable. 1.1.1.1 uses the parent-zone DS RRset as an authenticated signal to enforce a PQ-path-required local policy (RFC 4035 §5.3.3 permits it).
  4. DNSSEC is authenticity-only → no HNDL; the threat is live at Q-Day. The reason to start now is migration coordination lead time across authoritative servers, registries, registrars, and the DNS root — "break once, forge everywhere" at the root makes the top of the hierarchy the highest-value target.
  5. ML-DSA-44 now has its deployment prerequisites in DNSSEC: NIST standardisation (FIPS 204), cryptographic-library support, an IANA-assigned DNSSEC algorithm number 18, and the ML-DSA for DNSSEC Internet-Draft.
  6. Resolver-first is deliberate sequencing. There's little value signing a zone with ML-DSA if no resolver validates it; enabling validation on 1.1.1.1 lets Cloudflare + the ecosystem measure verification cost, extra bandwidth, and increased TCP use before pushing adoption up the chain.
  7. Next steps (roadmap): ML-DSA signing in Cloudflare Authoritative DNS and DS-record support in Cloudflare Registrar (free to all customers) — to test the complete path from generating signatures and publishing DNSKEY records through transporting and validating them via 1.1.1.1. Real-world deployability will also be probed via background probes on a small fraction of Cloudflare Challenge Pages. Sits within Cloudflare's full post-quantum security by 2029 roadmap. This is a default-on security upgrade: validation is on with no config.

Systems / concepts / patterns extracted

Operational numbers

  • ML-DSA-44 signature: 2,420 bytes; public key: 1,312 bytes; DNSSEC algorithm number 18.
  • ECDSA P-256 comparison: 64-byte signature (ML-DSA-44 ≈ 38× larger).
  • RSA-2048/SHA-256: 260-byte key / 256-byte signature.
  • DNS UDP budgets: original 512 B; conservative EDNS 1,232 B (IPv6 min MTU 1,280 B); RFC 9715 recommended max 1,400 B.
  • Transport mix: ~85% of 1.1.1.1 queries over UDP; ~60% UDP across all Big Pineapple services (~40% TCP/DoT/DoH).
  • Worked dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec: UDP reply truncated (WARNING: truncated reply ... retrying over TCP), EDNS advertised UDP size 1232 B, RRSIG uses algorithm 18, final response ~2,563 B received over TCP.

Caveats

  • Resolver-side only. This work covers DNSSEC validation. Signing (Authoritative DNS) and DS-record submission (Registrar/registries) are stated roadmap, not shipped in this post.
  • Local-policy, not-yet-standard. The DS-signal-gated "PQ-path required" behaviour is a deliberate local resolver policy (permitted by RFC 4035 §5.3.3), not current standard DNSSEC validation behaviour.
  • Downgrade protection is only as strong as the weakest link in the chain. Post-quantum security of the signal requires ML-DSA + downgrade protection from the trust anchor through every delegation to the root; more frequent zone-key rotation does not substitute.
  • Full chain of trust does not exist yet. Adding resolver validation is one of the first deployment steps; authoritative signing, registrar/registry DS publication, and root adoption (making the root's PQ key a trust anchor) all remain.

Source

Last updated · 766 distilled / 2,225 read