摘要

  • RFC 9910 是 IETF Proposed Standard，发布于 2026 年 1 月；它为区域互联网注册机构（RIR）的 RDAP 服务定义面向 IP 网络、自治系统号及反向 DNS 对象的特定搜索能力。
  • 它把资源层级中的关系变成可查询的关系表面，但返回结果仍受注册表状态、服务端政策、隐私、授权、速率限制和司法辖区约束。
  • 单一结果搜索可以提供指向对象的 lookup URL。保存原始搜索 URL 与替换后的 lookup URL，代表两种不同的操作语义：前者保存当时的查询意图，后者让后续客户端重新定位对象。

机制：搜索链接为何不是永久答案

基本搜索和关系搜索都在明确的 RDAP 路径段下表达，并使用注册的 rirSearch1 标识。基本搜索针对选定对象类别提交输入：IP 网络可使用 IP 地址或 CIDR 对，ASN 可使用单个 ASN 或 ASN 范围，反向 DNS 对象则使用域名。具体路径和输入格式必须按照对象类别及 RFC 9082 的 RDAP 查询模型构造，不能把一种对象的路径规则套到另一种对象上。

关系搜索不是简单地再次查同一个编号。它以另一个资源在层级中的位置为参照，寻找与该位置存在规定关系的对象；关系方向很重要。向上查找和向下查找可能得到不同的父级、子级或相邻结果。关系类型由扩展定义，状态过滤器可以进一步限制返回对象的状态。操作者应同时记录对象类别、输入、关系类型、层级方向和状态过滤条件。

RDAP 响应不是单一字符串。RFC 9083规定了 JSON 响应、结果对象以及 link 对象的表达方式；一个搜索可返回结果集合，集合中的每个结果可能带有与对象或搜索相关的链接。若搜索只得到一个结果，服务器可以把结果链接保留为搜索 URL，也可以将其替换为针对该对象的 lookup URL。保留搜索 URL意味着以后仍按原来的搜索条件查询；替换成 lookup URL意味着以后按对象标识查询。两者都不能消除时间差。

例如，客户端在时刻 T1 取得单结果搜索，服务器给出对象 lookup URL。资源在 T2 被重新分配、关系被调整、状态被改变，客户端在 T3 才访问 lookup URL。T3 的响应可能与 T1 的搜索结果不同。这个变化不表示协议给出错误，也不证明任何一方拥有法律上的所有权；它说明链接的后续解析再次观察了注册表。RFC 9910因此应被理解为带有观察时间的发现机制，而非对权利、归属或未来状态的永久证明。

操作员证据账本（观察时间）

在接受或转发任何关系结果前，记录以下证据：查询发生的 UTC 时间；服务端及其RIR权威；完整请求路径、查询参数和 rirSearch1；对象类别与原始输入；关系类型、层级方向及状态过滤器；原始响应字节或受控存档；结果集合大小；每个结果的 link relation、原始搜索 URL 和 lookup URL；客户端实际跟随链接的时间及二次响应。若无法保存响应全文，也应记录内容摘要、HTTP 元数据和保存策略，并标明证据缺口。

操作员接受决策路径

先确认使用目的、请求者权限和适用司法辖区，再选择基本搜索或关系搜索。其次核对路径段、对象类别、输入范围、关系方向和状态过滤器。收到响应后，检查结果集合语义、服务端授权要求、隐私暴露、速率限制和保密传输条件；必要时停止、降频、缩小范围或请求额外授权。最后，只有在记录观察时间和注册表权威后，才决定接受结果、保留搜索 URL、另存 lookup URL，或要求重新查询。若用途需要当前状态，应在行动前重新查询；若用途需要审计，应保存原始搜索而不能只保存快捷 lookup。

这些边界也限制结论：RFC 9910不证明所有权或法律权利；搜索结果不是 timeless truth；本文不推断任何RIR当前是否部署该扩展，也不推断某一数据集完整；扩展不覆盖RDAP访问控制、隐私规则或监管许可。RFC 7481所涉及的认证、授权、机密性和隐私要求仍然有效。具体服务器的速率限制、授权政策和某一司法辖区是否允许特定用途，必须单独核验。

来源