摘要

  • 真正供验证器使用的 DS RRset 位于父区。CDS/CDNSKEY 表达子区希望父区变成什么样；已有 DS 时，现有信任链能认证轮换信号，首次建链时这条链恰恰尚不存在。
  • RFC 9615 借用每个适用的域外权威服务器名称所处的既有 DNSSEC 链，并要求子区顶点与各个信号位置给出相同内容。它证明的是已列运营者的一致技术同意，不是注册人所有权。
  • 父方准入、摘要算法政策、DS 写入、TTL 消退和解析器验证必须分别留证。算法零是撤掉整组 DS 的破坏性请求，不能当作普通换钥的空集合。

一份能自证一致、不能自证授权的请求

一家企业在托管 DNS 平台上打开 DNSSEC。平台生成密钥，在区顶点发布 DNSKEY、CDS 和 CDNSKEY，并为这些 RRset 生成有效签名。三台权威服务器返回同一组内容，控制台显示“准备完成”。但上级区还没有这个域名的 DS。

验证器无法从子区自身开始。若“某把 DNSKEY 能验证包含它自己的 RRset”就足以建立信任，攻击者也能生成一套同样自洽的密钥和签名。DS 的作用正是从父区已有的可信状态指向被接受的子区密钥。第一次发布 DS 之前，这个指向尚未存在。

因此，签名回答了“谁持有对应私钥”，没有自动回答“谁有权替这个注册人改变委派”。DNS 运营商控制服务面，注册人通常选择运营商，注册商掌握账户关系，注册局或其他父方代理能够把 DS 放进父区。四者可能属于同一公司，也可能隔着多层转售关系。

CDS/CDNSKEY 的价值在于不再要求每次 KSK 或 CSK 轮换都由人复制摘要。手工流程容易漏步、抄错，也会让运营者推迟必要换钥。自动化应消除重复劳动，却不能消除对权力来源的说明。

子区提出目标，父区留下记录

DS 是父区数据。它用密钥标签、算法、摘要类型和摘要把父区的认证状态连接到子区 DNSKEY。CDS 与 DS 字段相同，但记录类型不同；CDNSKEY 携带公开密钥，让父方代理按自身支持的摘要类型计算 DS。

RFC 7344 把 CDS/CDNSKEY 定义为期望的替换状态。消费者比较它与现有 DS，把差异转换为父方系统里的增加和删除。这不是子区对父区进行直接 DNS UPDATE，也不是子区把一段权威数据“传给”父区后自动生效。父区仍然对自己的区内容负责。

两个记录都不存在时，含义是“不变”。同步成功后，子区可以移除信号；查询失败、空回答或正常清理都不代表删除 DS。自动系统若把“没有读到”理解为“目标为空”，会把通信故障升级成信任链撤销。

父方还要选择消费方式。它可以直接采用 CDS，也可以从 CDNSKEY 计算 DS；它可以只支持其中一种，或让另一种作为备用。摘要类型仍受本地政策约束，因此父区生成的 DS 可能在摘要集合上不同，却仍指向同一把子区密钥。

这是一组边界清楚的动作：子方选择希望被表示的密钥，父方代理认证并判断准入，父区发布，解析器验证。记录格式统一，并不意味着决定权统一。

已有 DS 为轮换提供桥梁

若父区已有 DS 对应当前 DNSKEY，新信号可以沿现有链认证。RFC 7344 要求区顶点的 CDS/CDNSKEY 由同时出现在当前 DNSKEY 与父区 DS 关系中的密钥签名，并要求应用后不破坏连续性。

旧的安全入口由此授权一次受限过渡，而不是给所有已签名内容颁发永久通行证。父方代理仍需获取当前 RRset、完成验证、比较父区状态，并阻止旧观察覆盖新观察。RRSIG inception 与 SOA serial 可帮助判断先后，但消费者也要保存自己已接受的状态。

父区发布新 DS 后，轮换还没有结束。不同解析器缓存着不同时间取得的 DS、DNSKEY 和 RRSIG。子区必须在所有权威节点提前提供新密钥，并保留旧密钥，直到旧 DS 不再可能被使用。单个 API 成功或一台父区服务器出现新记录都不足以触发退休。

BIND 当前文档把这段等待做成可观察状态：它能够发布 CDS/CDNSKEY、查询配置的 parental-agents，并在所有预期代理都返回目标 DS 前暂停换钥。若父区不消费信号，仍需人工提交。子方软件有能力，不等于父方已经参加协议。

第一次建链必须从别处借来信任

RFC 8078 为首次 DS 提供过多种准入方案：已认证的账户界面或 API、额外注册信息检查、跨地点持续观察、挑战，或在创建委派时处理。这些方案可以适应不同商业和法律关系，但它们没有从未安全的子区内部创造出 DNSSEC 验证路径。

RFC 9615 在至少存在一个域外权威服务器名称时提供更强的 DNS 内认证。它在父区 NS 所列的每个名称服务器主机名前加 _signal，形成运营商信号域；再在其下用带 _dsboot 的名称标识具体子区，发布与子区顶点一致的 CDS/CDNSKEY。

关键是信号副本由信号区既有的 DNSSEC 链签名。父方代理先通过运营商命名空间验证这份副本，再把它与未安全子区直接返回的内容比较。信任不是从子区的自签名凭空产生，而是从已经受信的运营入口迁移到新的子区安全入口。

执行时，父方首先确认目前没有 DS，并读取父区一侧的 NS。它绕过缓存，直接向每一台所列权威服务器查询子区顶点信号；再经受信解析器验证每个适用的域外信号；最后按记录类型检查所有 RRset 是否完全一致。

任一环节失败都必须停止：权威服务器无响应、信号未通过 DNSSEC、某处为空而另一处非空，或内容不同。若所有名称服务器都在子区域名之内，信号路径仍依赖尚未安全的子区，RFC 9615 就无法完成。

这种严格性限制了多运营商环境里的单方行动。某一家 DNS 提供商不能在其他权威仍展示不同密钥时，让父区只采用自己的安全入口。RFC 8901 在后续多签名运行中也要求提供商构造共同的 CDS/CDNSKEY 视图，否则父区面对的是互不兼容的“正确答案”。

运营者同意不等于注册人知情

RFC 9615 认证的是一个具体陈述：父区所列权威服务器背后的运营者愿意为该子区签名，并且认可同一组密钥材料。它不证明是谁签署了服务合同，也不证明组织内部谁批准了这次变更。

规范明确指出，DNS 运营者可能在域名所有者并不明确知情时加入这些记录，并建议在创建区时或通过邮件告知。因此，合规的一键启用、误操作和被盗的提供商账户，都可能产生密码学上真实的信号。真实性不能替代授权调查。

父方代理需要把技术控制与可审计的委派关系连接起来：谁可请求首次开启、谁可轮换、谁可请求回到不安全状态，所有者何时收到通知，以及如何取消意外操作。DNSSEC 验证证明数据没有在既定链上被替换，不证明链外的制度授权。

QNAME minimization 也属于这条证据路径。RFC 9615 警告，若查询暴露完整信号名称，上游父区可能尝试用自己的签名回答而不继续 referral。最小化能缩小这种替换面，但仍要验证最终信号区、名称和一致性集合。

算法零不是“没有选新钥匙”

RFC 8078 定义了两个精确的单记录形式：CDS 0 0 0 0 与 CDNSKEY 0 3 0 0。算法零不是可用的 DNSSEC 签名算法；在这里，它要求删除父区全部 DS RRset。

父方验证信号并通过其他准入检查后才执行删除。子区随后仍需等待父区相关 TTL 消退，才能停止签名。若 DNSKEY 先消失，而解析器缓存里仍有 DS，验证器会看到一条指向不存在密钥的链并把域名判为 bogus。

Cloudflare 当前的状态设计给出一个实现例子：在 pending-disabled 与 disabled 阶段仍然签名，并发布算法零信号；父区 DS 消失以后，后续 deleted 状态才移除 DNSSEC 记录。产品名称不是标准，但它展示了为什么“关闭”必须被拆成请求、父区变化、缓存退场和子区停签。

回到不安全状态会降低保护，也可能丢掉以后重新认证所需的链。因此它应拥有独立通知、审批、TTL 计划和恢复路径。只有精确的已签名删除信号才表示删除；列表为空或采集失败都不具备同等含义。

证据必须穿过委派切点

变更前，记录父区 NS 与 DS、每台子区权威服务器的直接回答、每个信号名称及其验证链、内容一致性、鲜度与重放判断、父方摘要政策、准入依据和计划执行的 DS 差异。账户与合同授权要作为另一条证据保存。

发布后，观察父区全部权威节点，等待明确的 TTL 窗口，确认各子区服务器都提供必要的 DNSKEY 与签名，再从多个网络进行验证查询。控制台绿色只说明一个系统接受了命令；父区回答只说明记录状态；成功验证才说明某条实际路径闭合。

停止决定同样要入账。一台权威不同意、信号链无效、摘要不受支持或委派完全位于子区域名内，都是边界正常工作的结果。只有能解释为什么没有执行，自动化才不会在下一次被人当作“卡住”而绕过。

来源