ICANN于2010年6月签署DNS根区域，引入单一根密钥信任锚点，五年后根区域密钥签名密钥（KSK）按计划需滚动更新。但此前从未执行过根KSK滚动，且不确定有多少DNSSEC验证解析器支持RFC 5011自动更新机制，不支持的解析器将因持有旧密钥而失效，需人工干预恢复。
信任链结构与单一锚点风险：
DNSSEC利用域名层级构建签名链：以www.example.com为例，其区域签名密钥（ZSK）由example.com的密钥签名密钥（KSK）签署，后者再由.com的ZSK签署，.com的KSK由根区域ZSK签署，根区域ZSK最终由根区域KSK签署。验证解析器通过回溯此链至根KSK确认响应真实性。全球四分之一互联网用户的查询经DNSSEC验证解析器处理（APNIC首席科学家Geoff Huston测量数据），所有验证均依赖这一单一注入的信任材料——根区域KSK的本地副本。密码学实践建议定期滚动密钥，根区域KSK采用五年滚动周期，2015年即为滚动节点。
滚动准备与RFC 5011支持度未知：
ICANN作为IANA职能运营方，自2012年起启动首轮公开咨询，筹备历时多年。RFC 5011定义了验证解析器自动更新本地KSK副本的标准流程，但原文未给出具体数据说明当前部署的DNSSEC验证解析器中有多少比例实现了该标准。不支持RFC 5011的解析器将滞留于旧KSK值，无法按预期运行，直至运维人员手动重载新KSK。此次滚动属首次实施，操作复杂性与不确定性并存。
对运维工程师而言，核心行动是确认管辖解析器是否支持RFC 5011自动滚动；若不支持，需制定在ICANN发布新KSK后的手动更新预案，避免验证中断导致用户查询失败。同时应关注ICANN后续发布的具体滚动时间表与测试指引，提前在实验环境验证更新流程。
原文: APNIC Blog（2015-05-22）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog