引言

根据 APNIC Blog 近期讨论，后量子密码学签名在 DNSSEC 中的引入，可能会显著扩大 DNSSEC 响应报文的体积。这一变化将促使许多原本通过 UDP 传输的 DNS 查询，不得不转向 TCP 协议。文章提出了运维层面的核心问题：解析器应当主动限制不必要的 DNSSEC 数据，还是顺应趋势接受 TCP 使用的普遍化？

DNSSEC 与传输协议的背景

当前互联网中，DNS 查询主要借助 UDP 协议承载，因其无连接特性带来较低的延迟与开销。当响应数据超出传统 UDP 报文可容纳的范围时，解析器与权威服务器会通过 TCP 进行重试或传输。DNSSEC 通过添加数字签名保障数据完整性，本身已增加了响应大小。

后量子签名带来的尺寸挑战

原文指出，后量子签名方案存在使 DNSSEC 响应“戏剧性增大”的潜在风险。尽管未提及具体算法细节，但可以理解，后量子密码学为保护量子计算攻击，其签名与密钥结构往往更为庞大。一旦该类签名部署于 DNSSEC，单条响应可能轻易突破 UDP 舒适区，导致大量查询回退至 TCP。

运维视角的两难抉择

面对这一趋势，网络工程师与 resolver 运维人员需权衡两种策略：

策略一：限制非必要的 DNSSEC 数据

  • 通过修剪冗余记录、优化区文件签名方式，尽量保持响应精简。
  • 挑战在于可能需修改标准合规实践，且过度裁剪或影响验证链条完整。

策略二：接纳 TCP 成为主要传输

  • 无需改动 DNSSEC 数据生成逻辑，任由解析器建立 TCP 连接。
  • 代价是 TCP 三次握手与拥塞控制引入额外延迟，并对解析器并发处理提出更高要求。

对读者的意义与技术解读

对于运维、SRE 与网络安全从业者，该议题具有现实预警价值。首先，应提前评估自有解析器与防火墙对 TCP 长连接的支持容量，避免迁移期性能瓶颈。其次，在监控体系中加入 DNS 响应大小的度量，识别异常膨胀。再次，关注 EDNS0 缓冲区大小协商机制，确保路径 MTU 发现正常。

在实际工作中，工程师可借助 dig 或在线 DNS 查询工具获取响应报文长度，利用 Tcping 测量 TCP 53 端口的建连延迟，从而建立基线。当后量子签名逐步试点时，对比 UDP 与 TCP 查询耗时差异，能为容量规划提供依据。此外，路由追踪可观察中间网络设备对大包的处理策略。

最后，在规划 DNS 基础设施时，将后量子准备纳入路线图，但避免过早盲目限制 DNSSEC 字段而牺牲安全。标准组织与厂商的后续指引值得持续跟踪。

“后量子签名可能大幅增大 DNSSEC 响应，使许多查询从 UDP 转向 TCP。” —— 原文核心判断

参考原文：The DOs and don’ts of post-quantum DNSSEC