DNS BADCOOKIE 响应循环：Server Cookie、Anycast 密钥与 NAT 排查
DNS BADCOOKIE 响应循环：Server Cookie、Anycast 密钥与 NAT 排查
BADCOOKIE 表示什么
RFC 7873 把 DNS COOKIE 定义为 EDNS 选项码 10，把扩展 RCODE 23 定义为 BADCOOKIE。客户端先发送 8 字节 Client Cookie；知道服务器 Cookie 后，请求中会携带 Client Cookie 和 8 至 32 字节 Server Cookie。Server Cookie 通常绑定 Client Cookie、客户端 IP 和服务器秘密值，为离路径伪造、放大与缓存投毒提供轻量防护。
它不是 HTTP Cookie，也不是 DNSSEC 签名。DNS Cookie 只提供有限的弱认证，无法抵御能看到明文 DNS 流量的在路径攻击者。排障时不要把 BADCOOKIE 解释为域名权威数据错误或 DNSSEC 验证失败。
正常的第一次重试流程
客户端只有 Client Cookie、没有可用 Server Cookie 时，服务器可返回正常答案或 BADCOOKIE，并在响应的 COOKIE 选项里附上新的 Server Cookie。客户端验证响应中的 Client Cookie 与自己发送的一致后，应缓存 Server Cookie，即使响应 RCODE 非零；随后使用新 Cookie 重试原问题。
因此，单次 BADCOOKIE 后立即成功并不一定是故障。真正异常的是同一查询反复获得新 Cookie、使用后仍被拒绝，或不同节点交替接受和拒绝同一 Cookie。
先保存完整报文
抓取客户端到权威服务器或递归服务器的双向 DNS 报文，保留源/目的 IP、传输协议、查询 ID、OPT 记录、COOKIE 选项长度、Client Cookie、Server Cookie 和完整扩展 RCODE。普通日志可能只显示 SERVFAIL 或数字错误码，无法证明是 BADCOOKIE。
建立至少三次连续事务的时间线：初始请求、服务器返回的新 Cookie、携带该 Cookie 的重试。若重试被路由到不同 Anycast 节点，也要记录节点身份、机房、软件版本和响应时延。敏感报告中不要公开 Server Secret；报文 Cookie 可脱敏后保留关联关系。
Anycast 节点不一致是首要嫌疑
RFC 7873 建议同一 Anycast 服务集合共享 Server Secret，或让同一客户端在足够长时间内稳定到同一节点。否则 A 节点生成的 Cookie 到达 B 节点后无法验证，B 返回新 Cookie；下一次又回到 A 时再次失败，形成循环。
逐节点使用单播管理地址或受控路由测试，比较相同 Client Cookie 的响应。核对所有节点的 Secret 版本、加载时间、配置来源、权限和进程是否真正重载。仅确认配置管理系统下发成功不够，还要确认运行进程使用的值一致。
多厂商算法也必须一致
早期 RFC 7873 没有强制统一 Server Cookie 构造方法，因此即使多厂商 Anycast 节点共享相同秘密值，生成结果也可能互不兼容。RFC 9018 为可互操作的版本 1 Server Cookie 规定 16 字节长度，并要求使用 SipHash-2-4 作为强制默认方法。
检查每个实现是否支持 RFC 9018、协商/生成的版本和长度是否一致，旧节点是否仍使用私有算法。升级期间新旧软件混跑尤其容易暴露问题。不要用“共享同一个 Secret”作为互操作已完成的唯一证据。
NAT 与客户端地址变化
Server Cookie 的计算包含客户端 IP。解析器经双出口 NAT、运营商级 NAT、IPv4/IPv6 切换或链路负载均衡时，同一缓存 Cookie 可能从新的公网地址发出，服务器会把它判为无效。RFC 9018 也要求客户端 IP 变化后不再复用已有 Client 或 Server Cookie，以降低跨网络跟踪风险。
同时记录解析器本机源地址和服务器观察到的公网源地址。若每次重试出口不同，先固定测试路径；再检查解析器是否按本地地址、服务器地址和地址族隔离 Cookie 缓存。NAT 端口变化通常不是关键，IP 变化才会直接影响常见 Server Cookie 计算。
密钥轮换不能一步切断
服务器轮换 Secret 时，应在过渡期同时接受旧 Secret 生成的有效 Cookie，并用新 Secret 生成新 Cookie。若所有节点没有同步轮换，或进程重启后只保留新 Secret，尚持有旧 Cookie 的客户端会集中收到 BADCOOKIE。
RFC 9018 给出了分阶段更新建议，并要求等待足够的 Cookie 有效期后才移除旧 Secret。检查轮换开始、各节点加载、旧密钥停止验证和监控告警的时间。不要通过高频随机轮换掩盖攻击，因为不协调的轮换本身会制造重试风暴。
区分 FORMERR、BADCOOKIE 与超时
RFC 7873 规定有效 COOKIE 选项长度为 8 字节，或 16 至 40 字节；其他长度应触发 FORMERR。BADCOOKIE 表示 Server Cookie 缺失或无效，而不是选项编码损坏。若抓包显示响应完全没有 OPT，可能是旧服务器或中间设备不支持 EDNS，而非密钥不一致。
扩展 RCODE 依赖 EDNS OPT 记录。某些监控器只读取 DNS 头部低 4 位，会把 BADCOOKIE 错报为普通错误。应使用能解析 EDNS 扩展 RCODE 的工具，并核对原始报文字段。
为什么会最终显示 SERVFAIL
递归解析器可能在内部处理 BADCOOKIE 并自动重试，应用只看到重试预算耗尽后的 SERVFAIL 或超时。把客户端日志、递归器抓包和权威节点计数关联，检查一次用户查询实际产生了多少上游事务。
无限重试会放大流量。RFC 7873 建议，客户端使用响应中新的 Server Cookie 重试仍得到 BADCOOKIE 时，改用 TCP 再试，因为 TCP 的连接属性可让服务器按策略处理请求。实现应有明确次数和总时限，不能在 UDP 上无界循环。
TCP 成功说明什么
若 UDP 连续 BADCOOKIE，而 TCP 查询成功，说明域名数据和基本权威服务可能正常，问题集中在 Cookie 验证、UDP 防护策略或 Anycast 路径。TCP 成功不是永久修复；它只是隔离证据，也可能增加连接与资源成本。
检查服务器在仅有 Client Cookie 或无效 Server Cookie 时的策略。BIND 的相关选项可用于测试客户端是否正确处理 BADCOOKIE，并通过较小错误响应降低反射放大，但合法客户端需要用新 Cookie 再发一次。测试开关不应在未知影响下直接全网启用。
中间设备与 EDNS 处理
防火墙、DNS 代理、负载均衡器或旧型审计设备可能删除 OPT、改写长度、缓存带 Cookie 的错误响应，或让请求与响应经过不同路径。比较服务器端抓包和客户端抓包：若服务器发出的 COOKIE 在客户端消失或变化，中间链路需要单独排查。
DNS 响应缓存不应把面向一个 Client Cookie 和地址生成的 Server Cookie错误复用于其他客户端。若只有经过某一代理时复现，绕过代理做对照，并核查其 EDNS 透明转发和缓存键设计。
推荐的排查顺序
1. 用支持 EDNS 的工具确认扩展 RCODE 确实为 23。
2. 抓取连续请求，验证重试使用了上一响应返回的新 Server Cookie。
3. 记录每次请求的客户端公网 IP、地址族和命中的 Anycast 节点。
4. 按节点核对 Server Secret、算法版本、Cookie 长度与软件版本。
5. 检查 Secret 分阶段轮换和旧密钥接受窗口。
6. 固定单播节点与固定出口分别测试，分离 Anycast 和 NAT 因素。
7. 用 TCP 进行受控对照，不把它当成长期掩盖措施。
8. 比较链路两端报文，确认代理没有删除或改写 OPT。
修复与验收
Anycast 集群应统一 RFC 9018 可互操作算法和密钥配置，并用原子、分阶段方式轮换。客户端应按服务器 IP 与本地源地址管理 Cookie，地址变化后生成新的 Client Cookie。对不支持 Cookie 的服务器应有退避策略，避免持续发送可跨网络跟踪的相同 Client Cookie。
验收至少覆盖：每个单节点、Anycast 混合路径、IPv4/IPv6、双出口 NAT、密钥轮换前中后、UDP 与 TCP。监控 BADCOOKIE 请求/响应计数、重试成功率和每个节点分布；正常状态下，新 Cookie 的下一次重试应被接受，不应出现节点间交替失败。
常见问题
BADCOOKIE 是否说明域名记录配置错了？
通常不是。它针对 DNS COOKIE 验证，发生在域名答案处理之前或防护策略阶段。应先查 Cookie、客户端地址和服务节点一致性。
第一次收到 BADCOOKIE 是否必须告警？
不一定。客户端没有有效 Server Cookie 时，服务器可用 BADCOOKIE 返回新 Cookie。若随后的有限重试成功，可以作为正常引导流程监控；连续失败才需要重点告警。
所有 Anycast 节点共享密钥就一定正常吗？
不一定。不同实现若使用不同构造算法仍可能互不验证。应同时统一 RFC 9018 方法、版本、长度、Secret 和轮换状态。
为什么更换网络后更容易出现 BADCOOKIE？
Server Cookie 通常绑定客户端 IP。公网出口或地址族改变后复用旧 Cookie 会失败，客户端应丢弃旧 Client/Server Cookie 并重新引导。
可以直接禁用 DNS Cookies 吗？
可作为受控对照，但会失去部分离路径伪造和放大攻击防护。应修复互操作、轮换或缓存问题，再根据风险决定是否启用，而不是长期靠关闭功能隐藏根因。
总结
连续 BADCOOKIE 的关键证据是“刚收到的新 Server Cookie 在下一次请求中仍不被接受”。围绕这条事务链检查命中节点、算法、Secret、客户端公网 IP、轮换窗口与 EDNS 透明传输，通常能快速区分 Anycast 不一致、NAT 地址变化和中间设备故障。修复后要用跨节点、跨地址族和轮换场景验收，确保保护机制不会反过来制造解析失败。