摘要

  • RFC 9877 定义了 geofeed1、geofeed 链接关系和 application/geofeed+csv 媒体类型，让 RDAP 的 IP 网络对象可以指向 HTTPS geofeed。
  • 链接出现，只能证明某次响应提供了一条发现路径；它不自动证明文件逐行有效、网络实际位于某地，更不能证明某个人身在何处。
  • 可靠使用必须保留对象范围，过滤范围外记录，核验发布者对地址资源的权威性和数据时效，再由独立政策决定是否采用。

查询一个 IP 地址时，RDAP 返回覆盖它的最具体网络对象。这个对象没有 geofeed 链接。客户端向上查父对象，链接出现了。此时最容易发生的错误，是把“父对象提供了文件入口”压缩成“地址的位置已经确认”。

实际上，前后出现了三种不同事实：子对象没有返回链接；父对象返回了链接；链接指向的文件包含地理声明。它们谁也不能单独替代最终判断。

2025 年 10 月发布的 IETF 标准轨 RFC 9877，正是在发现层建立秩序。RFC 9877 规定 RDAP 服务器如何在 IP 网络对象的 links 成员中放置 geofeed 关系，目标为 HTTPS URL，并建议标注 application/geofeed+csv。geofeed1 则用于声明服务器支持这套扩展行为。

这项改进很实在：消费者不必再猜某个注册服务如何表达入口。但 RFC 同时明确，获取和使用 geofeed 数据不在本文范围内。目录负责把路标说清楚，并不因此成为物理位置的证明机关。

geofeed1 承诺的是有条件披露

服务器若在 rdapConformance 中声明 geofeed1，就必须在包含 IP 网络对象的查询、搜索响应以及帮助响应中给出该标识。对某个对象，如果服务器持有 geofeed URL 且能够向客户端返回，就必须附上对应链接。监管或类似约束可能使它不能披露。

因此，在这种服务器上看到“无链接”，最多可以推断：在当前条件下，这个服务器没有为这个对象提供可用 geofeed。它不能证明父对象也没有，不能证明资源持有人从未在别处发布，更不能证明该前缀没有运营地理属性。

另一个细节同样重要：服务器可以直接使用已经注册的 geofeed 关系与媒体类型，却不声明 geofeed1。客户端必须同时查看合规数组和实际链接。只存一个真假字段，会把协议保留的差异抹掉。

HTTPS 保护传输并认证 Web 端点，但端点身份不等于地址空间授权。文件能安全下载，只说明传输环节成立；它没有替每一行的前缀归属和地理内容背书。

向父级递归时，权威范围也随之变化

按照 RFC 9082，IP 查询应返回覆盖目标的最具体网络对象。RFC 9877 认识到 geofeed 可能只挂在较不具体的父对象上，所以允许客户端考虑逐级向上获取。

每上移一级，引用的授权边界就扩大一级。若父对象覆盖一个较大地址段，而共享 CSV 还包含其他资源，消费者必须忽略父对象范围之外的所有记录。链接来自一个合法对象，不等于整个文件都与本次查询有关。

RFC 8805 建议确认发布者对相关地址资源具有权威性。RFC 9224 的 RDAP 引导机制，有助于把查询送往能够对资源处置作权威陈述的注册数据服务。它加强的是链接来源的出处链，而不是城市字段的现场真实性。

geofeed 本质上是资源持有人发布的前缀级运营地理声明。它可以有意保持粗粒度；网络迁移后，缓存可能尚未更新；Anycast、移动网络或跨区域企业网络也可能让单一地点失真。严谨表述应是“某时点、某前缀范围内的自报运营地理”，而不是“某用户位于某地”。

签名、时效与用途分别回答不同问题

取代 RFC 9092 的 RFC 9632 描述了可选的 RPKI 认证。有效签名能够加强“这份数据由覆盖该地址空间的证书授权”这一层证据，但不会自动证明每个地点的语义准确，也不会批准风控、访问限制或执法用途。

系统应把状态拆开保存：发现链接、完成下载、验证传输、记录引用对象、过滤记录、核验发布权威、检查签名、计算数据年龄、确认隐私依据、批准本地用途、观察实际结果。若最后只留下“已定位”，一旦数据纠正，就无法知道错误在哪一层进入决策。

时效还有负载代价。RFC 9877 禁止造成不当负载的频繁实时查询。RFC 9632 建议遵守 HTTP 新鲜度信号；没有信号时，抓取频率不应高于每周一次。实时调用一个接口，并不能把每周更新的数据变成实时事实。

隐私边界更硬。RFC 9877 继承 RFC 9632 的隐私要求，明确发布者不得暴露任何个人的位置，注册运营方也应评估当地监管环境是否允许实现该功能。技术上容易获取，不等于法律上可以无限使用。