Ginevra Fabrizio：Falcon 少 11 字节，NXDOMAIN 仍然超长

摘要

在一天的 .nl 查询重放中，未填充 Falcon-512 签名的中位数为 655 字节，较固定长度的填充签名少 11 字节。这个差距没有明显增加落在 1,232 字节和 1,500 字节限值以内的 NOERROR 响应。
所有受测 NXDOMAIN 响应都超过这两个阈值。让否定回答变大的，是多条带签名的 NSEC3 证明，而不是单条签名上的填充。

签名压缩省下了 11 字节，NXDOMAIN 还是塞不进一个包。这是 Ginevra Fabrizio 在 RIPE 93 报告里最扎眼的落差：单条签名的尺寸曲线变漂亮了，完整 DNS 响应几乎没变轻。

Fabrizio 是特温特大学研究者，与 SIDN 同事共同完成这项工作。论文发表于 2025 年 Applied Networking Research Workshop；2026 年 10 月 29 日，她在 RIPE 93 的 DNS 会议上重新讲解了两种格式的比较。问题很实际：DNSSEC 签名略短以后，真实查询里有多少响应能装进一个包？

DNSSEC 为 DNS 数据添加签名，让解析器验证响应的来源与完整性。否定回答需要证明名字不存在，一份证明可能带上多条 NSEC3 记录和对应签名。

团队取用 2025 年 4 月 3 日 .nl 权威服务器连续 24 小时收到的查询记录。他们先移除区域文件中原有的 DNSSEC 数据，再用 Falcon-512 分别签出填充和未填充的测试区域，最后把记录下来的查询重放到 NSD 服务器。测试比较 NOERROR 和 NXDOMAIN 两类常见响应的大小。.nl 生产区域当时没有运行 Falcon。

看单条签名，压缩格式占了上风。填充版 Falcon-512 固定为 666 字节；测试区域里的未填充签名中位数是 655 字节。11 字节确实省下来了，但一个 DNS 包还要容纳查询名、DNS 记录、DNSSEC 证明及其签名。

多数 NOERROR 响应留在 1,232 字节的 DNS 报文预算和研究采用的 1,500 字节以太网 MTU 以内。仍有一小部分、且数量不可忽略的响应超过阈值。填充与未填充两条分布曲线靠得很近；更换格式没有让更多响应明显落回单包范围。大多数普通回答本来就装得下，11 字节很少改变它落在线的哪一侧。

NXDOMAIN 才把难题摊开。签名的否定回答需要证明某个名字不存在。在这个区域里，一份证明可能包含两条或三条 NSEC3 记录，每条都带有自己的签名。查询重放产生了 113,348,878 条 NXDOMAIN 响应，每一条都超过两个尺寸阈值。两条已签名 NSEC3 记录对应的响应为 2,269 至 2,420 字节；三条则达到 3,075 至 3,767 字节。签名只是搭上了一辆已经装满证明的车。

NOERROR 查询组在重放后有 59,312,128 条 NOERROR 响应。超过阈值的那部分值得关注，但不能和 NXDOMAIN 的结果混为一谈：前者有过线和不过线两类，后者在这次测试中每条都超过两个限值。论文的尺寸表把原因说得很清楚：再加一条签名证明，响应会多出数百字节；只更改一条签名的格式，变化远小得多。

Fabrizio 的论文还比较了查询域名长度的变化和未填充 Falcon-512 签名尺寸的变化，两者处在相近量级。这个比较让压缩带来的收益回到 DNS 的实际算术里：域名有长有短，证明数量也会变，单条签名的格式决定不了整份回答的体积。

作者认为，固定长度的填充格式可能更值得采用，因为它可预测，也较不容易引入实现错误。在 RIPE 93 的问答环节，Fabrizio 把浮点运算称作实现难点，并将其与大量 TCP 回退放在同一张工程账单上。填充不会缩小超长回答；它能让签名长度稳定下来，让实现者衡量这份复杂度是否值得换取有限的平均节省。

她还说，她与 SIDN 正在启动测试平台，比较 Falcon 和 ML-DSA 在递归解析器与权威服务器两侧的负载。当时结果刚出炉，来不及整理成图。下一步有用的证据，是把响应尺寸分布与解析器实际发起的 TCP 重试和延迟关联起来。论文没有测量生产环境中的递归重试次数或端到端延迟；这些数据会改变 11 字节差距对应的运营成本。

目前可以确定的分界很清楚：多数受测 NOERROR 响应低于阈值，所有受测 NXDOMAIN 响应都高于阈值。今后为 DNSSEC 选择 Falcon 格式，应该按回答形态和证明数量评估，而不是只看一条签名的中位数。