DNSSEC上线后，域名仍能正常解析，但递归解析器返回 SERVFAIL，常见原因是更换了 KSK，却没有把父区的 DS 记录同步到委派区。若新旧密钥交接时间错位，签名链会在 DNSKEY、DS 或 RRSIG 之间断开；更麻烦的是，缓存中的旧 DS 还会把问题拖到 TTL 结束之后。
这类故障很少只表现为“签了名就一定安全”。密钥发布、签名刷新、父区 DS 更新、递归缓存和上游验证器必须同时处于一致状态。下面围绕 DNSSEC 签名链、KSK 与 ZSK 的轮换顺序，以及 DS 同步和 RRSIG 过期的判断方法展开。需要批量核对签名、DNSKEY 与 DS 状态时，也可以借助 ServLlama 汇总多域名的验证结果。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：myhbd（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先沿着签名链理解KSK与ZSK轮换
DNSSEC 的验证路径是：解析器取得 DNSKEY，使用其中的 KSK 计算 DNSKEY 的 RRSIG，再由父区 DS 指向对应 KSK，验证 DNSKEY RRset；随后用 DNSKEY 中的 ZSK 验证 A、AAAA 等数据的 RRSIG。KSK 负责建立父子区的信任锚，ZSK 负责日常业务签名，两者生命周期不同，轮换节奏也不同。ZSK 应先预发布，确保所有签名者都拿到新密钥且旧密钥仍可签名，再逐步切换并撤销旧 ZSK。
KSK 轮换则分为“预发布、等待 DS 同步、正式使用、撤销旧密钥”几个阶段。新 KSK 发布后，父区 DS 不能立即切换；必须等旧 DS 缓存基本消失，再把父区 DS 改为新 KSK，并保留旧 KSK 的可验证窗口。只有确认递归解析器已经取得并缓存新 DS，才适合移除旧 KSK。这里的关键不是命令是否执行，而是 DS 变更是否抵达每个父区服务器。
按验证链定位失败，再安排恢复动作
出现验证失败时，先看响应是 SERVFAIL 还是 bogus，并区分“解析结果错误”和“签名验证错误”。用带 DNSSEC 查询的 dig 工具分别查看 DNSKEY、RRSIG 和 DS：DNSKEY 缺少对应 KSK，通常是本地发布或预发布遗漏；DS 指向的密钥标识在子区不存在，说明父子区没有同步；DNSKEY 的 RRSIG 已过期或 inception 时间异常，则要检查签名器时钟、签名周期和刷新任务。RRSIG 过期并不等于 ZSK 轮换失败，它更常见于签名器停摆、时钟漂移或刷新队列堵塞。
应急恢复应优先恢复可验证状态，而不是直接删除 DS。确认旧 KSK 仍可用时，可先恢复旧 DNSKEY 和旧 DS 的服务路径，再重新发布新 KSK 并逐步推进 DS 切换；若 RRSIG 过期，则先修复时间同步和签名刷新，确保新签名的 inception 与 expiration 覆盖当前时间。长期监控应同时关注 DS/DNSKEY 密钥标识不一致、RRSIG 剩余有效期、签名生成延迟、父子区 DS 变更时间以及 SERVFAIL 比例，并设置至少提前数日的告警阈值，避免等到缓存失效后才发现轮换断链。
进入实操阶段后，重点不再是生成新密钥，而是保证验证者在整个过渡期都能沿DNSSEC签名链找到可信锚点。轮换记录应写明区域名、密钥算法、Key ID、签名窗口、负责人和回滚条件，避免只更换密钥却遗漏父区同步。
轮换中的签名链衔接与易踩坑
KSK轮换应采用“先发布新KSK，再新增DS，最后撤销旧DS”的顺序。新KSK写入子区DNSKEY RRset并完成签名后，在父区添加对应DS；等待父区签名、递归缓存和各级解析器同步后，再让区域改用新KSK签名。旧DS不可过早删除，否则尚未收到新DS的验证者会因找不到认证路径而返回SERVFAIL。
ZSK预发布是先在DNSKEY RRset中发布新ZSK，并用它预签数据；至少等待一个旧签名有效期加缓存传播窗口，再切换日常签名。这样即使部分递归服务器暂时只缓存了旧ZSK，仍可验证新生成的RRSIG。切换完成后应继续保留旧ZSK及其签名，直到旧RRSIG全部过期，再删除旧公钥并撤销对应预签名。
常见的坑包括DNSKEY TTL过短、只改子区却未改父区DS、DS记录同步顺序错误，以及旧RRSIG尚被缓存时立即清理旧密钥。密钥算法、Key ID和DS摘要必须逐项核对；删除旧记录后，即使递归缓存暂时保留旧数据，TTL到期仍可能暴露断链。
故障定位与可执行检查清单
出现验证失败时，先区分“签名无效”和“信任链断裂”：用dig +dnssec分别查看DNSKEY、RRSIG与DS，确认RRSIG的Key ID能对应DNSKEY中的Key ID，签名覆盖时间也未越界。若RRSIG过期，安全区通常会被判定为bogus并返回SERVFAIL；此时应检查权威服务器是否持续续签以及系统时钟是否准确，而不是反复删除缓存。
执行清单：①比对子区DNSKEY与父区DS的算法、Key ID和摘要；②确认新旧密钥按计划并存；③检查每个RRSIG的inception、expiration及当前UTC时间；④核对权威区、第二权威节点和公共递归的答案；⑤使用dig +dnssec +trace定位断点；⑥检查防火墙、NTP和签名任务日志；⑦持续监控至少一个旧签名有效期，确认没有SERVFAIL后再撤销旧DS；⑧保留旧密钥及回滚配置，直到观察期结束。
最终，DNSSEC轮换应被视为受时序约束的发布流程，而不是一次文件替换。按照“预发布并行签名同步DS持续观察撤销旧资源”的顺序推进，并自动监控每个签名链节点，才能把风险控制在可回滚范围内。
喜欢 
顶
难过
囧
围观
无聊
