摘要

  • Ray Bellis 独立署名的 RFC 5625 把“代理不可能理解现在与未来全部 DNS 功能”作为设计前提：格式正确但含义未知的数据应继续通过，完整响应、EDNS、TC 与 TCP 不应被代理悄悄改写；真正畸形的报文和主动策略则应以可归因、可观察的方式失败。
  • 该文档于 2009 年成为 BCP 152，但它不能证明今天的设备普遍合规。透明转发也不等于 DNSSEC 验证、TSIG 认证或完整安全策略。它真正解决的是权力分配：协议和端点定义语义，薄代理只保管路径上自己无权重释的信息。

一次没有错误码的升级失败

某个 DNS 新功能只占用报文头里的一个标志位。客户端已经支持，上游递归解析器也已经支持。查询从家中电脑发出，却永远等不到响应。抓包后来显示，丢包者是夹在中间的路由器：它出厂时那个位置仍被要求为零，于是固件把后来合法分配的值当作错误，直接丢弃。

这不是端点协商失败，也不是新标准本身无法部署。旧代理把自身知识的截止日期，变成了整个网络采用新语义的截止日期。

2009 年 8 月发布的 RFC 5625 就从这种错位出发。文档名为 DNS Proxy Implementation Guidelines，由当时供职于 Nominet UK 的 Ray Bellis 独立署名，状态为 Best Current Practice 152。它没有要求资源有限的网关成为全功能递归解析器，而是承认一个更现实的事实：硬件容量有限，固件升级周期漫长，未来 DNS 扩展无法预先穷举。

因此，简单代理最稳妥的角色不是“尽量多懂一点”，而是受限保管。它接收局域网查询，原样转给已知的上游递归解析器，再把完整响应原样交还发起查询的终端。代理仍然要匹配客户端、保存临时状态、选择上游和约束接口；但站在路径上，并不会自动获得解释所有 DNS 比特的权力。

24 台设备说明了什么，又没有说明什么

RFC 形成前，ICANN SSAC 对 24 台住宅路由器或小型办公室防火墙做过控制测试。SAC035 执行摘要 与完整报告记载，测试发生在 2008 年 7 月和 8 月。

24 台设备都能把 DNSSEC 查询直接路由到上游。22 台提供 DNS 代理模式，其中 6 台在 DNSSEC 相关标志或经过验证的响应上出现问题。18 台把 UDP 响应限制在 512 字节或与 MTU 有关的大小；只有 4 台能返回最大 4096 字节的代理响应，只有 1 台代理 DNS over TCP。默认配置下完全兼容的有 6 台，另有 9 台可通过重新配置绕开代理的不兼容。

这些数字是当时问题存在的实证，不是 2026 年市场统计。样本只有 24 台，测试环境和产品均属于 2008 年；不能据此推断今天某个厂商、某类网关或整个装机量的行为。真正跨越时间的，是一个代理总会面对比自己固件更新的协议语义。

IETF 的批准说明记录了 DNS Extensions 工作组的强共识，以及厂商和采购方对指导文件的兴趣。这可以说明标准化过程与问题的重要性，不能替代部署数据，也不能证明采购合同最终落实了要求。

不认识，不等于不合法

RFC 5625 最关键的判断，是把“未知”与“畸形”分开。

代理若遇到自己不认识的 DNS 头部标志，应忽略未知含义并继续转发，而不是沿用旧时代“保留位必须为零”的规则。QTYPE、QCLASS、资源记录 TYPE 与 CLASS 也一样；不同的标签压缩形式不应成为拒绝理由。旧解析器不能凭自己维护的代码表，决定新分配值是否有资格通过。

RFC 3597提供了更一般的扩展原则。服务器或解析器遇到未知资源记录类型时，应把 RDATA 当作无结构二进制数据保存和传输，不必假装理解，也不能擅自丢弃。保全字节，是为了让真正知道语义的端点仍能工作。

报文本身不可能成立，则是另一件事。无效压缩指针、与实际内容不可能一致的区段计数，并不会因为旧软件无法解析，就自动成为“未来扩展”。RFC 5625 允许代理拒绝这类输入。不过它倾向于在安全可行时返回 SERVFAIL，而不是无声丢包。客户端可以及时停止重试，运维者也能得到“哪一层拒绝了请求”的证据。

主动安全或网络策略同样是明确例外。运营者可以有意阻断或修改某些流量，但这种干预应能够被识别为策略。若行为只是解析器没写全造成的偶然结果，再把它包装为合规，就把实现缺陷伪装成了协议边界。

完整性也藏在包长与传输里

DNS 的含义不仅在记录内容，还在响应是否声明“我已经完整”。代理若把大于 512 字节的 UDP 响应截短，却不设置 TC，客户端会收到一个外观正常、实则缺失数据的答案。代理若删掉上游已经设置的 TC，则抹去了“请改用 TCP 重试”的指令。

RFC 5625 因而要求，代理不应只因为 UDP 响应超过 512 字节就截断。如果本地限制迫使它截断，必须设置 TC；上游带来的 TC 绝不能被移除。公开的截断可以触发恢复，伪装成成功的截断只会制造错误确信。

TCP 也必须连续。代理要能接收并转发 DNS over TCP；客户端已经用 TCP 发来查询时，上游也应继续用 TCP，而不是先降回本来就很可能截断的 UDP。Bellis 后来与四位作者共同署名的 RFC 7766，进一步把 TCP 支持设为 DNS 实现要求。那份 Standards Track 文档加强了传输边界，却仍不能证明每台现网设备都照做。

EDNS 把未知扩展问题具体化。RFC 5625 说，出现 OPT 记录不应导致代理拒绝查询。后来的 RFC 6891又明确指出，合规中间盒不得强加旧的 512 字节 UDP 上限，简单转发器也不得在任一方向修改或删除 OPT 内容。RFC 5625 当年提出支持 4096 字节，是 2009 年的工程能力建议，不是永恒上限。

薄代理仍然拥有一块控制面

“透明”不等于代理什么都不做。它要确定上游递归解析器，把返回报文映射回正确的局域网客户端，决定状态保存时间，也可能改写出站 Query ID 以完成关联。它还决定从哪些接口接收请求，以及 DHCP 向终端通告哪个解析地址。

这些权力需要单独约束。RFC 5625 引用 RFC 5452 的抗伪造措施，包括随机查询标识符与源端口。随机化能降低特定伪造风险，却不提供真实性保证，也不替代 DNSSEC。

认证内容进一步压缩了“善意改写”的空间。TSIG 签名覆盖 DNS 报文内容；除文档说明的 Query ID 处理外，代理若修改受保护部分，验证就会失败。要么原样保全，要么完整实现认证行为。只理解一半的改写，不是优化，而是可观察的破坏。

接口暴露也属于代理自己的责任。只为 LAN 客户端服务的网关代理，默认不应从 WAN 侧开放，否则可能成为反射放大路径。RFC 5358给出了开放递归服务参与反射攻击的风险背景。对合法内网客户端透明，不要求对全互联网无差别可达。

最后还要保留退出。除非有明确策略要求，用户应能指定上游解析器，绕开本地代理。便利服务若劫持所有替代路径，同时又不能证明自己保全未知功能，就从默认值变成了强制语义关口。

Ray Bellis 留下的是一条“无知测试”

IETF Datatracker列出 Ray Bellis 的 10 份 RFC，其中包括 RFC 5625。ISC 团队页面在研究日把他列为 DNS Operations Director。这样的工作背景帮助解释文档为什么不像功能清单，而更像一份运行责任分配表。

它衡量代理的方式，不是看“支持多少已知功能”，而是看“遇到不知道的东西会怎样”。未知标志能否穿过？未知资源记录能否保持原样？TC、TCP 和 OPT 是否仍把完整性与扩展信息交给客户端？策略阻断与固件无知能否被区分？

Mark Andrews 与 Ray Bellis 后来共同署名的 RFC 8906，把意外字段、类型、EDNS 版本、选项、标志、截断和 TCP 等情况变成显式测试项。后来的文档没有创造新问题，而是让旧问题更容易被测量，也让“什么都没回来”不再是唯一症状。

透明转发不会自动带来 DNSSEC 验证、TSIG 认证、隐私或可用性。RFC 5625 也没有取消运营者选择上游、收紧接口或执行明确策略的权利。它做的是一件更窄的事：不让路径中的中间者把“我不理解”偷偷升级为“协议不允许”。

代理可以拥有转发状态和本地控制；未来每一个比特的意义，不归它所有。

来源