递归解析器会替用户向权威 DNS 服务器查询，再把结果返回。若它接受任意来源的查询，攻击者就可能伪造受害者地址发起请求，利用较大的 DNS 响应造成流量放大。因此，DNS放大攻击的递归解析风险控制，首先要回答一个问题：这台解析器究竟应该为谁提供服务？
先判断风险来自哪里
常见风险有两类：一是递归解析器对公网开放，任何来源都能查询；二是服务原本只面向内部网络，却因防火墙规则、云安全组或 IPv6 配置遗漏而意外暴露。前者可能被直接滥用，后者则容易在网络调整后被忽视。
检查时应从公网和获准的内网网段分别测试递归查询，并核对监听地址、访问控制列表和边界规则。只看到 UDP 53 端口开放，并不能单独证明解析器允许递归；要确认外部请求是否真的获得递归结果。DNS放大攻击的递归解析风险控制也不能只靠监测流量，配置边界才是首要防线。
按服务对象选择防护组合
只服务组织内部用户
优先采用来源限制：递归功能仅对办公网、服务器网或 VPN 地址段开放，公网接口关闭递归。BIND、Unbound 等递归软件都可通过访问控制实现类似目标，具体配置项和语法应以所用版本文档为准。优点是规则直观、能从源头减少滥用；缺点是网段变更、分支接入或双栈环境需要同步维护策略。
需要承接较多合法查询
在访问控制之外，再设置每来源查询速率、并发上限或异常请求阈值，并观察正常业务的峰值后逐步收紧。阈值不能脱离环境照搬：低流量办公网与面向大量终端的公共解析服务，正常请求分布差异很大。限制过严会造成超时或间歇性解析失败；限制过松则难以抑制滥用。这里的响应速率限制应针对递归服务的实现能力配置，不要把权威 DNS 常用的 RRL（响应速率限制）误当成可直接替代访问控制的措施。
必须向公网提供解析服务
确有公开递归需求时，应单独部署并隔离该服务，避免与内部解析器共用同一访问范围和故障域；同时配置请求速率控制、容量告警和上游网络防护。DNSSEC 验证有助于验证数据真实性，但不是防止反射流量的开关；启用或调整 EDNS 缓冲区也应结合路径 MTU、分片和客户端兼容性测试，不能简单追求更大的响应包。
落地检查：从规则到复核
- 盘点解析入口：列出运行递归服务的主机、云实例、容器和 IPv4/IPv6 地址，确认哪些确实需要对外提供查询。
- 收紧访问范围：内部解析器只允许明确的客户端网段；不需要公网递归时，在服务配置和网络边界同时阻断外部访问。
- 逐步加入限速：先记录合法流量基线，再按来源、请求类型和时间窗口设置阈值。调整后检查误拦截、延迟及解析失败率。
- 监控并复测：关注查询量突增、来源分布异常、递归超时和出口流量变化；从外部网络复核非授权来源不能获得递归服务，并在规则变更后重复测试。
如果真正需要的是托管域名的权威解析，应配置权威服务器，而不是因此开放递归功能。递归解析器负责代用户查找答案，权威服务器负责发布域名记录，两者职责不同，混用会扩大暴露面。
常见问题
关闭递归会影响所有 DNS 查询吗？
不会影响权威应答；但依赖该服务器查询外部域名的客户端需要改用获准的递归解析器。
只启用 DNSSEC 能阻止放大攻击吗？
不能。DNSSEC用于验证数据完整性，仍需限制递归访问并配置适当的速率控制。
DoH 或 DoT 能替代访问控制吗？
不能。加密传输可保护客户端到解析器之间的通信，但解析器仍须限制哪些用户可以使用递归服务。
选择策略时，内部服务优先收紧来源，公开服务则需隔离、限速并持续监测。把边界、容量与复核流程一起落实，才是DNS放大攻击的递归解析风险控制的可靠做法。