DNS 协议自诞生以来即面临基于 UDP 的 IP 欺骗 DDoS 攻击：攻击者向成千上万台开放解析器发送伪造源地址的查询，服务器生成的放大响应汇聚淹没受害者链路。2013 年 Spamhaus 事件峰值超 100 Gbps，动用 30,000 台 DNS 服务器。根因在于 UDP 缺乏身份管理，不建立连接、不验证通信双方，允许任意伪造源地址。尽管 DNS 已支持 TCP、DoT、DoH 及 DNS Cookie 等具备身份认证与加密的机制，但权威服务器仍须响应 UDP 查询——规范强制、历史客户端多用 UDP、且服务器无法知晓客户端支持协议。
**攻击放大与协议根因：**
攻击者利用 UDP 无状态特性，以受害者 IP 为源地址向海量开放解析器发送小体积查询，触发数倍至数十倍的响应回包。2013 年实测 30,000 台服务器产生超 100 Gbps 流量，典型放大比使受害者入向带宽迅速耗尽。UDP 不握手、不验证源地址合法性，使伪造数据包极易注入，成为 DNS 反射放大攻击的基础设施级弱点。
**现有机制的防御盲区：**
TCP、DoT、DoH 通过连接建立或 TLS 握手天然提供身份确认；DNS Cookie 在 UDP 报文内嵌唯一标识符，兼顾速度与认证。然而规范要求服务器必须响应 UDP 查询，且绝大多数客户端历史沿用 UDP。服务器端无感知客户端能力，无法主动拒绝未认证的 UDP 请求，导致加密传输与 Cookie 机制在大规模反射场景下形同虚设。
**客户端偏好学习的失效实证：**
设想服务器记录客户端偏好协议后过滤 UDP，实测表明该思路不可行。DDoS 动用数千台服务器，受害者客户端几不可能与全部建立过通信；即便建立过，实验显示 99% 支持 Cookie 的服务器在查询突然不含 Cookie 时仍正常响应（详见论文《A peek into the DNS cookie jar》）。协议协商状态不具备跨服务器一致性，单点学习无法构建全局防御。
对运维与网络工程师而言，关键启示是：单靠服务端协议升级或状态记录无法阻断 UDP 反射放大，需在网络层部署源地址验证（BCP 38/SAVI）、限制开放解析器响应速率、启用响应速率限制（RRL）与 Anycast 分流，配合 DNSSEC 签名验证，从基础设施层面切断伪造源路径。
原文: APNIC Blog（2022-02-10）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog