摘要

  • ARIN ACSP 2023.1 记录，发布者通过 XML API 自动维护 AS13335:AS-CUSTOMERS，ARIN 生成的 RPSL 把大量成员放进了一条物理 members: 行。
  • 提议者展示了对一个被其判断为 IRRd v3 实例的镜像所作递归查询，完整协议响应只包含 7 个 ASN。ARIN 同意限制单行成员数量会改善查询结果，并让建议保持开放直至实施。
  • 逻辑成员集、RPSL 属性、序列化字节、镜像导入、已解析对象、递归查询结果和最终过滤配置，是彼此相连但不能互相替代的状态。
  • 一张跨镜像序列化回执应把规范成员数及摘要，与精确导出字节、行界限、导入身份、解析成员数和查询结果摘要连接起来，并明确标记拒绝、截断或部分导入。

7 个 ASN 是派生答案，不是源对象

ARIN ACSP 2023.1 由 Joe Abley 于 2023 年 1 月 30 日提交。建议称，Cloudflare 通过自动化 XML 请求发布 AS13335:AS-CUSTOMERS，ARIN 把该集合转换成 RPSL 时，将众多成员排在同一条 members: 行中。

公开页面列出一长串 ASN，中间以“还有许多”省略，再给出末尾若干成员。这份网页证据足以证明当时存在异常长的单行表示，却不是可以据此重建完整成员总数的原始对象副本。

随后，建议展示对另一台镜像的 !iAS-CLOUDFLARE,1 查询。提议者谨慎地说，他认为这是一台 IRRd v3 实例；协议响应以 7 个 ASN 和结束标记收尾，因此不是截图界面把内容折叠了。本文没有重新执行这次历史查询，也没有假定该镜像目前仍在线或运行相同软件。

ARIN 在 2023 年 2 月 7 日的答复同样克制：限制单条 members 行的项目数量，会让 AS-SET 查询得到更好的结果；ARIN 将研究需求、安排未来开发，并在实施前保持建议开放。当前页面仍标记为 Open。这个状态只证明公开工单尚未标成已实施，不能反推 ARIN 今天仍输出同样的长行，也不能证明内部没有任何缓解措施。

证据上限必须清楚。该记录没有证明 Cloudflare 现在的集合、过滤器或 BGP 公告存在错误，也没有证明发生过路由泄漏、劫持或中断。它证明的是：一份丰富的源表示与一个极短的镜像派生答案之间，曾出现可观察的不一致。

集合、属性和值所在的行是三层对象

RFC 2622 把 AS-SET 的 members 定义为可选、可多次出现的属性；每个值可以是 ASN 或其他 AS-SET 名称组成的列表。“列表值”和“属性可多值”是两件事：一个属性值内部可以有许多项，同名属性也可以出现多次。

文本表示又增加了物理行规则。每个属性—值对从新行开始；若后续行首字符是空格、制表符或加号，该值可以延续到后续行。因为 members 本身可多值，也可以重复书写 members:。于是，同一个逻辑集合能够对应一条很长的行、若干重复属性或多条续行；它们在语义上可能等价，字节摘要、总行数和最长行长度却不同。

这正是“排版”变成互操作界面的地方。新解析器可能接受数千字节的单行，旧读取器可能使用较小缓冲区、字段长度假设或不同的错误恢复方式。传输层可以完整送达所有字节，导入器仍可能只保留前缀；更新也可能失败，使镜像继续暴露旧对象。

ACSP 页面没有提供解析追踪、数据库转储或数据包记录，无法确定示例究竟在哪个组件截断。把原因锁定为某个缓冲区或特定 IRRd 缺陷，超出了证据。合理结论是：只要 RPSL 在独立系统之间流动，物理序列化就应成为可测状态。

XML 到 RPSL 的转换也是产品接口

ARIN 当前的 IRR 概览称，通过 GUI 或 XML REST 创建的简单对象，会在后端转换成 RPSL；其他使用者取回的记录仍是 RPSL。IRR REST API 指南同时描述 XML 与 RPSL 表示，并把 members 定义为集合中的 ASN 或其他 AS-SET。

发布者控制要提交哪些成员，ARIN 控制 XML 如何成为物理 RPSL。历史建议称，XML 模式无法指定每行放多少成员，这个决定由 ARIN 的构造代码完成。因此，“客户端提交的是合法集合”并不能覆盖下游兼容问题：消费者读取的不是发布者内存中的数组，而是序列化器产生的具体字节。

缩短行长是合乎逻辑的缓解。RFC 2622 提供重复属性和续行等合法表达方式。但换行本身不是完整性证明。网页可以视觉折行，实际导出仍保持单行；镜像也可能接收所有行，却另有成员数量限制；对象存储完整时，递归查询仍可能因来源选择或深度规则而变化。

真正的测试必须同时比较含义和字节：源端规范成员数与摘要是否稳定，导出字节是否符合预期，镜像接收的字节是否一致，解析后的成员集合是否仍相同。

镜像是新的证据保管边界

ARIN 当前提供 NRTM、数据库下载和 Whois，并说明现用服务器是 IRRd Version 4。IRRd 镜像文档描述，镜像获取快照或增量更新，再进行解析、验证并写入自己的数据库。

因此镜像并非透明玻璃。它有自己的软件版本、配置、来源政策、序列历史与错误处理。源端完整发布不等于镜像完整存储；镜像完整存储也不等于查询引擎按预期来源和递归规则给出完整结果。

端到端核验至少要连接三对状态。第一，源端导出字节与镜像接收字节是否一致。第二，源端规范成员集合与镜像解析后存储的集合是否一致。第三，镜像存储状态与指定查询条件下的派生结果是否一致。缺少中间一环，面对短答案时就无法判断问题出在传输、导入还是解析与展开。

现代 IRRd 的事务性装载有助于避免读者看到“导入到一半”的数据库，但事务完成不等于语义完整。一个被完整提交的部分解析仍然是部分状态；当前 IRRd 的性质也不能倒推 2023 年旧镜像的行为。

递归查询是在本地图上计算

IRRd Whois 查询文档把 !i 描述为处理后的查询。启用递归时，服务器沿嵌套集合展开，并以空格分隔返回成员。它不是原始 RPSL 文本。

直接查看镜像中的对象，可以回答“本地存了哪些属性”；递归查询回答“在本地对象图与这组来源规则下，会推导出哪些成员”；过滤器生成器随后可能再把这些 ASN 转成前缀和路由器规则。每一步都依赖上一层，却不是上一层的同义词。

因此，查询有正常结束标志，只证明协议完成，不证明集合完整。安静地返回一个格式正确的短列表，比明确报错更容易进入自动化。过滤器生成之前需要的是完整性凭据，而不只是成功退出码。

让含义与字节能够对账

跨镜像序列化回执可以让这条边界变得可观察。这是本文的编辑建议，不是 ARIN、IRRd 或 Cloudflare 已承诺的功能。

源端回执应记录 AS-SET 键、对象版本或发布序列、依据公开排序规则生成的规范成员数与摘要；随后标识序列化器及其版本，并保存精确 RPSL 字节摘要、总字节数、物理行数与最长行长度。

镜像回执应记录来源、快照或 NRTM 序列范围、导入时间、解析器版本与结果。它先核对接收字节摘要，再给出已存对象摘要、解析成员数和规范成员摘要。状态必须有类型：完整、拒绝、截断、部分解析，或导入失败后仍保留旧版本。沉默不能被当成截断信号。

查询回执再加入查询字符串、来源选择、递归开关或深度、排除集合、执行时间、结果数量与摘要。下游过滤器可自愿绑定其产物摘要，而无须公开私有配置。

这套回执不要求所有网络采用同一软件或同一路由策略。它只要求原本声称承载同一含义的表示，在首次分歧处留下可比证据。

来源