排查域名 SERVFAIL，比较 DNSSEC 验证结果，检查注册商 DS、权威 DNSKEY、签名、NS 和 TCP 53，并按安全顺序修复与回退。
先判断是不是域名本身出错：如果只有自己的域名返回 SERVFAIL，而其他网站都能打开，先不要改网站服务器、A 记录或清空 CDN。分别向两个公共递归解析器查询，再用关闭 DNSSEC 校验的方式做对照。正常查询失败、关闭校验后有答案，通常说明 DNSSEC 信任链断了；最常见的现场是更换 DNS 服务商后，注册商处仍保留旧 DS 记录。
费用与风险：查询 DNS 状态通常不收费，也不会修改网站数据。删除或更换 DS、DNSKEY、NS 属于生产变更，顺序错误会让启用 DNSSEC 校验的用户无法访问网站和邮件。DNS 服务、流量和高级套餐是否收费，以当前注册商或 DNS 服务商页面为准。操作前截图保存注册商的 DNSSEC 页面，导出当前区域记录，并保留原 NS、DS、DNSKEY 与 TTL。
先用四组查询把故障范围分开
下面命令只读取公开 DNS。把 example.com 替换为自己的根域名，保留末尾的点可以避免本机自动拼接搜索域：
dig @8.8.8.8 example.com. A +dnssec
dig @1.1.1.1 example.com. A +dnssec
dig @1.1.1.1 example.com. A +dnssec +cd
dig example.com. DS +trace前两条都返回 SERVFAIL，说明问题不像单台电脑缓存。第三条的 +cd 表示请求解析器暂时不验证 DNSSEC；如果它能返回正确 A 记录，而普通查询失败，重点检查 DS、DNSKEY 与签名。+cd 只用于诊断，不能作为让访客长期关闭校验的修复方案。
如果加不加 +cd 都失败，则还要检查权威服务器不可达、父区委派错误、区域未加载、DNS 响应过大或 TCP 53 被拦截。不要看到 SERVFAIL 就直接删除 DNSSEC。
DS、DNSKEY 和签名分别在哪里
DNSKEY 由当前权威 DNS 服务商在你的区域中提供；DS 位于上一级区域，通常通过域名注册商提交。验证解析器先从父区取得 DS，再用它检查子区的 DNSKEY，最后验证 A、AAAA、MX 等记录的签名。任何一层不匹配，解析器都不能把结果当作可信答案。
| 检查结果 | 更可能的原因 | 处理方向 |
|---|---|---|
| 父区有 DS，权威区没有 DNSKEY | 停用或迁移 DNSSEC 时顺序错误 | 先在注册商处理旧 DS，不要让父区继续声明已签名 |
| DS 与当前服务商给出的值不同 | 更换 DNS 服务商后留下旧 DS | 按当前服务商资料更新，紧急回退时先移除旧 DS |
| 各权威服务器 DNSKEY/答案不一致 | 部分节点或区域没有同步 | 修复权威区同步，逐台 NS 复核 |
| DNSKEY 正常但 RRSIG 过期 | 签名任务或权威服务异常 | 由权威 DNS 服务商恢复签名并重新发布 |
| UDP 失败、TCP 查询成功 | 大响应、分片或 TCP 53 路径问题 | 检查权威服务器与防火墙，不靠缩短业务记录掩盖 |
更换 DNS 服务商后为什么最容易出现 SERVFAIL
只改 NS 不会自动清理父区的 DS。旧服务商仍有一套签名密钥，新服务商会生成另一套；如果父区缓存中的 DS 指向旧密钥，而查询已经到新权威服务器，信任链就会断开。未验证 DNSSEC 的本地解析器可能暂时还能打开网站，Google Public DNS、Cloudflare 等验证解析器则会返回 SERVFAIL，因此故障看起来像“有些网络能开，有些网络打不开”。
计划迁移时，默认安全顺序是先按两家服务商都支持的迁移方案处理密钥；如果做不到不停机迁移，就先在注册商移除旧 DS，等待父区 DS 的 TTL 过期，再切换 NS，最后在新服务商启用 DNSSEC 并提交新 DS。不能刚删 DS 就立即删除旧 DNSKEY，也不能在旧 DS 仍缓存时先把旧签名停掉。
已经故障时怎样选择恢复路径
当前权威 DNS 仍能提供与 DS 匹配的密钥
先恢复该权威区的正常签名、区域发布和所有 NS 一致性。逐台查询权威服务器，确认都返回同一组 DNSKEY 和有效 RRSIG。此时保留 DS 比删除信任链更合适。
DS 明确属于已经停用的旧服务商
登录域名注册商，在域名的 DNSSEC 或高级 DNS 页面核对 DS。若旧服务商已经无法恢复签名，移除陈旧 DS 是常见的紧急恢复动作。移除后域名会暂时变成未由 DNSSEC 保护的普通委派；网站数据不会因此删除，但缓存中的旧 DS 在 TTL 到期前仍可能让部分用户失败。
不要在 DNS 服务商的普通记录列表里创建一个名为 DS 的文本记录来代替注册商操作。根域名的 DS 需要发布在父区，入口通常在注册商而不是当前权威区域。
DS 与 DNSKEY 看似一致但仍失败
检查算法、摘要类型、密钥标签、RRSIG 有效期和服务器时间。再逐台查询 NS，并分别测试 UDP 与 TCP：
dig +short example.com. NS
dig @ns1.example.net. example.com. DNSKEY +dnssec
dig @ns1.example.net. example.com. A +dnssec
dig @ns1.example.net. example.com. A +dnssec +tcp把权威服务器名称替换为真实值。若只有某一台 NS 答案错误，应先修复或从父区委派中安全移除异常节点；不能依赖“多数节点正常”，因为递归解析器仍可能访问坏节点。
哪些操作看似能恢复，实际会留下风险
- 把电脑 DNS 换成一个不验证 DNSSEC 的解析器，只绕过了症状，没有修复域名。
- 反复修改 A、AAAA 或 CDN 回源地址，不能修复 DS 与 DNSKEY 不匹配。
- 先删除 DNSKEY、后删除父区 DS，会直接制造验证失败窗口。
- 只在一个地区或一台手机上测试，无法证明父区缓存和所有权威节点已经一致。
- 在故障期间同时切注册商、NS、DNSSEC 和 CDN，会让证据消失，也难以回退。
怎样验证已经恢复并准备回退
- 使用至少两个验证递归解析器查询 A、AAAA、MX 和实际业务子域，状态应从
SERVFAIL恢复为预期答案。 - 如果 DNSSEC 仍启用，普通查询应出现有效签名，验证成功的响应可看到
ad标志；DS 与服务商给出的值一致。 - 逐台权威 NS 检查答案、序列号、DNSKEY 和 TCP 53，确认没有单个坏节点。
- 从外部访问网站、后台、API 和邮件域名，避免只验证根域名。
- 记录父区 DS TTL，至少覆盖一个完整缓存周期再宣布稳定。
如果提交新 DS 后再次出现故障，优先恢复到已记录的上一组匹配密钥；无法恢复时按注册商流程移除错误 DS，并等待缓存过期。DNSSEC 修复不需要改网站数据库。需要继续检查本机解析器时，可参考Linux DNS 解析失败排查；涉及 CDN 委派与 CNAME 时，可参考CDN CNAME 与 DNS 排障；证书验证同时失败时再检查Let's Encrypt 续签链路。
联系 Telegram 客服 