摘要

  • 对于只返回一个结果的 rdap-up 或 rdap-top，RFC 9910 允许服务器放入搜索 URL，也允许放入生成响应当时能得到同一结果的对象查询 URL。
  • 如果数据库状态在链接被访问前发生变化，同一个目标稍后可能返回不同内容；原始响应、关系语境、链接目标与每次解引用都应成为独立证据。

调查档案看上去十分完整：一份子网对象响应、一个接收时间，还有一条标为 rdap-up 的链接，目标是某个上级对象句柄。几小时后，分析员打开这条链接，保存了返回的上级对象。系统于是把两份记录拼成一幅“当时的层级图”。

缺口恰恰藏在这幅图里。团队没有在取得子对象时同步保存上级端点的响应。后来取得的对象能证明服务器后来返回了什么，却不能重建早先的表示，更不能证明两个请求之间层级从未变化。

这是为了说明控制边界而设的假想场景，不是在暗指任何名录机构。RFC 9910 对关系链接给出了明确的时间条件，而很多仪表盘会把这个条件压缩掉。

该标准为 IP 网络和自治系统号码增加基本搜索、关系搜索与反向搜索。rdap-up 寻找覆盖给定资源、但更不具体的最近一层；rdap-top 寻找最上层的覆盖对象。两者都是单结果搜索：成功时返回方式如同直接查询该对象，没有结果则返回 HTTP 404。

这与 rdap-down、rdap-bottom 的多结果结构不同。本文提到差异只是为了划定边界，不重新讨论 bottom 结果究竟覆盖哪些前缀，也不复用已有 ARIN 实测案例。这里真正的问题是：一条看似指向唯一上级的链接，经过时间后还能证明多少。

RFC 9910 允许服务器在 RDAP 响应中附加关系链接。目标可以是相应关系搜索的 URL，也可以是“在该次请求发生时”能产生相同响应的另一个 URL。对单结果关系而言，服务器因此可以把搜索地址换成命中的普通对象查询地址。

这种替换很实用。若搜索与直接查询此刻得到同一个上级，规范化的对象地址往往更便于客户端继续浏览。但“生成响应时相同”并不是永久承诺。标准特意提醒：若链接被解析前数据库状态已改变，直接查询 URL 可能不再得到搜索 URL 当时会给出的结果。

最容易误导人的，是 href 本身可能毫无变化。地址逐字相同，不代表地址背后的选定表示没有改变。链接保存的是通往目标的路径，而不是目标内容的副本。只存 URL，留下的是去处，不是观察。

RFC 9083 要求 RDAP 链接至少带有 value、rel 与 href，分别表达语境、关系和目标。RFC 8288 的 Web Linking 模型也把链接视为语境资源与目标资源之间的类型化连接。关系词解释两者怎样相连，并不冻结日后访问目标时取得的每一种表示。

权威服务发现也不能补上历史。RFC 9224 让客户端根据 IP 地址、前缀或 ASN 找到相应的权威 RDAP 服务。它解决的是请求应当发往哪里，不是把一次答案变成不可变的名录快照。

因此，时间必须成为证据模型的一部分。子对象响应是一次观察；如果当场解析上级，那个响应是第二次观察；数小时后的再次访问则是第三次。每一份都应有自己的原始字节、内容哈希、请求 URL、接收时间、HTTP 状态、报文 Date、验证器、符合性声明和经过认证的服务端点。它们可以关联，却不能互相覆盖。

HTTP 元数据能增强比较，但不能被夸大。RFC 9110 中，Date 表示报文生成时间；ETag 与 Last-Modified 在存在时描述或验证选定表示。它们不是名录事务编号，也未必总会提供，更不能自动解释为何发生变化。

RFC 9111 又增加一层界线。缓存年龄与新鲜度说明 HTTP 响应在什么条件下可以复用，不是名录数据库的历史。一个新鲜响应完全可能包含刚刚变化的名录状态；一个仍可复用的缓存响应也可能早于调查所关心的决策时点。“缓存不陈旧”与“历史上相同”不是同一句话。

status 过滤器还会改变表面层级。RFC 9910 规定，关系计算时可把不具备指定状态的对象视为已移除。因此，按 active 搜索时，查询可能越过一个更近、但状态不匹配的覆盖对象，直接命中更上一层。此时 rdap-up 表示的是带过滤条件的关系，而不是无条件的“父级”。

功能支持也必须实测。服务器可以用 HTTP 501 拒绝不支持的状态过滤组合。响应中是否带关系链接本身又是可选的。缺少链接不等于明确搜索必然没有结果。把“页面没给链接”自动翻译成“名录里没有上级”，就是把展示选项伪造成否定证据。

可靠的采集顺序并不复杂。先原样保存当前响应，再解析链接；不要丢掉语境值、关系词、目标地址和状态参数。若决策需要立刻解析目标，就把它作为新的观察获取，并用时间和哈希与第一份响应绑定。以后复查只能追加记录，不能把原记录更新成最新内容。

如果服务器提供验证器，条件请求可以帮助判断某个选定表示是否变化。304 响应能够支持一个受验证器语义约束的结论，却不能证明未查询的搜索 URL、另一种过滤条件或没有采集到的早期结果也相同。请求有多窄，证据结论就应当有多窄。

这种克制也能阻止制度性越界。关系结果可以证明某个权威 RDAP 服务在明确时刻、按明确查询语义展示了怎样的资源层级。它单独不能证明路由起源、RPKI 授权、账户控制、实际使用、法律权属，也不能解释名录变化的原因。

Heng Lu 在 Running-Code Primacy 中强调运行事实的重要性。RFC 定义互操作的问题，实际服务器状态、客户端行为与保存下来的输出才构成一次可检验的回答。

Minimum Initial Specification 提醒我们把共同语义控制在必要范围，把后续决定留给可问责、可验证的本地机制。关系词汇属于共同核心；保存多久、何时复查、变化多大才升级，应由实际责任人制定。

Reality Layers 解释了为何混淆如此诱人：类型明确的关系是一条精确的符号事实，数据库历史和网络运行则处于别的现实层。前者的精确不能替代后者的证据。Data Sovereignty 进一步区分了对权威记录的控制与对现实网络的实践控制。

RFC 9910 让层级导航更清楚。正确做法不是不信任链接，而是把时间保存得更好：保留子对象响应，保留首次上级响应，也保留后续解引用；写明查询和过滤条件。这样，链接才能完成它应有的任务——连接多次观察，而不是假装时间从未经过。

来源