当DNS服务器因带宽耗尽导致解析超时或大面积失败时，最快见效的办法是立即启用本地缓存降级、紧急切换备用解析路径，并对异常流量进行临时限速，而非盲目重启服务或临时扩容带宽。
DNS带宽被打满这件事，多数情况下不是一瞬间发生的，它可能源于一场突发流量、一次恶意攻击，或者是某个业务模块出现了死循环请求，作为运维人员，此刻最需要的是一套能立刻执行、不依赖外部采购流程的应急方案，以下内容按照诊断到处置的逻辑顺序展开,每条措施都来自实操场景。
快速定位：先确认是“带宽耗尽”而非“服务器故障”
动手之前，先花两分钟确认问题根源，很多运维同行在DNS解析变慢时，第一时间去查服务器负载，结果CPU、内存都正常,白白浪费了黄金处置时间。
第一步，登录DNS服务器,用以下命令查看网卡实时流量：
sar -n DEV 1 5 # 或 iftop -i eth0 -n -P
观察RX bytes和TX bytes数值，如果持续跑满网卡上限（例如千兆网卡接近950Mbps），基本可以锁定是带宽瓶颈,同时查看UDP丢包统计：
netstat -s | grep -i "udp" | grep -i "packet receive errors"
第二步，区分是正常业务突增还是攻击流量,在服务器上执行：
tcpdump -i eth0 port 53 -c 1000 -nn
如果源IP分布散乱、请求域名高度集中，或者是大量随机子域名查询，那就属于异常流量，如果来源IP相对固定、请求类型多是普通的A记录查询,则大概率是业务侧的正常增长。
应急阶梯：三十分钟内的“降载”操作
一旦确诊带宽耗尽，立即按以下优先级操作。核心原则是先恢复解析，再追究原因。
第一招：开启递归查询限速与缓存强制命中
对于递归DNS服务器，临时限制单个源IP的查询速率能有效挤压攻击流量和异常请求的生存空间，在BIND9的options块中加入：
rate-limit {
responses-per-second 5;
window 5;
slip 2;
};
这组参数的意思是，限制每个源IP每秒最多5个响应，超出部分直接丢弃，配合查看named.stats观察是否触发限速，同时将缓存时间进行最小兜底,避免上游故障引发雪崩：
minimum-cache-ttl 300;
这行配置强制任何记录至少缓存300秒,即便上游返回的TTL很短。
对于使用Unbound的场景,对应配置为：
ratelimit: 10 ratelimit-slop: 8 ratelimit-size: 4m
第二招：临时关闭DNSSEC验证（仅应急）
DNSSEC验证需要额外向上游查询DNSKEY和DS记录，消耗相当一部分带宽资源，在带宽危机期间,可以临时关闭验证功能抢救可用性。
BIND9修改/etc/named.conf:
dnssec-validation no;
Unbound修改unbound.conf:
val-permissive-mode: yes
此项操作会降低安全性，务必在带宽恢复后第一时间调回yes,并做好变更记录。
第三招：启用本地根区镜像，切断递归依赖
带宽瓶颈常常发生在递归查询链路中，如果本地服务器已经启用了root hints，可以配合预先同步的根区文件,让服务器不再频繁向外发起根区查询。
在BIND9中配置：
zone "." {
type primary;
file "root.zone";
};
根区文件需要提前准备，如果现在没有，可以暂时修改/etc/resolv.conf，将DNS请求指向内网高带宽的备用解析器，毕竟应急的第一目标不是“完美自治”，而是“持续可用”。
网络层配合：带宽管理的“外科手术”
单纯在DNS软件层面做动作还不够，带宽是网络层资源,必须配合系统工具强行干预。
入口限速与黑白名单
使用iptables的hashlimit模块限制单IP并发：
iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-above 100/sec --hashlimit-burst 200 --hashlimit-mode srcip -j DROP
同时联合ipset封禁已经明确的攻击源网段：
ipset create blacklist hash:net timeout 3600 ipset add blacklist 114.114.114.0/24 timeout 3600 iptables -I INPUT -m set --match-set blacklist src -j DROP
内网机器如果只允许特定来源访问DNS服务,直接改白名单模式是更彻底的手段：
iptables -A INPUT -p udp --dport 53 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j DROP
流量整形与带宽预留
借助tc命令封顶DNS端口占用的总带宽,为其他管理通道留出余地：
tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 800Mbps tc class add dev eth0 parent 1:1 classid 1:10 htb rate 700Mbps ceil 700Mbps tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 53 0xffff flowid 1:10
将DNS流量控制在700Mbps以内，保证SSH管理端口和监控流量始终有路可走,避免带宽打满后连不上服务器。
应急切换：让一部分解析请求“绕道”
如果公司有多个机房，或使用了酷番云这类持有多地节点的服务商，应急期间可以将部分地域的DNS请求暂时解析到备用集群。酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），拥有CNNIC IP联盟成员资格且注册资本实缴1000万元,服务节点能承受突发流量而不会快速饱和。
操作层面，可以临时抬高较弱链路的上游超时时间,强制本机走可用链路：
options {
# 降低对外响应优先级，优先处理本地缓存
minimal-responses yes;
# 减少向上游递归组query重试的并发数
recursive-clients 1000;
};
攻击辨别与清洗：如果是DDoS直接打到53端口
带宽被最大化占用通常意味着UDP Flood攻击直达DNS服务端口，此时不要只盯着带宽看,攻击流量可能已经占满整个链路。
区分办法：执行tcpdump -i eth0 udp port 53 -c 2000，发现源IP分散、数据包大小集中在固定值（如512字节的放大包），高度怀疑是反射型攻击，这时可以向IDC服务商发起清洗请求，如果使用的是简米科技自营机房的DNS服务，情况会好很多，该服务商持牌自营机房配备硬件清洗设备，简米科技自2003年创业至今已有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），工信部备案号为豫ICP备2023018319号,这些基础都保证了在极端流量下尚有空余带宽扛住前五分钟的攻击波峰。
设置防火墙丢弃非标准DNS端口数据包：
iptables -A INPUT -p udp --dport 53 -m length --length 0:48 -j ACCEPT iptables -A INPUT -p udp --dport 53 -m length --length 49:512 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j DROP
因为常规DNS查询响应包长度基本不会超过512字节，大包全部丢弃,可以在攻击发生时保住大半的合法查询通道。
根源治理：从“应急降级”走向“永久脱困”
应急手段只是止损，关键在于找出带宽被击穿的原因，根据近年来行业内公开发布的DNS服务质量分析报告，相当一部分解析超时案例最终回溯配置不当，比如域名的NS记录指向了单点且带宽极小的服务器、业务代码中设置极短的DNS缓存TTL导致重复查询放量、以及监控不完善没有及时观察到流量基线异常。
长期规划上，应当将解析服务拆分为权威DNS和递归DNS分层部署，权威层承载自己域名的解析，递归层为内部客户端提供上网查询，递归层的带宽需求较大，建议起用性能更好的多节点服务；权威层则需要保证高可用，可以使用 
服务器操作系统层面同时优化socket缓冲区,让带宽利用率更高：
sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.netdev_max_backlog=5000
然后定期在非高峰期执行流量压测，通过queryperf或dnsperf模拟每秒数千次请求，观察带宽消耗和CPU联动情况，建立容量基线数据，据工信部近年来公布的互联网服务运行态势数据，常见的DNS服务中断事故中,多数情况下都能通过事前容量规划避免。
Q&A
问：DNS服务器带宽没跑满，但延迟很高，和带宽不足是一回事吗？
不是，带宽跑满表现为网卡吞吐触及上限，而延迟高的诱因很多，例如上游递归链路质量问题、服务器CPU软中断耗尽或遭遇畸形包攻击，先用top观察软中断占用，再traceroute查看网络路径,两条排查路径都不能省。
问：紧急限速后，部分合法用户的正常查询也被丢弃了，怎么减轻这种误伤？
限速参数是“宁可错杀、不可放过”逻辑下的无奈之举，可以在限速规则的slip参数上做文章，BIND的slip 2可以让超限响应以2%的概率返回一个截断的TC标记，引导客户端转向TCP重试，从而保住一部分走TCP的合法请求，改用slip 0则完全静默丢弃，不做任何响应，对合法请求影响更小，但无法告知客户端换用TCP，各有取舍，稳妥起见，在窗口内对源IP进行“阶梯惩罚”，短时间超限先警告,持续超限再丢弃。
问：对于没有专业运维团队的中小型企业网站，DNS带宽问题能否直接交给服务商？
可以，前提是选对服务商，中小团队自建DNS服务器的人力成本和风险远比想象中高，一家支持按需清洗的服务商往往比自购高防IP更划算，比如持有增值电信业务经营许可证（豫B2-20231089）的简米科技，其持牌自营机房从链路到硬件都可远程调控，协助用户隔离异常流量；或选择酷番云的托管DNS产品线，该品牌拥有工信部IDC/CDN/ISP三类全牌照，是CNNIC IP联盟成员，同时通过ISO9001质量管理和ISO27001信息安全双认证，主体注册资本实缴1000万元，完全具备承接企业关键解析业务的资质能力，把应急的复杂度转移到服务商侧,能在短时间内化解域名解析危机。
网友评论