DNSSEC 签名区在更换密钥签名密钥（KSK）时，需将新的委派签名（DS）记录同步至父区。RFC 7344 定义的 CDS/CDNSKEY 机制允许子区通过 DNS 自身发布期望的 DS 状态，父区定期轮询并自动更新，实现信任锚维护的全流程自动化。
**CDS/CDNSKEY 机制与三类核心操作**
子区在自身权威数据中发布 CDS 与 CDNSKEY 记录，声明期望父区呈现的 DS RRset 形态。父区解析这些记录后，按需替换自身区内的 DS RRset。该机制覆盖三类典型场景：首次启用验证时写入初始 DS RRset；滚动区信任锚（通常为 KSK）或变更哈希算法（如 SHA-1 弃用）时更新 DS；彻底禁用 DNSSEC 验证时删除所有 DS 记录。作者 2017 年首次接触 CDS/CDNSKEY，2018 年访问 SWITCH 了解其对 .ch 与 .li 域名的落地实践，当时 .cz 已支持同类功能。
**SWITCH 注册商的工程化验收标准**
SWITCH 制定了公开的 CDS 处理指南，明确引导阶段的硬性条件：CDS RRset 必须在连续三天内保持一致发布，任何变更将重置计数器；所有权威服务器需可通过 TCP 访问并返回一致的 CDS RRset。这些规则旨在防止临时性配置错误触发父区误更新，同时确保父区轮询时能获得稳定信号。原文未给出具体轮询间隔与重试策略。
**实测中的引导流程与日志触发**
作者注册一瑞士域名进行实测，先在子区生成信任锚密钥并设定 CDS 于十分钟后发布，意在验证 BIND 网络研讨会中用户建议的“记录 CDS 发布日志供外部程序响应”思路。命令 `dnssec-keygen -a 13 -P sync now` 用于生成算法 13（ECDSA P-256）密钥并同步时间。实测旨在观察注册局首次查询能否检测到 CDS 并自动启动三天计数，原文未给出最终实验结果。
对运维工程师而言，CDS/CDNSKEY 将原本依赖注册商 API 或人工工单的 DS 变更转化为标准 DNS 数据交换，配合注册商侧的自动化轮询与一致性校验，可显著降低 KSK 滚换与算法迁移的操作风险。掌握引导期的连续发布要求与 TCP 一致性检查，是落地自动化信任链维护的关键前提。
原文: APNIC Blog（2021-11-02）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog