摘要

  • ARIN 2026 年 1 月的董事会会议纪要草案记载，一项定期的注册服务部门审计检查了文档、工作步骤和组织结构；所审工单中没有发现不符合 NRPM 的情况，部门被认为仍在高效运转。
  • 4 月会议纪要草案记载的是 2025 年 12 月 4.10 地址发放事件之后另行委托 Baker Tilly 的事件审计。草案称，所查看的所有领域都存在不一致，但同时说明十项标准刚刚制定，此前并非工作重点。
  • 两个结果不能直接相减。1 月公开表述的中心是工单层面的政策合规，4 月公开表述的中心是依据新标准检查结构性控制；两份公开记录都没有给出总体、样本、抽样方法、分母和完整严重度。
  • ARIN 可以用一张版本化审计对照表，把每项审计的身份、触发原因、期间、分析单位、规则或标准版本、例外数量与严重度、整改负责人、期限、复测，以及 Registry Control Plane 最终覆盖的具体交易连接起来。

“零项违规”与“处处不一致”之间缺少了什么

如果只摘录结论，ARIN 的公开记录很容易被写成一次突然翻转。

1 月 13 日的会议纪要草案把议程项目写作“2025 ARIN RSD Audit Report”。首席客户体验官说明，每两年会有一家外部公司检查注册服务部门的文档、工作步骤与组织结构。纪要称，工单审计没有发现不符合 Number Resource Policy Manual 的项目，部门继续高效运行。

这里的“没有”并不是一个自带分母的统计结果。公开页面没有说明可抽取的工单总数、实际样本数、选择方法、覆盖期间，也没有说明不同业务类型在样本中的分布。因此，它能够支持的表述是“所审工单没有报告 NRPM 违规”，而不是“全部工单都经过检查”，更不是“部门所有控制都有效”。

4 月 19 日的会议纪要草案起点不同。12 月的资源发放事件暴露了单人可以执行敏感操作的控制路径，ARIN 因此要求外部审计，并聘请 Baker Tilly。Mike Cullen 汇报了审计报告草案。纪要说，在审计查看的每个领域都发现不一致；紧接着又注明，十项审计标准是新近制定的，此前并不是关注重点。

后一句不是为前一句开脱，而是在限定证据。新制定的控制标准可以揭示真实风险，却不能仅凭“新标准下有差异”就证明旧做法违反了当时已经存在的要求。反过来，一张工单可以按照 NRPM 正确记录资源发放决定，也不能因此证明库存、权限分离、删除联动和异常检测都安全。

两个结论可以同时成立。矛盾产生于把审计的名称保留、却把审计的问题删掉。

七天的错误状态揭示了工单之外的控制面

ARIN 的12 月 12 日事件报告解释了为什么工单合规不足以代替系统控制。

23.150.164.0/24 原本正确发放给一个客户。2025 年 12 月 2 日，ARIN 在执行 4.10 发放流程时将其移除，并重新发放给另一客户。报告描述了一套部分离线的手工作业：电子黑皮书和 Excel 表格独立于主系统维护库存。地址块被移除时，相关注册服务也一起被删除，包括 ROA 与反向 DNS。随后，一家第三方服务商在错误登记状态下宣告了该地址块。

ARIN 没有自动发现错误。原客户在 12 月 9 日报告问题，错误状态持续约七天。ARIN 恢复原地址块，向另一客户提供替代 /24，协调撤回路由，并在当天完成纠正动作。公开报告没有给出客户技术影响声明，因而不能据此宣称发生客户中断、数据泄露或可测量的路由损失。

这也不是一句“人为失误”能够解释完的事件。ARIN 自己列出的机制同时包含混合库存、业务规则未充分整合，以及单方执行的可能性。报告说，带有网络删除操作的工单已经采取立即控制：限定由经验丰富的分析员处理，进行双人复核，并在固定时间由第二位复核者检查。

这些措施不应在报道中被抹去。正确问题不是“ARIN 有没有双人复核”，而是该控制覆盖哪些交易、如何证明复核者独立、例外如何记录，以及复核后是否把主系统、离线库存、ROA、反向 DNS 与路由状态重新核对。

这就是两类审计的分界。政策审计检查决定是否符合社区规则；控制审计检查系统和角色是否能阻止、发现并恢复错误的状态变更。它们会在同一工单上相遇，但不能共享一个未经解释的“通过率”。

公开对照表不需要公开敏感工作底稿

ARIN 无需披露客户数据、内部凭证或可被滥用的安全细节，也能让外界理解结论的边界。一张证据安全的对照表至少可以固定以下字段：

对照字段 可公开的最低内容
审计身份 稳定报告编号、委托主体、审计方、草案或最终状态
审计问题 触发事件、目标、审计期间与希望提供的保证
测试集合 总体、样本、选择方法和分析单位
适用标准 NRPM 章节与版本，或控制标准及其生效版本
例外 控制领域、定义、数量、分母和有边界的严重度
整改 建议、责任人、目标日期、依赖和实施状态
复测 方法、日期、结果与剩余风险
架构覆盖 Registry Control Plane 实际约束的应用与交易

当前公开资料在关键位置留下空白。1 月记录提到附件 W、X 和建议，却没有在页面上列出内容。4 月记录提到报告草案、十项标准、审查领域与建议，却没有公开标准清单、差异数量或严重度。这不能证明董事会没有获得详细材料；它只能说明公众无法从页面复原两项结论的分母。

对照表也能阻止几种过度推断。4 月记录没有证明恰好有十项失败、每项标准各失败一次，或每个不一致都很严重。新标准不能自动向过去追溯。公开页面没有证明两次汇报来自一份合并的 Baker Tilly 公共报告，也没有证明所引用附件已经公开。

更重要的是，版本字段能保存变化。某项标准经过修改之后，后续复测可以明确回答“相同要求是否已经稳定执行”，而不是用新版通过结果覆盖旧版发现。

Registry Control Plane 目前还是设计方向

4 月讨论提出在应用之间建立 Registry Control Plane，由其集中执行董事会和管理层定义的控制，降低单点执行风险，并提高可审计性。对于规则散落在多个应用、库存又部分存在于主系统之外的环境，这一方向有清晰吸引力。

但会议纪要也保留了尚未解决的问题。董事询问它究竟做什么、先处理哪个系统或应用、如何集成、外部开发会挤占哪些内部优先级。工作人员表示，规格仍需定义，尤其是成本和时间。

所以，现有证据只能称它为“提议”。不能写成已经批准、拨款、采购、部署、测试或证实有效。它是否解决 12 月事件，取决于第一批纳入的交易，而不是平台名称。

对 23.150.164.0/24 这条事件链，至少要分别标明：4.10 发放、库存移除、ROA 与反向 DNS 状态移除、重新发放、替代地址块，以及任何紧急越权。每一步都应绑定发起应用、规则版本、发起身份、独立批准和操作后核对证据。

如果控制层只记录了删除动作，却不解决哪套库存才是权威来源，它只会生成一份更清晰的错误日志。如果普通流程被阻断，但紧急旁路无人复核，单点风险只是迁移到旁路。真正的审计保证来自明确的控制边界、失败模式、越权治理与独立复测。

草案记录要求克制使用完成时

1 月和 4 月页面都标为草案。它们可以用于准确表述“董事会听取了什么”“纪要报告了什么”，却不能替代完整审计报告与附件。报道不应把草案中的摘要句升级为已经公开全部证据的最终结论。

截至 8 月 31 日抓取的董事会会议索引列出 2026 年 1 月和 4 月记录。4 月纪要说，工作人员希望在 8 月的下一次会议提交后续步骤。索引没有新增条目，并不能证明 8 月没有开会或项目没有进展。会议程序说明治理框架，但不会填补尚未公开的状态。

NRPM同样需要版本化引用。社区政策会变化；只有把审计日期、章节和版本保存在一起，未来才能区分“控制表现发生变化”与“适用规则发生变化”。

来源