注册数据发生变化时，为什么正常运行的网络也会消失？
沿着记录变更、路由过滤器和 RPKI 追踪故障，理解访问为何会中断，以及 Lu Heng 为何主张保障连续性并建立真正通向独立的路径。
设想你的服务通过移动网络仍能正常访问，但另一家网络的客户却再也无法连接。服务器运行正常，线缆也都连接着。一种可能的解释是：某条记录发生变化后，另一个网络不再接受通往你所用地址的路由。
容易被忽略的环节，是记录与路由器之间的决策。当某个系统利用数据库中的变更来生成过滤器或评估路由宣告时，这项变更就可能影响连通性。要理解故障，就需要沿着这条链路追踪。“注册机构出了错”只是诊断的起点。
记录变更影响路由接受时，物理连接仍可能完好无损。需要沿着证据和接收策略追查。
首先，问清哪条记录变了
IP 前缀表示一个地址块。自治系统号，即 ASN，用于标识与其他网络交换路由的网络。BGP 则是这些网络用来宣告自己能够到达哪些目的地的协议。
在这一交换过程之外，还存在几类相关记录。它们回答的是不同的问题：
- 注册记录：某个地址块登记在哪个组织名下，以及应联系谁。RIPE 数据库文档区分了资源注册、路由信息和联系人记录，尽管它们存放在同一个数据库中。
- 互联网路由注册库（IRR）记录：运营者可据此生成自己愿意接受的路由列表。记录描述的是预期的路由安排，本身并不宣告路由。
- 资源公钥基础设施（RPKI）记录：其中包括经过签名的路由起源授权，即 ROA。验证器据此生成数据，用于检查起源网络和允许的前缀长度。
过时的联系邮箱不会直接撤销一条 BGP 路由。但如果服务提供商生成的过滤器中缺少某条路由，就可能导致该提供商不再接受它。将两者都称为“无效的注册数据”，会掩盖真正重要的区别。
一条记录如何导致路由被拒绝
以一家依据 IRR 数据生成客户过滤器的服务提供商为例。下面是一种可能的故障过程：
- 一条路由记录被删除，或者客户的路由集合不再包含它。
- 服务提供商下一次生成过滤器时，遗漏了这条路由。
- 新的过滤器部署到服务提供商的路由器上，路由器拒绝客户的宣告。
- 如果没有其他可用路径，依赖这条路径的人就会失去访问能力。
只有当这些数据确实被用于生成该过滤器时，这条因果链才会发生。NTT DATA 公布的路由注册库政策提供了一个具体例子，说明基于 IRR 的客户过滤器及其自动更新机制。该政策还记载了拒绝 RPKI 状态为 Invalid 的路由，以及抑制相冲突的 IRR 记录的做法。这些都是可以明确识别的运营机制，并不是一个由注册机构掌握的通用断网开关。
RPKI 中的“Invalid”究竟意味着什么
在起源验证中，系统会将正在宣告的路由与经过验证的授权数据进行比较。RFC 6811 定义了三种结果：
- Valid（有效）：至少有一条覆盖该路由的授权与起源 ASN 匹配，并且允许所宣告的前缀长度。
- Invalid（无效）：存在覆盖该路由的授权数据，但没有任何一条同时满足这两个条件。
- NotFound（未找到）：没有授权数据覆盖该路由。
例如，如果与网络 A 所宣告路由相匹配的授权消失，而网络 B 的一条覆盖授权仍然存在，这条路由就可能变为 Invalid。如果不再存在任何覆盖授权，结果则是 NotFound。这里的“Invalid”是路由验证结果，并非对所有权或机构合法性的裁决。起源验证也不会验证路由声称经过的整条路径。
下一步取决于运营者配置的策略。RFC 8481 将设置验证状态与依据该状态采取行动区分开来：策略必须由运营者配置。如果某个网络配置为拒绝 Invalid 路由，就可能拒绝这条宣告。注册数据的编辑与路由被拒绝，通过这些机制联系起来；它们不是同一件事。
为什么有些人会先于其他人失去访问能力
各个网络并不会在同一时刻使用相同的过滤器、服务提供商或数据。RFC 7115 解释说，RPKI 缓存中的数据视图可能不同，更新到达路由器的时间间隔也没有统一保证。
在开头的例子中，一个网络可能已经依据变更后的数据采取了行动，而另一个网络仍然保留着一条可接受的路径。因此，局部中断是可能发生的。但这并不能证明任何一次具体中断由注册机构造成：工程师仍需检查受影响的路由、实际使用的数据，以及拒绝该路由的决策。
在作出更多变更前，先找到断裂的环节
真正有助于恢复的问题必须具体：哪个系统停止接受哪条宣告，为什么？运营者可以与服务提供商一起逐步排查：
- 识别宣告。记录受影响的前缀和起源 ASN，并检查预期路由是否仍在通告。
- 定位拒绝发生的位置。将服务提供商已部署的过滤器和验证结果与该路由进行比较。询问是哪一个数据源、哪一次更新导致了这一决定。
- 保留证据。保存相关记录、观测结果和时间戳，以便区分错误更新与未经授权的宣告。
- 修复并验证。协调实施准确的记录或配置修正，确认修正已传递到使用这些数据的系统，并从此前访问失败的网络测试连通性。
在所有地方关闭验证，也会一并移除对不良宣告的防护。运营上的任务，是恢复正确的证据和预期路由，再验证结果。仅仅成功编辑数据库，并不能证明客户已经能够重新连接。
更深层的问题：有用的证据可能成为集中的权力
技术链条在这里与 Lu Heng 的论点相交。管理方无需转发任何人的数据包，就能影响他们的可达性。如果其他系统依赖其控制的记录，它的决定就可能让运营者和客户承担远远超出其办公室范围的成本。
在第 65 则札记《运行代码优先》中，Lu Heng 主张，协调必须以运行中网络的需求为界限。维护记录的职能，不能自行扩张为永久的政治授权。一条记录经过签名，回答的是关于该项断言的技术问题；它并不确立统治所有受其影响者的权利。
他的提案不止于改进投诉程序。共同规则应保护唯一性、可核验的控制权和互操作性，同时由参与者在本地验证状态，并决定采纳哪些兼容的变更。一个拥有无限否决权的新委员会，只会换个名字重现同样的问题。
连续性需要一条其他网络也能使用的退出路径
一个可用的替代方案，必须延续可信记录、安全断言和现有合作关系。其他网络需要能够核验并使用这些记录。仅仅复制数据库，不会让它们接受替代方；宣布独立，也无法修复一条被拒绝的路由。
第 72 则札记明确说明了预期结果：准确的记录、运营连续性，以及真正离开失灵协调方的能力。实践中的挑战，是在建立这种能力的同时，不失去让独立网络彼此通信所需的共同唯一性和兼容性。
注册库状态导出指南探讨了这项工作中如何携带和延续记录的部分。这是过渡中的一个组成部分，还需要配合核验、运营者采纳和连续性测试。
趁服务仍正常运行时做好准备
请你的团队选取一个重要地址块，从其记录一路追踪到依赖它的服务提供商和客户。谁能修改每条记录？谁使用这些记录？如果当前管理方无法提供服务或存在争议，错误该如何纠正？
跨组织厘清这些问题需要时间。在故障前找到答案，才能留下行动空间；等到中断期间再去摸索，就会让客户承担成本。紧迫之处，在于趁连续性仍能得到保护时，建立切实可行的独立能力。
请继续阅读第 65 则札记：运行代码优先，了解 Lu Heng 关于以正常运行的网络、本地核验和自愿采纳为基础开展协调的完整论述。