域名系统（DNS）是互联网寻址体系的核心基石，负责将域名映射为底层 IP 端点。数十年来，DNS 查询主要依托基于 UDP 协议的 53 端口进行传输。尽管 UDP 无需三次握手即可显著降低传输时延，但其无连接特性却引入了严重的底层架构隐患：源 IP 地址伪造。攻击者频繁利用递归解析器和权威域名服务器，发起大规模反射型分布式拒绝服务（DDoS）攻击与旁路缓存投毒。为此，IETF 发布的 RFC 7873（DNS Cookies）及其标准化演进版本 RFC 9018（Interoperable DNS Server Cookies），在 EDNS(0) 扩展机制中建立起轻量级、无状态的双向密码学验证凭证。

传统无认证 UDP 查询（易遭受源 IP 伪造）：
攻击者（伪造受害者 IP） ──────── 查询请求 ────────> DNS 解析器
目标受害者 <─────────── 放大反射响应 ────────── DNS 解析器

启用 DNS Cookie 防护流程（RFC 7873 / RFC 9018）：
客户端 ──────── 查询请求 + Client Cookie (8 字节) ───────> DNS 服务器
客户端 <── 响应包 + Client Cookie + Server Cookie ─── DNS 服务器
（确立双向往返可达性，丢弃或限制未经认证的伪造查询）

UDP 放大攻击困局：传统无认证 DNS 的脆弱性

标准 UDP 传输下的 DNS 查询报文缺乏对发送方真实身份的内生认证机制。当域名服务器收到查询时，仅能校验 IP 报头中的源地址字段。由于 UDP 在传输前不校验双向网络路径可达性，处于任意网络位置的攻击者均可伪造包含受害者源 IP 地址的查询数据包。

无状态传输与源 IP 地址伪造风险

微型查询报文与庞大密码学响应之间的体积悬殊，造成了极高的流量放大倍数。一个仅 64 字节的查询请求（例如请求 ANY 记录、DNSSEC 密钥签名集 RRSIG/DNSKEY 或冗长 TXT 记录），通常会激增为超过 3,000 字节的庞大响应。当上游 ISP 未严格配置源地址验证（BCP 38 / RFC 2827）时，攻击者便能借助海量开放式 DNS 解析服务器汇聚海量流量，压垮目标下行带宽。

与此同时，缺乏验证也加剧了旁路缓存污染风险。攻击者通过预测事务 ID（Transaction ID）和源端口号，可在真实权威响应到达前向递归服务器注入伪造资源记录。DNSSEC 虽保障了应答报文的真实性，却无法阻断解析器被滥用为流量放大工具。

响应速率限制 RRL 的成本与局限

为遏制流量放大危害，权威服务器广泛启用了响应速率限制（RRL）。RRL 依据客户端网络前缀（IPv4 为 /24，IPv6 为 /56）统计请求频次，对超出阈值的响应采取静默丢弃或置位截断标记（TC=1）。

然而，RRL 带来了不可忽视的运维弊端：

  • 处于运营商级 NAT（CGNAT）后的合法终端与受感染机器共享公网前缀，极易遭受连带误伤导致解析超时。
  • 强制截断（TC=1）会迫使客户端回退至 TCP 协议，引入三次握手往返延迟与服务器套接字状态开销。
  • 高并发递归解析节点在突发业务峰值时极易触发误判，造成终端业务大面积延迟波动。

DNS Cookies 方案在无需维护连接状态表的前提下，直接证实往返网络可达性，终结了 RRL 机制下的两难妥协。

RFC 7873 在扩展 DNS 机制（EDNS(0), RFC 6891）中定义了 Option Code 10 选项，用于承载密码学认证凭证。

+-------------------------------+-------------------------------+
|       OPTION-CODE (10)        |     OPTION-LENGTH (16-40)     |
+-------------------------------+-------------------------------+
|                    Client Cookie (8 字节)                     |
+---------------------------------------------------------------+
|                    Server Cookie (8-32 字节)                  |
+---------------------------------------------------------------+

该协议依托两阶段握手机制，在客户端（存根解析器或递归服务器）与服务端（递归解析器或权威服务器）之间展开协同校验。

Client Cookie 是客户端生成的 8 字节伪随机令牌。该令牌既必须令旁路嗅探者不可预测，又需保证在一定时间窗口内针对特定目标服务器能稳定复现。符合标准的客户端采用带密钥伪随机函数计算生成：

$$\text{Client Cookie} = \text{PRF-64}(\text{Client IP}, \text{Server IP}, \text{Client Secret})$$

客户端密钥包含内存中的 128 位密码学熵值。定期平滑轮换（通常为 24 小时）可使陈旧凭据自动失效，且无需落盘存储。将客户端与服务端双方 IP 强行绑定的设计，有效防止了凭证在不同目标之间被盗用重放。

当服务端解析器接收到附带 Client Cookie 的查询时，将执行以下流程：

  1. 初始查询：客户端首次仅发送 8 字节 Client Cookie，选项长度为 8。
  2. 服务端生成：服务器判定此为握手初始化请求，结合 Client Cookie、客户端 IP 及本节点密钥，实时推导生成对应的 Server Cookie。
  3. 回传双 Cookie：服务器将客户端原始凭据与生成的 Server Cookie 一并封装入响应的 EDNS(0) OPT 记录中返回。
  4. 客户端本地缓存：客户端校验回传的 Client Cookie 与自身一致后，将 Server Cookie 缓存在以服务器 IP 为索引的本地映射表中。
  5. 后续查询通信：后续所有查询均携带两组 Cookie（总长度 16 至 40 字节），服务器只需执行一次快速哈希比对即可瞬时完成合法身份认证。

攻击者因无法接收来自目标服务器的回包，无从获知 Server Cookie，进而丧失了发起反射放大的基本条件。

尽管 RFC 7873 确立了协议骨架，但此前未约束 Server Cookie 的内部二进制格式。在采用 Anycast 架构的多厂商混合基础设施中（例如混部 BIND、NSD、Knot DNS 和 PowerDNS），不同软件生成的凭据彼此无法解析，导致解析请求出现高频异常失效。

为解决互通难题，RFC 9018 正式确立了标准化的 16 字节 Server Cookie 报文结构。

+---------------+---------------+-------------------------------+
| Version (0x01)|       Reserved (0x000000)                     |
+---------------+---------------+-------------------------------+
|                      Timestamp (4 字节)                       |
+---------------------------------------------------------------+
|                      Hash (8 字节)                            |
+---------------------------------------------------------------+

各字段具体定义如下：

  • Version（1 字节）：格式计算版本标识，目前规范固定为 0x01。
  • Reserved（3 字节）：保留字段，传输时置零 0x000000，接收端忽略。
  • Timestamp（4 字节）：32 位无符号整数，记录 UNIX 时间戳秒数。
  • Hash（8 字节）：64 位截断密码学认证码。

SipHash-2-4 算法构造与 64 位截断哈希

RFC 9018 明确指定采用 SipHash-2-4 伪随机函数计算 8 字节哈希值。SipHash-2-4 在短报文处理性能、哈希碰撞防护以及 64 位 CPU 流水线执行效率上表现出众。

具体计算逻辑公式如下：

$$\text{Hash} = \text{SipHash-2-4}(\text{Server Secret}, \text{Client Cookie} ,|, \text{Version} ,|, \text{Reserved} ,|, \text{Timestamp} ,|, \text{Client IP})$$

服务器在校验报文时执行双重约束验证：

  1. 时间戳有效性校验：确认 $|T_{\text{当前}} - T_{\text{Cookie}}| \le 3600 \text{ 秒}$。这 1 小时容差窗口兼顾网络时延与时钟漂移，同时收紧凭据重放周期。
  2. 常量时间签名比对：使用当前激活的主密钥重算 SipHash-2-4，并在常量时间（constant time）内完成 64 位比对，防范时序侧信道分析。

验证通过的数据包被标识为合规可信流量，服务端自动豁免 RRL 拦截规则，按商定的 EDNS 缓冲区大小完整返回解析结果。

Anycast 解析集群拓扑与密钥平滑轮换

现代高性能 DNS 网络普遍基于 BGP Anycast 架构构建，将同一 IP 前缀广播至全球数百个分布式边缘节点（PoP）。在实际运行中，路由震荡或负载均衡哈希变动可能导致前后连续请求落入不同物理机架。

为保障跨节点验证的一致性，整个 Anycast 集群内的所有边缘节点必须共享完全相同的密钥库。运维体系采用双对称密钥设计：

  • 主密钥（$K_{\text{active}}$）：用于为流出应答生成新版 Server Cookie，并校验流入的请求令牌。
  • 备份密钥（$K_{\text{previous}}$）：在密钥轮换窗口期（通常持续 2 至 24 小时）保持激活，负责平滑接纳基于上代密钥生成的历史 Cookie。

密钥轮换时，先将新密钥同步为预备状态，随后提升为主密钥，旧主密钥顺延为备份状态，直至客户端缓存自然淘汰后再彻底注销。全流程杜绝了 Anycast 节点切换引发的连接重置。

BADCOOKIE 错误恢复与中间件兼容回退

当服务器收到过期、非法或已损坏的 Server Cookie 时，系统严格执行 RFC 7873 标准规定的容错流程：

  1. 阻断反射：坚决拒绝对异常报文返回完整解析应答集合。
  2. 返回错误标志：构造仅包含报头的空响应，设置响应状态码 RCODE=9 (BADCOOKIE) 并回显事务 ID。
  3. 注入全新 Cookie：在 EDNS(0) OPT 记录中携带客户端原本的 Client Cookie，同时附赠一枚当前有效的全新 Server Cookie。
  4. 客户端瞬时重试：合规客户端提取新令牌更新映射表，即刻重新投递原查询请求。

若中间链路中的陈旧网络防火墙彻底剥离了 EDNS(0) 选项字段，客户端检测到无响应凭据回传后，会自动回退至传统标准 DNS 查询模式，确保网络连通性不受影响。

深度融合 RiceGuard：零信任 DNS 与流量保护

VPNRice 底层自研的 RiceGuard 核心网络引擎，全面将 DNS Cookies 协议规范深度注入终端调度层与边缘递归解析链，构建起一体化零信任 DNS 防御体系。

RiceGuard 零信任 DNS 协同拓扑：
终端应用（VPNRice Client）
  │
  ├── 加密 WireGuard / IPsec 隧道（ChaCha20-Poly1305 / AES-256-GCM）
  ▼
RiceGuard 边缘 Anycast 接入网关
  │  - 强制检验流入 UDP 请求的 RFC 9018 Server Cookie
  │  - 在网络入口前置过滤伪造源地址的探测包
  │  - 跨全球边缘节点高精度同步 SipHash-2-4 轮换密钥
  ▼
加固型递归解析引擎核心
  │  - 向上游根域与顶级域权威查询附带 Option 10 凭据
  │  - 严格核验权威回执中的 Server Cookie 签名
  │  - 全链路执行 DNSSEC 密码学链条验证
  ▼
互联网权威域名解析基础设施
  1. 隧道链路加密隔绝：终端解析请求均在 WireGuard 或 IPsec 加密隧道内点对点直达专用 Anycast 节点，免疫公共 Wi-Fi 窥探与运营商旁路劫持。
  2. 边缘节点流量护城河：公网暴露接口对 UDP 查询实施严格的 RFC 9018 凭据校验。未附带有效 Cookie 的伪造流量将被限速或触发凭据挑战，防范节点被黑客利用为对外攻击的跳板。
  3. 上游迭代查询抗投毒：RiceGuard 递归集群在向上游权威服务器发起查询时，主动嵌入 Client Cookie 并检验返回凭据，使非 DNSSEC 签名的常规域名同样具备极强的抵御伪造注入能力。

链路层高强度对称加密与传输层 DNS Cookies 机制相互协同，为网络环境赋予了兼具极低延迟与坚固防护的现代解析体验。

运维验证实践：使用 Dig 工具测试 DNS Cookies

系统管理员可直接使用现代 BIND 9 套件自带的 dig 工具排查分析 DNS Cookies 的实际协商状态。

较新版本的 dig 默认会自动激活 Cookie 协商流程：

# 查询支持 Cookie 校验的 Anycast 解析服务器
dig @1.1.1.1 vpnrice.com +cookie

在终端输出的 OPT PSEUDOSECTION 拓展区中，可直观查验协议交互结果：

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5a8e2b109c3d4f8a 01000000672c8410d9f82e14a7c3b901 (good)
;; QUESTION SECTION:
;vpnrice.com.			IN	A

;; ANSWER SECTION:
vpnrice.com.		300	IN	A	104.21.48.12

字段解析说明：

  • 5a8e2b109c3d4f8a：客户端工具本地生成的 8 字节 Client Cookie。
  • 01000000672c8410d9f82e14a7c3b901：标准 16 字节 RFC 9018 Server Cookie：
    • 版本号：01
    • 保留位：000000
    • 时间戳：672c8410（十六进制 UNIX 秒级时间戳）
    • 哈希值：d9f82e14a7c3b901（SipHash-2-4 截断摘要）
  • 结尾处的 (good) 标签代表客户端已成功确认服务端凭据的合法性。

模拟凭证损坏与重协商容错

管理员可通过人为构造错误凭证，测试服务端的异常处理能力：

# 故意提交损坏的 16 字节 Server Cookie 测试容错
dig @1.1.1.1 vpnrice.com +cookie=5a8e2b109c3d4f8a0100000000000000ffffffffffffffff

遵循 RFC 9018 标准的服务器会迅速返回 status: BADCOOKIE，应答区置空，并在 OPT 选项中同步附赠新生成的合法 Server Cookie 促使客户端完成状态更新。

DNS Cookies 巧妙弥合了传统 UDP 协议低延迟诉求与现代化身份鉴别之间的鸿沟。在递归与权威解析全链路落地 RFC 7873 和 RFC 9018 标准，可从源头掐灭反射放大攻击的生存土壤，维持毫秒级疾速解析效率。

若需强化网络传输安全，依托加固型 Anycast 解析网络获得可靠的网络体验，推荐获取 VPNRice。