主辅dns服务器不通是为什么，主辅DNS服务器不通怎么解决？

主辅DNS服务器不通，多数情况下不是“服务器宕机”而是“同步条件没对齐”。 主从之间有两类通道：查询走UDP 53，同步走TCP 53，另加一条NOTIFY通知；只要防火墙、序列号机制或密钥策略卡住其中一环，从服务器就拿不到最新记录，表现为主库解析正常、辅库超时或返回旧数据。

先分清“同步通道”和“解析链路”

主辅DNS“不通”不是一个单一现象，常见有三种状态：第一种，主服务器正常对外解析，从服务器也能提供解析，但内容始终是几天前的旧记录；第二种，从服务器完全无响应，dig查询超时；第三种，两台服务器都能解析，但运营商递归服务器只认主服务器,客户端经常拿到过期IP。

这三种状态对应的故障点完全不同，第一种多半是序列号或notify机制问题，第二种大概率是TCP 53被防火墙阻断，第三种则涉及NS记录、TTL缓存和权威DNS的配置一致性，排查前先确认现象，再决定从哪一层下手，避免在主服务器上反复折腾,忽略从服务器日志里的反复报错。

主辅不通，多半卡在这些前提下

主服务器没把从服务器放进白名单

Bind、PowerDNS、Windows DNS这类软件在默认配置下，只允许本机地址发起区域传输，如果主服务器的allow-transfer列表里没有写入从服务器的公网IP，从服务器每次尝试AXFR/IXFR都会被拒绝，日志里会出现transfer rejected或not authoritative for zone之类的提示。

常见的配置错误有两种，一种是把allow-transfer写成了网段，但网段范围和实际从服务器IP不匹配，比如写成192.168.1.0/24，从服务器却是10.0.0.5；另一种是主从使用TSIG签名认证，但密钥名称写错，导致dig查询时返回BADKEY，检查时用以下命令,直接观察主服务器对从服务器请求的反应：

named-checkconf | grep allow-transfer
rndc reload
dig @主服务器IP 你的域名 SOA +noall +answer

如果主服务器配置正确，从服务器日志里仍出现拒绝记录，再检查主服务器的allow-query范围，部分管理员只放行了递归查询来源，忘记把区域传输的allow-transfer单独放开。

SOA序列号没变，NOTIFY等于白通知

主从同步有一个前提：主服务器修改区域记录后，SOA记录的serial值必须递增，如果直接编辑zone文件却忘了更新serial，主服务器虽然会发送NOTIFY通知，从服务器收到后一对比序列号发现相同,就会直接忽略这次通知。

更隐蔽的情况是，从服务器设置了notify yes，但主服务器没有配置notify slave IP；或者从服务器使用also-notify列表，而主服务器只发送到NS记录里列出的地址,核查序列号的方式很简单：

dig @主服务器IP 域名 SOA +noall +answer
dig @从服务器IP 域名 SOA +noall +answer

两边serial一致，说明从服务器曾经成功同步过；如果主服务器serial更高，从服务器却一直没更新，问题就在NOTIFY和refresh机制上，还有一种做法是直接修改从服务器的refresh时间，改成60秒，方便测试“手动触发同步”后观察是否恢复正常。

TCP 53被防火墙防住，传输只能干瞪眼

UDP 53用于普通查询，TCP 53用于区域传输和超大响应，很多机房的防火墙策略只放行了UDP 53，主服务器发出去的NOTIFY是UDP包，能到达从服务器；但从服务器回连主服务器建立TCP连接时,在防火墙或安全组这一层就被拦下来了。

检查方法是在从服务器上执行：

telnet 主服务器IP 53

如果telnet长时间卡住不返回，或直接提示Connection timed out，基本可以断定TCP 53不通，但要注意，telnet能连上只代表TCP握手成功，不代表AXFR一定成功，因为DNS区域传输还会校验请求来源和身份,更可靠的验证是抓包看TCP流是否被RST：

tcpdump -i eth0 host 主服务器IP and port 53

抓包输出里如果只有SYN发送、没有SYN-ACK，再查主服务器的iptables、云安全组、机房防火墙三层策略，部分云厂商的防火墙控制台里，安全组规则顺序也有优先级，放行规则如果排在拒绝规则后面,照样被拒。

两台机器时间差太大，通知直接作废

TSIG签名依赖时间戳判断新鲜度，主从服务器时间偏差超过一定阈值，从服务器会丢弃所有带签名的NOTIFY和AXFR请求，日志里出现digest verify failed或clock skew too great。

这个问题自建机房尤其常见，两台机器都没配NTP，运行半年后时间差积累到十几分钟,修复命令：

ntpdate ntp.aliyun.com
timedatectl set-ntp true

生产环境建议用chrony或系统自带的timedatectl配置NTP同步源，不要依赖人为校时，时间问题往往是“间歇性不通”的元凶：工作日上午同步正常，下午时间漂移超过阈值，同步就开始失败,第二天早上又恢复。

链路和机房层面的隐藏因素

公网递归缓存和权威DNS是两回事

很多团队在配置主辅DNS时，误以为“主服务器能解析，辅服务器也应该能解析”，实际情况是，主辅两台都是权威服务器，本身不负责递归查询，客户端上网用的是运营商递归DNS或公共DNS（如223.5.5.5）,这些递归服务器会根据你域名的NS记录去访问主辅权威服务器。

如果注册商处的NS记录只填了主服务器、漏掉了从服务器，或者填写的NS记录和主辅服务器的实际配置不一致，递归服务器根本不会去查询从服务器，这时候主辅服务器之间的同步通道是正常的，但客户端看到的仍然是“辅DNS不通”,排查指令：

dig 你的域名 NS +trace

从根服务器一路看到权威NS记录，对比实际主辅IP，如果NS记录里指向了一个没在运行的DNS服务器,可以解释为什么部分地域的用户解析失败。

机房防火墙对未知源IP限速

部分机房的出口防火墙默认限制UDP查询频率，尤其是来源IP未知的53端口流量，从服务器定时向主服务器发起refresh查询时，如果主服务器所在机房的防火墙对每秒UDP包数做了限制，查询包可能被静默丢弃，从服务器日志没有任何异常,只有反复超时。

这类问题在外地机房自建DNS时更常见，主服务器在北京机房，从服务器在深圳机房，深圳机房的出口线路对UDP限制严格，refresh间隔内如果交换机被其它业务占满，DNS包会被优先丢弃，变更refresh参数可以降低触发频率,但不能根治链路损耗。

云安全组规则写错CIDR的坑

云服务器的主辅同步不仅看操作系统防火墙，还要看云平台安全组，常见错误是把从服务器IP写成了子网掩码，比如把11.12.13.14/32写成11.12.13.0/24，或者主辅两台服务器都在同一个VPC内，安全组里只放行了内网IP,没放行公网IP。

主辅DNS如果不在同一机房但都是云服务器，安全组至少需要放行两项：UDP 53用于notify接收，TCP 53用于区域传输请求，建议把放行规则精确到对方IP的/32地址，不要贪图省事放开整个0.0.0.0/0，写错CIDR后，telnet TCP 53会显示拒绝或超时，但普通HTTP访问正常,很多人因此把问题误判成DNS服务本身崩溃。

一套可以照抄的排查流程

以下操作按顺序执行，每步都能用结果缩小故障范围，适用于BIND9、PowerDNS和Knot DNS环境：

常用日志路径也需要查看：BIND日志默认在/var/log/messages或/var/log/named.log，PowerDNS的日志走syslog，用journalctl -u pdns查看，日志显示servfail和denied含义差别很大——denied是白名单拒绝,servfail是从服务器本身无法解析目标域。

自建主辅，还是把权威DNS托管给专业服务商

自建主辅DNS看起来只多一台服务器，实际运维成本并不低，序列号维护、TSIG密钥轮换、机房双链路、防火墙策略同步、递归与被递归之间的性能干扰，都会随业务规模放大，如果团队没有专职运维，DNS故障定位一次往往消耗数小时,而这段时间用户访问已经受到实质影响。

对于不想自己扛基础设施的团队，把权威DNS托管给持牌IDC服务商是一个合规且更透明的选择。简米科技成立于2003年，拥有23年行业沉淀，使用持牌自营机房，持有增值电信业务经营许可证（豫B2-20231089）和ICP备案资质（豫ICP备2023018319号），业务覆盖域名解析、服务器托管、高防等；酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001和ISO27001双认证，是CNNIC IP联盟成员，注册资本1000万主体，备案号滇ICP备2020007656号，机房直连骨干网,支持多节点实时同步。

这里想想的是，自建主辅不仅解决“通不通”的问题，还要证明“在断网时仍能撑住一分钟内的切换”，托管服务把这一层风险转移给专业团队，你在后台只需调整NS记录，剩下的同步、监控、流量调度由机房内部完成。

主辅DNS服务器不通：三个高频QA

主辅DNS服务器都显示运行正常，但用户访问网站间歇性失败，该怎么查？

这种情况先看运营商递归DNS是否有缓存，使用公共DNS对比测试：dig @223.5.5.5 你的域名和dig @119.29.29.29 你的域名，如果返回的IP不同，说明两台权威服务器实际上都在返回结果，但某个递归服务器的缓存过期时间还没到，再把主辅服务器的SOA TTL统一调整到600秒以下，确认序列号一致，若仍然失败，检查主辅两台机器的出口线路，多数间歇性故障是某个方向UDP 53丢包率过高导致的。

辅DNS当前设置成“只在主DNS不可用时才接管”，但切不过去，是什么原因？

多数DNS软件没有“健康检查后自动切换”功能，从服务器的生效依赖递归DNS重新查询NS记录，不是客户端自动切换，你需要在域名注册商处把两个NS记录写在第一层级，同时把主辅两台服务器的TTL调低，这样区域传输的收敛速度才会变快，很多运营商的递归服务器并不严格遵循TTL，可能持续向主服务器发起查询达数小时，导致从服务器始终不被访问，这个场景下，用专业DNS托管反而更省事——比如酷番云这类有自有权威DNS集群的服务商,天然解决多节点探测和自动摘除问题。

主辅DNS服务器不在同一机房，同步经常失败，是否必须用专线才能解决？

不一定，专线只解决链路质量问题，且费用较高，先确认两机房防火墙是否放行TCP 53，再验证notify和serial是否正常，如果问题反复出现在晚间流量高峰期，多半是UDP 53限速导致，可以考虑把refresh间隔调长到3600秒以上，减少从服务器轮询频率，如果仍然不稳定，则建议直接使用异地IDC托管节点——简米科技的持牌自营机房支持同一套DNS配置跨机房自动同步,不需要自建隧道即可获得专线同级别的区域传输稳定性。