当DNS辅服务器不可用时，最直接的解决办法是：先检查主辅同步是否中断，再确认辅服务器的防火墙和递归权限配置，最后通过dig或nslookup命令验证解析响应，若短期无法恢复，可临时将辅服务器IP从NS记录中摘除，避免解析超时拖垮整体体验。
辅服务器挂掉之前，先搞清楚它到底哪里疼
很多站长遇到辅服务器不可用，第一反应是重启服务器，但重启往往解决不了根上的问题，DNS辅服务器的职责很简单：从主服务器拉取区域数据，然后对外提供解析，它本身不产生数据，所以它的“不可用”基本可以归类为三种情况：同步断了、服务没起来、网络被挡了。
先说同步断了，辅服务器靠AXFR或IXFR协议从主服务器拉数据，如果主服务器上的allow-transfer没配上辅服务器的IP，或者TSIG密钥对不上，辅服务器就会一直拿不到数据，这时候辅服务器虽然活着，但它手里的区域文件是旧的，甚至根本没有区域文件，对外解析自然失败，你可以登录辅服务器，查看系统日志里有没有transfer failed或者zone expired之类的报错，如果有,基本就能锁定是同步问题。
再说服务没起来，named或者unbound这类DNS服务进程可能因为配置语法错误、端口被占用、权限不对而崩溃，别急着怀疑硬件，先跑一下named-checkconf检查配置，再看看systemctl status named的状态，这一步能过滤掉很大一部分“假故障”。
网络被挡，辅服务器本身没问题，但防火墙策略把TCP 53端口（区域传输用）或UDP 53端口（递归查询用）给堵了，很多运维人员只放行了UDP 53，忘了TCP 53，结果辅服务器能ping通,但区域传输死活不成功。
如何快速确认辅服务器是不是真的挂了
与其猜，不如直接测，这里有一套简单的排查流程，按顺序走一遍,基本能定位问题。
第一步：检查进程状态。 登录辅服务器，执行ps aux | grep named或者systemctl status named，确认进程在跑，如果进程没了，看日志,大概率是配置问题。
第二步：检查区域文件是否最新。 在辅服务器上执行ls -l /var/named/slaves/（路径因系统而异），看区域文件的修改时间，如果这个时间跟主服务器上的序列号对不上，说明同步有问题，更直接的办法是在辅服务器本地执行dig @127.0.0.1 example.com SOA,看返回的序列号跟主服务器是否一致。
第三步：测试区域传输。 在主服务器上执行dig @辅服务器IP example.com AXFR，如果返回Transfer failed，说明辅服务器拒绝了传输请求，问题在主服务器的allow-transfer配置或者TSIG密钥上。
第四步：模拟外部查询。 找一台跟辅服务器不同网段的机器，执行dig @辅服务器IP example.com，看响应时间，如果超时，检查防火墙；如果返回
REFUSED，检查辅服务器的allow-query配置。
这套流程走完，你基本能判断辅服务器到底是“死”了还是“装死”。多数情况下，辅服务器不可用不是硬件故障，而是配置漂移或同步中断，这类问题不需要重启机器,改配置就能解决。
辅服务器不可用的常见原因和对应解法
主辅同步失败：最容易被忽视的隐形杀手
主辅同步失败的特点是：辅服务器进程正常、网络通畅、防火墙也放行了，但区域数据就是不同步,这通常由以下原因导致：
- 主服务器的
allow-transfer没包含辅服务器IP，检查主服务器的named.conf，确认allow-transfer { 辅服务器IP; };这一行存在且生效。 - TSIG密钥不匹配，如果用了TSIG认证，两边的key名称和secret必须完全一致,一个字符的差异都会导致握手失败。
- 区域序列号没递增，每次修改主服务器区域文件后，必须手动或通过
rndc reload递增SOA记录里的序列号，否则辅服务器会认为数据没变化,拒绝重新传输。
解决方法是：在主服务器上执行rndc reload强制重载区域，然后在辅服务器上执行rndc retransfer example.com强制重新拉取，如果还不行，检查两边日志,确认具体的报错信息。
递归查询被关闭或限制
辅服务器不仅要提供权威解析，很多时候还要承担内网客户端的递归查询，如果辅服务器配置了recursion no，或者allow-recursion只允许了特定网段，外部用户查询时会直接收到REFUSED响应,表现跟服务器不可用几乎一样。
行业共识认为，辅服务器的递归策略应该单独规划：对公网关闭递归，只做权威应答；对内网开放递归，并限制源地址范围，这样既安全,又不会因为递归查询风暴把辅服务器打垮。
防火墙和云安全组策略遗漏
如果你是云服务器，除了操作系统自带的firewalld或iptables，还要检查云控制台里的安全组规则，常见的坑是：安全组只放行了TCP 53，但DNS查询走的是UDP 53；或者放行了入方向，但出方向的TCP 53没放行,导致辅服务器无法主动连接主服务器拉取数据。
排查技巧：在辅服务器上执行tcpdump -i eth0 port 53，然后从外部发起一次查询，如果看到请求到达但没响应，问题在本地防火墙或DNS配置；如果连请求都没看到,问题在云安全组或路由。
辅服务器不可用时的临时替代方案
辅服务器挂掉，如果主服务器还能扛住压力，可以暂缓处理；但如果主服务器本身性能一般，或者流量峰值明显,那就得先止血。
- 从NS记录中临时摘除辅服务器，在域名注册商的DNS管理面板里，把辅服务器的NS记录删掉，只保留主服务器的NS记录，这样解析请求就不会再往辅服务器上发了,用户侧感知不到超时或失败。
- 利用DNS轮询或GeoDNS，如果你的主服务器支持多IP应答，可以临时把辅服务器的IP加到主服务器的A记录里，通过轮询分摊流量，但要注意，这种做法会让主服务器同时承担权威解析和流量分发,对性能有额外要求。
- 临时把辅服务器IP改为CNAME指向，如果你有备用服务器，可以快速搭建一个临时的DNS服务，然后把辅服务器的NS记录指向这台备用机器,前提是备用机器上已经有同步好的区域数据。
这些方案都是临时手段，核心思路是别让辅服务器的故障拖累整个域名的解析成功率,等到辅服务器修复后再恢复NS记录。
长期预防：辅服务器别当“一次性用品”
辅服务器不可用，很多时候是因为部署完就没管过，DNS主辅同步需要持续维护,建议从以下几个方面做预防：
配置自动监控和告警
不要等用户投诉了才发现辅服务器挂了，用脚本定时检查辅服务器的SOA序列号，跟主服务器做比对，不一致就告警，或者用外部监控服务，比如DNSViz或自建的Prometheus + blackbox_exporter，每5分钟从公网发起一次dig查询,响应超时或RCODE异常就触发通知。
定期演练主辅切换
很多团队从来没做过主辅切换演练，真出问题时手忙脚乱，建议每季度做一次：把主服务器的DNS服务停掉，观察辅服务器能否独立承担解析；再把辅服务器停掉，观察主服务器能否扛住全部流量。演练过程中记录切换耗时和解析成功率,这些数据在后续优化时很有价值。
部署位置要分散
如果辅服务器跟主服务器在同一机房、同一运营商，那它就失去了“冗余”的意义，辅服务器的价值在于不同网络路径上的容灾能力，所以尽量把辅服务器部署在另一个机房或另一家云厂商，这样即使主服务器所在的网络出口出问题,辅服务器依然能响应来自其他网络的查询。
定期检查同步日志
别只看监控面板，日志里的细节能提前暴露隐患，辅服务器的系统日志里如果频繁出现zone transfer failed或者connection timed out，说明网络链路质量有问题，或者主服务器负载过高导致传输超时，这类问题如果放任不管,迟早会演变成辅服务器完全不可用。
DNS辅服务器不可用时的排查顺序（速查表）
| 症状 | 排查方向 | 常用命令 |
|---|---|---|
| 查询超时 | 防火墙、安全组、路由 | telnet 辅服务器IP 53 |
| 返回REFUSED | 递归权限、allow-query配置 | dig @辅服务器IP 域名 |
| 返回SERVFAIL | 区域数据损坏或同步中断 | tail -f /var/log/messages |
| 区域文件旧 | 主辅同步失败 | dig @辅服务器IP 域名 SOA |
| 进程崩溃 | 配置语法错误、端口冲突 | named-checkconf |
什么时候该考虑彻底重建辅服务器
如果辅服务器的配置经过多次修改已经变得混乱不堪，或者系统版本太老、安全补丁缺失，与其花时间排错，不如直接重建,重建辅服务器的步骤很简单：
- 备份旧的配置文件（主要是named.conf和区域文件目录）。
- 部署新的服务器实例,安装最新版bind或unbound。
- 把主服务器的
allow-transfer更新为新辅服务器IP。 - 在新辅服务器上配置区域声明，启动服务,观察日志确认同步完成。
- 更新域名NS记录,把旧辅服务器IP替换为新IP。
- 等待TTL过期后,观察解析流量是否平滑切换。
重建辅服务器的成本远低于长期维护一台“带病运行”的机器，如果你发现辅服务器经常出问题且根因不明,直接重建往往更省心。
辅服务器和主服务器同时不可用的极端情况
这种情况很少见，但一旦发生，影响面极大，如果你的主辅服务器同时不可用，而域名NS记录里只配置了这两台，那整个域名将无法解析，邮件、网站、API全部中断。
应急方案是：提前在域名注册商处配置好DNS托管服务，很多注册商自带免费的DNS托管，你可以把主辅服务器的区域数据同步一份到注册商的DNS上，这样即使自建的两台DNS全部宕机，注册商的DNS依然能响应查询，这个兜底方案成本几乎为零,但能救命。
另一个建议是：给辅服务器配置独立的DNS服务商，比如用华为云DNS或简米云DNS作为辅服务器，跟自建的主服务器做区域传输，这样既保留了自建主服务器的灵活性,又获得了云厂商的SLA保障。
常见问题
辅服务器解析正常但延迟很高，是怎么回事？
延迟高通常不是辅服务器本身的问题，而是网络链路质量差，辅服务器所在机房的带宽、路由跳数、跨运营商互联都会影响响应速度，你可以在辅服务器上执行ping 主服务器IP看延迟，如果延迟超过50ms，说明跨机房链路有问题，检查辅服务器的并发连接数，如果连接数打满,也会导致响应变慢。
辅服务器拒绝了我们的区域传输请求，怎么排查？
先确认主服务器上的allow-transfer配置，看看是否包含了辅服务器的IP，如果配置了TSIG密钥，检查两边的key名称和secret是否一致，然后在主服务器上执行rndc notify或者rndc reload，再在辅服务器上手动执行rndc retransfer 域名，同时观察两边日志，最常见的错误是主服务器的allow-transfer里写的是辅服务器的旧IP,而辅服务器已经换过IP了。
辅服务器对公网开放递归查询安全吗？
不安全，开放递归查询的DNS服务器很容易被利用做DDoS反射攻击，一旦被攻击者盯上，辅服务器不仅自身会被打垮，还可能连累主服务器被连带封禁。辅服务器对公网应该只开放权威解析，递归查询只允许内网特定网段使用，这是DNS安全的基础要求,没有任何例外理由。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/dns%e8%be%85%e6%9c%8d%e5%8a%a1%e5%99%a8%e4%b8%8d%e5%8f%af%e7%94%a8%e6%80%8e%e4%b9%88%e8%a7%a3%e5%86%b3%ef%bc%8c%e6%98%af%e4%bb%80%e4%b9%88%e5%8e%9f%e5%9b%a0%e5%af%bc%e8%87%b4%e7%9a%84/
