摘要

  • PeeringDB 当前公开的 AFRINIC ASN 33764 记录仍把 IRR AS-SET 写作 AS-AFRINIC，没有来源前缀；2026 年的产品改动则试图让含糊的 IRR 引用更容易解析。
  • 前缀可以告诉工具去哪里查找集合，却不能证明集合成员、授权关系、时效性，也不能证明它适合直接生成路由过滤器。

这条记录能证明到哪一步

PeeringDB 的 AFRINIC 网络记录 3803 列出 ASN 33764 和 AS-AFRINIC。公开 API 的标量字段 irr_as_set 返回相同字符串。网页还显示“IRR AS-SET Verified”。这能确认 PeeringDB 当前向读者展示了什么；但在所检查的公开页面和接口中，看不到它查询了哪个 IRR、何时验证、验证了什么，或最终取回了哪些成员。

时间戳也不能混为一谈。API 中网络主记录的 updated 是 2025 年 5 月 2 日；PeeringDB 同时给网络互联 LAN 子记录单独列出 netixlan_updated，日期为 2026 年 3 月 26 日。较新的子记录日期不能证明 AS-SET 字段当日发生变化。主记录的较早日期也不能推出整条网络记录已经过期。公开字段没有给出 IRR 字段自身的变更或验证历史。

PeeringDB 的改动针对的是更窄的问题。Issue #1973 记录了无法确定来源的名称、在多个 IRR 中重复出现的名称，以及运营者在自动化前必须进行人工复核的负担。8 月 19 日发布的 2.82.0 版本说明称，系统加入智能 AS-SET 名称编辑器；来源明确的条目可被主动修正，来源不明的则联系网络维护者。9 月的产品更新用 AFRINIC::AS-AFRINIC 举例，并说明来源不确定时会联系维护者。这些材料证明产品改动及清理流程存在，但没有解释为何这条 AFRINIC 公开记录仍未加前缀。

命名空间改变的是查找路径

AS-SET 名称指向一条集合记录，并不包含其成员列表的副本。RFC 2622 描述的 as-set 可以由 AS 号或其他 AS-SET 名称组成。使用 PeeringDB 字段的工具可能先据此选择 IRR，再取回记录、递归展开成员，最后把结果转成路由策略。如果不同 IRR 中有同名集合，来源前缀能够减少第一步查询的歧义。

这是真实的改进，但只发生在发现环节。前缀不能证明记录仍然存在、维护者有权管理、成员与网络所声明的客户集合一致，也不能证明递归展开完整无缺。它没有说明工具应如何处理引用、滞后的镜像或彼此冲突的副本。只有名称本身，无法证明最终过滤器符合运营者原本想接受的路由范围。

这不是文字上的细分。自动流程若选错数据库，或者读到空集、部分集合，可能生成排除预期路由或接纳非预期路由的过滤规则。PeeringDB 的 Issue #1973 把过滤策略出错列为含糊名称可能造成的影响。但本次调查没有发现 ASN 33764 已发生此类错误的证据，也没有证据表明 AFRINIC 自身 IRR 数据有缺陷，或该目录记录已被接入某个在线过滤器。存在一种风险机制，不等于已有事故。

把交接过程留下证据

更稳妥的流程应保存 PeeringDB 记录及其版本、选定的 IRR 来源、查询时间、返回记录的标识、展开后的成员数量与结果摘要，随后还要保存下游策略测试。“已验证”标签或许有用，但要将它当作可决策的证明，就必须知道验证范围和时间。当前查看的公开页和 API 提供了标签与名称，没有提供这条审计链。

因此，出现 AFRINIC::AS-AFRINIC 时，恰当的理解是：它缩小了该到哪里查的范围，并不保证查到的答案正确。AFRINIC 记录中的未限定值具体显示了名录、IRR 记录和路由决策处在不同的控制面。命名空间能让交接清楚一些；接收它的工具仍须证明自己拿到了什么。

主要来源：PeeringDB Issue #1973、2.82.0 发布说明、PeeringDB 九月更新、AFRINIC 的 PeeringDB 网络记录、公开 API 记录、API 规范与 RFC 2622。