摘要

  • IETF 于 2026 年 8 月发布 RFC 10037，允许 RDAP 的域名与名称服务器对象通过 ttl0_data 选择性公开注册局数据库里配置的 DNS TTL。规范明确排除“实时 DNS 查询所见的剩余 TTL”。
  • 这个观察面没有把权力合并：注册局政策、已接受配置、权威 DNS 发布、递归缓存状态和最终业务结果仍是五个需要对账的阶段。

假设某域名将在中午更换 NS。团队先把 TTL 从一天降到五分钟，11:55 在 RDAP 里看到 300，于是把 12:00 当作安全切换点。问题是，11:54 仍可能有解析器拿到了旧 RRset，并按旧的一天期限保存。新的 300 秒不会反向改写那份缓存。

还有解析器可能提前清除副本，立刻去权威服务器重取；也有解析器在刷新失败时按独立规则提供过期数据。它们都没有违反 RDAP 展示的数字，因为 RDAP 根本没有声明自己在计量这些副本。

RFC 10037是 2026 年 8 月发布的 IETF Standards Track 文档。支持者可以在 RDAP 的 domain 或 nameserver 对象中加入 ttl0_data。其中 values 把 IANA 已登记、以大写书写的 DNS RR 类型助记符映射到 0 至 2^31−1 的 JSON 整数。使用扩展的响应必须在 rdapConformance 中声明 ttl0。

它最重要的约束不是字段格式，而是证据范围：数值必须反映注册局数据库中已配置的 TTL，而不是从实时 DNS 查询看到的剩余 TTL。注册信息服务由此成为一个外部观察窗口，却没有成为递归缓存的控制台。

能看见配置，不等于获得修改权

ttl0_data 是可选字段。服务器可以不提供；不了解它的客户端应依照 RFC 9083 忽略未知成员。真正实现该扩展的客户端则必须接受所有有效 DNS 类型，并定期跟进 IANA DNS 参数注册表，不能因为本地软件发布较早就把后来登记的类型当作畸形数据。

IANA RDAP 扩展注册表给 ttl0 一个公共标识。登记证明语义有出处，不证明任何特定注册局已经部署，也不证明注册商允许客户选择 TTL。

写入权由另一套边界处理。RFC 9803定义 EPP 的 DNS TTL 扩展，服务器可以限定适用的 RR 类型、最小值、默认值和最大值，可以因安全或稳定原因不采用客户提交值，也可以在带外修改或在一段时间后自动恢复默认。RFC 10037 与它互补，却不要求注册局实现 EPP 扩展。

因此，注册局完全可以公开自己决定的配置，而不把决定权交给外部客户。透明度不是授权。

同一次变更有五个不同状态

第一层是政策：谁能提出什么值，适用于哪些 RRset，允许持续多久。第二层是注册局接受并保存在数据库里的配置，RDAP 报告的正是这里。第三层是区生成与各台权威服务器实际发布的 RRset 和 TTL。第四层是某一递归解析器此前取得并在本地保存的副本。第五层才是应用得到新地址、通过 DNSSEC 验证并完成真实请求的结果。

RFC 2181明确 TTL 属于 RRset，集合内记录应采用相同值。RFC 1035给出普通缓存期限。RFC 9499进一步说明 TTL 是最大生存时间：解析器可以按本地政策缩短，也可以提前清除。副本一旦被清除，“还剩多少秒”就失去对象。

到期也不是全世界同步删除。RFC 8767允许解析器在善意刷新失败后，在受限条件下提供过期数据。这是解析器为可用性作出的局部选择，既不改变注册局配置，也不把过期答案重新变成当前权威数据。

旧 TTL 必须在实质变更前消化

RFC 9803 指出一种常见错误：在修改 NS、DS 或其他实质记录的同时才降低 TTL。旧缓存不会收到远程补丁。要缩短切换窗口，较小数值至少应在旧 TTL 长度之前生效，还要加上注册局接收命令到权威 DNS 真正发布之间的延迟。

可审计流程应从旧状态开始：确认旧 TTL 与政策，授权提交新值，读取注册局已接受状态，观察所有适用权威服务器确实发布较低值，再从这个经过证明的发布时刻等待旧期限。之后才更换记录内容，并从不同递归网络观察结果、验证 DNSSEC、运行应用探针。恢复常规 TTL 要等新状态稳定，同时保留回滚所需的旧服务或密钥。

“保存时间加五分钟”是门户自己的日程。“首个经过验证的权威发布时间加旧 TTL”才是能够解释的保守边界。

TTL 两端都带有治理成本

域名持有人喜欢短 TTL，因为切换和回退更快。注册局与权威服务承担更多查询负载，也要考虑 fast flux 对极短委派 TTL 的利用。很长的 TTL 能减少日常查询，却可能在注册商账户被入侵后，把恶意 NS 或 glue 更久地留在缓存里。

所以 RFC 9803 把限制、覆盖与自动恢复留给注册局。RDAP 可以让决定被看见，却不能证明决定适当。RFC 7481还说明 RDAP 依赖其他协议层提供认证、授权、保密与完整性。传输完整只能证明收到的字段没有在路上被随意改动，不能证明生成该字段的政策、区发布和业务结果正确。

真正有用的是一条共同变更账

每次委派或 DNSSEC 变更至少应保存：操作人与授权、政策版本、旧 TTL、EPP 事务或等价确认、带时间的 RDAP 值、区版本、各权威回答、多处递归观察、DNSSEC 结果、业务探针和回滚决定。所有时间都要写明对应哪一个 RRset、哪一个服务与哪一个阶段。

Heng Lu 的运行代码优先原则要求用真实执行路径证明变更，而不是用计划代替结果。他对数据主权技术形式与实际控制的区分解释了注册局为何无法支配已经交给外部解析器的副本。他关于最小初始规范与本地后续决策的框架也与 RFC 10037 相合：共同标准定义窄而清楚的观察语义，本地运营者承担采用、政策、排序和后果。

RFC 10037 没有让全球时钟同步。它让注册局能够准确说明自己展示的是哪一只钟。