10月11日，互联网最受信任的那把钥匙要换手了。KSK-2017，这把从2018年10月11日起为DNS根区签名的密钥签名密钥，将停止签名。接棒的是KSK-2024。整整八年，一天不差，而整个DNS的信任链都要穿过这次交接。
时间表不是传闻，它来自IANA自己的轮换页面：2025年1月11日发布，全年通过RFC 5011建立信任，2026年10月11日，"后继密钥计划为根区签名；当前密钥将不再签名"。
如果你自己跑着验证型解析器，这篇文章是写给你的。如果你不跑，它同样是写给你的——因为解析器错过这个窗口时的失败方式安静得漂亮：一切看起来正常，域名却停止解析。
到底在发生什么
DNSSEC把信任从根往下串起来：根区为自己的DNSKEY集合签名，你的解析器持有一个信任锚——它相信根区使用的公钥——根以下的每个应答都沿着这条链向上验证。根区当前的密钥签名密钥KSK-2017（密钥标签20326）已经当了八年的锚点。
这次轮换被刻意放得很慢，因为你没法重启整个互联网的信任：
- 2025年1月11日——KSK-2024（密钥标签38696）与KSK-2017一起出现在根区的DNSKEY记录集中。什么都没变，两把钥匙只是同时在那里。
- 大约从2025年2月起——实现RFC 5011（自动信任锚更新）的解析器开始观察新密钥。该机制要求30天的静置期，期间定期查询，之后解析器才会把新密钥提升为信任锚。
- 2026年10月11日——KSK-2024开始为根区签名。KSK-2017停止。
整套设计只假设了一件事：你的解析器在整个过渡期一直在运行、一直在定期查询。RFC 5011是自动化，不是魔法——它需要大约30天的在线时间才能提升一把新密钥。一台关机一个月的验证器、一台缓存了锚点的设备、一个在静置窗口结束后恢复的虚拟机快照——它们中的任何一个，在10月11日早晨可能仍然只信任KSK-2017。
谁会坏，坏得多安静
信任锚里只有KSK-2017的解析器，面对由KSK-2024签名的根区，在信任链上无路可走。根区变得无法验证，其下的一切也随之无法验证。
接下来发生什么取决于配置，而这正是比硬故障更该让你担心的部分：
- 严格验证会大声失败——查询返回SERVFAIL。烦人、可见，一旦知道原因几分钟就能修好。
- 机会式验证会无声失败——解析器回退到未验证的应答。什么都没坏。你只是不再获得DNSSEC的保护，没有错误，没有你配置过的日志行，没有横幅提示。黑盒没有坏；它只是悄悄停止了检查。
谁在风险池里？不是那些大型公共解析器——它们已经提供新密钥好几个月了。风险池是没人统计的那群人：自托管的Unbound、BIND、Knot、PowerDNS；办公室地下室里的DNS设备；固件自2024年起就没更新过的嵌入式盒子；你八月暂停的那个homelab虚拟机。恰恰是最不可能在本周读到轮换公告的那些运维者——而且，今天查过之后我可以告诉你，dev.to上关于这件事的文章是零。
凭据——五分钟，三项检查
今天就把这些跑一遍，针对你运营或依赖的任何东西：
- 添加阶段的凭据：今天根DNSKEY RRset里必须两把钥匙都在。20326是KSK-2017（10月11日退出），38696是KSK-2024（10月11日进入）。
- 通过你自己的解析器做端到端验证——"fully validated"意味着穿过根区的链条完整。
- 自托管验证器上的信任锚状态——10月11日之前，KSK-2024必须出现在正在运行的解析器的受管状态里。
检查一是过渡本身按计划进行的凭据：两个密钥标签出现在同一个RRset里，正是轮换"只添加"阶段在起作用。检查二告诉你验证到底能不能用。检查三告诉你10月12日它还能不能继续用。
为什么没人在看
2017年的第一次根KSK轮换上了全球新闻——而且被推迟了，因为测量显示大多数验证型解析器还没准备好。它最终在2018年10月11日完成。这一次落地的动静只有当年的一小部分，还撞上两个模型发布和一个agent API发布周期。十年一遇的基础设施故事只得到一个日历条目；本周的发布得到头版。
这里有一种凭据形状的讽刺：轮换是网络领域最可公开验证的事件——每个阶段都能用dig检查——它仍然会让人措手不及，因为验证需要有人去跑那个检查。机制在2017年就带着自动化（RFC 5011）和仪表盘发布了，而存活下来的失败模式不是密码学的。是一个从未看过一眼的运维者。
热门跟贴