摘要

  • RFC 2845 规定，签名 DNS 响应的 MAC 要纳入触发它的请求 MAC。
  • 对多报文 DNS/TCP 交换，运行中的 MAC 会覆盖前一 MAC 和其后的报文；TSIG 位于首尾报文，并至少每百条报文设置一次检查点。
  • RFC 8945 后来要求发送方给每条响应报文附上 TSIG，同时为验证方保留有限的兼容容忍。无论新旧规则，交易认证都不等于保密、数据真实性或本地授权。

响应不是彼此无关的报文

DNS 的消息编号和响应码可以描述一次请求与应答，却不能认证对端，也不能阻止交易内容被改动。RFC 2845 于 2000 年 5 月发布，引入 TSIG：附在 DNS 报文上的元记录，由共享密钥校验。它的范围刻意限定在点对点交易。两个对端必须事先配置同一密钥；密钥如何分发不属于这份规范。

设计关键在 MAC 的输入。客户端先认证自己的请求；服务器返回签名应答时，计算会纳入请求 MAC、应答本身和应答 TSIG 的变量。验证方因此不会把响应当成脱离上下文的新对象：密码学检查一路回溯到最初请求。签名时间与容差值也被覆盖，中间节点若修改时间字段，MAC 就不再匹配。

这个绑定说明的是“这些被覆盖的字节与某个共享密钥关系相符”。密钥由双方共用，校验成功表明报文能通过本地配置密钥的验证，却不能指出究竟是哪个人或进程持有密钥。TSIG 不会加密 DNS 内容，也不决定服务器应否接受更新。RFC 2136 定义 DNS UPDATE；接收方仍须通过本地策略判断已认证的对端能否改动区域数据。

区域传送成为一段报文记录

更棘手的情况是一个响应横跨多条报文，例如通过 TCP 进行区域传送。如果每条报文各自孤立校验，验证方就看不到它们的顺序关系。RFC 2845 要求第一条和最后一条报文带 TSIG，并至少每一百条报文设置一个签名检查点。两个检查点之间，DNS 报文按顺序逐条并入下一次 MAC 计算，同时带上前一 MAC 和相关计时字段。

验证方检查的是一段有界报文流的连续性，并非每条中间报文都带有独立签名。校验失败时，规范要求关闭 TCP 连接，并把区域传送视为中断；至于具体如何重试，规范没有作出统一规定。因此，即便某个检查点有效，它证明的也只是收到的报文链某一段，不能证明服务器后来已提交哪些内容，或从服务器取得数据的次级节点后来实际提供了什么。

规则变了，边界没有

RFC 4635 在原有 HMAC-MD5 设计之外增加了 HMAC-SHA 算法标识。2020 年，RFC 8945 取代 RFC 2845 和 RFC 4635，成为 STD 93。它收紧了发送要求：符合规范的发送方应为响应中的每条报文附上 TSIG。验证方的兼容规则是另一回事：它必须允许最多 99 条中间报文没有 TSIG，但第一条和最后一条仍须签名。“最多 99 条可接受”并不意味着现代发送方可以省略签名。

RFC 8945 也明确划出证据边界：TSIG 认证的是共享密钥双方之间的传输，不是源数据的来源或正确性。它与采用另一种信任模型认证数据的 DNSSEC 不同。某些部署可用 TKEY 建立密钥，但密钥分发并非 TSIG 自带能力。这组标准描述的是边界明确的交易机制，不是一枚包办一切的信任印章。

来源：RFC 1035、RFC 2104、RFC 2845、RFC 8945、RFC 4635、RFC 2136、RFC 2930。