摘要

  • CDS 与 CDNSKEY 只负责表达子区希望采用的委派信任参数。父侧代理必须验证信号来源，检查委派中每个权威服务器名称的全部地址，确认两种记录指向同一组密钥，并证明变更后至少保留一条有效验证路径。
  • NOTIFY(CDS) 只能提醒父侧“现在去看”，不能替代验收。验收、父区发布、旧缓存过期和外部验证各有自己的事实边界，任何一步的成功回执都不能代替下一步。

一台服务器还停在昨天

设想一次常规密钥轮换。子区新的 DNSKEY RRset 已签名，CDS 与 CDNSKEY 也已经发布。控制台查询主服务器，看到预期指纹，于是把任务标为绿色。

父侧代理没有更新 DS。

它按照父区委派列出的每个权威服务器名称，取得全部 IPv4 与 IPv6 地址并逐个查询。多数地址返回新记录，但某个辅助节点仍在提供旧记录。此时子区对外呈现的并不是一个无歧义的未来状态，而是两个互相冲突的状态。停止更新不是官僚拖延，而是安全属性。

这是分析场景，并非对某个注册局、注册商或 DNS 服务商事故的指称。它揭示了“已经发布”这个说法的多重含义：配置系统已经写入，不等于所有权威节点已经提供；某个节点已经提供，不等于全部地址一致；子区已经提供 CDS，不等于父区已经发布 DS；父区已经发布，也不等于递归解析器已经清除旧缓存。

把这些事实分开，才可能知道事故发生在哪一层。

子区不能替父区签名

DNSSEC 在区域切点上分配责任。父区发布 DS，用它指向子区的一把 DNSKEY；子区发布并签署自己的 DNSKEY。验证器依靠这条父区到子区的链路延伸信任。

RFC 7344 定义了两种机器可读信号。CDS 的数据形式与 DS 相同；CDNSKEY 提供可由父侧计算 DS 的 DNSKEY 数据。子区运营方把它们放在子区顶点，告诉父侧代理自己希望采用哪些参数。

这里的动作是“表达”，不是“远程写入”。父侧代理可能是注册局、注册商、经销商或其他获授权角色。它有权促成父区 DS 变更，却无权把这种窄权限扩张成对子区业务模式、客户位置或换钥原因的治理。反过来，子区也不能以自己的签名代替父区承担其发布责任。

最小初始规范的意义正在这里：共同层只规定互操作必需的认证、一致性和连续性条件，其余运营选择留给各自系统。协议连接责任，不取消责任边界。

检查对象是每一个地址

RFC 9975 把“一致”说得非常具体。父侧代理要使用验证型解析器，取得父区委派中每个权威服务器名称的全部地址，包括可用的 glue，然后对每个地址查询相关 RRset。

只按服务器名称抽样不够。一个名称可以同时有多条 A、AAAA 记录，也可能指向 anycast 或不同发布后端。多供应商配置更可能在短时间内暴露不一致。父侧要验证的是委派实际向外界提供的服务，而不是某个控制面声称已完成的动作。

NODATA 也是收到的回答，不能当作不存在。只要收到的回答互不一致，操作就必须终止：原本会新增的记录不新增，会修改的不修改，会删除的不删除。父侧不能多数表决，更不能自行猜测哪组记录更新。

无响应与不一致也不能混为一谈。暂时超时应进入重试，指数退避是推荐选择；还可以从另一个网络观测点复核，排除局部路由故障。运行记录至少要分别保存“不可达”“回答冲突”“DNSSEC 验证失败”。一个笼统的 check failed 既不利于修复，也无法审计。

两种格式必须表达同一把钥匙

CDS 让子区直接给出 DS 形式的数据，因此子区影响摘要类型的选择。CDNSKEY 让父侧根据密钥计算 DS，因此父侧可按自身规则选择摘要。由于没有通用协议让子区发现父侧偏好，RFC 10026 要求在偏好未知时同时发布两者。

同时发布不是给父侧两票，而是用两种表示法说同一件事。两组 RRset 必须指向同一组密钥。若有冲突，父侧不能选择自己更熟悉的一种，也不能根据时间戳推断；它必须拒绝，让子区消除歧义。

密码算法也不是永久常量。IANA 的 DNSSEC 算法与 DS 摘要注册表会记录当前的实现和验证建议。验收记录应保存当时采用的规则版本、输入指纹、计算出的 DS 及结果，避免几年后只能看到一个无法解释的布尔值。

真正的底线是验证连续性

信号一致仍不代表结果安全。RFC 10026 要求父侧确认，若发布计算出的 DS，DNSSEC 仍可继续验证；否则取消更新。

至少要有一条结果 DS 指向的密钥，能够用合适的算法与摘要验证子区 DNSKEY RRset 上的签名。轮换期间，新旧密钥通常需要重叠，使仍持有旧 DS 的缓存和已经看到新 DS 的缓存都能找到有效路径。

这项检查为父侧权限划出正当边界。父侧保护的是自己将发布的公共信任连接，而不是判断子区选哪家供应商或为何轮换。额外的本地密码政策可能存在，但应公开、版本化、可复现。无法说明理由的“政策拒绝”，不是技术安全性的替代品。

运行代码优先也意味着：RFC 被发布、记录类型被分配、控制台显示启用，都不等于采用已经发生。只有相关实现完成验证，父区实际发布，验证器真正走通链路，兼容状态才成为事实。

第一次启用不是普通轮换

已有安全委派可以借现有 DNSSEC 链认证后续 CDS/CDNSKEY。首次启用时，父区尚无 DS，子区顶点的签名不能通过一条不存在的父链来自证。

RFC 9615 引入由 DNS 运营方签名信号区承载的认证信号。父侧验证与权威服务器相关的信号区，找到针对特定子区的 _dsboot 信息，再认证仍属不安全委派的子区 CDS/CDNSKEY。

这不是覆盖所有域名的万能机制。过长的子区名称、仅使用区内权威服务器等情况存在明确限制。因此能力声明必须区分：是否支持认证引导、是否支持已有安全委派的自动轮换、是否仍需要传统渠道。一个“已启用自动化”开关不足以表达这些差异。

删除同样不能靠沉默推断。RFC 8078 用算法 0、摘要类型 0、摘要 00 的 CDS 表示明确删除信号。CDS 消失可能是发布失败或节点滞后，不能被解释为关闭 DNSSEC。不可逆动作需要可识别、可认证且一致的请求。

通知只是门铃

父侧周期扫描大量子区会带来延迟。RFC 9859 定义 DSYNC，让父侧公布接收通知的目标。子区更新 CDS/CDNSKEY 后，可向该目标发送 NOTIFY(CDS)。

通知的作用是缩短发现时间，不是授权。收到通知后，父侧仍要重新查询权威数据、验证签名、遍历全部地址、比较 CDS 与 CDNSKEY、计算 DS 并检查连续性。

这种安排使系统能够承受通知丢失、重复或伪造。丢失只会延后发现，可由较慢的对账扫描补上；重复应是幂等的；伪造通知若没有权威数据变化，也无法制造一个可接受的 DS。

监控界面应分别显示目标发现、通知接收、扫描开始、达成一致、验收决定、父区发布和验证观察。把“通知送达”称为“DS 更新成功”，相当于让门铃替门锁作证。

父区发布之后，缓存才开始迁移

父侧验收成功可能仍停在注册系统或发布队列。更强的发布证据，是在父区权威服务器上看到目标 DS 指纹，并记录区域序列、TTL 和观察时间。

但递归解析器会按旧 TTL 保留先前的 DS。过渡期内，不同验证器看到不同父区状态并不异常。安全轮换必须保证两类观察者都至少拥有一条有效链。

RFC 10026 建议变更后暂时把新 DS RRset 的 TTL 降到约五至十五分钟，保留一段易回退窗口；只有旧 RRset 已有足够时间从缓存消失后，才恢复原值或默认值。新 TTL 无法倒流改写已经缓存的旧记录。

因此，外部 QA 不能在父区发布五分钟后宣布全球收敛。它要覆盖旧 TTL 时间窗，从多个网络查询多个递归解析器，同时记录看到的 DS、使用的子区 DNSKEY 和验证结果。一次成功只证明一条路径在一个时刻成功。

自动化必须保留逃生门

密钥维护属于持续安全运营。普通注册商或注册局更新锁本身不应暂停 DS 自动维护，因为这类锁常保护客户门户，并不能阻止同一注册商或注册局通过自己的权限行动。

不过，自动路径不能成为唯一途径。子区可能丢失签名密钥，DNS 供应商可能不支持自动化，迁移时也可能出现多个提交方。RFC 10026 要求保留另一条包括人工方式在内的 DS 维护通道。

恢复通道必须独立于已经失效的钥匙或供应商，并留下同等级别的决策记录。人工变更可以暂时暂停自动化以重建基线，但不能把一次应急操作变成永久且无说明的封锁。

来源