远端dns服务允许递归查询 漏洞

2015年冬天，远端我帮朋友排查一台托管在机房的许递询漏Linux服务器，发现它每小时向外发出上万条DNS查询请求。归查流量不大，远端但频率异常。许递询漏抓包一看，归查目标全是远端境外一些毫不相关的域名——他的服务器被人当成了DNS反射攻击的跳板。问题根源很简单：那台机器上跑着一个BIND服务，许递询漏配置里允许递归查询，归查而且对所有人开放。远端

这就是许递询漏远端DNS服务允许递归查询漏洞的典型面貌。它不是归查某个CVE编号里的缓冲区溢出，而是远端一个配置层面的问题。DNS服务器通常扮演两种角色：权威服务器负责回答自己管辖域名的许递询漏解析请求，递归服务器则帮客户端一层层追问，归查直到拿到最终结果。两种角色本身都没问题。问题出在，当一台面向公网的DNS服务器同时允许任意来源发起递归查询时，它就变成了一个放大器。

攻击者怎么利用它

DNS查询通常走UDP协议，源IP地址在协议层面不做验证。攻击者伪造受害者的IP地址，向开放递归的DNS服务器发送一个查询请求。这个请求可能很小，比如几十字节，但服务器递归查询后返回的响应可能大得多——尤其是查询像 ANY 类型记录或者DNSSEC签名的域名时，响应体可以膨胀到原始请求的几十倍甚至上百倍。

攻击者用一台DNS服务器还不够。他们会控制一批被感染的机器，同时向全球数万个开放递归的DNS服务器发送伪造查询。所有响应都涌向同一个受害者IP。这就是DNS放大攻击，带宽放大倍数通常在28到54倍之间，最坏情况下能到100倍以上。

2016年那场让半个美国互联网瘫痪的Dyn攻击，背后就是Mirai僵尸网络操控了大量IoT设备，配合DNS反射放大。Dyn是托管DNS服务商，它自己的基础设施被海量DNS响应淹没。那些响应从哪来？相当一部分来自配置不当的开放递归服务器。

为什么这个问题反复出现

我见过不少运维人员的思路是：“我的DNS服务器就是给自己内部用的，但放在公网上方便远程管理。”或者装完BIND、Unbound之后直接用默认配置跑起来，没想过 allow-recursion 这行配置意味着什么。默认配置有时候是允许递归的，有时候限制不严。不同发行版、不同版本的默认行为还不一样，这就更容易踩坑。

另一个原因是，很多小型企业或个人的VPS上跑着DNS服务，但他们并不觉得自己“在运营DNS”。可能只是装了个面板、跑了个邮件服务器，顺带把DNS服务带起来了。他们不会去监控DNS查询日志，也不会注意到自己的服务器正在被当作武器使用。

还有一个现实：开放递归的DNS服务器数量在下降，但远没有消失。Open Resolver Project长期跟踪这个数据，高峰期全球有超过3000万台开放递归服务器，现在降到了几十万台级别。绝对数量仍然可观，足够支撑大规模攻击。

怎么判断和怎么处理

判断自己的DNS服务器是否开放递归，最简单的办法是从外部网络执行一次查询。用 dig @你的IP example.com，如果返回了结果且状态是 NOERROR，同时你的服务器本不该对公网提供递归服务，那就有问题。也可以查Open Resolver Project的公开数据库，看自己的IP是否在列表里。

处理方式取决于服务器的角色。如果它只负责解析自己管辖的域名，直接关闭递归功能。BIND里设置 recursion no;，Unbound里限制访问控制列表。如果它确实需要为内部客户端提供递归服务，把 allow-recursion 限制在内部网段，别用 any。同时别忘了检查IPv6的配置——很多人只看了IPv4，忘了v6那边可能还敞着。

另外，别只依赖防火墙。有些运维觉得“我防火墙封了53端口就行了”，但DNS服务可能还监听在其他端口上，或者防火墙规则只覆盖了TCP没覆盖UDP。DNS主要走UDP，这个疏漏很常见。

这个问题说到底不复杂，但它的危害不体现在自己的服务器上——你的CPU和带宽可能毫无感觉，直到某天收到 abuse 投诉，或者你的IP被列入了DNS黑名单。等到那时候再查，往往已经跑了几个月的“免费打工”。