摘要

  • RFC 9975 以父区当前发布的子区委派为观察范围：取出全部 NS 名称和对应的全部地址，再直接询问每一个地址。
  • NODATA 是一份有意义的权威回答；完全没有回答则需要重试、退避，并可从另一个网络观察点复核。
  • 只要相关回答不一致，父区代理就必须终止整个操作，不新增、不删除也不改写目标记录。一致性证明的是共同请求，而不是身份、授权或最终验证结果。

假设同一子区的一个服务器发布了新 CDS 密钥，另一个服务器给出经过验证的 NODATA。两台机器都可能健康，两份回答也都可能带有有效 DNSSEC 证明。若父区只采用先到达的密钥，它便把复制时差变成了信任锚变更；若忽略密钥，它也可能延误一场正常轮换。

普通解析器追求一份可用回答，因而通常无需遍历所有服务器。准备修改 DS、NS 或 glue 的父区代理却在做另一件事：它把子区的可见状态升级为命名空间上层的持久决定。这项动作需要比“能解析”更强的证据标准。

2026 年 5 月发布的 RFC 9975 正式定义了这种标准。Peter Thomassen 是该文档的唯一作者。它要求父区在处理 CDS/CDNSKEY 或 CSYNC 之前，确认委派权威服务呈现“可信的一致性”。这个词没有承诺全知，而是拒绝让一个偶然样本冒充整个服务。

由既有委派确定被询问者

检查不是从请求方提供的一份服务器名单开始。父区代理先读取父区内的子区 NS 委派，获取每个名称的所有 IP 地址，并包括可用的 glue。地址解析应经过验证，然后相关查询被直接送到每个地址。

这一顺序切断了一个利益冲突：被检查的信号不能自己挑选证明该信号的见证者。否则，一个配置错误或有意裁剪的来源可以漏掉仍发布旧状态的服务商。父区的现有委派虽然不等于法律权属，却是父区已经向互联网宣布的运行范围。

只通过递归解析器问一次 NS 名称也不等价。一个名称可以对应多个地址，不同地址可能通往不同实例；同一个 anycast 地址从不同地点也可能抵达不同节点。RFC 因此允许使用另一个网络观察点，对无回答状态再次求证。

这仍是一套有限证据。路径故障可能遮蔽可用实例，测量时刻也不覆盖永远。但有限并不等于任意：代理应保存它依据哪份委派、解析出哪些地址，以及每个地址是否真正进入了本轮判断。

NODATA 与沉默不能互换

RFC 9975 最关键的定义之一，是把 NODATA 明确算作“收到的回答”。服务器权威地作出回应，只是没有返回被询问的记录类型。对 CDS/CDNSKEY 来说，这可能表示该视图没有提出自动变更。

若一个服务器列出新密钥，另一个返回 NODATA，两者不能被平均。忽略 NODATA 会形成单向偏差：只有要求改变的服务器才有发言权，而保持现状的权威回答被当作不存在。

完全没有响应是另一种状态。丢包、路由、过滤或服务器故障都会使观察失败。父区代理应在把地址视为永久不可达之前重试。RFC 给出的退避示例为 5、10、20、40 分钟递增；具体间隔和总时限由本地政策规定。第二观察点可帮助区分服务端故障与单一路径问题。

标准并不要求无限等待。它要求运营者公开那条把“尚未观察到”转为“永久不可达”的规则。等待多久、从哪里重试、由谁升级处理可以本地化；沉默却不能悄悄被解释为同意。

不一致的唯一写操作是零写入

一旦相关状态不一致，父区代理不能选择多数、最高 SOA 序列号或最快回答。它必须放弃此次操作。拟新增的记录不能新增，拟删除的不能删除，现有集合也不能部分调整。

保留旧状态并非宣称旧状态永远正确。它只是父区目前已经发布、风险已知的基线。从两个互相冲突的子区视图中任选一个，都可能破坏解析或 DNSSEC 验证。原地不动为子区完成复制、修复多供应商分裂或采用经过认证的带外流程留下时间。

下一次尝试应重新发起查询，形成一轮新的相干观察，而不是只继承上一轮有利的回答。在某个回答已确认维持现状时，RFC 允许提前移出部分待决查询，因为后续回答只会确认不变或暴露不一致，两种情况都不会产生写入。用于报告的查询仍可继续，以补全诊断。

原子性同样阻止“先改安全的一半”。若一个 CSYNC 请求所依赖的视图互相矛盾，代理不能先移动 NS 再等待地址一致。被评估的是拟议操作整体。

CDS 与 CDNSKEY 比较密钥集合

可信一致性不是要求每个数据包逐字节相同。对 CDS/CDNSKEY，任何一处引用的合格密钥，都必须在其他相关回答中同样被引用。一处存在、另一处缺失，即构成不一致。

完全移除 DS 集合的请求也不能被特殊宽待。一份删除请求若与另一份更新请求或 NODATA 并存，就不是一个共同状态。RFC 对允许参与比较的摘要类型给出了边界；父区可在边界内选择发布策略，却不能通过本地偏好重新解释子区实际共同引用了哪些密钥。

2026 年 7 月以 Best Current Practice 发布的 RFC 10026 由 Steve Sheng 与 Thomassen 合著，它在一致性之外增加另一道门：拟生成的 DS 集合还必须维持有效的 DNSSEC 验证路径。所有服务器完全同意，也可能一致地请求一项会造成失验的错误变更。共同意图与技术连续性不是同一张收据。

CSYNC 允许不同序列号，不允许不同决定

CSYNC 需要针对字段的比较模型。收到的回答中，immediate 标志和类型位图必须一致。SOA 序列号在常规复制或多供应商环境中可能不同，所以每个 CSYNC 序列号要与来自同一服务器的 SOA 一起判断；最终得到的“是否允许更新”决定必须相同。

若 CSYNC 指定要同步 NS 或关联地址等数据集合，相关服务器返回的 RDATA 集必须相等，包括全部为空的情况。CSYNC 的其他处理顺序仍然有效，例如名称服务器与 glue 变更的先后关系。

因此，“问遍所有服务器”只是入口描述。真正的实现必须知道不同记录族允许什么差异，什么代表传播中的过渡状态，什么差异使父区无法安全推导一项变更。

通知只是门铃

Thomassen 也是 RFC 9859 的作者之一。该机制允许子区通知父侧接收者：与 CDS 有关的状态已经变化，从而减少周期扫描的等待。

通知不会跳过证据链。接收者应启动与定时器触发时相同的 DNS 查询和验证。通知送达、全地址采集、跨服务器一致性、预期 DS 验证、父区发布以及缓存过期后的可见结果，是彼此分开的状态。

若把它们压成一个绿色的“自动化完成”，最后到达的消息就会冒充此前每一步和此后结果的证明。通知改善发现速度，却不扩大请求的权力。

一致不等于有权

所有服务器给出同一值，并不能证明域名属于谁、谁有权向 DNS 服务商发令，也不能排除账户被攻破。既有 DNSSEC 链可为部分维护操作提供技术认证。首次引导时父区尚无 DS，需要 RFC 9615 所描述的路径。注册管理机构、注册商和持有者的授权控制仍然位于记录比较之外。

父区写入成功也不代表每个递归解析器已经观察到新状态。缓存会在 TTL 到期前保留旧 DS 或委派数据。子区若过早进入密钥轮换下一阶段，仍可能制造故障。RFC 10026 因此把时间、持续验证、回滚与报告视为独立运行工作。

当子区运营者无法形成一致发布时，RFC 9975 保留经过认证的带外途径。它不是绕开一致性检查的漏洞，而是不同的授权路径。多供应商之间的治理僵局，不能靠让第一个可达服务器获胜来解决。

作者身份记录贡献，而非控制面

RFC Editor 将 RFC 9975 的唯一作者记为 Peter Thomassen。公开 IETF 资料在所审查时点将他列为 deSEC 创始人兼首席技术官、SSE 执行董事、Domain Connect 主席以及 DNSOP 秘书。他也参与撰写 RFC 9615、RFC 9859 和 RFC 10026。

这些事实把他的工作置于可核实的标准演进中，却不意味着他运行每个父区代理、控制注册管理机构、认证具体实现或造成某起事故。RFC 说明最低行为；只有部署日志能证明哪些地址被问过、答案如何比较，以及冲突出现时父区是否真的未动。

这与机制本身的界线相呼应：作者姓名是贡献证据，不是对所有实现的权力；委派中的服务器名称是观察来源，不是单独改写父区的主权。

最终产品是一张决定收据

符合标准精神的系统，应保留定义范围的父区委派、解析出的全部地址与 glue 来源、查询时间和观察点、每个相关回答或 NODATA、验证结果、比较结果、重试、退避和任何永久不可达排除。

随后还要记录拟议的父区差异、持续验证检查、放弃或应用决定，以及发布后的实际父区状态。秘密凭据不应进入这份记录；重现决定所需的证据必须进入。

共同的最低规范很清楚：不得从不一致的子集推导会修改委派的结论。重试时限、替代观察点、报告渠道和允许范围内的摘要策略可以本地决定。运行代码才会证明这条边界是否真正存在于文档之外。

来源