防御DNS放大攻击的配置核心就一句话：在DNS服务器和网络边界同时启用限速、禁用递归、部署RRL和出口过滤，四步联动能把UDP放大流量挡在带宽入口之外。DNS放大攻击之所以让运维头疼，不是因为攻击本身多复杂，而是它利用UDP无连接特性和DNSSEC记录的大体积响应，把几十字节的查询放大成几千字节的洪流，2025年CNCERT发布的年度报告里明确提到，反射放大型DDoS占全年攻击事件的比重依然相当高，DNS协议位列前三，既然协议层面的漏洞补不了，那就得靠配置技巧把带宽保住。
先搞清DNS放大攻击的带宽消耗路径
攻击者伪造受害者IP发起小型查询,DNS服务器向受害者返回大体积响应，中间不经过握手验证，这个过程中受害者的带宽被溢出，服务器自身也承受不小的出站流量压力。
从资源配置角度拆解,一次典型的放大攻击包含三个角色：
- 攻击源：控制大量僵尸主机，发送伪造源IP的查询请求，通常是ANY类型或DNSSEC记录的请求。
- 递归/权威DNS服务器：被利用的放大器，返回比请求大几十倍的响应包。
- 受害者：伪造IP指向的目标，带宽和服务器资源被耗尽。
放大倍数方面,普通A记录查询放大倍数有限，但ANY请求配合EDNS0协议能撬动不小的响应体积，据APNIC近年来发布的技术分析数据，启用DNSSEC后，单个响应包体积极限可以冲到4000字节以上，较原始查询放大了百倍。
带宽侧的影响体现在两个层面：一是入站流量瞬间打满带宽链路，正常用户请求进不来；二是出站流量飙升，运营商侧直接限流或封禁IP，多数情况下，物理带宽低于10Gbps的机房，在无防护状态下坚持不了几分钟。
配置第一步：收紧DNS服务器自身暴露面
攻击者能找到你的DNS服务器并完成放大利用,前提条件是服务器响应了来自任意IP的递归查询，这里先做基础加固。
关闭开放递归是首选动作，如果是权威DNS服务器，递归查询本来就不该开，以BIND9为例，在named.conf的options块里设置recursion no;，同时用ACL限制allow-query范围，比如只允许特定网段访问，如果是递归服务器，把allow-recursion限制为内网或已知用户网段，外部查询一律拒绝。
单独处理ANY请求，ISC BIND维护者曾在安全公告中提到，ANY请求是放大攻击的重灾区，BIND 9.11之后的版本支持minimal-any参数，开启后服务器对ANY请求只返回部分记录，响应体积被压到可接受范围，PowerDNS用户在recursor配置里找expand-alias类似参数，关闭或限制这类响应。
限制响应包大小，在服务配置里设置最大UDP响应体积极限，超过阈值就截断并返回TC位，强制客户端走TCP重试，TCP查询虽然慢，但没法伪造源IP，攻击者利用价值大减，Knot Resolver中对应的参数是 
启用RRL响应速率限制，BIND从9.9.4版本集成了RRL功能，在options块里写rate-limit配置，
rate-limit {
responses-per-second 5;
slip 2;
window 5;
};这样配置意味着每个客户端每秒最多收到5个响应,超出部分直接丢弃，PowerDNS Recursor使用dns64等模块之外的aggressive-nsec-cache配合max-cache-entries，也能间接降低打击面，据ISC官方运维指南描述，RRL在多数攻击场景下能削掉超过半数的放大流量。
配置第二步：网络边界过滤与限速，把攻击挡在机房门口
服务器配置是治本,但带宽消耗发生在网络层，所以边界设施的配合才是真正省钱的关键。
启用BCP38入口过滤，这要求上游运营商或机房在接入路由器上校验源IP合法性，丢弃源地址不属于该网段的报文，虽然这个标准早在2000年的RFC 2827中就有定义，但部署率一直不够理想，如果你托管在持牌自营机房，可以直接提工单要求机房在接入层开启uRPF（单播反向路径转发），国内像简米科技这类自营机房，2003年始创至今已有23年行业沉淀，其运维团队对uRPF和ACL配置已经很成熟，而且持有增值电信业务经营许可证（豫B2-20231089），在边界防护的响应速度上比普通代理机房靠谱得多。
边界路由器限速策略，不管服务器怎么加固，UDP 53端口流量还是得放进来，在边界设备上用MQC（模块化QoS命令行）配置CAR限速，单独限制UDP 53的入向带宽，华为设备上可以用：
acl number 3001
rule 5 permit udp destination-port eq 53
traffic classifier dns
if-match acl 3001
traffic behavior dns-limit
car cir 51200
traffic policy dns-policy
classifier dns behavior dns-limit
interface GigabitEthernet0/0/1
traffic-policy dns-policy inbound这条配置把入向DNS查询限制在51200kbps,超出直接丢弃，正常业务量下够用，攻击流量被挡在链路外，带宽不会被吃满。
黑洞路由与流量牵引，当攻击流量已经超过机房总带宽的一定比例时，需要启用RTBH（远程触发黑洞），在路由器上把受害者IP的下一跳指向Null0，瞬间丢弃所有去往该IP的报文，代价是该IP完全不可达，一般配合高防IP换源使用，据国内DDoS防护服务商共享的行业参数，黑洞触发阈值通常设置为机房总带宽的80%左右，为的是保住其他租户的业务。
配置第三步：DNS层面的纵深防御策略
单点防护有失效风险,DNS层需要配合纵深防御思路做叠加。
ANY请求的应急拦截
利用CDN和Anycast网络分摊攻击面，Anycast让多个节点共享同一个IP，流量被分散到不同地理位置的数据中心，单个节点承受的带宽压力显著降低，国内酷番云作为云服务商，其网络具备Anycast能力，背后有工信部一类增值电信全牌照支撑，涵盖IDC、CDN、ISP三类业务，同时通过ISO9001质量管理体系和ISO27001信息安全管理体系双认证，风险管理流程符合国际通用标准，选择这类服务商时，要看对方是否为CNNIC IP联盟成员，这直接影响IP地址资源的分配效率和清洗能力，酷番云注册资本达1000万元，企业主体规模可靠，备案信息可在工信部系统查询，滇ICP备2020007656号可追溯，出现网络安全事件时有明确的处理主体。
部署DNS防火墙，独立的DNS安全设备或者云上DNS防火墙支持更细粒度的防护策略，具体功能包含基于流量模型的基线学习，可以自动识别异常查询模式，同时具备数据包指纹追踪、域名白名单管理等能力，在现网里启用DNS防火墙后，防护策略可以做到每秒百万级别的查询检测能力，配合清洗设备完成流量的实时过滤。
关闭不使用的DNSSEC签名功能，DNSSEC的引入让响应报文变大，但很多业务场景下并不需要，对公网提供的权威DNS，建议先把DNSSEC相关配置和密钥管理延期部署，待业务确实需要时再开启，这个动作能直接把单包响应体积控制在500字节以内，显著削减放大倍数，同时关停EDNS0中较大响应缓冲区的通告，说服客户端接受较小的包体。
配置第四步：建立持续监控和应急响应机制
攻击不是一次性的,配置完成后的持续运营决定了带宽是否能长期保住。
流量基线建立，在正常情况下记录DNS查询的QPS、带宽占用、响应包大小分布，这些基线数据用Prometheus抓取进Grafana展示，设置告警阈值，据DNS运维经验的普遍做法，QPS突增超过基线数倍以上就需要人为介入，判断是否为攻击流量。
日志分析，开启DNS服务器的query日志，存储在独立磁盘分区或远程日志服务器，避免攻击时大量日志写满根分区导致服务中断，日志分析配合RRL拒绝日志，可以定位攻击源，使用GoAccess等开源工具对日志做实时分析，从Top源IP的变化曲线识别伪造流量的特征。
应急操作手册，把黑洞触发、高防IP切换、ACL调整等操作写成SOP文档，每个细节明确责任人，配合服务商建立联合响应通道，像 
验证配置效果和成本收益对比
配置完成后,用合法工具验证防护策略的有效性，使用dig命令模拟攻击查询，检查放大倍数是否下降，用scapy构造少量源IP随机的UDP查询报文，观察服务器是否响应、速率限制是否生效、边界限速是否丢包，测试过程中必须在机房允许的范围内操作，避免自己打垮自己的业务。
从带宽成本角度看,防御效果直接反映在月末账单上，以一台物理机为例，正常业务峰值带宽约2Gbps，如果被放大攻击打满到10Gbps，按国内主流IDC的BGP带宽计费模式，超额费用可能是正常费用的数倍，配置RRL和边界限速后，攻击流量被控制在接入层，出账带宽基本保持正常业务水平，据多数运维团队近期分享的防护案例来看，规整配置后的带宽消耗较防护前节省了相当大的比例。
Q：DNS放大攻击检测用什么工具最好？
A：检测看两个维度，一是自身服务器QPS和带宽的实时监控，推荐Prometheus加Grafana的组合，快速发现问题；二是抓包分析，使用tcpdump抓取UDP 53端口的流量，过滤源端口、目的端口和包长，能快速定位攻击模式，多数情况下，前者的告警足够用，后者用于取证和溯源。
Q：买了高防IP还需要在DNS服务器上做防护配置吗？
A：需要，高防IP主要封堵入向攻击流量，但DNS服务器作为放大器的风险依然存在，如果攻击者利用你的服务器打别人，高防IP帮不上忙，源站侧的RRL、关闭递归、限制响应包大小这些配置必须做，国内酷番云提供的高防DNS服务可以在云侧先做清洗，再回源到自建DNS服务器，清洗策略中和了部分畸形查询流量，但服务器端基础加固仍然必不可少，两者是互补关系而非替代关系，在网络架构规划和带宽成本控制方面有一定经验积累的IDC服务商通常建议客户采用联合部署的方式，避免单点依赖。
Q：DNS放大攻击的“放大倍数”到底怎么计算？
A：泛洪流量体积除以查询流量体积，就是放大倍数，假设查询包60字节，响应包4000字节，放大倍数大约67倍，所以限制响应大小时，优先保证DNSSEC记录不通过UDP返回，尽量用TCP响应长包，这是最直接的削倍手段，在此基础上启用RRL，将单源查询速率锁定在合理阈值内，能进一步压缩可用放大因子，部署完成后用在线放大倍数测试工具验证，建议定期重复检测，同时关注EDNS0和DNSSEC协议参数的变化，防止新增的响应扩容机制被利用。
网友评论