摘要

  • RFC 9103 解决的是一个具体风险：攻击者通过被动监听明文区域传输，一次取得大量区域内容。它不隐藏名称服务器关系、传输时序或大小，也不阻断普通查询与 DNSSEC 枚举。
  • 可信的 XoT 结论需要一串独立收据：主服务器身份、针对该区域的客户端授权、全程 TLS、接收成功、整个 transfer group 无明文弱边，以及副本到达后的保管规则。

最容易被忽略的参与者不在访问控制表里

主服务器可以只允许指定地址发起 AXFR，也可以要求 TSIG。未获授权的客户端会被拒绝，看起来区域传输已经受到保护。然而，若获准传输仍沿普通 TCP 发送，路径上的被动监听者根本不必伪造源地址，也不必取得 TSIG 密钥。它只需阅读经过的字节。

RFC 9103 把这个第三方从路径上移走。该文件于 2021 年 8 月作为 IETF Standards Track 发布，规定 AXFR over TLS 与 IXFR over TLS，合称 XFR over TLS（XoT）。完整区域复制和增量区域复制都可以进入 TLS 信道，不再把资源记录作为明文暴露给链路观察者。

这不是一句笼统的“DNS 已安全”。它只证明一项重要能力：在被检查的传输边上，载荷对被动监听保密。真正严谨的运营结论还要回答：secondary 是否认出了正确的 primary；primary 是否授权了这一个客户端复制这一个区域；所有请求和响应是否都被 TLS 包住；收到副本的人如何存放和再分发；同一批名称是否仍可从其他 DNS 接口获得。

TSIG 与 TLS 不能相互代写收据

TSIG 的用途是 DNS 消息认证和完整性。RFC 8945 让共享密钥的参与者验证消息来源与内容未被篡改，RFC 5936 也把它用于区域传输客户端的授权。但消息认证码不加密消息。带有完全有效 TSIG 的明文 AXFR，仍可能被旁路读取。

TLS 处理的是另一层。RFC 9103 要求 secondary 按 Strict Privacy profile 认证 primary；primary 则用 mutual TLS，或 IP ACL 加有效 TSIG/SIG(0)，判断客户端是否有权请求或代理区域传输。严格 TLS 能提供服务端身份和信道机密性，mutual TLS 再提供客户端身份。它们与 TSIG 的 data-origin authentication 是互补属性，而不是可以互换的标签。

这也解释了为什么成功建立 TLS 连接还不等于获得区域。一个服务器可以在一条连接上处理多个区域和多个请求。RFC 9103 指出，常见实现会在收到具体 XFR 请求后逐次应用 ACL。接入端口、完成握手和获准复制某个区域，是三项不同事实。

一次成功不能代表整个 transfer group

区域复制通常不是简单的一对一关系。RFC 9103 把参与某组区域 XFR 的全部 primaries 和 secondaries 称为 transfer group。若某一条边仍允许明文，监听者便可以绕开其余边的 TLS。若 IXFR 使用 XoT 而 fallback AXFR 回到普通 TCP，机密性声明也会在异常路径上失效。

因此，XoT 的证明单位不是一张握手截图。策略必须覆盖 transfer group 的成员、每一条 AXFR/IXFR 边、可接受的认证组合、TLS 终止位置和禁止的 fallback。TLS proxy 也要进入图中：从 secondary 到 proxy 加密，并不能自动证明 proxy 到 primary 的后半段同样加密。

RFC 9103 对审计难度很诚实。运营者可以尝试不带 TSIG、来自未授权地址或使用明文的区域传输，观察服务器是否拒绝。更难证明的是每个 secondary 是否拒绝无签名数据、是否采用 Strict 而不是 Opportunistic TLS，以及第三方 secondary 是否把同一规则延伸到下游。跨运营者协调和强制机制不在该 RFC 的范围内。

Opportunistic TLS 也不能代替这种承诺。它可能在认证资料缺失或认证失败时继续，甚至在 TLS 不可用时回退明文。对某些通信而言，这比始终明文更好；对“本区域传输不允许出现明文弱边”这一结论而言，它没有提供所需的确定性。

TLS 终止之处，副本保管问题才开始

设想所有传输控制都正确工作。secondary 认证 primary；primary 认可 secondary；TLS 1.3 保护 IXFR；新 serial 被接收。链路监听者确实失去了区域内容。

此刻，完整或增量形成的区域副本已经进入另一个管理域。它可能出现在 journal、区域文件、数据库快照、备份、调试日志或支持工具中。接收方还可能向其他 secondary 继续复制，并通过权威 DNS 有意公开应答。这些不是 TLS 的失败，而是复制成功后的保管与发布事实。

所以，证书身份不能成为审计的最后一格。收据必须继续记录：副本存放在哪里，谁能访问，备份与日志保留多久，会转发给哪些节点，新增下游需要谁批准，密钥或合作关系结束后如何停止后续传输。已经交付的副本无法靠撤销证书收回，这正是事前最小授权比事后轮换更重要的原因。

ZONEMD 提供了另一项容易混淆的能力。RFC 8976 的区域摘要可用于独立于传输信道的完整区域对象验证；RFC 9103 明确称其与 XoT 互补且正交。摘要不提供传输机密性，而 TLS 也不证明区域内容真实、及时、合理或获得正确人员批准。

加密复制不会取消 DNS 的公开应答

RFC 9103 把传输监听与区域枚举视为两条正交路径。使用 NSEC 的 DNSSEC 区域可能被逐步遍历；NSEC3 通过散列名称提高枚举成本，却不等于 XoT 已经隐藏每个名称。普通权威查询又是第三条路径：服务本来就应公开回答的记录仍会被回答。

这要求运营者避免两种夸大。其一，不要把“传输不再明文”写成“整个区域不可被发现”。其二，不要因为区域本来服务于公开 DNS，就否认批量复制流存在额外暴露价值。准确的结论应同时保留两面：XoT 关闭了高密度明文收集入口，但普通查询、否定证明、流量模式和获准接收者仍然各有自己的风险面。

八格传输机密性收据

可审计记录至少需要八格。第一格是范围：区域、策略版本、transfer group 和责任运营者。第二格是primary 身份：认证域名或 SPKI pin、证书结果、TLS 版本和实际端点。第三格是secondary 准入：mTLS 身份，或 IP ACL 与 TSIG/SIG(0) 的组合，以及针对本区域的授权结果。

第四格是传输：AXoT 或 IXoT、明文禁令、fallback 规则和 proxy 边界。第五格是完成状态：请求 serial、IXFR 是否转为 AXFR、最终接收 serial 与错误。第六格是副本保管：存储、访问、备份、日志与下游复制。

第七格是残余暴露：普通查询、NSEC/NSEC3、端点关系以及时序和大小信号。第八格是重新验证触发器：证书、TSIG 密钥、ACL、proxy、secondary、拓扑、签名策略或运营者变化。

每一格只能证明自己的属性。TLS 握手不是区域授权；TSIG 不是加密；完成传输不是内容正确；接收 serial 不是下游保密。只有让这些收据保持分离，XoT 的真正价值才不会被一句过度承诺掩盖。

来源