摘要

  • AFRINIC 托管的 Routinator 页面允许用户只输入前缀，再从 BGP 自动寻找源 ASN，随后用 RPKI 对“前缀—ASN”组合做源验证。这不是一次查询，而是两次证据操作。
  • 在冻结样本中，196.216.2.0/23 的搜索结果从 riswhois 选出 AS33764，并标为精确匹配，却没有携带 BGP 数据的更新时间；RPKI 返回 valid 和 generatedTime，却不再携带 BGP 来源与观察时间。
  • 页面另有 Data Freshness 表，公开 RPKI、BGP 和各 RIR 分配数据的更新时间。因此问题不是“隐藏时间”，而是单次结果离开页面后，无法证明自己使用了哪一版来源。
  • 建议提供一份复合验证回执：输入、匹配模式、BGP 所选组合及来源版本、Routinator 版本与验证序号、VRP 结果、生成时间、摘要和后续更正关系。

少填一个 ASN，多出一道判断

如果用户同时输入前缀和 ASN，验证器面对的是一个明确命题：在当前已验证的 RPKI 载荷中，这个 ASN 是否获准为这个前缀发起路由。AFRINIC 的公开工具还提供更方便的路径——启用“从 BGP 找到 ASN 后验证前缀”，让系统代替用户补上源 ASN。

这个功能有充分的操作价值。排障常常从一个 IP 地址或网段开始，而不是从完整的路由对象开始。工程师未必知道某个采集视角此刻看到了哪个源 ASN。页面还允许在“精确匹配”和“最长匹配前缀”之间选择，明确暴露了一个本可藏在代码里的决策。

问题也正由此产生。此时绿色或红色标签回答的已经不是单一问题。系统先问 BGP 数据：“按这条匹配规则，应该拿哪个前缀和源 ASN 去验证？”然后再问 RPKI 验证器：“这个组合与当前 VRP 集合是什么关系？”前一步选择被验证对象，后一步给对象分类。

两步可能在不同时间更新。BGP 观察改变时，RPKI 授权可以不变；ROA 更新时，BGP 路由也可以不变；用户把最长匹配改成精确匹配时，系统甚至可能换了被测对象。只保存最后的 valid，等于保存结论，却没有完整保存命题。

AFRINIC 已经承认三个时间轴

评价现有设计，应该先说它最强的一面。页面没有把所有数据伪装成同一时刻。Data Freshness 区域分别列出 RPKI、BGP，以及 AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC 分配数据的时间。Routinator 状态接口提供软件版本、验证序号、更新周期字段和按信任锚划分的统计。另一个来源状态接口把 BGP 来源标为 riswhois，给出序号和 lastUpdated；各 RIR 分配来源也有自己的序号和时间。

搜索响应同样保留了有用的结构。2026 年 9 月 12 日冻结的公开样本以 196.216.2.0/23 为输入，返回相同前缀。一条元数据说明分配背景来自 AFRINIC；另一条说明 BGP 来源为 riswhois，源 ASN 是 AS33764，匹配类型为 exact-match。

接着，对 AS33764 与 196.216.2.0/23 的 Routinator 请求返回 valid。响应展示了匹配的 VRP：ASN 同为 AS33764，前缀同为 196.216.2.0/23，最大长度为 24；同时给出 generatedTime。这比只给一个颜色更负责，因为读者可以看到被比较的组合和命中的授权。

缺口非常具体：BGP 搜索对象没有 riswhois 的 lastUpdated；RPKI 有效性对象没有 riswhois、BGP 观察时间，也没有说明源 ASN 是按精确匹配还是最长前缀匹配得出。页面用于展示关联前缀的分配数据版本也没有进入结果对象。

这些信息在当时的状态页面上存在。谨慎的工程师可以手工抄录。可是“可以在别处查到”和“某个结果绑定了它使用的版本”不是一回事。前者说明此刻整个服务看到了什么，后者说明这张截图或这份工单当时由什么产生。

刷新页面不能恢复旧证据

实时系统最容易制造一种错觉：再查一次，就能验证上一次。其实第二次查询只会得到第二次观察。BGP 采集已经可能换了源，Routinator 可能完成新一轮验证，分配文件也可能前进。新结果无论相同还是不同，都不能替旧结果补上已经丢失的来源版本。

因此，这不是对样本判定正确性的指控。本文没有发现错误路由、过期公告、攻击、故障或成员失误，也不知道 AFRINIC 的内部日志保存了什么。样本只证明公开响应的边界：选择 ASN 的那一步与产生 RPKI 状态的那一步，没有在同一个可携带对象中保存各自的时间。

还要限制 valid 的含义。它表明至少有一个覆盖该路由的 VRP，在源 ASN 与长度规则上匹配。它不证明 AS_PATH 其余部分可信，不证明全球都看见这条路，不证明任何路由器接受或优选它，也不替运营者作策略决定。

AFRINIC 分配数据则是第三种证据。它能说明资源的登记区域，为关联前缀提供上下文，但它不是 ROA，也不为 BGP 源起签名。回执保留其版本，是为了显示它只承担背景角色，而不是把三种权威混为一谈。

回执要保存连接，不必保存一切

一份实用的复合回执可以很短：

  1. 用户请求的前缀，以及用户是否手工提供 ASN；
  2. 是否启用 BGP 自动查找；
  3. 精确匹配或最长匹配前缀模式；
  4. 最终选中的前缀、源 ASN 和 BGP 来源标识；
  5. BGP 来源序号与 lastUpdated；
  6. 页面若展示分配背景，则记录相应 RIR 来源、序号和时间；
  7. Routinator 版本、验证序号与已完成轮次的时间；
  8. 验证状态和匹配、ASN 不匹配、长度不匹配 VRP 的摘要；
  9. 响应生成时间、回执摘要，以及被更正或取代时的指针。

字段旁边应该有动词边界。riswhois 是“观察”到一个源起；AFRINIC 分配文件是“登记”某种资源背景；Routinator 是“比较”路由组合与已验证载荷；网络运营者才是“决定”接受、告警、降权或过滤。没有任何一个序号能把观察者变成资源权威，或把验证器变成路由策略制定者。

隐私成本也可控。公开前缀与 ASN 本就出现在查询里。若某次排障涉及客户机密，组织可以在工单内保存完整回执，只对外分享摘要、来源版本、结果类别和必要的时间。无需公开客户身份、内部拓扑或 NOC 讨论。

让截图不再膨胀成机构承诺

简单工具会获得超出设计的权威。一张带着 AFRINIC 标识的绿色截图，经过几次转述，容易变成“AFRINIC 认定这条路有效”。这句话抹掉了 BGP 采集视角、Routinator 轮次和本地策略，把一次诊断比较扩大为机构背书。

复合回执反而保护 AFRINIC。它把服务的责任界定得很窄：在某个 BGP 版本下选中这个组合，再用某个 Routinator 状态进行比较。AFRINIC 不需要保证全球 BGP 一致，也不需要替路由器承诺行为；用户却能准确重述工具做过什么。

现有页面已经公开表达了正确的世界观：数据源不止一个，时钟也不止一个。接下来只需让每次结果在离开页面时，仍把这份诚实保留下来。

来源

AFRINIC 资源认证页面说明服务背景，托管的 Routinator 界面提供检查入口。冻结证据包括 Routinator 状态接口、BGP 与 RIR 来源状态、样本前缀搜索及其 RPKI 有效性响应。NLnet Labs 的 Routinator 界面文档解释产品职责；版本化界面代码包则显示本文观察到的 BGP 查找与新鲜度逻辑。