你在注册商点开了 DNSSEC、粘贴了 DS 记录，感觉安全感拉满。然后站点在 Google Public DNS（8.8.8.8）和 Cloudflare（1.1.1.1）上挂了——dig 返回 status: SERVFAIL。源站好好的、A/AAAA 记录也对，但公网上所有做验证的解析器都因为 DNSSEC 信任链断了而拒绝返回结果。这种故障最坑：非验证型解析器照常能用，所以你坐在公司网里以为一切正常，真实用户其实全炸了。
最快的恢复办法： 如果你几分钟内修不好、用户又在掉线，直接去注册商删掉 DS 记录，等父区 TTL 过期（通常几个小时）——你的区会退回到普通的未签名 DNS，解析随之恢复。如果时间够、要彻底修，先读 dig 输出里的 EDE 错误码（见第 1 步），它会直接点名是哪一环断了，然后从当前 DNSKEY 重新生成 DS、在注册商替换。两条路下面都有。
先读 EDE 错误码（2026 年 6 月）
大约从 2022 年起，主流验证型解析器（Cloudflare 1.1.1.1、Google 8.8.8.8、Quad9 9.9.9.9）都会在 SERVFAIL 上附带一个 Extended DNS Error（EDE，RFC 8914）。截至 2026 年 6 月，dig 会把它打印在 OPT PSEUDOSECTION 里。这一行通常就能告诉你落在下面哪一类原因里，所以动手前先跑这条：
dig +dnssec yourdomain.com @1.1.1.1找这样一行：
; EDE: 6 (DNSSEC Bogus): failed to verify DS yourdomain.com.: using DNSKEY ids = [12345]跟 DNSSEC 相关的 EDE 错误码及含义：
| EDE 码 | 名称 | 最可能的原因 |
|---|---|---|
6 | DNSSEC Bogus | DS 和 DNSKEY 对不上，或 NSEC3 证明无效（原因 1、2、5） |
7 | Signature Expired | RRSIG 过期了；签名器停止重新签名（key 静默过期） |
8 | Signature Not Yet Valid | 签名器时钟偏差，或你发布的签名 inception 在未来 |
9 | DNSKEY Missing | 注册商的 DS 指向的 key tag 在 DNSKEY 里找不到（原因 4） |
10 | RRSIGs Missing | 区（或某台 NS）返回记录但没有签名（原因 3） |
如果完全没有 EDE 行、答案干净、还带 ad 标志，说明验证其实已经通过——问题在别处（或者只是缓存没刷新，原因 6）。
常见原因
按命中率从高到低排。
1. 注册商的 DS 和权威 NS 的 DNSKEY 对不上
父区的 DS 记录（Delegation Signer）必须能哈希到子区 DNSKEY RRset 里的某一把 key。你粘的 DS 是半年前的截图、或者 host 那边轮换过 key 但注册商这边没同步，链就断了。
怎么判断：dig +dnssec yourdomain.com DNSKEY @8.8.8.8 拿得到 key，但 dig DS yourdomain.com @8.8.8.8 的 digest 跟 dnssec-dsfromkey 从 DNSKEY 算出来的不一样。
2. 算法或 digest 类型对不上
注册商的 DS 声明算法 8（RSASHA256），但你的权威 NS 实际签名用的是算法 13（ECDSAP256SHA256）；或者 DS 用的是 digest 类型 1（SHA-1）——截至 2026 年，验证型解析器已经不再接受它，只认 digest 类型 2（SHA-256）。
怎么判断：上 dnsviz.net/d/yourdomain.com/dnssec/，它会把链画出来，算法和 digest 对不上的地方标红。出现 EDE: 6 (DNSSEC Bogus): no supported DS / no matching DNSKEY 也指向这里。
3. 多家 DNS 服务商，只有一家在签名
你有一个会签名的主 NS（Cloudflare、开了 DNSSEC 的 Route 53），加一个不签名的从 NS。解析器随机命中从 NS 时拿不到 RRSIG，直接判 bogus。
怎么判断：分别查每个 NS：dig @ns1.yourprovider.com yourdomain.com +dnssec。有的回 RRSIG、有的没有，就是这条。
4. Key 轮换后旧 DS 没删干净
你轮换了 key，host 把新 DS 推到注册商，但旧 DS 没删（或者你删了新的、留了旧的）。解析器会把所有 DS 都拿来验，至少要有一个能对上。只剩旧 DS 而旧 DNSKEY 已经退役，链就断了。
怎么判断：dig DS yourdomain.com @8.8.8.8 返回两条 DS，但 dig DNSKEY yourdomain.com 只有新 key。旧 DS 的 keytag 在 DNSKEY 里找不到对应。
5. NSEC / NSEC3 配错导致存在性证明失败
哪怕名字存在，NSEC/NSEC3 还要证明”哪些不存在”。NSEC3 的 salt 或迭代次数配错，存在性证明无效，验证型解析器对什么都判 BOGUS。
怎么判断：dnsviz.net 会专门标 NSEC3 错误；或者 delv yourdomain.com 打印的是 ;; validating ...: no valid signature found / insecurity proof failed 这类行，而不是 ; fully validated。对一个存在的名字返回 EDE: 6 (DNSSEC Bogus) 也指向这里。
6. TTL 没过期，解析器把坏状态缓存住了
哪怕你已经修好了，解析器还会按原始 TTL（常见 1-24 小时）继续缓存 BOGUS 结论，用户继续 SERVFAIL。
怎么判断：dig 看记录都对，但解析器还在 SERVFAIL。查 TTL：dig +noall +answer +ttlunits yourdomain.com。
开始前
- 记下你在哪一侧（注册商还是 host）、什么时间开的 DNSSEC。
- 把注册商的当前 DS 记录用文本保存下来，可能要回滚。
- 看清楚注册商和 DNS 服务商是不是同一家——不是一家的话，问题基本就在这里。
- 准备一个非验证型解析器做对照测试（运营商 DNS 通常不验证）。
需要收集的信息
dig +dnssec yourdomain.com DNSKEY @8.8.8.8 +multiline输出。dig +dnssec yourdomain.com DS @8.8.8.8 +multiline输出。delv yourdomain.com @8.8.8.8输出（会直接给出验证结论和失败原因）。- 注册商 DS 记录页的截图（算法、digest 类型、key tag）。
- DNS host 的签名算法设置（Cloudflare / Route 53 等的 RSASHA256 vs ECDSAP256）。
一步步修
按从便宜到破坏性的顺序。
第 1 步：确认故障形态
delv +rtrace yourdomain.com @8.8.8.8delv 会自己做验证，并一步步打印整条链。健康的区最后会输出 ; fully validated；断掉的区会输出 ;; resolution failed: SERVFAIL，外加一行原因，比如 ;; validating yourdomain.com/A: no valid signature found、broken trust chain 或 RRSIG has expired——这行原因就点名了断的那一环。动手前先把这段输出存下来，作为修复前后的对比证据。
然后确认记录本身没问题、只是 DNSSEC 在出错：
dig +cd yourdomain.com @8.8.8.8+cd（checking disabled）会跳过验证。如果加了 +cd 能拿到正确答案、不加就 SERVFAIL，那么你的记录是对的、DNSSEC 是断的——正是本文要修的情况。对照开头那张表里的 EDE 码，先定位到对应原因，再去动注册商。
第 2 步：从当前 DNSKEY 重新生成 DS
大多数 DNS host（Cloudflare / Route 53 / DNSimple）都有一个”给注册商的 DS”面板。打开它，把当前的值复制下来。不要相信半年前粘过的那个值。
如果你自己用 BIND 跑权威：
dnssec-dsfromkey -2 Kyourdomain.com.+013+12345.key-2 强制生成 SHA-256（digest 类型 2）的 DS。截至 2026 年 6 月，只有 digest 类型 2 是安全的：SHA-1（digest 类型 1）已经被验证型解析器淘汰，注册商上一条类型 1 的 DS 在哪儿都验不过。文件名里的 +013 表示算法 13（ECDSAP256SHA256），也是 RFC 8624 推荐的算法；算法 8（RSASHA256）还能验，但正在被淘汰。不管你的区实际用什么算法签名，DS 里的算法编号都必须跟它完全一致——区用 13 签、DS 却写 8，就是 EDE 6 Bogus。
第 3 步：在注册商替换 DS
登录注册商，删掉旧 DS，加上第 2 步拿到的新 DS，所有字段都要对上：key tag、算法编号、digest 类型、digest。保存。
部分注册商（GoDaddy、老版 Namecheap）让你贴整条字符串，格式：
12345 13 2 ABC123DEF456...（keytag、算法、digest 类型、digest）
第 4 步：用验证型解析器确认链通了
dig +dnssec yourdomain.com @1.1.1.1要看到 flags: qr rd ra ad——其中 ad 标志（authenticated data）才说明解析器验证通过。没有 ad = 没验证；SERVFAIL = 还没修好。
每次重试之间等 5-10 分钟，公共解析器会缓存 DNSSEC 负结果。
第 5 步：实在修不好就先临时关掉 DNSSEC
修不动、用户又在受影响的话，去注册商把 DS 删掉：
- 登录注册商。
- 删除 DS 记录。
- 等父区 NS 的 TTL 过期（顶级域 NS 的 TTL，通常 6-24 小时）。
父区 TTL 过期后，信任链层面你的区就是未签名的，解析器不再验证、当普通 DNS 返回。站点恢复。然后你离线把 key 弄对，再重新开。
第 6 步：在已知公共解析器手动清负缓存
主流公共解析器都有刷新页面（都有 reCAPTCHA 拦自动化，不需要证明域名所有权）：
- Google Public DNS：
https://dns.google/cache（apex 和出问题的子域都刷一遍） - Cloudflare
1.1.1.1：https://one.one.one.one/purge-cache/——把记录类型选成DS和DNSKEY，别只刷A，因为被缓存成 BOGUS 的就是这两类
逐个提交，能缩短用户卡在 SERVFAIL 的时间；Cloudflare 几秒内就会把这次清缓存推送到所有数据中心。
验证
dig +dnssec yourdomain.com @8.8.8.8返回带 RRSIG 的 ANSWER 区、头部带ad（authenticated data）标志、且没有EDE行。delv yourdomain.com @8.8.8.8输出; fully validated。dnsviz.net/d/yourdomain.com/dnssec/显示从根（.）到你的区的完整绿链，没有红色错误。- 至少 2 个公共解析器（
1.1.1.1/8.8.8.8/9.9.9.9）的普通（非+cd）查询都成功。 - 用户那边反馈站点能打开。
长期预防
- 用支持 CDS / CDNSKEY 自动同步的注册商 + DNS host 组合（Cloudflare 加很多 TLD 都支持），注册商自动从 host 拉 DS，省去手动复制出错。
- 轮换 key 时按两步走：(1) 推新 DNSKEY、等一个 TTL；(2) 在注册商推新 DS、再等一个 TTL；(3) 才退役旧 key。
- 任何固定生命周期的 DNSSEC key 都加一个日历提醒——静默过期就是一个等着爆的 P1。
- 每天 cron 跑一次
dnsviz或dnssec-monitor，链漂移要进告警、别等用户工单。 - 团队里写清楚 DNSSEC 谁负责。把注册商权限和 DNS 权限分给两个人，就是这个故障反复复现的温床。
常见坑
- 在 host 那边打开了 DNSSEC，但 DS 从来没复制到注册商。父区没链接，host 一开始签名，所有 validator 立刻判 BOGUS。
- DS 粘错一位然后等 DNS “自然恢复”——它不会自己好。
- 不同 key 用不同算法：KSK 用算法 8、ZSK 用算法 13，validator 行为不一致，有的过、有的挂。
- 轮换之后旧 DS 留着”以防万一”。旧 DS 指向已删除的 DNSKEY = BOGUS（取决于解析器实现），哪怕旁边还有一条新 DS。
- 忘了关 DNSSEC 同样要等父区 TTL：删 DS 不会瞬间不 BOGUS。
FAQ
Q：运营商 DNS 没事，Google DNS 一直 SERVFAIL，是我的域名挂了吗？
对，用验证型解析器的用户全挂。运营商 DNS 不验证，照旧返回缓存数据。Google / Cloudflare / Quad9、绝大多数企业 DNS 都验证——这些用户就是真挂。按真实故障处理。
Q：直接把 DNSSEC 关了行不行？
短期行。在注册商删 DS、等父区 TTL，区就回到普通 DNS。失去完整性保护、换回可用性。等你搞清楚原因再重新开。
Q：BOGUS 缓存能挂多久？
受 SOA 最小 TTL 或那次失败验证的负 TTL 约束，大多数解析器在 5 分钟到 1 小时，激进缓存能到 24 小时。用上面提到的 flush 页面能缩短。
Q：注册商有两条 DS、host 只有一把 DNSKEY，正常吗？
轮换中正常（新 DS 先发、旧 key 后退）。但不能长期这样。旧 key 从 DNSKEY RRset 完全消失之后，把对应的旧 DS 删掉，dig DS 才干净。
Q：我的 dig 输出显示 EDE: 7 (Signature Expired)，怎么办？
你的签名器停止给区重新签名、RRSIG 过期了。这不是 DS/注册商的问题，要去 DNS host 修。托管型 host（Cloudflare、Route 53）通常重新保存任意一条记录、或把签名开关切一下就会强制重签；自建 BIND 要检查 dnssec-policy / 自动重签是否在跑、以及服务器时钟是否准（EDE: 8，Signature Not Yet Valid，是同一类问题，由时钟跑快引起）。重签之后，按第 6 步刷一下解析器缓存。
Q：delv 和 dnsviz 都说验证通过，但 Cloudflare 还在 SERVFAIL，为什么？
几乎都是缓存里那条 BOGUS 结论还没过期（原因 6）。delv 和 dnsviz 是直接向权威查询、不走解析器缓存，所以它们立刻看到修好的状态，而 1.1.1.1 还在按 TTL 返回旧的负结果。用 https://one.one.one.one/purge-cache/ 页面、记录类型选 DS 和 DNSKEY 刷一下，再重试。
相关问题可看 CAA 记录挡了证书签发、绑了自定义域名但 SSL 没发、Name server 跟 DNS records 分不清。