DNS放大攻击属于典型的反射与放大型拒绝服务攻击。攻击者控制僵尸网络，向互联网上配置不当的开放DNS解析器发送体积很小的查询请求，但在请求中伪造源IP为受害者的地址。DNS服务器收到查询后，将远大于请求体积的响应报文发送给受害者，从而在攻击者只需付出极小带宽成本的情况下，让受害者承受巨大的入站流量压力。由于DNS协议本身基于UDP、不强制验证源地址真实性，这种攻击实施门槛低、放大倍数高，常可达到数十倍甚至上百倍。
从原理上看，放大倍数取决于查询类型与响应大小的差值。常见的攻击查询会使用ANY类型请求或者特定的TXT、DNSSEC相关记录，这些响应往往携带大量数据。例如一个六十字节左右的查询，可能触发一个三千字节以上的响应。当攻击者掌握成千上万个开放解析器时，受害者接收到的聚合流量足以占满骨干链路。理解这一机制后，防护的核心思路就变得清晰：减少可被利用的开放解析器数量、压缩响应体积、在网络边界丢弃伪造流量、以及在被攻击时快速引流清洗。
网络层与边界设备的过滤策略
最有效的第一道防线是防止伪造源地址的流量离开自己的网络，以及阻止异常DNS响应进入内网。对于拥有自治域和出口路由器的企业，应在边界路由器上部署入向与出向的BCP38式过滤，即严格校验数据包源IP是否属于本网络分配的地址段。这样即便内部主机被植入恶意程序，也无法向外发送伪造受害者IP的DNS查询，从而减少成为攻击跳板的可能。同时，在面向互联网的防火墙或清洗设备上，对UDP 53端口的入站流量做速率限制和异常特征识别，例如同一目的IP在短时间内收到大量来自不同DNS服务器的大体积响应，就应当触发告警或丢弃。
除了源地址校验，还可以针对DNS报文本身做粗粒度控制。很多DNS放大攻击使用ANY查询，因为这类查询返回的响应最大。在边界设备上可以配置规则，识别并丢弃指向内部不存在域名的ANY请求，或者限制外部对递归解析服务的访问。如果业务并不需要对外提供递归解析，就应该将DNS服务器配置为非开放解析器，仅响应来自授权客户或内部网络的查询。下面是一个使用Linux iptables限制DNS响应包大小的示例，虽然不能彻底解决攻击，但能缓解极端大包的影响：
# 限制进入本机的DNS响应报文长度，超过1200字节的UDP 53包直接丢弃 iptables -A INPUT -p udp --dport 53 -m length --length 1200:0xffff -j DROP # 对来自外部网络的DNS查询做每秒速率限制 iptables -A INPUT -p udp --dport 53 -m limit --limit 50/s -j ACCEPT iptables -A INPUT -p udp --dport 53 -j DROP
上述规则的思路是先从报文长度维度削弱放大效果，再用速率限制避免单IP被海量小查询拖垮。需要注意的是，这种手段在攻击流量远超链路带宽时作用有限，必须配合上游运营商的清洗能力。此外，企业如果自己运行权威DNS，应确保响应仅针对真实存在的记录，不为任意域名返回超大容量的默认数据，从根源降低被借用的价值。
DNS服务自身的加固与配置优化
运行DNS服务的系统管理员应当默认关闭对互联网的递归解析。以常见的BIND为例，通过配置allow-recursion指令，只允许受信任的内部网段使用递归，其余来源仅能查询已授权的区数据。这样一来，外部攻击者无法利用你的服务器向其他根或权威服务器转发查询并放大响应。同时，应禁用或严格限制ANY查询，因为ANY原本用于调试，在生产环境几乎没有必要对外开放。下面是一段BIND配置片段，展示了如何限制递归并关闭ANY：
options {
// 仅允许内网网段进行递归查询
allow-recursion { 192.168.0.0/16; 10.0.0.0/8; };
// 禁止外部进行区域传送
allow-transfer { none; };
// 限制单客户端并发与速率，视版本可使用rate-limit
rate-limit {
responses-per-second 10;
nxdomains-per-second 5;
};
};
// 针对特定视图或区，可显式拒绝ANY类型
除了递归控制，启用响应速率限制（RRL，Response Rate Limiting）也是重要手段。RRL能在检测到同一应答被高频发送给某目标时，自动丢弃重复响应或返回截断标志，从而大幅压缩放大攻击的输出带宽。现代权威服务器如BIND、Knot、PowerDNS都支持类似机制。与此同时，若业务使用了DNSSEC，应注意签名记录本身会增大响应，因此在开放查询时要结合RRL与最小响应策略，避免安全特性反而成为放大帮凶。
在架构层面，建议将权威DNS与递归DNS物理或逻辑分离。权威服务器只回答自己负责的域名，不提供递归；递归服务器部署在内网边界并仅服务内部用户。这种分离既符合最小权限原则，也让外部扫描工具难以把你的权威节点识别为开放解析器。定期使用如dig命令从公网测试自身域名服务器的行为，确认没有意外暴露递归或ANY响应，是运维中的必要巡检项。
流量清洗与应急响应机制
当攻击流量已经形成实质性拥塞，单靠本地设备难以消化时，必须依赖上游运营商或专业DDoS清洗服务。多数云服务商提供Anycast DNS与流量清洗中心，通过将DNS查询引流到分布式节点，在靠近攻击源的位置丢弃异常包。企业可以在平时与运营商签订限速与清洗预案，在攻击发生时通过BGP通告或DNS切换，将域名解析迁移到具备大带宽吸收能力的防护平台。这样真实源站不会直接收到放大响应，用户仍可通过清洗节点获取解析结果。
建立监控与自动触发机制也极为关键。通过SNMP或流镜像观察UDP 53的入站速率、每秒查询数、响应体积分布，当指标突破基线时自动调用API开启清洗或临时关闭外部解析。下面的Python伪代码展示了基于阈值触发告警的逻辑：
def check_dns_traffic(inbound_pps, resp_avg_size):
# 设定阈值：入站包速率超过两万且平均响应大于一千字节视为异常
if inbound_pps > 20000 and resp_avg_size > 1000:
trigger_cleanup()
send_alert('疑似DNS放大攻击，已启动清洗')
else:
log_normal(inbound_pps)
def trigger_cleanup():
# 调用运营商或云清洗接口
call_api('enable_scrubbing', target='udp53')
def send_alert(msg):
print('[ALERT] ' + msg)
最后，业务侧应准备降级的解析方案。例如将关键域名同时托管在多家DNS服务商，攻击一家时由其余家承接；对核心业务使用IP直连或HTTPDNS减少单纯依赖传统DNS。通过多层防护、配置加固与应急流程的结合，才能把DNS放大攻击的影响控制在可接受范围内，而不是在流量洪峰到来时被动断网。
DNS_amplification防御策略流量清洗修改时间：2026-08-19 00:14:37