摘要

  • GSS-TSIG 通过 TKEY 协商 GSS 安全上下文，再以 TSIG 保护 DNS 消息；它认证消息，却不授予区域修改权。
  • 完整审计必须分别证明认证主体、本地规则、获准动作、主服务器写入、传播范围与最终查询结果。

先审视一句常见结论：“签名是对的。”这句话可以准确描述一次验证，但无法独立回答其他问题。签名所对应的主体是谁？该主体是否有权修改这个所有者名称和记录类型？服务器是否执行并保存了操作？权威副本是否同步？绕过缓存后的查询又看到了什么？

RFC 3645 把流程分成两阶段。第一阶段，客户端与服务器把不透明的 GSS-API 令牌装入 TKEY 记录，分别调用 GSS_Init_sec_context 与 GSS_Accept_sec_context，让上下文从未初始化进入协商，再进入已建立状态。第二阶段，双方通过 GSS_GetMIC 和 GSS_VerifyMIC 产生与验证消息签名，签名随 TSIG 记录进入 DNS 报文。纯文本规范 明说：本文范围是认证机制，不讨论或提出授权机制。

这句话划定了责任边界。认证说明哪一个主体和上下文保护了请求；授权说明该主体能否执行这一个动作；协议接受说明服务器如何回应；状态变更说明区域数据是否真的改变；传播与观察则说明其他节点和读者后来看到什么。把五项事实压成一个“成功”字段，等于主动删除事故调查所需的因果链。

协议的组合方式也要求逐层留证。RFC 2743 定义 GSS-API 抽象；RFC 2930 让 TKEY 承载密钥建立令牌；RFC 2845 给出早期 TSIG 事务认证框架，后来由 RFC 8945 更新并取代；RFC 4121 规定 Kerberos v5 的 GSS 机制。每层都解决一个问题，没有哪层替区域管理员决定权限。

安全上下文也不是永久通行证。RFC 3645 要求针对客户端与服务器关系维护独立上下文；上下文具有有限寿命，协商可能需要多次令牌往返，规范中的循环最多尝试十次。客户端必须验证最后的签名响应，才把状态推进到“已建立”。验证失败意味着消息不应被视为真实；上下文过期意味着应重新建立，而不是默默继承旧权限。

互操作配置同样需要精确表述。RFC 3645 建议以 SPNEGO 协商底层机制，并要求相关实现支持 Kerberos v5，以确保规定范围内的互操作；同时允许支持其他机制。协议安全性取决于底层 GSS 机制。因此，日志只写 gss-tsig 远远不够，还应保存协商机制、目标名称、凭据来源、密钥名称、上下文寿命、重放与顺序状态、对端及验证结果。

权限判断见于另一份规范。RFC 3007 规定，安全动态更新的策略由区域管理员配置，由服务器执行；判断依据包括已认证主体与希望执行的动作，没有明确授权时默认不得修改。RFC 2136 定义动态更新的前置条件和操作。由此可见，认证主体只是授权引擎的输入，不是授权结果本身。

读到的 DNS 数据也不能倒推出完整写入历史。RFC 4033 说明 DNSSEC 为 DNS 数据提供来源认证与完整性保护。DNSSEC 验证成功可以支持“这份响应来自受信任的签名链”，却不会自动重建当初哪位管理员的更新请求获得授权。反过来，一次经过认证的更新请求也不保证数据已经传播到目标观察点。

登记表只能证明共同命名。IANA 的 TSIG 算法名称登记表 收录 gss-tsig；DNS 参数登记表 与 RFC 6895 协调相关数值。登记并不证明某个实时上下文存在、某个主体被许可或某次变更已经发生。

原始规范的范围可通过 RFC Editor 信息页、Datatracker 条目、文档历史与勘误检索交叉核对。这些来源可约束本文事实，但不能支持对当前部署率、具体产品行为或现实事故的臆测。

Lu Heng 关于现实层次、最小共同规范和运行代码优先的论述，为这套证据链提供了制度解释。GSS、TKEY、TSIG 与登记名称形成共同技术底座；具体权限仍由本地规则决定；真实服务器与后续查询决定目标状态是否存在。公共协调层有价值，但不应冒充所有后续事实的权威。