注册状态导出：如何让互联网号码资源记录能够恢复

有用的导出资料能让另一位运营者验证已记录的状态及其历史。保留副本只是开始；交接还必须让人看得懂、能测试。

注册机构正常提供服务时，互联网号码资源似乎只是一次简单查询：输入 IP 前缀或自治系统号，便得到一份记录。这份记录很有用，但它只是更完整状态的一个视角：注册机构认可的是谁，发生过什么变化，哪些服务被委托管理，曾有哪些路由授权，以及当前答案由什么证据支持。

当注册机构无法提供服务、陷入争议、遭到入侵或正在被替换时，更难的问题就出现了：没有原始数据库和内部流程的人，能否仍然理解并验证该资源的合法状态？

连续性问题：如果当前注册系统明天停止响应，合法持有人或接替方需要哪些信息，才能重建最近一次经验证的状态，而不是凭空创造一个新状态？

先区分三种不同状态

许多关于注册机构的讨论之所以混乱，是因为把三个不同问题当成了一个：

• 注册状态：权威机构当前记录的资源、受认可的持有人、联系人、事件、委托关系和状态信息。
• 运维状态：资源在实践中如何被使用，包括反向 DNS、服务商关系和服务连续性。
• 路由状态：哪个自治系统是路由起源，以及相关路由授权是否有效。

这些状态可以一致，但不一定同时变化。前缀可以在服务商之间迁移，而受认可的持有人保持不变；注册记录可以正确，但路由配置有误；路由授权可以有效，但联系人对象已经过时。有用的导出资料必须保留这些状态之间的关系，并说明每项证据支持的是哪一项陈述。

RDAP 能提供什么，不能提供什么

RDAP 是注册数据的标准查询层。其 JSON 模型描述 IP 网络、自治系统号、实体、事件和链接等对象，让不同注册机构的实时记录更容易查询和理解。其结构由 RFC 9083 定义。

RDAP 回答的是当下的查询问题：提供服务的注册机构现在为这个对象返回什么？响应可能包含当前记录和事件信息，但实时响应并不自动构成独立的连续性资料包。它本身无法保证持有人拥有一系列可迁移、经过认证的历史状态、完整的状态转换记录，或有序开展接替流程所需的材料。

这一区别很重要。实时目录是观察系统的一扇窗口；注册状态导出则是一种方法，用于保存足够的已验证状态，以便在窗口、系统或机构关系发生变化时，仍能分析如何维持连续性。

RPKI 能证明什么，不能证明什么

RPKI 回答的是路由问题。路由源授权标明某个自治系统已获地址空间持有人授权，可以为一个或多个前缀发起路由通告。相关格式规范和验证规则见 RFC 9582。

这是有价值的证据，但不足以完整回答每一个注册管理问题。有效的 ROA 本身不能证明资源的完整法律或管理历史，不能识别所有运维联系人，不能确立反向 DNS 的连续性，也不能解决应当认可哪一种注册状态的争议。RPKI 授权是连续性记录中的一个层面，不能取代整份记录。

注册状态导出的工作定义

注册状态导出，是一种拟议的连续性资料包，旨在让 IPv4、IPv6 或 ASN 资源的核心已验证状态能够迁移、理解和测试。它应让独立阅读者能够回答四个问题：

1. 我们谈的是哪项资源，以及哪一位受认可的持有人？
2. 最近一次经验证的状态是什么，从何时开始生效？
3. 在那之后发生了哪些重大变更？
4. 哪些证据和授权依据支持合法的状态转换或接替流程？

这比数据库转储更有针对性，也比截图更有用。导出资料应包含接替方需要的状态，同时排除无关客户数据、私密商业策略，以及无法用来确立资源情况的内部实现细节。

最基本的有效导出内容

实用的导出资料可以组织成一小组相互关联的记录。每份记录都应包含稳定的标识符、生效时间、来源，以及足以发现无法解释的变更的信息。

• 资源身份：IPv4 前缀、IPv6 前缀或 ASN，适用时的上级资源或分配关系，以及其注册标识符。
• 受认可的持有人：在经验证状态中受到认可的组织或实体、注册标识符，以及该认可的生效日期和状态。
• 联系人：接替方或依赖这些记录的主体确实需要的管理、技术、滥用投诉和安全联系人。
• 重要历史：转移、名称或组织变更、委托、状态变更、争议，以及与每个事件关联的证据或授权。
• 运维关系：相关服务商、受委托使用者、反向 DNS 和服务关系，以及各自的有效期间和终止状态。
• 路由与安全引用：相关路由起源 ASN、ROA 或 RPKI 对象的引用信息、发布状态，以及观察到该状态的时间。
• 冲突状态：是否存在争议、暂停处理或相互冲突的主张，影响哪项资源，以及最后一个未受争议的状态。
• 审计轨迹：谁在何时、依据何种权限，将什么从哪个值改为哪个值，以及验证结果如何。
• 完整性信息：版本号、时间戳、对象哈希、签名和导出清单，让接收者能够验证来源并发现修改。

导出资料不必复制每一张内部数据库表。它需要保留的是那些关系：正是这些关系，让公开查询答案有意义，也让状态转换可审计。

为什么备份还不够

备份通常是为了让同一个运营者恢复系统。注册状态导出则是为了在原系统、组织或运作安排无法直接恢复时，让另一位获授权主体理解并验证状态。

• 备份可能依赖专有软件、未记入文档的关联关系，以及原始凭据。
• 导出资料应当能被独立接替方读懂，并标明每项重要主张背后的证据。
• 备份包含的数据，可能远超资源持有人有权或愿意接收的范围。
• 导出资料应限定于该资源，经过认证、可供机器读取，并且能够迁移。

这不是技术偏好之争，而是保存一台机器，与保留识别合法状态的能力之间的区别。

需要维持连续性时，该如何处理

连续性流程不应从允许两个系统同时声称对同一资源具有权威开始，而应先固定最近一次经验证的状态，并明确记录状态如何转换。

1. 明确触发原因：中断、资不抵债、遭到入侵、迁移、争议，或其他已定义的连续性事件。
2. 保留最近一次经验证的状态：记录资源、受认可的持有人、联系人、重要历史，以及支持该快照的证据。
3. 验证导出资料：检查签名、哈希、时间戳、授权引用和清单完整性。
4. 区分证据层面：将注册状态与实际运维使用、反向 DNS、路由观测和 RPKI 状态对照，而不是把某一层当作其他所有层面的证明。
5. 记录接替方：明确旧状态如何被取代、冲突如何处理，以及依赖这些记录的系统如何发现受认可的接替方。
6. 公布状态转换：让新状态及其生效时间可以被查得，同时将先前状态保留为可审计的历史记录。

这一流程旨在保持连续性，同时避免中断成为未经验证的主张者改写历史的机会。

注册状态导出绝不能做什么

连续性导出资料不是第二家注册机构，不会赋予每个接收者声称拥有资源的权力。它不应制造并行的权利主张，不应绕过适用的资源政策，不应暴露客户流量或机密策略，也不应悄悄把实际运维使用转变为受认可的管理控制权。

导出资料还应说明自身局限。如果某个字段无法获取、经过遮蔽或存在争议，记录就应如实注明。坦诚的未知，比看似完整却没有证据的值更安全。

如何在危机前测试导出资料

资源持有人或运营者，可以通过一次简单审查来检验这一思路：

• 独立阅读者能否识别确切的 IPv4、IPv6 或 ASN 资源？
• 能否识别最近一次经验证的受认可持有人及其生效日期？
• 能否还原重要的转移、委托和组织变更？
• 能否区分注册状态、当前路由和实际运维使用？
• 能否找到相关的 RPKI 和反向 DNS 证据？
• 能否看出是否存在争议或相互冲突的主张？
• 能否验证导出资料由谁生成，以及之后是否被修改？
• 合法接替方能否在不导入原始私有数据库的情况下使用这些记录？

如果这些问题的答案是否定的，那么组织可能拥有实时查询服务或备份，却还没有经过检验的连续性记录。

它如何融入 IPv4 生命周期

IPv4 资源的生命周期，包括注册记录、转移、运维委托、路由，以及最终的用途变化。导出资料将这些时点连接起来。可先阅读注册数据能反映 IPv4 生命周期的哪些方面，再区分跨 RIR 转移中的区域变动与 BGP 重新归属中的路由变更。

同样的道理也适用于更广泛的治理问题：当一个系统负责协调唯一资源时，验证并迁移状态的能力，不应完全依赖某个可能无法提供服务的管理节点。因此，注册状态导出应与互联网注册机构失效时会发生什么，以及控制权证明究竟能说明什么这些实践问题一并讨论。

结语

注册状态导出，是让连续性变得具体可行的一种方式。它不会取代 RDAP、RPKI、路由数据、反向 DNS 或注册机构政策，而是把相关证据连接为一份经过认证、具有版本信息且可迁移的记录，使合法查阅者在原系统无法直接被信任或恢复时，仍能理解资源状态。

如果注册机构消失，目标不是让任何人都能声称拥有资源，而是保存足够的已验证状态，让合法答案仍然能够被识别、检验并延续下去。