DNSSEC 排错：DS 记录里最容易填错的那一格

证书签发失败的报错是这样的：

DNS problem: DNSSEC: Bogus: validation failure
<zone>: no keys have a DS with algorithm ECDSAP256SHA256

第一眼看像是在说算法不对。实际上算法（13）是对的，摘要也是对的，错的是 Key Tag。

DS 记录的四段

.com 注册局里的 DS 记录长这样：

257 13 2 41D799191A8328F97752164AEC6F6806765942FCCA3259F3D96E094CE6B47B6E

四段分别是：

1. Key Tag —— 指向 DNSKEY 的标识
2. Algorithm —— 13 是 ECDSAP256SHA256
3. Digest Type —— 2 是 SHA-256
4. Digest —— DNSKEY 的摘要

我填的是 257 13 2 41D7...。摘要没错，但第一段填成了 257。

257 是从哪来的

257 是 DNSKEY 记录里的 flags 值，表示这是一个 KSK（Key Signing Key）。真实的 Key Tag 是另一回事——它是从 DNSKEY 的 RDATA 算出来的一个 16 位值，这次是 2371。

两个数字都在同一条 dig DNSKEY 的输出里，挨得很近：

example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
                              ^^^ flags        ^^^^ 真正的 key tag 在 RRSIG 里

Key Tag 本身不出现在 DNSKEY 记录里，要看同一区域的 RRSIG：

example.com. 3600 IN RRSIG DNSKEY 13 2 3600 20261216000000 20261016000000 2371 example.com. ...
                                                                       ^^^^ 这个

为什么校验器只说「没有匹配的 DS」

校验器拿到 DS 后，先按 Key Tag 筛选候选 DNSKEY，筛完发现一条都不剩，于是直接报 Bogus——它不会去逐个比对所有 DNSKEY 的摘要，因为那在大型区域上是不可接受的成本。

所以你看到的信息是「no keys have a DS」，而不是「digest mismatch」。这句话的误导性就在这里：真正对不上的是 Key Tag，摘要根本没被检查到。

排查顺序

遇到 DNSSEC Bogus，按这个顺序走比较省时间：

1. dig +dnssec DNSKEY <zone> @<权威服务器> —— 确认 DNSKEY 和 RRSIG 存在且未过期
2. 看 RRSIG 里的 Key Tag，和 DS 第一段对比
3. 只对匹配 Key Tag 的那个 DNSKEY 算摘要，和 DS 第四段对比
4. dig DS <zone> @<上级> —— 确认上级实际发布的 DS 和你以为的一致

第 4 步经常能直接定案：控制面板里改过 DS，但上级还没生效，或者填的时候少复制了一段。

教训

DS 记录的四段要整段复制，不要手工抄。特别是第一段——它和 DNSKEY 的 flags 都是小整数，长得像，位置也近，抄错的概率不低，而错误信息会把你引向算法和摘要两个正确的地方。