计划于2026年10月11日变更域名系统（DNS）根的密钥签名密钥。这将是其历史上第二次变更。当时，密钥标识符为38696的KSK-2024将取代标识符为20326的KSK-2017。这项变更尤其关系到验证DNSSEC的DNS解析器运营者，因为如果不信任新密钥，使用这些解析器的用户可能无法访问本来正常运行的网站。
信任链发生了什么变化？
DNSSEC使用加密签名来验证DNS记录是真实的且未被修改。信任链从解析器预先信任的公钥开始，该公钥称为信任锚，随后从DNS根延伸到.com等顶级域，再延伸到最终域名。
区域签名密钥（ZSK）对根区域记录进行签名，而密钥签名密钥（KSK）对包含根密钥的DNSKEY记录集进行签名。因此，KSK轮换会改变解析器用于验证其余信任链的起点，即使签名算法保持不变。
网站运营者需要采取行动吗？
大多数网站运营者不需要更改其域名设置。管理DNSSEC解析器的运营者则应确认解析器信任KSK-2024；如果缺少该密钥，还应按照软件供应商的说明更新信任锚。
Cloudflare表示，其域名专用DNS、1.1.1.1或Gateway DNS服务的用户无需采取行动，因为其系统已经信任新密钥。KSK-2024已于2025年1月11日加入根区域，这使支持按照RFC 5011自动更新的解析器有充足时间发现并接受该密钥。此外，自2024年7月起，Cloudflare已将该密钥加入其解析器软件内置的信任锚中。
如何测试准备情况
Cloudflare提供了一个测试工具：dnstest.dev/ksk-2024。该工具会询问浏览器所使用的解析器是否信任新密钥。测试依据RFC 8509，该标准定义了一种名为Root Key Trust Anchor Sentinel的机制，用于查询信任锚状态。
测试使用两个相反的名称：is-ta-38696用于确认该密钥受到信任，not-ta-38696用于确认该密钥不受信任。对于验证DNSSEC且支持该机制的解析器，当KSK-2024受到信任时，第一个名称应返回有效响应，而第二个名称应返回SERVFAIL。
不过，不确定的结果并不一定意味着缺少该密钥；解析器可能不支持sentinel机制。此外，浏览器测试测量的是浏览器实际使用的解析器路径，可能受到安全DNS功能或VPN网络的影响。也可以使用dig工具直接向1.1.1.1发送查询。
密钥变更并不意味着算法变更
KSK-2017和KSK-2024使用相同的RSA/SHA-256算法，因此10月的事件并不是向新算法的迁移。变更将持续到2027年，届时ICANN计划撤销KSK-2017，将其从根区域中移除并删除其私钥；这些阶段与停止使用该密钥签署DNSKEY记录集是彼此独立的。
Cloudflare表示，定期轮换密钥可以限制单个私钥的使用期限，并训练运营者在进行更复杂的迁移前分发和测试信任锚。ICANN正在研究未来迁移至ECDSA P-256；此外，迁移至后量子密码也将需要新的根密钥和更新后的信任链。
为什么这条消息很重要？
实际风险不在于网站本身发生故障，而在于未做好准备的DNS解析器验证失败，这可能向用户表现为无法访问多个域名。因此，RFC 8509测试可作为解析器是否保留新密钥的实用指标，但它依赖供应商对该机制的支持，不能替代基础设施运营者对信任锚设置的审查。