2016年，伪源某安全团队在Black Hat大会上演示了一个攻击：攻击者伪造源IP为受害者的地址的DNS服务器地址，向全球大量开放递归解析器发送查询请求。远程结果呢？攻击受害者的DNS服务器被海量响应包淹没，直接瘫痪了整整48小时。漏洞这不是伪源什么高级零日漏洞，就是地址的UDP协议本身的设计缺陷被玩明白了。

DNS查询默认走UDP。远程UDP不验证源IP。攻击你把包的漏洞源地址字段填成别人的IP，发出去就发出去了，伪源没人拦你。地址的递归解析器收到查询后，远程会老老实实把响应发回那个“源地址”——也就是攻击受害者的DNS服务器。攻击者只需要找到足够多的漏洞开放递归解析器，就能把流量放大几十倍甚至上百倍砸向目标。

这个攻击链里有个关键角色：开放递归解析器。很多中小网络的管理员配置DNS服务器时图省事，允许任何来源的递归查询。一台这样的服务器就是一台免费的流量放大器。攻击者用伪造源IP发一个60字节的查询包，服务器可能返回一个3000字节的响应包。放大50倍，一万台开放解析器就是50万倍的流量杠杆。

我翻过几份Shodan的扫描报告，截至2023年全球仍有超过30万台DNS服务器开放递归查询。北美和欧洲的占比在下降，但东南亚和南美部分地区反而在增长。原因不复杂——那些地方的网络设备更新慢，默认配置往往就是全开。

防御这事，说起来简单做起来烦。入口过滤（BCP 38）能挡住伪造源IP的包，但需要ISP在边缘路由器上配ACL。很多ISP不愿意干，因为影响转发性能，而且“别人的攻击关我什么事”。结果就是伪造源IP的包在全球网络上畅通无阻。

另一条路是关闭开放递归。对权威DNS服务器来说本来就不该开递归，对递归服务器来说只允许内网查询就行。但现实是，很多DNS服务器是“一套配置走天下”，装完BIND或者Unbound，配置文件里recursion yes一写，ACL也不加，直接上线。我见过一个县级运营商的DNS服务器，开放递归不说，连rate limiting都没开，查询日志里全是伪造源IP的异常请求，管理员压根没看过日志。

DNSSEC和这个漏洞关系不大。DNSSEC解决的是数据完整性和来源验证，不解决UDP反射放大的问题。有人觉得上了DNSSEC就安全了，那是两码事。真正对症的是RRL（Response Rate Limiting），对同一目标IP的响应做限速，能有效削弱放大效应。但RRL会增加内存开销，高并发场景下可能误杀正常查询，所以部署率一直不高。

还有个被忽视的点：攻击者不一定非要打DNS服务器。他们伪造源IP为任意目标，向开放递归发查询，目标收到的是DNS响应包。防火墙看到UDP 53端口的包，很多默认放行。这就让攻击流量更容易穿透边界防护。我见过一个案例，攻击者用这招打掉了一台游戏服务器，运维查了半天以为是DDoS清洗设备故障，最后抓包才发现全是DNS响应。

要彻底堵住这个漏洞，需要三件事同时做：ISP部署入口过滤、DNS管理员关闭开放递归并开启RRL、防火墙对非请求的UDP 53响应做状态检测。缺一个，攻击者就还有操作空间。现实是这三件事在全球范围内都没做到位，所以这个“老漏洞”到今天还在被利用。