Summary

  • A University of Twente and SIDN Labs experiment found an 11-byte median saving from compressed Falcon-512 signatures over fixed padded signatures. Replaying a day of .nl queries showed almost no practical gain at the DNS message-size thresholds that matter.
  • The big replies were big because they carried multiple signed proofs, especially for names that do not exist. A standards choice sold on the size of one signature would miss the shape of the answer.

Eleven bytes meet a 3,000-byte answer

Imagine the standards meeting as an airline check-in desk. One suitcase is 11 grams lighter. Behind it stands a passenger carrying three wardrobes. The agent has a scale, a rulebook and a queue. The lighter suitcase gets a congratulatory sticker; the passenger still cannot board.

That is roughly the argument in a 2025 study by researchers at the University of Twente and SIDN Labs. The researchers tested two formats of Falcon-512 signatures for DNSSEC: compressed, whose length varies, and padded, whose length is fixed. In their signed .nl test zone, the compressed signatures had a median size of 655 bytes. The padded version was 666 bytes. Eleven bytes looks like a tidy saving on a slide. Then the researchers sent real query patterns through the signed test zone and measured complete DNS responses.

The .nl data came from 3 April 2025. The team removed the existing DNSSEC material from that day's zone file, signed two laboratory versions with Falcon-512, hosted them in separate NSD instances and replayed a day of recorded queries. The experiment covered 59,312,128 responses that remained NOERROR and 113,348,878 that remained NXDOMAIN across collection and replay. These are test answers driven by real traffic, not evidence that .nl put Falcon into its live signing chain. That distinction matters because the result is strong evidence about this packet-size question, while deployment would be a different undertaking.

For the matched NOERROR replies, most already fitted the study's 1,232- and 1,500-byte thresholds under either format. A smaller, significant tail did not. Those larger answers could carry an additional signed NSEC3 record proving the absence of a DS record for an unsigned child. Shaving roughly 11 bytes from one signature did little to change which side of the gate a complete answer landed on. The response structure, including the number of signed records, wrote the bill.

The non-existent-name answers were blunter. In the studied NXDOMAIN set, every matched response exceeded both thresholds. Some contained two signed NSEC3 records and measured 2,269 to 2,420 bytes. Others contained three and measured 3,075 to 3,767 bytes. The extra signatures made the compression difference more visible in absolute bytes, yet none of those answers squeezed under the thresholds. This is the kind of result that makes a benchmark slide look lonely at the standards meeting.

There is even a small joke buried in the word “compressed.” The researchers found one unpadded signature of 667 bytes among 9,912,711 signatures in the test zone, larger than the fixed 666-byte padded signature. The padded signer would retry generation until a signature fit its fixed size. A rare outlier is hardly a general indictment of compression. It does show why a variable-size format asks implementers to deal with a distribution, not a single number printed on the box.

The paper's conclusion is pointed: given no meaningful packet-threshold benefit in this replay, fixed padded signatures may be preferable for predictable implementation and fewer opportunities for error. That is a research recommendation, not a DNSSEC standards decision. The researchers measured message size; they did not present a complete bill for CPU, memory, signing operations, validator behaviour, hardware support or every other zone. The result nevertheless changes the first question a standards editor should ask. “How small is the signature?” is an ingredient. “How many complete answers cross a transport boundary?” is the meal.

The public standards record is still open. NIST's post-quantum project page, updated on 27 October 2026, says Falcon was selected for standardization and FIPS 206 remains in development. An October individual Internet-Draft by ICANN's Paul Hoffman lays out the DNSSEC selection table: record size, deployment speed, CPU, protocol changes, hardware security modules, cryptanalysis and patent licensing. The draft has no formal IETF standards standing. It is useful precisely because it puts the packet problem beside the other costs instead of promoting one attractive column into the whole decision.

The RIPE 93 programme schedules Ginevra Fabrizio to present this work on 29 October. On 28 October, the talk is still ahead and the published paper is the evidence. There is no need to invent a conference verdict. The paper already gives operators a better cross-examination for any future format proposal: show the zone, the query mix, the complete answer distribution and the fallback behaviour. Bring the suitcase and the wardrobes to the same scale.

The packet is the electorate

The institutional temptation is familiar. A committee can choose a property that is easy to state, compare and vote on. Median signature size is one. A DNS response, unfortunately, does not arrive as a median. It arrives with a name of some length, a record type, a delegation state and sometimes multiple proofs that a name or DS record is absent. The paper notes that name-length variation in its data is of a similar order to the unpadded signature-size variation. A neat eleven-byte headline competes with the ordinary mess of DNS names before the packet even reaches the transport layer.

Running-code primacy is often invoked as a badge of technical authenticity. Here it is a much less glamorous demand: make a proposal pass through observed query patterns and count the full answers. A standard that optimizes a component while leaving the delivery failure unchanged is an elegant filing system for disappointment. The decision should attach its promised benefit to an operational threshold, and the people who sign zones and run validators should be able to reproduce the claim.