限制递归查询范围是削弱DNS放大攻击效果最直接、成本最低的手段之一，通过只允许可信客户端使用递归服务，攻击者便无法借助你的DNS服务器放大流量。 当攻击者伪造大量源IP地址向开放的递归服务器发送查询时，服务器返回的响应会远大于请求，形成流量放大，而限制递归查询范围，等于把门锁起来，只认自己人，攻击者伪造的请求从哪儿来都进不来。
DNS放大攻击是怎么发生的？递归查询的角色不容小觑
DNS放大攻击的本质是利用了递归解析器的“无条件信任”，攻击者发送一个很小的查询包，比如请求ANY类型或长TXT记录，服务器却会返回一个包含大量数据的响应包，这个响应包的大小可能是请求的几十倍甚至上百倍，如果攻击者把源IP伪造成受害者的地址，那么所有响应都会集中打到受害者身上，形成流量淹没。
递归查询在其中扮演了核心角色,普通用户设备向你的DNS服务器发起递归查询，服务器负责替用户完成完整解析流程，但如果这台服务器没有限制谁可以用，它就变成了一个公开的放大器，行业共识认为，开放递归是导致DNS放大攻击泛滥的首要原因，许多企业内网、小型云主机甚至家庭路由器默认开启了递归功能，却又暴露在公网，这类设备正是攻击者最爱找的肉鸡。
要理解限制递归查询范围为什么有效,可以看实际攻击路径，攻击者扫描全网，找到开放递归服务器后，会向它们发送伪造源地址的查询，如果服务器只允许特定IP段发起递归查询，那么从公网伪造来的源地址根本不匹配ACL规则，请求会被直接丢弃，即使请求侥幸进入了服务器，响应包也无法发回给攻击者指定的伪地址，因为访问控制列表在解析前就拦住了。
限制递归查询范围能削弱DNS放大攻击效果吗？核心机制
答案是明确的：能，而且效果非常显著，限制递归查询范围虽然不能阻止攻击者伪造IP，但能从源头切断放大器，攻击者要用一台不可用的递归服务器发起放大，就像拿一把没有钥匙的锁去锁门，白费力气。
从整个攻击效果看,当全球相当一部分开放递归服务器都关闭了无差别查询后，攻击者能利用的放大源数量会大幅减少，经过限制的服务器不仅不参与放大，甚至可能成为“安全过滤器”，业内专家指出，限制递归查询范围是DNS安全基线中最基础的一条，优先级高于配置防火墙规则。
具体机制可以拆解为两层：
- 第一层：若ACL设置正确，来自非授权IP的查询在TCP/UDP传输层就被丢弃，递归解析进程根本不会执行，攻击者发送的查询包如石沉大海。
- 第二层：即便攻击者把源IP改成内网IP段，若路由策略拒绝非对称路径，响应包无法到达伪装的地址，多数情况下，攻击者伪造的源地址在外网会被正确过滤。
限制递归查询范围并不是缓解措施,而是前置阻断，它让你的DNS服务器从攻击工具箱中消失，攻击者需要重新寻找其他开放递归，这显著抬高了攻击的复杂度与成本。
实操：企业内部DNS递归权限怎么配置？
真正动手时,配置本身并不复杂，但要分清几个概念。allow-query控制谁能向你这台DNS服务器发起查询，而allow-recursion专门控制谁能使用递归解析，很多管理员只设置了allow-query，忽略了递归限制，结果ACL形同虚设，正确做法是明确指定递归白名单。
BIND配置步骤
以BIND为例,在named.conf的options段中同时配置allow-query和allow-recursion：
options {
listen-on port 53 { any; };
allow-query { trusted_clients; };
allow-recursion { trusted_clients; };
allow-query-cache { trusted_clients; };
};
acl trusted_clients {
192.168.1.0/24;
10.0.0.0/8;
127.0.0.1;
};
配置完成后,执行named-checkconf检查语法，然后重启服务，大部分开源DNS服务器都是类似逻辑：先定义ACL，再绑定到递归相关配置中。
dnsmasq与Windows DNS的配置差异
dnsmasq常用于家庭路由器或轻量级局域网环境,它默认只在本地接口工作，但如果你把它暴露到公网，就需要显式限制接口，修改配置文件：
interface=eth0 except-interface=ppp0 local-service
local-service会忽略来自非本机网络的查询，非常适合内网场景，Windows DNS则需要在服务器管理器里打开DNS管理工具，右键服务器属性，在“接口”选项卡中限制对指定IP地址提供解析服务，同时可以设置递归访问范围。
国内服务器DNS递归查询设置的注意事项
国内服务器使用BIND或systemd-resolved时，常用防火墙辅助限制，比如用iptables先阻断来自未知IP的UDP 53端口请求，再放行内网网段：
iptables -A INPUT -p udp --dport 53 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j DROP
这里有一个容易踩坑的点：递归查询和授权查询可以分开控制，如果你这台DNS服务器同时对外提供权威解析，比如解析你自己的域名，那么allow-query需要保留给公网用户，而allow-recursion只给内部网络，把两者混在一起配置，会导致外部用户无法解析你的域名，或者内部用户无法递归。
不同场景下的方案对比：内网自建DNS与公共DNS的差异
很多运维人员会问：我直接用公共DNS不就行了？自建DNS限制递归和公共DNS比起来，到底哪个更实用？下面这张表可以快速看懂差异。
| 场景 | 递归查询控制方式 | 配置复杂度 | 安全风险 | 成本 |
|---|---|---|---|---|
| 内网自建DNS | ACL限定内网IP段 | 低 | 低，只要不暴露公网 | 仅服务器成本 |
| 公共DNS | 服务商统一限制，用户无法自控 | 零 | 依赖服务商防护能力 | 免费或按量付费 |
| 混合模式（内网缓存+公共转发） | 内网仅允许合法DHCP网段，上游指向公共DNS | 中 | 中，需保护内网节点 | 低 |
对于大多数中小公司,内网自建DNS配合ACL是最合适的，内网解析速度快，能缓存频繁访问的域名；限制递归范围后，这台服务器就算被扫描到，也不会变成放大器，公共DNS当然更省事，但你无法控制它的递归策略，且它可能被大流量攻击误伤。
如果预算敏感,开源方案完全够用，商业安全设备价格可能较高，但用于多节点或合规要求时更有优势。价格不是决定因素，限制递归查询范围是无论商业还是开源都必须做的基础动作，表里每一种方案都需要把“谁有权查询”这个边界画清楚。
怎么确认限制生效？验证递归查询的实操方法
配置完成后,不能只看配置文件就放心，要从外部视角验证，最直接的方法是使用dig模拟外部查询，在一台不在白名单内的机器上执行：
dig @你的服务器IP baidu.com
正常情况下,响应状态应该是REFUSED，或者直接超时，如果是NOERROR且返回了A记录，说明递归限制没有生效，需要回去检查ACL或防火墙，注意，REFUSED包仍然会返回给攻击者，但这只是一个小包，没有放大效果。
另一个验证角度是看递归服务器日志,BIND默认会记录client denied recursive resolution之类的错误信息，你可以统计日志中来自非授权IP的查询次数，确认它们是否被拦下。
如果你有网络流量监控,可以同时抓包查看端到端流量，限制递归后，UDP 53端口的入向查询包数量中，非授权源IP的包会被系统丢弃，出向响应包中不会再出现针对这些伪造源IP的大流量，用tcpdump抓取一段时间，对比之前的情况，会看到明显差异。
关于限制递归查询范围与DNS放大攻击的常见问题
限制递归查询范围会影响用户正常解析速度吗？
不会,递归查询限制只拒绝非白名单客户端的请求，内网用户仍然能正常使用递归解析，响应速度和之前没有区别，反而因为过滤掉了恶意查询，减少了资源占用，解析性能可能更稳定。
如果业务要求对公网提供递归服务怎么办？
你需要修改架构,把递归服务和授权服务分开部署，公网侧提供授权解析，只负责响应NS记录指向的域名，不开放递归，内网侧单独一台纯递归服务器，通过ACL限制来源IP为自有网段，或者使用RRL（响应速率限制）配合防火墙进一步加固，这样既满足业务需求，又不会让服务器变成放大器，据行业共识，长期暴露公网的递归服务必须有严格ACL与监控。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/786705.html
