网站更换 DNS 服务商、修改名称服务器或重新启用 DNSSEC 后，域名可能突然无法解析。浏览器只显示“找不到服务器”，命令行查询却返回 SERVFAIL。有些网络打不开，有些网络暂时正常，权威 DNS 控制台里的记录看上去也没有问题。
这种故障需要同时检查注册局父区和当前权威 DNS。只改 A、AAAA 或 CNAME 记录通常无效，因为启用 DNSSEC 后，递归解析器还会验证父区的 DS 记录、子区的 DNSKEY 以及响应中的 RRSIG。任何一环对不上，支持 DNSSEC 验证的递归解析器都可能拒绝返回结果。
先确认是 SERVFAIL，不要与 NXDOMAIN 混淆
NXDOMAIN 表示解析器得到的结论是“这个名称不存在”。SERVFAIL 表示解析器未能给出可信答案，可能来自 DNSSEC 验证失败、权威服务器超时、网络不可达、区域配置错误或响应过大等问题。看到 SERVFAIL 还不能直接认定 DNSSEC 出错，需要做对照查询。
先从两个公共递归解析器查询同一条记录：
dig example.com A @1.1.1.1
dig example.com A @8.8.8.8
再请求 DNSSEC 相关记录：
dig +dnssec example.com A @1.1.1.1
dig +dnssec example.com A @8.8.8.8
留意输出中的 status、flags、SERVER 和 Query time。验证成功的响应通常可看到 ad 标志，但是否出现还受查询方式和解析器策略影响，不能把缺少 ad 单独当成故障证据。
接着使用 +cd 关闭本次查询的 DNSSEC 验证：
dig +dnssec +cd example.com A @1.1.1.1
dig +dnssec +cd example.com A @8.8.8.8
如果普通查询返回 SERVFAIL，加上 +cd 后却能得到正确的 A 或 AAAA 记录，故障范围已经明显缩小：递归解析器能够联系权威服务器并取得答案，但无法通过 DNSSEC 验证。若两种查询都失败，还要继续检查权威服务器、委派、网络和区域数据。
dig +trace 可以查看从根区、顶级域到权威 DNS 的委派过程：
dig +trace example.com A
它适合发现 NS 委派、胶水记录或权威服务器不可达等问题，但不能替代完整的 DNSSEC 验证。排查时要把追踪结果与验证型递归解析器的结果放在一起看。
从父区开始检查 DS 记录
DNSSEC 的信任链从父区向子区延伸。以 example.com 为例，.com 父区发布的 DS 记录用于指向 example.com 区域中的某个 DNSKEY。域名更换 DNS 服务商时，名称服务器可能已经切到新平台，注册商处却仍保留旧服务商的 DS。这是迁移后出现大面积 SERVFAIL 的常见原因。
查询父区可见的 DS：
dig +dnssec example.com DS @1.1.1.1
dig +dnssec example.com DS @8.8.8.8
还可以从追踪结果中找到顶级域权威服务器，再直接查询：
dig com NS
dig +dnssec example.com DS @<某台-com-权威服务器>
一条 DS 记录包含四个需要核对的部分：Key Tag、Algorithm、Digest Type 和 Digest。注册商或域名注册局控制台显示的值，应当对应当前权威 DNS 正在使用的密钥。只看“DNSSEC 已开启”这个开关不够。
排查时记录下面几项：
- 父区是否仍发布 DS。
- DS 的 Key Tag、Algorithm、Digest Type 和 Digest 是什么。
- 当前域名由哪组 NS 提供权威解析。
- DS 是旧平台生成的，还是当前平台生成的。
- 注册商最近是否修改过 DS，修改时间是否已经超过正常的父区更新与缓存周期。
如果当前并不打算使用 DNSSEC，父区仍有 DS 就会带来风险。权威 DNS 停止签名后，验证型解析器会把“父区承诺存在签名”与“子区没有可验证签名”视为失败。
再核对当前权威 DNS 的 DNSKEY
先查出当前权威服务器：
dig example.com NS
然后绕过递归缓存，直接向每台权威服务器查询 DNSKEY：
dig +norecurse +dnssec example.com DNSKEY @ns1.example-dns.net
dig +norecurse +dnssec example.com DNSKEY @ns2.example-dns.net
正常情况下，多台权威服务器应返回一致、完整的区域数据。若某台服务器没有 DNSKEY、返回旧密钥、缺少 RRSIG，或多台服务器尚未完成同步，递归解析器可能因命中不同权威节点而得到不一致结果。
安装了 BIND 工具后，可以根据 DNSKEY 计算 DS，再与父区中的 DS 对照。以下命令中的权威服务器和域名需要替换为实际值：
dig +norecurse example.com DNSKEY @ns1.example-dns.net > dnskey.txt
dnssec-dsfromkey -f dnskey.txt example.com
重点比较输出中的 Key Tag、算法、摘要类型和摘要内容。只要父区 DS 指向的密钥已经不在当前 DNSKEY 集合里，验证链就会中断。
区域里可能同时存在多把 DNSKEY，用于密钥轮换或区分 KSK、ZSK。不能简单地要求所有 DNSKEY 都与 DS 一致；至少要有一条有效的信任路径，从父区 DS 对应到当前可用的 DNSKEY，并能验证区域签名。
检查 RRSIG 是否存在、过期或尚未生效
DNSKEY 对得上以后，还要检查实际记录的签名。例如：
dig +norecurse +dnssec example.com A @ns1.example-dns.net
dig +norecurse +dnssec example.com SOA @ns1.example-dns.net
dig +norecurse +dnssec example.com DNSKEY @ns1.example-dns.net
响应中的 RRSIG 带有签名生效时间和过期时间。常见故障包括：
- 签名已经过期，自动续签任务没有运行。
- 新签名的生效时间还没到。
- 服务器时间偏差过大，生成或判断签名有效期时出错。
- 只有部分权威节点更新了签名。
- 区域发生变更后，DNSKEY、RRSIG 与实际记录没有同步完成。
检查权威 DNS 主机的时间同步状态：
timedatectl status
chronyc tracking
托管型 DNS 通常不需要用户维护签名任务，但仍要确认平台控制台是否报告签名失败、密钥轮换未完成或区域处于待生效状态。自建 BIND、Knot DNS、PowerDNS 等环境，则要继续检查签名器日志、区域序列号、主从同步和定时任务。
更换 DNS 服务商后，旧 DS 最容易留下
典型迁移过程如下：旧 DNS 服务商开启了 DNSSEC，注册商处保存着旧 DS；随后域名 NS 切到新服务商，新服务商生成了另一组 DNSKEY。普通 DNS 记录已经迁移成功，但父区仍要求使用旧密钥验证。支持 DNSSEC 的解析器因此返回 SERVFAIL。
处理这类问题时，不要只在新权威 DNS 上关闭 DNSSEC。父区 DS 仍然存在，故障不会消失，甚至会把原来部分可验证的状态变成完全不可验证。
计划迁移时，可按下面的顺序操作：
- 在新平台建立完整区域，确认所有记录与旧平台一致。
- 根据两家平台支持的迁移方案，决定采用预发布密钥、双签名或暂时撤销 DS。
- 在注册商处更新或移除 DS，并等待父区更新。
- 确认新的信任链可验证后，再停用旧平台。
- 从多个递归解析器和多个网络重新检查域名。
不同 DNS 服务商对密钥预发布和迁移的支持并不一致。控制台没有提供可控轮换流程时，短暂撤销父区 DS 往往比带着旧 DS 强行切换更稳妥，但这段时间域名不再获得 DNSSEC 的验证保护。操作前应保存原 DS、DNSKEY、NS 和 TTL 信息，并准备回滚路径。
紧急恢复时，先处理失效的信任链
已经发生全站解析失败时，优先目标是恢复稳定解析。如果确认父区 DS 与当前权威 DNSKEY 不匹配，可以在域名注册商处删除旧 DS。删除后需要等待注册局父区更新以及递归缓存过期，恢复不会在点击保存后立刻覆盖所有网络。
紧急处理建议保留这些证据：
- 修改前的 DS 完整值与截图。
- 当前 NS、DNSKEY 和 RRSIG 查询结果。
- 至少两个公共递归解析器的返回结果。
- 注册商操作时间、工单编号和预计生效时间。
- 用于恢复 DNSSEC 的新 DS 值。
解析恢复稳定后，再在当前 DNS 服务商处确认签名正常，生成或复制正确的新 DS，提交到注册商，并从父区开始重新验证信任链。不要在旧 DS 尚未撤销时反复切换 DNSSEC 开关，这会增加缓存状态和排查记录的混乱。
还有一种情况：签名没错，DNSSEC 响应却到不了
DNSSEC 会让响应携带 DNSKEY、RRSIG 等额外数据，报文可能明显变大。网络路径、旧防火墙或错误的 EDNS 配置如果丢弃分片，或阻止 DNS 使用 TCP 回退，也会表现为超时或 SERVFAIL。
可以比较 UDP 与 TCP 查询：
dig +dnssec example.com DNSKEY @ns1.example-dns.net
dig +tcp +dnssec example.com DNSKEY @ns1.example-dns.net
再测试不同 EDNS 缓冲大小：
dig +dnssec +bufsize=1232 example.com DNSKEY @ns1.example-dns.net
dig +tcp +dnssec example.com A @ns1.example-dns.net
如果 TCP 查询稳定成功，UDP 查询经常超时或只在特定网络失败，需要检查权威 DNS 前面的防火墙、安全组、负载均衡、Anycast 节点和运营商路径。DNS 同时依赖 UDP 53 与 TCP 53，不能只放行 UDP。
用一组固定检查完成恢复验证
修改完成后，从父区到业务记录逐层验证：
dig +dnssec example.com DS @1.1.1.1
dig +norecurse +dnssec example.com DNSKEY @ns1.example-dns.net
dig +norecurse +dnssec example.com A @ns1.example-dns.net
dig +dnssec example.com A @1.1.1.1
dig +dnssec example.com A @8.8.8.8
dig +trace example.com A
检查结果应满足这些条件：
- 父区 DS 与当前有效 DNSKEY 能建立信任路径，或者父区已经按计划撤销 DS。
- 每台权威服务器返回一致的 DNSKEY、SOA 和业务记录。
- RRSIG 在有效期内，服务器时间正常。
- 普通验证查询不再返回
SERVFAIL。 +cd查询与普通查询得到的业务记录一致。- UDP 与 TCP 查询都能完成，多个公共递归解析器结果一致。
还可以使用 DNSViz 等验证工具查看完整信任链。第三方工具适合快速定位断点，最终仍应以父区 DS、权威 DNS 实际响应和验证型递归解析器的结果为准。
DNSSEC 故障的排查顺序可以固定下来：先用 +cd 对照确认是否与验证有关，再查父区 DS，然后核对权威 DNSKEY 和 RRSIG，最后检查报文大小与网络路径。更换 DNS 服务商时把 DS 更新纳入迁移清单，通常就能避开“记录已经切换，域名却全网 SERVFAIL”的故障。
参考资料
- ICANN：What Is DNSSEC, and Why Is It Important?
- Cloudflare DNS 文档：DNSSEC
- Google Public DNS：Troubleshooting
- BIND 9 文档：dig
- RFC 4033：DNS Security Introduction and Requirements
- RFC 4034：Resource Records for DNS Security Extensions
- RFC 4035：Protocol Modifications for the DNS Security Extensions
资料核验日期：2026-09-24。