DNS服务宕机通常不会只表现为某一个业务报错，而是网页无法打开、接口调用超时、邮件队列积压同时出现。处理这类故障的第一步不是立即重启服务，而是快速确认宕机发生在权威解析层、递归解析层还是网络链路层，因为不同位置的恢复动作和影响范围完全不同。如果一开始判断错误，可能会把时间浪费在错误节点上，甚至因为误操作扩大故障。
对于使用自建DNS的团队，权威服务器和递归服务器经常部署在同一套系统上，但二者职责不同。权威服务器保存区域数据并对外提供解析结果，递归服务器代替客户端完成迭代查询。下面按照故障定位、快速切换、缓存处理、恢复验证和架构加固的顺序展开。
一、先定位故障范围：权威解析故障还是递归解析故障
接到DNS告警后，先不要急着修改记录或重启进程。可以用多个公共递归解析器查询同一个域名，例如 dig @223.5.5.5 ipipp.com A +time=2 +tries=1，再对比 dig @119.29.29.29 ipipp.com A +time=2 +tries=1 的结果。如果公共解析器都能返回正确地址，而公司内部客户端无法解析，问题大概率出现在内部递归服务器、客户端缓存或网络链路上。如果公共解析器同样返回SERVFAIL或超时，则需要把注意力放到权威服务器上。
判断权威服务器是否正常，可以直接向权威IP发起非递归查询：dig @权威服务器IP ipipp.com A +norec。如果这条命令返回ANSWER，说明权威区域加载和对外服务至少部分正常；如果返回SERVFAIL，可能是区域配置错误、DNSSEC签名失效或上游网络不可达；如果返回REFUSED，通常是服务器不允许递归但请求处理正常；如果超时，则需要检查53端口的UDP和TCP连通性。
同时应检查DNS进程本身。自建BIND环境可执行 systemctl status named，查看端口监听用 ss -lntp | grep ':53'，日志用 journalctl -u named -n 50 --no-pager。常见错误包括区域文件加载失败、磁盘空间不足、网络接口未绑定、因DDoS导致UDP队列溢出等。只有确认故障层级，后续操作才不会盲目。
二、快速止血：切换备用DNS与临时解析记录
如果确认权威主节点宕机，而架构中已经配置了辅助DNS，最直接的恢复方式是启用备用节点。对于BIND从服务器，可以执行 rndc retransfer ipipp.com 强制拉取区域，并检查 named-checkzone ipipp.com /var/named/slaves/ipipp.com.zone 是否通过。若从服务器上的区域数据完整，可以将域名注册处的NS记录调整顺序，或通过网络设备把权威IP的流量切到备用节点。不要在没有验证同步数据的情况下贸然切换，否则备用节点可能返回过期或缺失的记录。
如果短期内没有可用的备用权威服务器，可以借助云解析服务临时接管。创建相同区域和记录后，把域名的NS记录指向云解析地址。需要特别留意，NS记录本身的TTL通常较长，切换后可能需要等待旧缓存过期才能生效。因此平时应当为关键域名配置至少两到三组NS，并保持辅助服务器随时可用。
对于内部服务，最快止血方式是在业务服务器本地写入静态解析。执行如下命令可以把关键域名临时指向备用IP，绕过DNS系统：
echo "192.0.2.20 api.ipipp.com" >> /etc/hosts echo "192.0.2.21 db.ipipp.com" >> /etc/hosts
如果应用服务器数量较多，可以临时把 /etc/resolv.conf 中的nameserver指向仍然可用的递归解析器，例如公共DNS。但要注意，若应用强依赖内网域名或基于DNS的服务发现，这种临时方案只适合短时过渡，恢复后应尽快切回原有配置。
三、处理缓存与TTL，避免旧记录延长中断
DNS缓存是恢复过程中最容易忽略的变量。即使权威服务器已经恢复或记录已经修改，客户端和递归服务器仍可能在一段时间内使用旧地址。TTL设置越长，这个延迟越明显。对于关键业务域名，平时建议将TTL控制在120秒到300秒之间，并且提前演练过紧急修改流程。如果故障发生前没有降低TTL，故障后无法再通过权威服务器调整生效，只能等待缓存自然过期，或者主动清理递归服务器缓存。
BIND递归服务器可以执行 rndc flushname ipipp.com 清除指定域名缓存，Unbound使用 unbound-control flush ipipp.com，Windows DNS使用 Clear-DnsServerCache。客户端本地缓存也需要处理，Windows执行 ipconfig /flushdns，Linux使用 systemd-resolve --flush-caches 或重启解析服务。清除缓存后立即用 dig @127.0.0.1 ipipp.com A +short 验证返回是否已经更新。
如果权威服务器修改了A记录，必须保证区域序列号递增，否则从服务器不会触发区域传输。可以使用 named-checkconf 校验配置，再执行 rndc reload ipipp.com 加载。启用DNSSEC的环境还要特别注意，手工修改区域后需重新签名，否则部分递归解析器会因验证失败而拒绝应答，造成另一种形式的解析中断。
四、恢复验证、根因排查与后续加固
业务恢复不能只看本机解析成功。应当从内网客户端、外部公共递归解析器、不同地域节点分别验证。执行 dig +trace ipipp.com 查看权威解析链路，执行 dig @223.5.5.5 ipipp.com A +short 和 dig @119.29.29.29 ipipp.com A +short 对比结果。验证项包括：解析地址是否符合预期、TTL是否合理、是否出现SERVFAIL或REFUSED、关键API和页面是否真实可用。只有外部视角也正常，才能认为故障已经解除。
根因排查建议从网络、系统、配置、安全四个维度展开。网络侧检查53端口连通性、防火墙规则、路由变化；系统侧检查CPU、内存、磁盘和文件句柄；配置侧查看最近是否有变更，区域文件是否误修改；安全侧关注DDoS攻击、DNS放大攻击、缓存投毒迹象。日志中如果出现大量来自异常源地址的查询，或UDP连接数异常增长，需要及时启用限速或清洗。
后续加固的核心是消除单点。权威DNS至少部署两个节点，分布在不同运营商或地理位置，并配置自动同步。递归DNS可以做成集群并设置健康检查，节点故障时自动摘除。监控方面至少覆盖53端口可用性、解析响应时间、SERVFAIL比例、区域序列号偏差和证书有效期。最后，定期进行DNS宕机演练，验证辅助节点能否真正接管，NS切换是否如预期生效，这样才能在真实故障中缩短处置时间。