APNIC Labs 持续十年的 TLD 注册商观测显示，DNSSEC 部署中运维人员在内部流程上遵循开发者建议，但在涉及时间参数与跨运营商交互的密钥轮换环节普遍偏离推荐做法，揭示开发者假设与实际运维的结构性分歧。
观测对象与方法：
为何选择 TLD 注册商？研究组给出两个理由：一是根区列表提供了稳定、客观的观测名单，避免主观划线；二是 TLD 运营质量直接决定下层域名能否正常工作，可视为“运维良好”的基准样本。项目通过抓取区内 DNSSEC 相关记录（DNSKEY、RRSIG、DS 等），推演各注册商的密钥生成、签名、发布与撤销全流程，形成长达十年的行为序列。
内部与外部决策的分野：
数据呈现明显的“内外有别”：算法选型、密钥长度、签名有效期等完全由单一运营商掌控的参数，高度贴合开发者文档；反之，密钥滚换周期、预发布间隔、DS 记录提交时窗等需要与注册局、注册商或父区协调的时间型参数，普遍偏离推荐值。例如原文指出运维团队倾向于拉长滚换周期以减少协调成本，导致密钥实际寿命远超设计预期。
密钥生命周期暴露的核心矛盾：
DNSSEC 的基础假设是私钥终将被破解，因此必须定期轮换，且轮换过程在区数据中留下完整痕迹。观测发现，运维侧为规避跨组织协调风险，常采取“锁定密钥、延长签名有效期、人工介入应急滚换”等策略，使密钥生命周期呈现非周期性、长尾分布。这并非技术无能，而是在可用性与安全性权衡中，运维侧理性选择降低操作复杂度。
对网络工程师而言，这十年观测提示：部署文档若仅给出“最佳实践”而不提供跨组织协调的标准化流程与工具链，密钥滚换等时序敏感环节必然走样。下一步改进应聚焦于父子区同步自动化、滚换状态机标准化，而非继续堆砌参数建议。
原文: APNIC Blog（2021-09-20）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog