ICANN 根区 KSK 轮换进入倒计时，10 月 11 日或影响全球解析
ICANN 官方博客近期发布提醒：ICANN 与 Verisign 正在准备历史上第二次根区密钥签名密钥（KSK）轮换。对普通用户来说，域名解析是否正常取决于这一把"互联网信任总钥匙"，而对站长来说，这可能直接影响网站与邮件的可达性。
什么是 KSK 轮换
根区 KSK 是 DNSSEC 体系中最顶层的加密信任锚，用来验证域名解析结果的真实性，防止用户被劫持到钓鱼或伪造的网站。第一次轮换发生在 2018 年 10 月；由于疫情、硬件安全模块（HSM）升级等因素，本轮轮换周期被拉长，新密钥 KSK-2024 已于 2025 年 1 月 11 日首次发布到根区。
在 RFC 5011 的自动信任更新机制下，解析器需要观察新密钥满 30 天才自动信任。数据显示，本轮采用率几乎复刻了 2018 年成功轮换的曲线，超过 95% 的已上报解析器成功识别并采用了 KSK-2024。
两次轮换时间线对比
| 项目 | 第一次（2017-2018） | 本次（2025-2026） |
|---|---|---|
| 新密钥名称 | KSK-2017 | KSK-2024 |
| Key Tag | 20326 | 38696 |
| 首次写入根区 | 2017-07-11 | 2025-01-11 |
| 根区唯一使用日期 | 2018-10-11 | 2026-10-11 |
| 观察期 | 约 15 个月 | 约 21 个月 |
观察期拉长不是坏事——留给运营者的缓冲越长，漏更的风险越低；但代价是"准备期"很容易被日常琐事淹没，而大多数事故恰恰发生在临近截止日的那几天。
关键时间点：2026 年 10 月 11 日
2026 年 10 月 11 日之后，根区将只使用 KSK-2024。这意味着：如果你的 DNSSEC 校验解析器没有在截止日前配置好 KSK-2024，届时将出现整体 DNS 解析失败，用户会直接断网。ICANN 特别强调，系统管理员必须手动核对配置，而不能假设自动更新已经生效。
需要重点检查的信任锚文件包括：
- ISC BIND：
bind.keys - Unbound / PowerDNS Recursor：
root.key - Knot Resolver：
root.keys
新密钥的 Key Tag 为 38696。如果文件中没有它，请确认自动信任更新已开启，且解析器对其存储目录有写入权限。
没更新会发生什么
假设某个办公网络的自建解析器没有在 10 月 11 日前采用 KSK-2024：当天零点过后，解析器向根区请求 DNSKEY 时发现密钥不匹配，校验链断裂，于是对所有开启校验的域名返回 SERVFAIL。用户打开任何网站都超时或报错，而邮箱客户端则会反复提示"无法连接服务器"。更麻烦的是这类故障很难直观定位——网络正常、服务器在线，但就是解析不了，排查时常常先怀疑交换机、防火墙或运营商，很少有人第一时间想到根区密钥。这也是 ICANN 反复强调"提前手动核对"的原因：自动更新机制确实存在，但一旦某台旧版本解析器因为磁盘权限、时间偏差或软件缺陷没有跟上，故障就会在无人察觉中发生。
对使用公共 DNS（如 8.8.8.8、1.1.1.1）的普通用户和大部分托管站点来说，无需任何操作；需要行动的是自建递归解析器和边缘缓存节点的运营者。
如何自检解析链路
如果你自建了递归解析器，两条命令就能确认状态。先看根区当前发布的 DNSKEY 里有没有 Key Tag 38696：
dig +dnssec DNSKEY . @8.8.8.8 | grep 38696
再用 delv 跑一次从根区到域名的完整校验链：
delv @127.0.0.1 example.com A +rtrace
返回 valid 或 fully validated 说明链路健康；报 no valid RRSIG 或 indeterminate 则多半是信任锚不对，需要先升级解析器软件，再按官方指引手动导入新锚。对已启用DNSSEC的站点，还应在域名侧确认自己的 DNSKEY/DS 记录仍然有效——很多"突然解析失败"其实发生在自己域名的签名过期上。
站长需要做什么
对绝大多数托管在专业服务商（云主机、CDN、权威 DNS 托管）上的网站来说，服务商通常会代为处理解析器的信任锚更新。但如果你自建 DNS 解析、自建邮件服务器，或在边缘网络运行缓存解析器，就需要把 10 月 11 日标记为运维节点。建议：
- 在维护清单中记录 KSK 轮换时间点，提前一周复查解析器日志；
- 用
delv或dig校验 DNSSEC 解析链路是否正常（命令见上一节）； - 检查服务器系统时间与 NTP 同步——时间偏差会导致签名验证失败，这类问题在轮换前后尤其常见；
- 做一次"只读演练"：先备份信任锚文件，确认自动更新开关和存储目录权限，再决定是否需要手动干预。
DNS 是网站可用性的地基，这次轮换再次提醒我们：基础设施的"确定性维护"远比事后救火重要。域名与 DNS 的安全加固可参考域名与主机安全。
参考：ICANN KSK 轮换资料页 https://www.icann.org/resources/pages/ksk-rollover
原文来源：https://www.icann.org/en/blogs/details/preparing-for-the-root-zone-ksk-rollover-what-you-need-to-know-27-07-2026-en