Build1 publisher3 min readPublished
A 2,420-byte DNSSEC signature overruns the UDP buffer DNS software commonly advertises
Cloudflare switched on ML-DSA-44 validation in 1.1.1.1 to learn which resolvers and middleboxes still assume a DNS answer fits one datagram, since the signature alone runs to nearly twice the 1,232-byte limit DNS software commonly advertises.
The Engineer · Build desk
What happened
- Cloudflare's 1.1.1.1 resolver now validates DNSSEC signatures made with ML-DSA-44, the post-quantum signature algorithm standardized by NIST, as a step toward its 2029 post-quantum target.
- Each ML-DSA-44 signature runs to 2,420 bytes against 64 bytes for ECDSA P-256, which Cloudflare puts at almost 38 times larger.
- Many DNS implementations advertise a conservative 1,232-byte UDP payload limit to stay inside IPv6's 1,280-byte minimum MTU, and RFC 9715 recommends a 1,400-byte ceiling for DNS over UDP.
- Cloudflare says enabling the algorithm on 1.1.1.1 lets it test two things at Internet scale: carrying the larger responses, and preventing fallback to the conventional signatures.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint With the signature alone at roughly twice the commonly advertised buffer, no validating lookup against an ML-DSA-44 zone finishes inside one conventional datagram, so a signed zone's reliability now rests on how each network path handles oversize DNS responses.
- decision Operators who dual-sign have to decide how a resolver's algorithm capability gets signalled, because the same fallback that keeps old resolvers answering is the path an attacker would aim at.
- exposure The migration has to reach the root for the exercise to pay off, and that is where Cloudflare argues a single recovered signing key would let an attacker forge a validation path to every zone beneath it.
- precedent Cloudflare's TLS run sets the expectation that the failures found here will be in middleboxes and stacks nobody suspected, which is the argument for turning validation on years before the threat is real.
Divide the signature by the buffer and the problem is a ratio of about 1.96 [1]. One ML-DSA-44 RRSIG needs nearly two full datagrams under the 1,232-byte convention [5], before the response carries a question section, an answer RRset, or its own OPT record. Against the more generous 1,400-byte maximum recommended by RFC 9715 [6], the signature is still 1,020 bytes over [2]. The original 512-byte UDP ceiling [16] holds about a fifth of one [4].
The transition is worse than the steady state. Cloudflare says zones will need to keep publishing conventional signatures for older resolvers for years [7]. Since an ECDSA P-256 RRSIG is 64 bytes [4], an RRset signed with both algorithms carries 2,484 bytes of signature when those RRSIGs travel together [3].
For 1,232 to be the number that bites you, it has to be the number your own resolver advertises. EDNS(0) is an advertisement of the largest UDP response a resolver is willing to accept from a nameserver [15], and Cloudflare describes 1,232 as a conservative choice made by many implementations to fit inside IPv6's 1,280-byte minimum MTU rather than a protocol constant [5]. The transferable part is simpler than the constant: no ML-DSA-44 answer completes inside a conventionally sized datagram, so every validating lookup against such a zone depends on what your path does with oversize responses.
Size is only one of the two properties Cloudflare names as making the transition hard. The other is that the old algorithm cannot always be removed safely [18]. Cloudflare states the goal as carrying the larger responses reliably without letting compatibility with older resolvers weaken protection for newer ones [9], and it is testing both of those at once on 1.1.1.1: the big responses, and the prevention of fallback to conventional signatures [17]. On that framing the packet problem and the downgrade problem are the same problem seen twice. A resolver that quietly accepts the 64-byte RRSIG whenever the 2,420-byte one fails to arrive has bought itself nothing, and the thing making it fail to arrive is the buffer.
None of this is driven by cryptanalysis. Machines capable of the attack do not exist today [10], and because DNSSEC signs for authenticity rather than confidentiality there is no harvest-now-decrypt-later pressure [11]. What sets the schedule is coordination across authoritative servers, registries, registrars and validating resolvers [12], ending at the root, where Cloudflare's case is that one quantum-recovered signing key would forge a validation path to every zone beneath it [13]. Its own two dates leave roughly a year of slack [5]: full post-quantum security planned for 2029 [2], against the possibility of a sufficiently powerful quantum computer in 2030 [14].
What to watch
- Whether Cloudflare publishes measurements of how often ML-DSA-44 answers fail to arrive over UDP, and what the retry costs in latency.
- Whether root and TLD operators signal any timeline for ML-DSA-44 in the root zone, since Cloudflare's case for urgency rests on the root key.
- Whether resolver and nameserver implementations raise their default EDNS(0) advertisements above 1,232 bytes or hold the line and push these answers elsewhere.