开放解析器之所以沦为DNS放大攻击的帮凶，根本原因是它对任何来源IP都来者不拒地执行递归查询，攻击者用伪造源地址的小请求撬动数十倍大的响应流量，把海量第三方DNS服务器变成免费流量放大器。
开放解析器为什么被DNS放大攻击盯上
DNS放大攻击的成本结构里,攻击者最在意两件事：一是请求包要小到可以忽略不计，二是响应包要大到能压垮目标带宽，开放解析器恰好同时满足这两个条件。
攻击者看中的是“小请求换大响应”的杠杆
一次典型的DNS查询请求可能只有几十字节,但如果查询的是ANY记录、DNSSEC相关的大记录集，或者构造一个可触发大量响应的域名，解析器返回的响应可以达到请求的数倍到数十倍，攻击者并不需要自己拥有带宽，只需要把伪造了受害者源IP的查询包发往开放解析器，响应就会直接涌向受害者，这中间的杠杆倍数，就是DNS放大攻击的杀伤力来源。
业内专家指出,DNS协议的请求响应不对称性本身是设计使然，问题不在于协议，而在于解析器是否愿意为陌生人提供递归服务。
伪造源IP让攻击变得“隐身”
DNS主要跑在UDP协议上,UDP没有三次握手，源IP可以随意填写，攻击者把源IP伪造成目标地址，向开放解析器发一个查询，解析器老老实实把大响应包发往目标，整个过程攻击者只出了一份小包，解析器承担了放大和反射的角色，目标看到的是来自四面八方的DNS响应洪水。
这类攻击的“隐身性”还体现在：受害者和开放解析器的运营者通常互不相识，攻击路径上留下的真实攻击者痕迹几乎为零。
开放解析器与递归解析器有什么区别？为什么前者更危险
很多运维人员把递归解析器和开放解析器混为一谈,递归解析器本身是正常基础设施，开放解析器则是把递归能力暴露给了全网，两者之间差的就是一条访问控制规则。
递归解析器的合法用途
递归解析器负责替内网客户端一步步查询根、顶级域、权威服务器，直到拿到最终结果，企业内部DNS、运营商DNS、公共DNS服务都属于递归解析器，合法使用时，它们只服务于授权的客户端范围。
开放与受限配置对比
| 配置维度 | 开放解析器 | 受限递归解析器 |
|---|---|---|
| 允许查询来源 | 任何IP地址 | 仅授权网段或本地接口 |
| 递归功能 | 对全网开放 | 默认关闭或按ACL放行 |
| 被利用风险 | 高，可被反射放大 | 低，外部无法借用 |
| 运维成本 | 看似省事，实则隐患大 | 需维护ACL但风险可控 |
| 典型场景 | 误配的云服务器、老旧内网DNS | 企业内网DNS、运营商递归节点 |
从对比可以看出,开放解析器的危险不在于“递归”这个功能，而在于“开放”这个状态，多数情况下，一台配置疏忽的服务器只是因为默认允许递归且没有限制查询来源，就变成了攻击链条上的一环。
DNS放大攻击的实操路径
攻击者视角的简化路径如下,理解它有助于防守方判断自己的服务器是否具备被利用的条件：
- 扫描全网UDP 53端口，对每个IP发送测试查询，
dig @目标IP test.example.com，观察是否返回递归结果； - 确认开放递归后,构造查询类型为大响应记录的域名，
dig @目标IP ANY isc.org； - 将源IP伪造成受害者地址,批量发送查询包，解析器响应即涌向受害者。
防守方可以用同样的命令自查,区别只在于目的不同。
企业内网DNS如何避免成为开放解析器帮凶
企业内网DNS被利用的情况并不少见,尤其是自建DNS、测试环境遗留服务器、云上默认镜像自带的解析服务，避免成为帮凶的关键动作是“关掉不必要的递归、限制查询来源、加上响应限速”。
自查：一条命令验证是否开放
在服务器本机或从外部机器执行：
dig @你的DNS服务器IP www.baidu.com +short
如果返回了A记录,且你的DNS服务器本来不应该对这台外部机器提供服务，说明递归查询对外部来源是放行的，再换一个不在授权网段内的IP重复测试，结果一致即可确认存在开放解析器风险，Windows环境可以用 nslookup www.baidu.com 你的DNS服务器IP 做类似验证。
加固：ACL与递归限制的配置要点
以常见的BIND为例,核心是三条：
- 用
allow-query限定允许发起查询的客户端网段，只放行内网和必要来源； - 用
allow-recursion限定允许递归的客户端，默认只对本地网段开放； - 启用响应速率限制（RRL），对同一目标的高频响应进行压制，降低被用作放大器的效率。
配置示例如下：
acl "trusted" {
192.168.0.0/16;
10.0.0.0/8;
};
options {
allow-query { trusted; };
allow-recursion { trusted; };
rate-limit {
responses-per-second 20;
};
};
修改后执行 named-checkconf 校验，再重载服务，云上环境还要检查安全组，UDP 53端口不应默认对全网放开，只对确需使用递归的地址段开放。
云服务器开放解析器加固多少钱？
这是不少中小团队关心的现实问题,价格差异主要来自三块：如果只是修改现有DNS软件配置，成本基本是运维人力，按工时计通常几百到一两千元；如果需要购买商业DNS防护或云解析企业版，年费从数千元到数万元不等，视查询量和防护能力而定；如果是等保测评或安全整改涉及的加固服务，打包报价可能更高，多数情况下，最有效的动作恰恰是零成本的配置修正先把 allow-recursion 收窄，再考虑商业防护。
地区与行业层面的治理现状
近年来,针对开放解析器的扫描和整治一直在持续，行业共识认为，开放解析器数量与反射攻击活跃度存在明显关联，华东地区部分运营商曾对辖区内开放递归的宽带接入设备发起过专项清理，减少了一批可被利用的节点，从公开的网络安全通报看，DNS反射放大仍是DDoS攻击中被频繁使用的低成本手法之一，对单个企业来说，等待外部整治不如先把自己的解析器配置查一遍。
开放解析器与DNS放大攻击Q&A
问：开放解析器和递归解析器是一回事吗？关闭递归会不会影响内网正常上网？
不是一回事，递归解析器是功能角色，开放解析器是配置状态，内网用户需要递归解析才能访问外部域名，所以不能一刀切关闭递归，正确做法是把递归限制在授权网段内，对外部来源关闭。
问：我的DNS服务器只服务内网，为什么还会被外部扫描到？
常见原因是云安全组或防火墙对UDP 53放行过宽，或者服务器存在多网卡、公网地址直接暴露，攻击者的扫描不区分“内网用途”，只看端口是否可达、是否返回递归结果，把公网入口收窄到必要地址，是比改DNS配置更前置的一步。
问：DNS放大攻击的流量一般有多大，小带宽目标会被打瘫吗？
放大攻击的反射流量取决于开放解析器的数量和查询构造，近年来公开披露的案例中，数百Mbps到数Gbps的反射流量并不罕见，对于带宽较小、缺乏清洗能力的目标，即使反射流量不算顶级，也足以造成可用性中断，防御的重点不是硬扛流量，而是减少可被利用的开放解析器，从源头压缩攻击面。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787833.html
