摘要

  • RFC 9910 把 rdap-down 定义为直接子对象查询，把 rdap-bottom 定义为一组共同覆盖所请求范围的最具体登记对象。
  • ARIN 对一个 /21 的实时返回同时包含有效的 /22 直接分配和管理状态的 /8；后者负责覆盖余下地址，并不表示它是 /21 的子对象。

看似倒置的抽屉

这组结果第一眼像是违反了前缀层级。查询 ARIN RDAP 服务中 149.112.152.0/21 的 bottom 对象，会得到两个登记对象：NET-149-112-152-0-1 是以 /22 表示的有效直接分配，NET-149-0-0-0-0 则是以 /8 表示的管理对象。

一个 /8 显然不可能是 /21 之下更具体的子前缀。但接口也没有作出这种声明。矛盾来自把“bottom”直觉地理解为“这个节点以下的全部叶节点”。RFC 9910 让它回答的是另一道题：有哪些已登记对象，在各自可用的最具体层级上，合在一起可以覆盖客户端给出的整个互联网号码资源范围？

其中 /22 只覆盖所查询 /21 的一半。对于其余地址，这次响应能够给出的最具体登记对象是更宽的 /8。因此，bottom 集合允许重叠。它不是把范围切成互斥的下级块，而是说明哪些登记对象共同承担完整覆盖。

向下查询不等于底部覆盖

配对查询把区别显露出来。对同一个 /21 使用 rdap-down，ARIN 只返回 /22 直接分配。原因是 rdap-down 沿直接子关系查找：它寻找输入范围之下紧邻的已登记对象。/8 不符合这个条件。

rdap-bottom 执行的是覆盖计算。如果更具体对象只覆盖请求范围的一部分，就可能保留一个包围对象来说明剩余地址。RFC 9910 明确指出，bottom 对象不一定彼此分离，集合中甚至可以出现比输入范围更不具体的对象。ARIN 的公开说明采用同一规则：当发现的 bottom 对象不能完全覆盖查询值时，还会返回负责其余部分的最具体网络对象。

这种机制很实用。客户端不必自行递归重建整个登记树，就能看到一个范围在登记层面细分到了哪里。风险出现在后续展示。如果面板把每一行都标为“子分配”，覆盖对象就会被错误改写成下级关系。前缀本身没有错，丢失的是它为何进入结果集的语义。

响应实际携带什么

返回项都自称为 ip network 对象，包含 handle、起止地址、CIDR 表示、ARIN 模型中的类型和状态。此次抓取中，/22 的类型是 DIRECT ALLOCATION，状态为 active；/8 的状态是 administrative。

这些字段属于登记界面。它们不能证明两个前缀正在 BGP 中发布、从某个网络可达、承载流量，或已由 ROA 授权。抓取时两个对象的 ARIN 可选源 ASN 数组都为空，但空数组也不能证明没有路由；它只说明某一时刻、某个登记响应中的一个字段没有给出值。

RFC 9083 把 IP 网络对象定义为登记信息。RFC 9082 还说明，普通 IP 查询会选择能够完整包含查询值的最具体已登记网络。两份规范都没有把登记几何关系变成现场网络状态。

让查询关系跟随数据

可复核的记录不能只保存前缀。它还应保存所请求的关系、输入范围、抓取时间，以及每个结果的 handle、起止地址、CIDR、类型和状态。保留这些字段后，/8 就不再像异常：它是 /22 未覆盖部分所对应的登记覆盖对象。

路由采集器、IRR 路由对象、RPKI 验证和内部地址管理记录必须继续分开。它们各自回答不同问题。bottom 搜索说明登记覆盖，却不说明谁能配置路由器、谁掌握账户、谁拥有法律权利，或哪条路由此刻可见。

这是一个很小的接口差异，却可能产生持久影响。一旦关系名称被删除，准确响应就会变成虚构的委派树。最稳妥的标签其实最直白：由查询范围内可用的最底层登记对象共同形成的覆盖。

来源