摘要

  • DNS Cookie 把请求与源地址、Client Cookie 和先前服务器响应联系起来，为抵御路径外放大、伪造和缓存投毒提供有意受限的保护。
  • 有效 Server Cookie 不识别人或持久设备：多个客户端可以共享 NAT 公网地址，地址变化要求轮换 Cookie，而在途观察者能在有效期内复用其看见的值。
  • 运维回执应保留 Cookie 方法与年龄、地址上下文、anycast 验证域和重试结果；访问控制、账务归属及按人限速必须使用独立的认证主体。

监控系统把一次 DNS 请求标成“已认证”，理由是其中的 Server Cookie 验证成功。下游策略据此放宽限速，或者把查询量计入某个订户。这个推理看似顺畅：服务器生成了难以猜测的值，请求又从预期地址把它带了回来。问题在于，这个地址可能是几千名用户共用的运营商级 NAT 出口，也可能是一台代表整家机构查询的递归解析器。

Cookie 本身没有失效，是标签超出了它的合同。正确的问题更窄：这次请求是否带来证据，表明使用该 Client Cookie、处于这个源地址上下文的客户端，曾收到该服务器或其可互操作 anycast 集合的响应？这是回程路径和 DNS 事务证据，不是人的姓名、账号或权限。

有效 Server Cookie 佐证一次先前交换

RFC 9018 把 DNS Cookie 定义为轻量级 DNS 事务安全机制，为抵御路径外攻击者发起的拒绝服务放大、伪造和缓存投毒提供有限保护。“有限”不是保守修辞，而是威胁模型的一部分：目标攻击者看不见声称的客户端与 DNS 服务之间的流量，只能猜一个从未收到的值。

COOKIE 选项中的两个字段作用不同。客户端自行生成不可猜测的 Client Cookie，并且对每一个不同的服务器 IP 地址使用不同值。RFC 9018 建议提供 64 位熵。它不是服务器签发的账号凭据，而是客户端选择、服务器随后回送的事务值。按服务器地址分离，能提高另一台 DNS 服务器伪造目标服务器响应的难度。

Server Cookie 才是服务端生成的回程令牌。RFC 9018 将其描述为实质上的消息认证码，输入包括 Client Cookie、客户端 IP 地址、规范规定的版本与时间字段，以及服务器或同一 anycast 地址下服务器集合掌握的秘密。请求带回有效值时，服务器得到弱保证：处于该源地址、使用该 Client Cookie 的客户端，先前收到了包含这个值的响应。

RFC 7873 允许服务器据此认为自己曾与这个客户端上下文交互，并减少面向伪造源地址 UDP 请求的部分防护。规范并没有把 DNS 选项提升为通用身份认证协议。有效 Cookie 不证明请求属于某个账户、某台受管设备，也不授予查看受限区域、绕过策略或承担账务责任的资格。

所以运维文字也必须跟随证据。“在此时刻，对该源地址、Client Cookie 和验证集合有效的 Server Cookie”是可核对陈述；“已认证用户”则加入了协议字段并不包含的结论。

共享地址会打破“地址等于身份”

即使没有攻击者，NAT 也足以暴露这条边界。家庭网关、企业出口或运营商级 NAT 可以让许多独立终端与用户在 DNS 服务器看来共用一个公网地址。Server Cookie 完全可以正确绑定这个地址，却仍无法辨别地址后方究竟是谁发起了某项应用操作。

RFC 9018 还指出，处于 NAT 设备之后的客户端可能无法察觉其公网地址已经改变；服务器则可以观察并跟踪该 NAT 设备的公网地址，而如何防止这种跟踪不在规范范围内。于是，同一份地址证据可以在服务器网络边界上完全正确，却仍不足以做订户归因。

若以有效 Server Cookie 作为按人限速键，多个无关用户会被合并。若把它当成账务身份，就会让临时的网络属性承担长期责任。这里不是密码学出错，而是策略要求 Cookie 区分它从未承诺命名的主体。

移动性造成相反误判。为避免设备跨链路被跟踪，也为防止绕过 IPv6 隐私地址，RFC 9018 要求客户端 IP 地址变化后不得复用原有 Client Cookie 或 Server Cookie。换了 Cookie 可能仍是同一个人、同一台设备在正确执行隐私规则；Cookie 稳定也只能说明进程与地址环境稳定，不能证明人的连续性。

一个地址可以代表很多客户端，一个客户端也可以合法地使用很多地址与 Cookie。持久身份必须由能够明确表达这些变化的凭据和生命周期来承担。

BADCOOKIE 是诊断分支，不是攻击判决

Server Cookie 无效有多种符合规范的解释。RFC 7873 列出的原因包括：值已经过旧、客户端地址或 Client Cookie 改变、anycast 集群配置不一致，以及发生伪造尝试。服务器会按“没有该无效 Server Cookie”的方式继续处理。协议结果不会替运维人员挑定唯一原因。

BADCOOKIE 的作用是组织恢复。客户端使用响应中提供的新 Server Cookie 重试。如果刚收到的新值再次触发 BADCOOKIE，anycast 集合中的共享秘密或生成方法不一致就成为更具体的假设；随后按规范改用 TCP 重试，以利用 TCP 的事务属性继续处理。

真正有价值的是事件顺序：旧 Cookie 的年龄和方法、双方看见的地址、anycast 成员或验证域、新值、下一次响应，以及切换 TCP 后的结果。若仪表盘把每个 BADCOOKIE 都记成“攻击”，正常过期、网络移动、部署漂移和恶意流量之间的差别就被抹掉了。

秘密轮换尤其需要这条证据链。RFC 9018 要求 anycast 集合分阶段换密钥：所有成员先学会并验证新秘密，之后才开始用它签发，同时在过渡期继续接受旧秘密。某个成员过早或过晚切换，会使客户端随着 anycast 落点变化而交替得到有效与无效结果。把客户端判为攻击者，反而遮蔽了控制面失配。

DNS 其他防线仍然不可省略

DNS Cookie 是补充，而不是响应匹配规则的替代。RFC 5452 要求解析器在应用 DNS 信任规则之前，对响应的源/目的地址、目的端口、Query ID、查询名称、类别和类型进行匹配，并使用不可预测的源端口与 Query ID。每个属性都扩大路径外攻击者必须猜中的空间，但没有一个因此成为应用身份。

这些控制回答的是相邻而不同的问题。响应匹配判断回包是否属于尚未完成的查询；响应带回正确 Client Cookie，弱关联到客户端选择的服务器地址；请求带回有效 Server Cookie，则给服务器一条先前回送至源地址上下文的证据。它们都不识别人，也都不单独提供机密性。

RFC 6891 固定了传输边界：EDNS 是逐跳扩展，OPT 记录承载一次问答序列的控制信息，不包含 DNS 数据，也不得被缓存、转发或写入主文件。COOKIE 选项因此属于事务处理面，而不是需要长期保存的用户目录。

在途攻击边界同样明确。能看见明文 DNS 的观察者可以捕获 Server Cookie，并在其有效期内针对该客户端复用。服务端 MAC 让不知道秘密的路径外攻击者难以自行制造有效值，却不会加密传输中的 Cookie，也不会认证所有能在已观察路径上发送流量的主体。

让回执保留上下文而不是制造身份

每次 Cookie 决策都应保留服务器看见的源地址、可获得时客户端看见的地址、Client Cookie 的不可逆引用、Server Cookie 方法与年龄、验证结果、anycast 验证集合、重试序列和 TCP 回退结果。秘密本身不能进入日志，但秘密代次和各成员部署状态应独立记录，以便检查漂移。

若服务另有账户或设备认证，就用该机制自己的方法和时间戳记录主体。它与 DNS 事务的连接必须显式说明：哪一个认证会话在什么时间范围内产生了哪一次解析请求，共享解析器或 NAT 介入时存在什么不确定性。没有这条连接，就应保留“无法归属”，而不是用 Cookie 补出身份。

告警措辞也要与证据相称。“回程令牌有效”是准确描述；附带地址与时间后，“服务此前到达过这个源地址上下文”也可以成立。“已知客户”“可信设备”“获授权用户”则需要完全不同的事实。

参考资料

  1. RFC 9018 — 可互操作的 DNS Server Cookies
  2. RFC 7873 — DNS Cookies
  3. RFC 5452 — 提高 DNS 抵御伪造响应能力的措施
  4. RFC 6891 — DNS 扩展机制（EDNS(0)）