DNS-OARC 40 会议披露 Google Public DNS 在缓存投毒防护上的部署实践。尽管 DNSSEC 与加密传输可从根本解决欺骗问题，但普及率低、明文查询仍占主流，导致递归解析器仍面临离路与在路伪造攻击。Google 采用 RFC 5452 随机化查询 ID 与源端口，并部署 RFC 7873/9018 DNS Cookies，但权威服务器对 Cookies 的不合规响应成为主要障碍。
攻击面与基础防护机制
缓存投毒可在网络边缘针对存根解析器实施精准攻击，也可向递归解析器注入伪造答案扩大影响范围，Google Public DNS 因用户量大成为重点目标。当域名未签名 DNSSEC、查询又走明文通道时，递归解析器难以抵御在路攻击；即便攻击者不在路径上，也可诱导目标发起查询，再竞争伪造匹配查询 ID、UDP 地址端口的首个响应。RFC 5452 要求解析器使用随机查询 ID 与随机源端口，Google 已全面落实该对策。
DNS Cookies 部署与合规性测量
为进一步对抗 IP 地址欺骗，Google 还实现了 RFC 7873 与 RFC 9018 定义的 DNS Cookies。权威端若支持 DoT 或 DoQ，伪造响应可被直接拒绝，但现实中权威服务器对 Cookies 的支持不达预期。Google 持续开展每日结构化测量，发现主要问题是权威服务器返回不合规的 Cookies 响应，导致协议机制难以生效。原文未给出具体测量样本量与不合规比例数据。
加密权威通道的潜在价值
会议同时指出，权威 DNS 部署 DoT 或 DoQ 可从协议层面切断伪造响应路径，因为解析器能凭借服务器认证直接丢弃伪包。然而当前权威端加密部署率仍低，且 Cookies 合规性不足，使得防御体系仍依赖查询端随机化这一单一层面。Google 的实践表明，协议层面的多层防护仍需生态侧协同推进。
对运维工程师而言，需在递归端强制启用查询 ID 与源端口随机化、部署 DNS Cookies，并监控权威端 Cookies 响应合规性；长期应推动权威域名签名 DNSSEC 与 DoT/DoQ 部署，从源头压缩投毒面。
原文: APNIC Blog（2023-02-23）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog