摘要

  • draft-ranjbar-regext-rdap-subordinate-referrals-01 提议用两个有方向的关系，把注册局持有的上级对象连接到资源持有者指定的 RDAP 服务，以查询其下的域名、网络或地址。
  • 下游服务的数据由持有者断言，并非注册局断言。严格从属范围、返回链接和单跳上限约束它能说什么；查询到达持有者设施后，持有者也能看到访问兴趣。
  • 客户端应保留“权威接缝”：注册局的覆盖对象、指定行为和持有者的下级回答必须分别显示和留证，不能压成一条无来源差别的权威记录。

RDAP 的通常路径很容易给人完整权威链的印象。客户端从 IANA 引导信息出发，找到负责某个顶级域或号码资源范围的服务，再取得该运营者数据库中最具体的对象。每一步都在既有登记层级中收窄问题。

但这条链有意停在某处。域名注册局可以保存已注册域名，却不必保存平台在其下动态创建的每个名称；RIR 可以保存覆盖分配或汇总指派，却不必保存资源持有者在内部派发的每个更具体网络和单一地址。细粒度数据不在中央库里，未必是遗漏，也可能是责任分工。

这份个人草案试图补上“如何找到下一处数据”的缺口。持有者可以指定由自己或受托方运营的 RDAP 服务。注册局响应向下指向它，持有者响应再向上指回覆盖对象所在的注册局。数据无需全部上收，客户端却能继续发现更具体的记录。

技术收益很直接。问题在于，界面是否把跨越的那条线抹掉。

向下的链接不传递注册局身份

第 01 版提出 rdap-base-down 与 rdap-base-up。前者指向保存下级或受委托数据的下游 RDAP 基础 URL，后者从下游服务指回覆盖注册局的基础 URL。这两个名称描述跨服务的方向，不代表下游运营者继承了上级注册机构的地位。

草案给出了严格边界：持有者指定的服务只可作为被引用对象之下资源的候选来源；目标必须使用 HTTPS；客户端不得把它视为其他资源的权威。反向链接保留回到上级的路径，客户端还必须限制所跟随的持有者级转介数量；文中场景只需一跳。

这些规则能阻止持有者借同一链接去断言兄弟前缀、上级分配或无关域名，却不能自动证明每条下级记录正确。注册局表达的是“该持有者为此范围指定了这个服务”；持有者随后表达的是“这是我维护的下级记录”。如果产品把合并结果统一标成“注册局数据”，就把指定误写成了背书。

向后兼容可能让换人发言悄无声息

提案照顾旧客户端。只要持有者的指针已经登记，注册局服务仍会把下级资源查询重定向到指定服务，使不理解新关系的客户端继续得到最具体记录。理解关系的客户端可以主动发现 rdap-base-down 并有意识地跨越；希望同时查看注册局覆盖记录的客户端，可以使用配套显式转介草案讨论的“抑制重定向”控制。

这种兼容性合理，却也是来源最容易消失之处。HTTP 重定向在视觉上很安静，程序库往往自动跟随。最终页面仍像一次查询的直接结果，但回答机构、可用性责任、隐私后果和证据等级已经改变。

工作组草案 draft-ietf-regext-rdap-referrals-04 定义了针对相关 RDAP 记录的显式重定向请求。若存在唯一合适链接且客户端获准，服务器使用标准 HTTP 重定向状态和 Location。它还处理关系选择、内容协商、缓存与多跳限制。它减少了为取得一个链接而传输整份记录的浪费，却不负责告诉读者最终由谁发言。

持有者既是数据来源，也是查询观察者

安全章节明确说，下游服务返回的数据由持有者断言，而不是注册局运营者断言。客户端展示数据时应区分来源。这不是署名装饰，而是决定谁能纠错、谁承担连续性、争议时可以引用哪份证据。

转介还改变了查询可见性。请求进入持有者设施后，持有者能观察外界对自己下级资源的兴趣。草案把它类比为 DNS 运营者对自身区域已有的可见性，同时允许有保密要求的客户端不跟随转介。只有软件在跳转前揭示这个选择，并允许继续查看注册局覆盖对象，这项权利才真实存在。

故障也必须分层。持有者服务不可达，会使新增的下级信息消失，但注册局自己的响应不受影响。“RDAP 不可用”过于粗糙。注册局宕机、指定指针错误和持有者服务故障分别属于不同责任人。

未标准化的指定过程才是权力铰链

草案没有规定持有者如何把目标服务告诉注册局。注册商或注册局门户、未来 EPP 扩展都只是例子。对聚焦 RDAP 的文本而言，这种留白可以理解；对治理而言，它恰好留下了谁能移动查询的关键步骤。

谁有权创建、更新和撤销指针？运营下游服务的代理是否也有权改变指定？新目标何时生效？上级域名或号码资源转移后，旧指针是否自动失效？紧急撤销留下什么记录？如果账户被盗，把请求导向错误服务，谁能重建当时的授权链？

草案建议注册局在发出转介前验证目标能为持有者资源提供合规 RDAP。合规很重要，却不等于归属。一个服务器可以返回格式完美的 JSON，同时谈论它无权控制的对象。指定生命周期仍需经过身份验证、范围证明、目标检查、激活、续期、变更、撤销和转移清理。

为每次跨越保留权威接缝

我建议客户端为每次已跟随的持有者转介保存一份“权威接缝记录”。这不是草案要求，而是防止发现机制变成隐性背书的最小证据。

第一层保存注册局侧事实：引导路径、覆盖对象、注册局服务、关系、指定目标、指定人和渠道、激活时间、授权范围以及最近一次合规检查。无法取得的字段写作未知，不用推断补齐。

第二层保存跨越过程：请求路径、普通重定向或显式关系、HTTP 状态、是否选择抑制、目标 URL、TLS 结果、取回时间与跳数，并记录用户是否在请求暴露给持有者之前得到提示。

第三层单独保存持有者断言：实际响应服务、下级对象、响应时间、适用的合规标记、缓存期限以及返回覆盖注册局的链接。界面可以提供细节，但应写明“持有者断言”，并把上级登记记录并列，而非静默替换。

失败路径同样要留证。下游不可用时，客户端保留覆盖对象并指出故障层；指定撤销或持有者变更时，缓存的下级断言必须有明确寿命；响应越过严格从属边界时，应直接拒绝，而不是借转介为它洗白。

关系名称故意不绑定“持有者”角色，以便用于委托或混合 RPKI 发现，以及 RWhois、SWIP 的现代化替代。复用可以减少协议词汇，却也可能把不同信任安排压成一种含义。“下游”只是拓扑，不是法律授权、质量保证或服务承诺。

第 01 版是 2026 年 7 月 21 日的个人 Internet-Draft。Datatracker 显示它没有 IETF 正式地位、RFC 流或预期状态，页眉却写 Standards Track；作者更希望内容合并入 REGEXT 的显式转介草案。实现章节报告一个持有者侧服务在运行，同时说注册局侧转介仍是缺失的一跳。这是作者提供的实现背景，不是广泛部署或共识证据。

下级数据需要被发现，但发现路径不应借来上级机构的权威。最诚实的实现不是阻止客户端向下走，而是在跨越时明确告诉读者：道路继续了，发言者已经改变。

来源