域名间歇性NXDOMAIN或SERVFAIL：NS委派与Glue排查指南

直接答案

先保存失败与成功响应的 resolver、时间、rcode、flags、ANSWER/AUTHORITY、TTL 和实际被问到的权威服务器。运行 dig +trace 域名 观察从根到 TLD 再到权威的委派，然后对父区列出的**每一台** NS 直接查询 SOA、NS 和故障记录，比较 rcode、SOA serial、地址与 TTL。核对父区 delegation NS 与子区 apex NS，一并检查 in-bailiwick NS 的 glue A/AAAA。任何一台权威超时、REFUSED、NXDOMAIN、非权威回答或旧 serial 都要修复；不能因为其中一台正常就宣布完成。

一、先保存原始DNS响应

不要只记录浏览器“找不到服务器”。在失败网络执行：

dig example.com A
dig example.com A +comments +authority
dig example.com A @递归解析器IP

保存 status、flags 中是否有 aa/ra/ad、ANSWER、AUTHORITY 中的 SOA、SERVER 和 Query time。NXDOMAIN 表示名称不存在，NOERROR 空答案表示该类型无数据；SERVFAIL 是服务器无法完成处理，三者不能混用。

二、从根开始查看真实委派

运行：

dig +trace example.com A

trace 展示根、TLD/父区返回的 NS 与 glue，再请求权威。记录在哪一级停止、哪些地址超时。注意本地防火墙可能阻止 trace 的直接 UDP/TCP 53，失败时要区分诊断环境限制与公网权威故障。

注册商控制台中的 NS 配置是意图，父区实际返回才是运行事实。刚修改委派时也要确认注册局已发布，而不是仅看到面板保存成功。

三、逐台直接查询所有权威NS

从父区响应取得 NS 列表与地址，然后逐台查询：

dig @ns1.example.net example.com SOA +norecurse
dig @ns1.example.net example.com NS +norecurse
dig @ns1.example.net www.example.com A +norecurse

对 ns2、ns3 全部重复，并通过 IPv4/IPv6 分别测试。预期响应应有权威 aa 标志、正确 rcode 和一致 zone 内容。某台返回递归缓存答案不能证明它权威托管该区。

四、识别Lame Delegation

父区把域名委派给某台 NS，但该服务器没有加载该 zone、拒绝查询或不以权威身份回答，就是 lame delegation。递归解析器选中它时会失败或绕行，造成间歇延迟和 SERVFAIL。

检查 nameserver 配置、zone 文件加载日志、视图/ACL 和服务监听。要么让该 NS 正确权威托管并公网可达，要么从父区委派中删除它；只在子区 NS 记录删除而不改父区，不能消除 lame server。

五、比较父区NS与子区apex NS

父区 delegation NS 决定解析器去哪里找；子区 apex NS 描述该区自己的权威集合。两者短期迁移可有差异，但长期不一致会导致监控、DNSSEC 和运维混乱。分别查询父区和每台权威的 NS 记录，列成集合比较。

迁移 nameserver 时先让新 NS 完整加载并可达，再在父区加入；等待传播后移除旧 NS，最后同步子区 apex。不要先关旧服务器再改委派。

六、检查Glue记录

若 nameserver 名称位于被委派域内部，例如 ns1.example.com 为 example.com 服务，解析器在进入子区前需要父区提供 glue 地址，避免循环。核对父区 Additional 中的 A/AAAA 与 nameserver 当前实际地址。

Glue 是导航数据，不替代子区中 NS 主机名自己的权威 A/AAAA。两处应一致。改了服务器 IP却漏改注册商 host object/glue，会让部分解析器继续访问旧地址。

七、分别测试IPv4与IPv6权威地址

父区若发布 NS 的 AAAA，但服务器 IPv6 没有监听 53、路由缺失或防火墙阻断，优先尝试 IPv6 的解析器会超时后回退，甚至返回失败。对每台 NS 的每个 A/AAAA 地址测试 UDP 和 TCP 53。

没有稳定 IPv6 能力时不要发布不可达 AAAA；具备 IPv6 时则验证路由、ACL、MTU 与服务监听。仅从 IPv4 办公网络测试不能证明双栈权威健康。

八、SOA Serial揭示从区不同步

对所有权威查询 SOA，比较 serial、MNAME、refresh、retry 和 expire。serial 不同说明 zone 内容版本不一致；从服务器长期无法 AXFR/IXFR，超过 expire 后可能停止权威回答，形成间歇故障。

检查主从传送日志、NOTIFY、ACL、TSIG、TCP 53 与 serial 更新流程。修改 zone 后必须按采用的 serial 规则递增；内容变了但 serial 未增，从服务器可能不会更新。

九、确认UDP与TCP 53都可用

DNS 通常先用 UDP，截断或较大响应会回退 TCP。防火墙只开放 UDP 53，可能让普通 A 记录正常、DNSSEC 或大型响应失败。对每个权威地址执行普通查询与 +tcp 对比。

EDNS、分片和路径 MTU 也可能造成部分网络失败。检查响应大小、TC 位、ICMP 和防火墙，而不是一味缩小所有 DNS 数据。权威应同时稳定支持 UDP/TCP。

十、检查不同View与ACL

Split-horizon DNS 或 view 配置可能按客户端来源返回不同 zone。公网查询若误入内部 view，可能得到私网地址、NXDOMAIN 或 REFUSED。直接从多个外部探针查询每台权威，并比较响应。

权威服务器通常不应为公网随机客户端提供递归，但应对所托管 zone 权威回答。不要把“关闭递归”的 ACL错误地写成“拒绝所有非内网查询”。

十一、NXDOMAIN负缓存会延长现象

递归解析器可根据 SOA 相关参数缓存否定答案。即使权威已修复，先前从错误 NS 得到 NXDOMAIN 的 resolver 仍可能在负 TTL 内继续返回失败。保存 Authority 中 SOA 与剩余 TTL，等待或在可控 resolver 清除缓存。

切换到另一个公共 DNS 只能绕过当前缓存，不能修复权威不一致。先让所有权威返回一致正确答案，再考虑缓存传播；否则新 resolver 也会随机遇到坏 NS。

十二、DNSSEC会放大委派不一致

如果父区存在 DS，而某些权威返回错误 DNSKEY/RRSIG 或旧 zone，验证解析器可能 SERVFAIL，非验证 resolver 看似正常。对父区 DS、子区 DNSKEY、目标 RRset RRSIG 和签名有效期逐台检查。

迁移 DNS 服务时必须先让新权威拥有正确签名材料/记录，再改变委派和 DS。不要通过删除 DS 临时掩盖普通 NS 同步问题，除非按正式 DNSSEC 回滚流程执行。

十三、Anycast与后端节点不一致

同一 NS IP 可能是 anycast，来自不同地区会命中不同后端。单点直接查询正常不代表全球实例一致。使用多地探针查询同一 NS IP，比较 SOA serial、rcode、延迟和答案。

后端发布应原子、可回滚，并以 zone 哈希/serial监控所有 PoP。健康检查不能只验证进程和端口，还要查询代表记录并确认权威标志。

十四、变更时控制传播顺序

降低 TTL 只能影响子区记录缓存，不能让父区委派立刻刷新；TLD 的 delegation TTL 由父区控制。迁移前了解各层 TTL，至少提前一个周期准备。新旧权威在重叠期返回相同 zone。

每一步记录父区、子区和 glue 变化，设置回滚窗口。不要同时更换 NS 名称、IP、DNSSEC key 和应用记录，否则出现失败时无法隔离变量。

十五、修复后的验收清单

从多个地区和多个递归 resolver 执行 trace，对父区列出的每台 NS、每个 A/AAAA 地址分别用 UDP/TCP 查询 SOA、NS 和代表记录。确认全部权威、serial 一致、glue 正确、无超时/REFUSED/NXDOMAIN。

等待旧负缓存和 delegation 缓存过期后再次测试。监控权威可用率、rcode、SOA serial 差异、zone transfer、DNSSEC 验证、UDP/TCP 和各 PoP。配置变更自动阻断 lame delegation 与不可达 IPv6 地址。

常见问题 FAQ

换成公共DNS后正常是否说明问题解决？

不说明。可能只是新 resolver 尚未缓存坏答案或选择了正常权威。必须逐台检查父区委派中的所有 NS。

父区NS和子区NS不一样会怎样？

解析首先依赖父区委派，长期不一致会造成运维和迁移问题。应按重叠迁移顺序最终同步两边集合。

Glue什么时候必须？

当 nameserver 名称位于被委派域内部时，需要父区提供地址以打破解析循环，例如 ns1.example.com 服务 example.com。

为什么只有IPv6网络失败？

某台权威发布了 AAAA 但 IPv6 端口、路由或防火墙不可用。逐地址测试 UDP/TCP 53并修复或移除不可达 AAAA。

修复权威后为什么仍返回NXDOMAIN？

递归 resolver 可能保留旧的否定缓存。查看 SOA 与剩余 TTL；先确认全部权威一致，再等待或清理受控缓存。

总结

间歇性 NXDOMAIN/SERVFAIL 的根治方法不是换 resolver，而是审计完整委派链。以父区实际 NS 为准，对每台权威和每个地址直接查询，比较 SOA serial、apex NS、glue、UDP/TCP 与 DNSSEC。修复 lame server 和不同步从区后，再等待负缓存与委派缓存传播，并用多地监控持续证明所有权威一致可用。

官方资料

• RFC 1034：Domain Names - Concepts and Facilities：https://www.rfc-editor.org/rfc/rfc1034
• RFC 1035：Domain Names - Implementation and Specification：https://www.rfc-editor.org/rfc/rfc1035
• RFC 1912：Common DNS Operational and Configuration Errors：https://www.rfc-editor.org/rfc/rfc1912
• IANA：Nameserver requirements：https://www.iana.org/help/nameserver-requirements