更换 DNS 服务商后 SERVFAIL：检查注册商残留的旧 DS

更换域名的权威 DNS 后，直接查询新服务器能拿到 A 记录，普通查询却返回 SERVFAIL。如果域名此前启用了 DNSSEC，需要检查注册商处是否仍保留旧 DNS 服务商的 DS 记录。

DS 位于父区，用来把域名的签名密钥接入信任链。只更换 NS 或导入 A、MX 等普通记录，不会自动让旧 DS 匹配新服务商的密钥。新权威服务器不签名，或者换用了另一把密钥时，执行 DNSSEC 校验的递归解析器可能拒绝返回结果。

用同一个解析器比较校验结果

下面的命令用于查询诊断，不修改 DNS。将 example.com 替换为域名，8.8.8.8 也可以替换为正在出错的递归解析器：

dig @8.8.8.8 example.com A +dnssec
dig @8.8.8.8 example.com A +dnssec +cd

第一条保留解析器正常的校验行为；第二条设置 Checking Disabled，便于观察不强制校验时是否能取得答案。

如果第一条是 SERVFAIL、第二条能返回预期地址，DNSSEC 校验失败是重要线索，还需要核对 DS、DNSKEY 和签名。+cd 只是诊断选项，不应把关闭终端或公共解析器的校验作为站点修复。

如果两条都失败，继续检查新权威服务器是否可达、委派是否正确，以及所有被委派的服务器是否都能回答。SERVFAIL 还可能来自超时、错误委派或其他故障，不能只凭状态码删除 DS。

检查父区 DS 和新权威密钥

对域名区域的根名称查询，而不是只查某个业务子域名：

dig example.com DS +trace
dig @ns1.example.net example.com DNSKEY +dnssec
dig @ns1.example.net example.com A +dnssec

这里的 ns1.example.net 是新服务商分配的权威服务器占位名称。应逐台查询当前委派的服务器。

检查父区返回的 DS 是否与新服务商给出的 DS 参数一致，包括 key tag、algorithm、digest type 和 digest。仅看到 key tag 相同不足以证明匹配。新服务商启用 DNSSEC 时，还应能提供对应的 DNSKEY 和有效签名；没有 DNSKEY、缺少签名或者 DS 不匹配，都需要进一步处理。

dig +trace 得到最终地址，只说明这次追踪能走到权威答案，不能单独证明递归解析器的 DNSSEC 校验会通过。

根据新服务商的签名状态修复

新服务商已经正确签名： 从新服务商取得准确的 DS 信息，通过域名注册商更新父区 DS。修改前保存旧 NS、DS、区域记录和 TTL，确认当前委派指向哪组服务器。还在迁移过程中、同时存在旧新服务器时，应按两家服务商支持的 DNSSEC 迁移流程处理，不能随意替换密钥与委派顺序。

新服务商尚未签名，且确认要暂时停用 DNSSEC： 在注册商处移除父区旧 DS。这样会中断该域名的 DNSSEC 信任链，是安全属性的变更。先确认业务允许，再等旧 DS 缓存按 TTL 消退；不要只在新 DNS 区域里删除签名或 DNSKEY，那会让仍缓存 DS 的解析器继续校验失败。

如果需要恢复旧服务商，必须同时恢复与旧 DS 匹配的权威服务、密钥和签名，单独改回 NS 未必立即恢复。缓存中的 NS 和 DS 可以处于不同更新阶段，因此不应承诺修改后固定几分钟或几小时生效。

恢复标准

从多个递归解析器重新查询，不带 +cd 时应返回预期业务记录。继续启用 DNSSEC 的域名，应验证完整信任链有效；可信校验解析器的响应中通常可以看到 ad 标志。暂时关闭 DNSSEC 后没有 ad 并不等于仍然故障。

最后检查网页、邮件和其他依赖域名的服务。DNSSEC 错误影响的可能是整个区域，不能只以某一个 A 记录恢复作为所有业务正常的证明。