迁移站点后，域名仍能打开，浏览器却报 SECONDS bogus，监控也提示验证失败；更棘手的是，权威 DNS 返回正常，递归解析器却持续拒绝结果。此时若凭一条 SERVFAIL 重装服务，真正断点可能在根信任锚、顶级域 DS、域名 DNSKEY 或区域签名中的任意一层。盲目改配置，只会把密钥、算法与缓存问题混在一起。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：starrydns（服务器与主机），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
DNSSEC 的委派不是“父区给子区一个密钥号”这么简单。验证器先用内置根信任锚验根 DNSKEY 与 RRSIG，再由根密钥验顶级域 DS；顶级域密钥验注册域的 DS，最后用注册域 DNSKEY 验 DNSKEY 集及业务记录签名。每跨一级，都同时检查签名有效性、时间窗和密钥是否被上一级授权。
DS 与 DNSKEY 的关联靠摘要计算，不是只看 Key Tag。父区 DS 应命中子区至少一把可用的 DNSKEY；子区 DNSKEY 集必须有对应 RRSIG。若轮换 KSK，父区 DS 的摘要也必须同步更新，并保留旧链直到旧 DS 过期。仅在子区增加新 DNSKEY、却未发布匹配 DS，验证器仍会把完整链条判为无效。
先固定证据：用支持 DNSSEC 的递归查询分别取得父区 DS、子区 DNSKEY 和 DNSKEY 集 RRSIG，再对 A、AAAA 等业务记录验签。随身服务器上运行递归解析器时，还要记录查询出口、解析器版本与缓存状态；同一时刻换多个公共解析器复测，可排除单点故障，但不能代替层级检查。
随后按现象归类。密钥问题表现为 DS 找不到匹配 DNSKEY、Key Tag 变化或签名过期；算法问题是父区 DS 的算法字段、子区 DNSKEY 算法及验证器支持集不兼容；配置问题包括父区漏发 DS、子区未签名、委派 NS 错误或签名区配置未加载；缓存问题则是权威数据已正确，但递归端仍返回旧 DS、旧 DNSKEY 或旧否定缓存。比较父区 SOA serial、子区 DNSKEY TTL 与委派 TTL，确认变更传播窗口；证据留存后再清理缓存或重启解析器。若权威端和递归端都一致地指向同一层级，才能判定是密钥、算法还是配置造成，而不是缓存假象。
DNSSEC 的委派验证是从根信任锚逐级核对 DS 记录、DNSKEY 与 RRSIG 的过程。父区 DS 必须与子区同名 DNSKEY 的密钥标识、算法和摘要类型一致；子区更换密钥而父区仍保留旧 DS 时，验证器会在委派点返回 bogus 响应。
排查时先看失败原因码：无 DS 多表示委派未声明签名；DS 不存在说明父区声称信任子区却缺少匹配摘要；DNSKEY 验签失败才进入密钥与算法检查。区分“无记录”和“有记录但不匹配”，可避免盲目修改配置。
DS 位于父区的委派边界，并指向子区 DNSKEY。委派 www.example.com 时，DS 应放在 example.com 一侧，而不是 www.example.com 自身之下。CDS、CDNSKEY 属于委派发现扩展，不能当作普通 DS；通配符委派还需确认其覆盖范围。
若权威数据看起来完整，边缘代理仍可能截断信任链。应从权威服务器、公共递归解析器和客户端分别测试，比较 AD 标志、SERVFAIL 与 bogus 结果，并确认 CDN 节点返回的是原委派的 DS。
DNSKEY 轮换应按“先发布新密钥、再签名、随后切换 DS、最后撤销旧密钥”执行，并保留旧密钥过渡期。DS 通常指向 KSK，区域数据多由 ZSK 签名；只换 ZSK 通常无需改 DS，替换 KSK 则必须让父区 DS 与子区 DNSKEY 同步。
常见坑包括提前删除旧 DNSKEY、DS 已切换但新密钥尚未下发，以及新旧密钥标识不一致。应先按 flags、protocol 确认 KSK 或 ZSK，再把 algorithm、key tag 与 DS 逐项比对；同时检查 TTL、负缓存和区域传送延迟，避免验证器尚未拿到新密钥。
签名算法兼容性也可能成为断点：旧算法可能已被递归器淘汰，新算法启用后，父区 DS 的摘要类型又可能与 DNSKEY 不匹配。迁移时应同步核对 DS、DNSKEY、RRSIG 的 algorithm 和 digest type，并检查验证器支持列表、签名时间戳及机器时钟。
可执行检查清单：①确认根信任锚与本机验证链；②在每个委派边界查询 DS，核对名称、位置、key tag、algorithm、digest type；③查询 DNSKEY，确认 KSK、ZSK 的 flags、protocol 和密钥状态；④检查 RRSIG 覆盖范围与有效期；⑤从权威和递归视角复测，记录 bogus、SERVFAIL、EXPKEY、EXPSIG 等原因；⑥变更时保留旧 DS 与旧 DNSKEY，按“新增等待传播切换观察撤销”执行，并用 dig +dnssec、delv、drill 交叉验证。发现不一致时，先修复最靠近根部的断点，再逐级向下复测。
