Falcon DNSSEC：省下 11 字节，报文仍过不了门

摘要

特温特大学与 SIDN Labs 用真实的 .nl 查询重放测试 Falcon-512。压缩签名的中位数为 655 字节，固定填充格式为 666 字节；省下的 11 字节，几乎没有改变完整 DNSSEC 应答能否越过研究所用的报文门槛。
不存在的域名需要多份已签名的 NSEC3 证明。研究中这类应答全部超过 1,232 和 1,500 字节。单张签名的瘦身成绩，代替不了整张报文的体检。

给大箱子剪掉一角

行李超重，柜台有人提出妙计：从箱角剪掉 11 克。剪刀确实很锋利，可箱里还塞着三套西装和一台打印机。DNSSEC 的后量子签名争论也有这种滑稽之处。签名短一点当然好；网络传送的却是整份应答，附着的证明一多，漂亮的省字节成绩单就只能贴在超重箱上。

特温特大学和 SIDN Labs 的 2025 年论文给 Falcon-512 的两种签名格式做了一次实际负载测试。压缩格式长度可变，填充格式固定为 666 字节。在他们重新签名的 .nl 测试区域里，压缩签名的中位数为 655 字节。若只展示这一行，压缩方案赢了 11 字节。研究者随后问了更难回答的问题：一整份 DNSSEC 应答究竟有没有因此跨过 1,232 或 1,500 字节的界线？

实验材料来自 2025 年 4 月 3 日的 .nl 区域文件和当天到达权威服务器的查询。研究者清掉原有 DNSSEC 数据，分别用两种 Falcon-512 格式签署测试区域，再把记录下来的查询送往两个 NSD 实例。最终比较的同类应答中，NOERROR 有 59,312,128 份，NXDOMAIN 有 113,348,878 份。查询源自实际运行流量；Falcon 应答来自实验重放。这个设计足以检验报文尺寸，却不是 .nl 已在生产环境启用 Falcon 的证据。

在 NOERROR 组，多数应答无论采用哪种格式，原本就低于两道尺寸门槛。另有一部分应答偏大，原因之一是未签名的子域名缺少 DS 记录，需要额外的已签名 NSEC3 证明。压缩签名让报文略薄，却没让足够多的应答从门外挪进门内。决定尺寸的往往是“要带几份证明”，而不是“每份证明能否再削去一点边角”。

不存在域名的 NXDOMAIN 组更不给宣传材料留面子。纳入研究的应答全部越过两道门槛。带两份已签名 NSEC3 记录的应答为 2,269 至 2,420 字节；带三份的则为 3,075 至 3,767 字节。签名越多，压缩节省的总字节数确实会增加。可一份三千多字节的应答，不会因为每张签名少了十来个字节就突然挤进 1,232 字节的门。边界没有动，传输安排也就没有得到论文所期待的改变。

“压缩”本身还有一个小插曲。研究者在测试区域的 9,912,711 个签名中发现一个 667 字节的未填充签名，比固定的 666 字节还大一字节。填充格式会在超出固定长度时重新生成签名。这个例子极少见，谈不上推翻压缩格式；它提醒实现者，可变长度意味着要处理分布及尾部，而不能把中位数当成每次必达的承诺。

论文因此倾向于考虑固定填充格式：在这次测试中看不到有意义的报文门槛收益，而固定长度便于预估和实现。作者研究的是报文尺寸，并未把 CPU、内存、硬件、签名和验证成本算成一份总账。标准也还没由这篇论文决定。它已经把一个常见推销话术拆开了：单个部件更小，不等于整条交付路径变通畅。

NIST 在 2026 年 10 月 27 日更新的项目页面仍将基于 Falcon 的 FIPS 206 列为开发中。ICANN 的 Paul Hoffman 提交的一份个人 IETF 草案列出 DNSSEC 选型还要面对的项目：记录大小、部署速度、CPU、协议改动、硬件安全模块、密码分析和专利许可。它没有正式的 IETF 标准地位，清单却很有价值：别把一个最容易做成图表的数字，包装成全部的决策依据。

RIPE 93 日程安排 Ginevra Fabrizio 于 10 月 29 日介绍这项研究。今天是 10 月 28 日，会议发言尚未发生；可供核对的是已经发表的论文。届时真正值得追问的，不是压缩签名能否继续瘦几字节，而是完整应答分布、不同查询类别、TCP 回退频率以及实现成本。把整只箱子放上秤，胜过在剪下的纸角上印一张金牌。