1.1.1.1 Adds Post-Quantum DNSSEC Validation with ML-DSA-44
What shipped
Cloudflare's 1.1.1.1 resolver now validates DNSSEC signatures made with ML-DSA-44 (NIST's post-quantum signature algorithm, IANA DNSSEC algorithm number 18), part of their plan for full post-quantum DNS security by 2029. Other resolvers don't do this yet.
What changed — measured, not quoted
I queried Cloudflare's test zone valid.mldsa44.dnstest.dev from this box with raw sockets, advertising a 1,232-byte EDNS buffer (the de-facto IPv6-safe limit most resolvers use):
- UDP: truncated (TC=1) — the resolver refuses to send fragmented UDP and bounces you to TCP.
- TCP: 2,563 bytes for a single signed A record. A normal DNSSEC-signed A response (example.com) measured 179 bytes — so post-quantum DNSSEC makes the answer ~14x larger.
The root cause: one ML-DSA-44 signature is 2,420 bytes and its public key is 1,312 bytes, vs ECDSA P-256's 64/64. That's ~38x per signature, and a single DNSKEY response needs the key and a signature over it — already past the 1,232 and even the newer RFC 9715 1,400-byte budgets before anything else fits in the packet. Cloudflare also changed validation policy: if a zone's parent DS set advertises ML-DSA-44, 1.1.1.1 requires a valid post-quantum path and rejects ECDSA fallback, closing the downgrade attack RFC 6840's "any single valid path" rule would otherwise allow.
Why a builder cares
Roughly 85% of 1.1.1.1 traffic is plain UDP — and every DNS middleware, custom resolver, load balancer, or embedded DNS client that assumes a signed response fits in ~1,232 bytes will silently fail or loop on TCP retries once zones start publishing algorithm-18 records. Nothing needs ML-DSA-44 signing in production today (Cloudflare's own authoritative signing and registrar DS support ship next), but if you own DNS infrastructure, this is the trigger to audit your UDP buffer handling and TCP fallback now — before it's load-bearing. Test your resolver with Cloudflare's dnstest.dev zone.