摘要

  • APNIC 的可选 geofeed 属性允许获授权的维护者为地址资源挂接一个 HTTPS 地理位置数据源。
  • 受保护的链接能说明发布路径，却不能独立证明外部 CSV 中每一行都准确、完整且仍然有效。

一次点击就跨过了治理边界。在证据截止时间，APNIC 对 206.83.119.190 的查询显示地址范围为 206.83.112.0 - 206.83.119.255，维护者为 MAINT-SPACEX-AP，并指向另行托管的文件。登记对象最后修改于 2026 年 3 月；另行抓取的外部文件，其 HTTP 头却显示在 8 月 26 日当天早晨刚刚修改。

这不是时间矛盾，而是两套时钟。APNIC 管理登记对象及其变更授权；网络运营者控制站外 CSV；地理位置服务商决定何时抓取、如何解决冲突、何时向下游传播。一条长期不变的 URL，背后可以是持续更新的内容。

APNIC 的 inetnum 对象指南把 geofeed 定义为可选、单值字段，内容是指向自发布 CSV 的有效 HTTPS URL。同一指南说明，mnt-by 用于授权和认证受保护对象的变更。因此，维护链可以支持“有权维护该记录的一方放置了这个链接”，但不能支持“APNIC 核验了文件里的每个地点”。

APNIC 的操作指南把流程明确分成三步：制作 CSV、通过 HTTPS 托管、再经 MyAPNIC 把 URL 加入 Whois 对象。指南还提醒，在 APNIC 维护的记录里，country 表示机构依法登记的经济体，可能不同于网络实际使用地点。APNIC 于 2023 年 8 月 18 日宣布 Whois 支持这一属性。

RFC 8805将 Geofeed 定义为运营者自发布的前缀到国家或经济体、地区和城市等可选信息的映射。它要求消费者合理核验发布者的权威性，并在可行时核验地点准确性。由于发布者可以不经通知更新文件，在没有其他约定时，消费者通常应至少每周刷新。

RFC 9632进一步限定发现和消费：必须使用 HTTPS；无签名数据里超出引用地址范围的行必须忽略；选择时还要考虑最具体的适用对象。可选的 RPKI 签名能加强认证，但签名认证的是一项声明，不是对物理地点的测量。

被引用的外部 Geofeed在该 /21 内把七个 /24 和两个 /25 标为 Sydney。抓取结果可以证明发布者当时这样陈述，却不能独立定位终端用户、卫星网关、设施或流量路径。

可复现的判断应保存 APNIC 对象、维护者语境、最具体的适用地址范围、URL、抓取时间、响应头、完整文件哈希、匹配行和签名状态，再用独立证据处理准确性问题。否则，“APNIC 认证了这条发布路径”会悄然被放大为“APNIC 证明了这个城市”，而后一个结论从未写在登记系统里。

来源