DNS放大攻击消耗服务器带宽现象

DNS放大攻击消耗服务器带宽的直接原因在于攻击者利用少量探测流量触发大量应答流量，使反射流量集中冲击目标带宽，造成链路拥塞直至业务不可达；防御关键在于带宽冗余与流量清洗能力。

DNS放大攻击的生命周期：从一次查询到一场洪峰

三个角色一台戏：反射源、放大因子、伪造源IP

DNS放大攻击之所以长期存在，是因为它把协议本身的结构性缺陷利用到了极致，互联网上有大量开放递归DNS服务器，这些服务器对任何来源的查询请求都愿意响应，攻击者向这些服务器发送一个源IP伪装成受害者IP的DNS查询报文，服务器把应答报文发往受害者地址，受害者的服务器网络入口处,数据包数量与字节数量会在瞬间暴增。

这个过程中有三个关键参与者：

• 攻击者主机：仅需发送很小的查询流量，不直接参与高带宽洪流
• 开放递归DNS服务器：天然的反射放大节点，自身不感知已被利用
• 攻击目标（受害者）：被动接收海量DNS应答报文，带宽被耗尽

DDoS攻击的常见手法是从多个方向发包，但DNS放大攻击的特殊性在于应答报文普遍大于请求报文，这被称作放大因子，查询一个约40字节的DNS请求，可以触发一个超过400字节的应答，放大倍数在多数实测场景下能达到数十倍，部分支持DNSSEC、ANY查询或EDNS0扩展的服务器还可能返回更大的响应，放大程度更明显，2018年GitHub遭受的1.35Tbps攻击即与此类反射放大技术密切相关。

放大倍数不是玄学：一个公式看清流量规模

放大因子 = 响应报文字节数 ÷ 查询报文字节数

仅从公式看，攻击者用1Mbps带宽就能打出30-50Mbps甚至更高的流量，攻击者在一台普通VPS上运行分布式工具，向大量开放递归服务器发送伪造源IP的查询，这些服务器的响应流量从四面八方涌向目标机房入口。当入向流量超过带宽上限，路由器开始随机丢包，合法用户请求和服务响应一起被丢弃，服务器本身CPU和内存可能尚未耗尽，但入向带宽已满，业务表现为连接超时、页面无法打开。

某些高度优化的攻击工具会持续循环改变查询域名、查询类型和反射源端口，使防御方很难通过简单封禁某几个IP来缓解，流量一旦到达物理带宽上限,任何存在于链路后端的防护措施都无济于事。

带宽被消耗时的现场表现与识别信号

服务器日志和网络层的不同反应

很多运维人员最初发现问题的场景并非系统日志出现异常，而是CLB或公网网关的监控图上流量曲线突然拉平到带宽上限，出向和入向流量可能出现极端不对称——入向流量数倍于出向流量，相反方向流量却很少,这是DNS放大攻击区别于Web攻击的显著特征。

从服务器内部观察,常见的现象有几个：

• ss -unp 看到大量来自不同源IP的UDP 53端口连接，且远端地址不重复
• iftop 或 nload 显示入向流量远高于正常水位，峰值持续数十分钟
• 机房交换机或云厂商控制台的丢包计数持续上升
• 同样的访问请求，响应时间明显拉长，TCP三次握手频繁超时

需要注意的是，有些攻击并不以填满带宽为唯一目标，某些情况下攻击流量并未占满所有带宽，但因为这些流量全部流向服务器的53端口，使named或dnsmasq进程的CPU使用率飙升，引起权威DNS响应变慢，混合型攻击在现实中更为常见,也更难排查。

为什么攻击源难以追踪

刚接触这类攻击的运维常有的疑问是：既然有那么多来源IP，为什么不逐个封禁？现实是攻击者伪造了查询报文中的源IP地址，反射端看到的“查询来源”是受害者的IP，所以应答会正常返回，而受害者只能看到反射服务器的地址，进一步分析时还会发现，攻击者控制的反射服务器数量可能达到数万台，分布在全球各运营商网络,手工处理几乎不可能在攻击持续时间内完成。

确认攻击并量化损失的四个实操步骤

第一步：抓包验证报文特征

在受害服务器或防火墙旁路镜像口执行：

tcpdump -i eth0 udp port 53 -c 1000 -w dns_attack.pcap

抓取若干秒后分析报文，一个典型特征是请求报文来自随机高位端口，且不同报文的源IP分布极广，但DNS报文内容和查询域名高度集中或完全一致,与之形成对比的是正常情况下源端口和请求频率相对稳定。

打开pcap文件可以直接检验：

tcpdump -r dns_attack.pcap -nn | awk '{print $3}' | sort | uniq -c | sort -nr | head

若前若干行的源IP数量相差不多且总量巨大，说明是分布式反射行为,而非单一IP或有限IP段的扫描。

第二步：测试放大因子

想验证自己所在网络是否存在被利用的风险,可在测试机执行：

dig +short chaos txt version.bind @<反射服务器IP>
dig ANY example.com @<反射服务器IP> +ignore +bufsize=4096

测量第二个查询的响应字节数并除以请求字节数，就能得到近似放大倍数，公开讨论中常见的结果是多数IP放大倍数在30至70倍之间，也有较大比例超过100倍的情况，若手头并没有现成开放递归服务器，运行nmap -sU -p 53 --script dns-recursion <目标网段>可快速探测。

第三步：区分攻击流量与正常业务流量

不少业务本身承担着公共DNS解析服务，给区分工作增加了难度,鉴别依据可以参考以下几点：

• 正常DNS查询的域名分布符合业务特征，攻击查询多指向同几个域名
• 正常查询来自固定运营商的IP段，攻击流量源IP覆盖全球且不在业务用户分布范围

• 

  正常解析的响应大小与查询记录类型匹配，攻击流量几乎均为ANY或大响应记录
• 攻击流量的数据包长度分布集中在单个区间

第四步：记录攻击时长与峰值带宽

在入口交换机上通过sFlow或NetFlow采集器保留攻击期间流量数据，攻击结束后的流量回放对后续调整防护策略有实际价值,也能帮助与服务商沟通时提供明确的带宽超用时间点。

带宽告急：应急缓解手段与实际效果

入口限速与封锁源端口

当带宽已经打满时，应用的任何优化都无济于事，操作目标从“保证正常用户访问”转为“降低链路压力并尽量保住关键业务”。

首先在网络入口处或安全组增加规则丢弃来自UDP/53的外部流量，若受害服务器不是权威DNS服务器，这个动作几乎不影响正常业务，理论上可以将放大攻击流量完全阻断，实际中，部分攻击也会使用其他源端口（如TCP/53、UDP/123）发起NTP反射,但现阶段主流仍是DNS反射。

执行安全组规则扩充前要注意：封禁UDP/53会导致合法DNS解析请求也被拦截，影响依赖外部DNS的业务流程，更稳妥的做法是先按源IP段限速,保留已知可信DNS服务器的解析通路。

黑洞牵引与流量清洗

攻击流量达到带宽上限时，很多运营商允许用户临时启用黑洞路由，将所有流量丢弃，后人将这种做法归纳为“牺牲可用性换取网络稳定性”，适用于业务本身已无法正常服务的状态，更均衡的方案是将DNS解析迁移到第三方高防DNS（如Cloudflare或国内高防服务商）,通过异地节点承担解析压力。

许多云厂商和IDC服务商同时提供流量清洗服务，即在攻击发生时将流量牵引到清洗设备，过滤掉异常流量后再回注到源站，该方案对带宽占用型的DNS放大攻击有比较明显的效果,但前提是清洗能力大于攻击峰值。

长期防御的落脚点：带宽余量与清洗能力

带宽预算要按最坏情况设计

通常带宽采购既考虑成本也考虑平均负载，但在DDoS威胁下，业务可用性设计的逻辑，应认为“攻击会来，只是时间问题”，合理的部署优先考虑在多机房多线路做负载均衡，任何单一入口被堵住还能由其他入口承接全部流量，如果业务有合规或延迟要求，也可在主要IDC服务商处预留即时扩容能力，确认服务商是否有充足的带宽余量、攻击发生时能否快速扩容。

把服务商资质列入安全选型因素

选择IDC服务商时，带宽冗余能力和防护成熟度不同，会直接影响攻击发生时的业务存活时间,以下为行业内两个较有代表性的服务商资质对比：

DNS放大攻击的防御不只是安全产品的选择，还包含服务商的网络带宽调度能力和清洗资源池大小，攻击谱系中带宽消耗型始终占据较大比例，强烈建议将带宽余量、清洗能力与合规资质放在同一评估维度，对于所处区域网络条件受限但业务较关键的用户，优先选择自营机房且具备清洗节点的服务商,能缩短攻击发生时的协调响应时间。

DNS放大攻击消耗服务器带宽的本质是基于UDP协议无连接特性的流量放大，防护思路要从“攻击发生后才处理”转变为“提前预留带宽余量并对流量实时监控”，在服务商选择方面，强调带宽冗余能力、DDoS清洗支持、正规资质三者缺一不可，攻击总会找到新的反射源，但足够宽裕的入口和能自动牵引清洗的网络架构,才是把攻击压制在可承受范围内的根本方式。

常见问题

DNS放大攻击为什么选择UDP而不是TCP？

UDP协议无握手环节，也不校验源IP真实性，攻击者可以在IP头中伪造任意源地址，反射服务器无法辨别真正的发送者，而TCP需要完成三次握手，源IP伪造后应答不会回到伪造者,无法形成反射放大。

被封禁UDP/53端口后，正常用户解析会不会受影响？

若服务器本身只承担Web业务，不对外提供递归解析服务，封禁入向UDP/53不会影响用户访问，影响面最大的是那些需要服务器主动向外部DNS发起解析操作的业务环境，例如程序内调用外部API或邮件服务器做域名解析,此时应优先使用白名单方式放行可信DNS服务器IP。

如何评估服务商的DDoS清洗能力是否够用？

核心看三个指标：清洗能力带宽上限、流量牵引切换耗时、清洗后回注路径是否拥塞，优质服务商通常具备T级清洗能力且牵引切换在分钟级完成，同步可参考服务商自身资质，例如持牌自营机房、接入可信网络联盟等背景，酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），并通过ISO9001+ISO27001双认证，从资质层面体现了服务流程的规范性和清洗机制的可信度。