DNSSEC启用或换钥后SERVFAIL：DS、DNSKEY与RRSIG失配排查清单

直接答案

先分别向验证递归器和权威服务器查询 DS、DNSKEY、目标记录及其 RRSIG，保留完整报文、服务器地址和时间。若验证器支持 Extended DNS Error，查看是否为 DNSSEC Bogus、Signature Expired、Signature Not Yet Valid、DNSKEY Missing 或 RRSIGs Missing。计算当前 KSK 对应的 DS，并与注册局父区实际发布值逐字段比较；确认所有权威节点都提供相同 DNSKEY 和有效签名。换钥时先让新 DNSKEY 充分传播，再更新 DS；停用旧钥前等待父区与递归缓存的 TTL 窗口。不要用关闭验证或永久设置 Negative Trust Anchor 作为修复。

一、先确认SERVFAIL是否来自DNSSEC验证

SERVFAIL 是通用失败码，也可能由权威不可达、循环转发、超时或服务器故障引起。先用同一名称、同一记录类型分别查询两个验证递归器和权威服务器。验证器 SERVFAIL、权威服务器能返回带签名数据，而关闭检查的诊断查询能看到回答，才强烈指向验证链问题。

ICANN 的说明使用特意无效的 dnssec-failed.org 来验证递归器是否执行 DNSSEC 检查：验证递归器应返回 SERVFAIL，非验证递归器可能返回 NOERROR。这个测试只用于确认解析器能力，不证明你的域名具体错在哪里。记录查询中的 AD、CD、DO 位和服务器地址，避免把不同解析路径混在一起。

二、优先读取Extended DNS Error

RFC 8914 定义 EDE，为普通 SERVFAIL 补充诊断信息。常见代码包括 6 DNSSEC Bogus、7 Signature Expired、8 Signature Not Yet Valid、9 DNSKEY Missing、10 RRSIGs Missing、11 No Zone Key Bit Set 和 12 NSEC Missing。支持 EDE 的 dig 或解析日志可以直接缩小范围。

EDE 不改变原有 RCODE 处理，而且其文本本身通常不是经过认证的事实，只能作为诊断线索。仍需用实际 DS、DNSKEY、RRSIG 和时间验证。若返回 22 No Reachable Authority 或 23 Network Error，应先查权威可达性，而不是立刻重签整个区域。

三、从父区查询真实DS

DS 位于父区的委派点，不是放在子区 apex 就能生效。向父区权威服务器查询域名的 DS，记录 Key Tag、Algorithm、Digest Type 和 Digest。再从子区当前 KSK 的 DNSKEY 计算 DS，四项必须对应。控制台里的待发布值、注册商数据库和公网父区实际回答可能处于不同状态，以父区权威回答为准。

最危险的情况是父区保留旧 DS，而子区已经删除对应 DNSKEY。验证器沿父区 DS 寻找子区密钥却找不到匹配项，信任链变为 Bogus。另一种情况是注册商提交时复制了错误摘要、选错算法或对另一个 DNSKEY 计算了 DS。不要只比较 Key Tag，因为碰撞或误认都可能发生，应比较完整字段。

四、检查所有权威节点的DNSKEY一致性

分别直接查询委派中的每台权威 NS，不经过递归缓存。确认 apex DNSKEY RRset 内容、TTL 和覆盖它的 RRSIG 一致。迁移期间若一半服务器仍提供旧区、一半已使用新钥，用户会表现为间歇性成功与失败。

检查 hidden primary 到 secondary 的区域传送、签名文件同步、序列号、Anycast 节点发布和托管商控制平面状态。只有一台服务器正确并不足够。DNSKEY 回答可能较大，还要验证 UDP、EDNS 与 TCP 回退，避免防火墙丢弃大响应造成看似随机的验证失败。

五、区分KSK、ZSK与Zone Key位

运维流程通常用 KSK 对 DNSKEY RRset 签名，用 ZSK 对普通 RRset 签名，但协议验证关注的是可建立的有效链，而不是控制台标签。确认父区 DS 指向的 DNSKEY 存在，DNSKEY 设置了 Zone Key 位，DNSKEY RRset 的签名能由受信任密钥验证，目标 RRset 的 RRSIG 也能关联到发布的 DNSKEY。

EDE 11 表示验证器没有发现设置 Zone Key 位的适用 DNSKEY。不要靠手工修改 Key Tag；Key Tag 是从 DNSKEY 数据计算出的标识。重新生成或导入密钥后，应重新计算 DS，并确保签名器、权威发布和注册商提交使用同一份密钥材料。

六、检查RRSIG生效与过期时间

RRSIG 有 inception 和 expiration。服务器时钟偏差、签名任务停止、区域内容更新但未重新签名，都可能产生“尚未生效”或“已经过期”。比较签名时间与标准 UTC 时间，检查签名系统、权威服务器和验证器的时钟同步。

不能只检查 apex DNSKEY 的签名。逐项验证 A/AAAA、MX、NS、SOA，以及否定回答所需的 NSEC/NSEC3。若某类记录缺少 RRSIG，只有访问该记录时才失败。设置签名有效期时应留出自动续签和发布缓冲，并对距离过期时间建立告警。

七、换钥顺序必须覆盖缓存窗口

安全轮换的核心是新旧链在过渡期至少有一条可验证路径。常见 KSK 流程是先发布新 DNSKEY，等待它传播并进入缓存，再向父区增加或替换 DS；确认新 DS 公网生效后，继续保留旧密钥足够长时间，最后才撤销旧 DNSKEY。具体时长由父区 DS TTL、子区 DNSKEY TTL、签名有效期和注册商处理时间共同决定。

不能把“注册商显示成功”当作过渡完成。直接查询父区权威并从多个地区的验证器测试。若同时变更 NS、DNS 托管商和密钥，故障面会叠加；尽量拆成可回滚步骤，每一步都等待传播并验证后再继续。

八、迁移DNS托管商时的典型失配

旧托管商的 DS 仍在父区，而新托管商默认生成了另一套密钥，是最常见迁移事故。迁移前应决定沿用密钥还是重建信任链。如果新平台不能导入旧密钥，可以在旧、新权威并存阶段发布新 DNSKEY 和对应 DS，完成双链过渡；若无法安全协同，应按照注册局和托管商支持的明确流程先移除旧 DS、等待变为 insecure，再重新签名，期间理解安全降级影响。

不要在未确认传播窗口时同时删除旧 NS 与旧 DNSKEY。保留旧平台的可恢复配置和区文件，记录每次 DS 提交的工单、时间、字段和父区实测结果。回滚必须恢复一条完整信任链，而不只是把 A 记录改回去。

九、检查否定回答的NSEC或NSEC3

DNSSEC 不仅验证存在的记录，也要验证名称或类型不存在。RFC 4035 要求通过认证的 NSEC 证明不存在；使用 NSEC3 的区域遵循相应机制。通配符、空非终端、委派点或新建记录附近若否定证明不完整，可能只有部分查询返回 SERVFAIL。

测试一个存在的名称、一个不存在的名称和一个存在名称下不存在的记录类型。若 EDE 显示 NSEC Missing，检查签名器生成链、区域增量更新和权威节点同步。不要通过增加一个伪造记录来掩盖否定证明故障。

十、缓存会让修复看起来延迟

递归器可能缓存旧 DS、旧 DNSKEY、旧签名或 SERVFAIL。RFC 8914 的 Cached Error 可表明返回的是缓存失败。修复权威数据后，旧缓存不会在全球同时消失。根据各 RRset 原始 TTL 估算窗口，并用多个未共享缓存的验证器复查。

只清理你控制的递归器缓存不能改变公网用户的缓存。不要反复修改 DS 或密钥来“催生效”，这会制造更多交错版本。先证明父区和全部权威已稳定正确，再等待有界 TTL；若必须紧急处理，遵循注册局与 DNS 托管商的应急流程并保留时间线。

十一、不要用CD或关闭验证当永久修复

带 CD 位的诊断查询可让验证器返回未经检查的数据，帮助观察原始 RRset，但应用不应长期依赖它。关闭递归器 DNSSEC 验证会让所有域名失去保护，也会把配置错误伪装成恢复。Negative Trust Anchor 只应是有政策、有到期时间、有监控的应急机制。

真正修复必须恢复父区到子区的验证链。完成后重新启用标准验证，确认回答带有预期 AD 状态，并从不同验证器重复查询。不要向普通用户暴露完整内部密钥路径或管理凭据。

十二、修复后端到端验收

验收应覆盖：父区 DS 与当前 KSK 匹配；所有权威 NS 返回一致 DNSKEY；DNSKEY RRset 和常用业务 RRset 的 RRSIG 有效且时间合理；不存在名称的否定证明可验证；UDP 与 TCP 查询均成功；至少两个独立验证器返回 NOERROR；非验证查询与验证查询的业务数据一致；EDE 不再报告 Bogus 或缺失数据。

随后验证网站、邮件和 API 的实际解析，持续监控 SERVFAIL、签名到期、区域序列和 DS 变化。把当前 DS、DNSKEY 哈希、签名时间窗、权威节点列表和回滚步骤写入脱敏报告，但绝不保存私钥材料。

FAQ

为什么公共DNS返回SERVFAIL，权威查询却有A记录？

权威服务器可以返回未验证的数据，而验证递归器必须检查 DNSSEC 信任链。若父区 DS 与子区 DNSKEY/RRSIG 不匹配，验证器会丢弃看似存在的 A 记录并返回失败。

删除父区DS能马上恢复吗？

不一定。递归器可能仍缓存旧 DS，且删除 DS 会让区域降级为 insecure。应先评估 TTL、业务风险和注册局处理时间，按受控应急流程操作，不要在不确定时反复增删。

Key Tag相同是否证明DS匹配？

不能。必须比较 Algorithm、Digest Type 与完整 Digest，并从实际 DNSKEY 重新计算。Key Tag 只是辅助标识，不足以单独证明链正确。

EDE显示Signature Expired应该怎么处理？

检查签名任务、区域是否成功重签、权威节点是否同步，以及系统 UTC 时间。生成新有效签名并发布到所有节点，确认后再等待旧缓存过期。

可以通过关闭DNSSEC验证解决业务故障吗？

只能作为受控诊断，不能当修复。关闭验证会影响解析器上的所有域名并掩盖真实错误。应修复 DS、DNSKEY、RRSIG 或否定证明，恢复完整信任链。

总结

DNSSEC SERVFAIL 的排查顺序是：先证明故障来自验证，再读取 EDE，随后核对父区 DS、全部权威的 DNSKEY、各 RRset 的 RRSIG 时间以及 NSEC/NSEC3 否定证明。换钥和迁移必须覆盖父区与递归缓存窗口，始终保留至少一条有效信任链。修复完成的标准不是“不验证时能打开”，而是多个独立验证器都能从根信任锚连续验证到业务记录。

参考资料

1. RFC Editor — RFC 4035, Protocol Modifications for DNSSEC: https://www.rfc-editor.org/info/rfc4035/

2. RFC Editor — RFC 8914, Extended DNS Errors: https://www.rfc-editor.org/rfc/rfc8914.html

3. IANA — Domain Name System Parameters, Extended DNS Error Codes: https://www.iana.org/assignments/dns-parameters

4. ICANN — Checking the Current Trust Anchors in DNS Validating Resolvers: https://www.icann.org/dns-resolvers-checking-current-trust-anchors/