摘要

  • 2026 年 2 月的最终模型规定，只有完成前 11 个里程碑、公开评估、公众咨询和 Council 正式表决后，治理结构才会进入全面授权阶段。届时，SIR 可在极端安全情形下暂停一名 RSO 的运营；现有公开材料不能证明这项权力已经生效。
  • 永久移除由 DNR 另行处理：调查、给予充分纠正机会、向 Council 提出建议，并依照 RSSAC030 协调从三项 DNS 根源中有序移除。模型没有说明 SIR 的临时暂停是否触及这些根源，也没有定义暂停期限、上诉的暂停效力和恢复资格的决定。
  • 在 Milestone 12 授权之前，Council 应批准一份版本化的“暂停—恢复连续性记录”。公开层只需写明权力依据、作用范围、时钟、纠正、上诉和最终状态；可能帮助攻击者的技术证据保留在受保护附件中。

一项权力，缺少它的反向状态

治理文件最容易在授予权力时写得具体，在权力退出时写得含糊。根服务器系统治理结构的最终模型正好提供了一个可在实施前修补的例子。

未来的 Security Incident Reporting 职能，简称 SIR，不只是接收报告。进入 Governance Phase 后，它可以发起调查、要求运营者提交资料和配合、强制实施安全改进、执行安全政策、对违规者采取纠正措施，并在重大安全事件中授权紧急行动。其最强的一项措施是：若违规对 Root Server System 构成重大威胁，可在极端情况下暂停一名 RSO 的运营。

对于关键基础设施，这种能力并非天然不当。一个机构若只能记录风险、不能在风险扩大前采取隔离措施，它的监督可能只剩下事后解释。

问题在于，“暂停运营”究竟暂停哪一种状态。它可能表示治理结构中的资格被冻结，可能限制某项服务义务，可能隔离一部分实例或基础设施，也可能进一步影响客户端用来识别根服务器服务的公共根源。最终模型没有定义这一对象。

全文也没有出现 reinstatement，即恢复资格或复位的明确状态。文件写了调查、纠正措施、上诉和永久移除，却没有规定：若风险已经排除，谁依据何种标准把暂停状态改回有效状态；若上诉成功，运营是否自动恢复；若技术纠正完成但复核尚未结束，运营者处于什么位置。

这不是对任何现任 RSO 的风险判断，也不是说现有 ICANN、RSSAC 或 IANA 已经能够执行暂停。它是一个应当在权力启用前完成的制度接口。

这仍是一套拟议模型

最终模型本身设置了相当严格的授权门槛，不能把其中的未来时态改写成现在时。

Initiation Phase 负责建立 Council 和 Secretariat，权限有意保持有限。Establishment Phase 才会设立并具体定义 SAP、FRM、PME、SIR 和 DNR 五项职能，制定政策、绩效标准、资金机制、安全报告、指定和移除程序、正当程序以及上诉机制。

进入 Governance Phase 之前，全部职能必须建立并实际运行，核心治理政策须获 Council 批准，Milestones 1–11 的完成情况要写入一份向公众开放的综合评估。随后还要进行公众咨询，与参与型利益相关方社群确认共识，并由 Council 正式投票确认准备就绪。只有 Milestone 12 才写明治理结构开始拥有完整治理权限。

截至证据截止日，公开轨迹只证明工作组在 2026 年 2 月 18 日以共识批准最终报告，并于 20 日向 ICANN 社群、Board、IETF/IAB、RSSAC 和 RSO 提交。ICANN Board 主席 23 日的回信表示感谢，并期待后续进程。回信没有宣布采纳、实施或进入 Governance Phase。ICANN 的运营规划曾预计 Board 采纳，并将后续工作明确置于 Board 决定和优先级安排之下；预计不等于已经作出的决定。

因此，本文讨论的是一项“将会允许”的权力，而不是已经存在的处罚机制。正确的治理审查，是在授权前检查状态机是否完整，而不是把提案写成事实。

SIR 处理紧急风险，DNR 处理永久地位

模型没有把所有问责权集中在同一个职能中，这是其设计上的优点。

SIR 从安全事件出发。它定义事件、规范报告、进行事后分析、制定安全控制、执行审计、推动漏洞缓解并向外部沟通。它的时间尺度偏向即时：在事件仍在发展、材料尚不完全时，也可能需要先保护系统。

Designation and Removal，即 DNR，从绩效问题或不合规状态出发。它根据 PME 发现的问题展开审查，与运营者在规定期限内处理纠正，只有在给予充分纠正机会后仍不达标，才向 Council 建议永久移除。移除需要 Council 最终批准，并与 IANA 沟通，协调有序停止及从 DNS 根源中移除。

暂停和移除因而不是同一件事的快慢版本。紧急暂停可以在完整的永久地位审查之前发生；永久移除则会改变运营者群体的组成，需要更高、更慢、也更可复核的门槛。

双轨也带来保管问题。一个 SIR 案件可能因技术纠正而结束，可能因上诉而撤销，可能缩小为更有限的措施，也可能转入 DNR 的永久移除审查。最终模型没有规定哪一个动作构成正式移交，移交期间由谁维护当前状态，或者 SIR 如何作出结案决定。

“纠正已经完成”和“资格已经恢复”必须是两个字段。前者是证据状态，后者是授权状态。如果没有明确连接，一项临时措施可能只因没有人签署反向决定而长期存在。

RSSAC030 让“暂停”具有技术后果

RSSAC030 只有一页，却清楚说明了为什么不能把暂停只当成制度标签。

IANA Functions Operator 维护三项关键根源：root hints 文件、根区以及 root-servers.net 区。这些来源把根服务名称映射到 RSO 控制的 IPv4 和 IPv6 地址。组织的信息被纳入其中，既让全球客户端能够发现相应服务，也标识其 RSO 身份。

最终模型在描述 DNR 的永久移除时明确引用 RSSAC030：DNR 要协调有序停止，并从 DNS 根源中移除一名 RSO。SIR 的暂停条款没有使用同样措辞。

因此至少存在三层不同状态。

第一层是治理状态：某个被授权职能宣布运营者处于暂停。第二层是运行状态：事件响应期间，某些实例、系统或服务义务被限制或隔离。第三层是根源状态：IANA 维护的三项来源发生修改，使组织的根服务信息被删除或改变。

这三层不能相互推定。治理资格暂停，不必自动等于根源条目被删除。事件期间隔离某个组件，不是永久移除。若一项临时 SIR 措施实际上产生了根源移除效果，就可能在 DNR 调查和 Council 批准之前形成事实上的永久决定。

证据并不表明模型一定会这样运作。更合理的要求是：未来程序必须明确声明本次行动触及哪一层、没有触及哪一层，以及任何根源动作依据哪一项独立授权、如何撤回。

上诉不是自动恢复

模型为 SIR 决定提供了向 Council 上诉的渠道；DNR 的决定也可直接向 Council 上诉，永久移除建议则需 Council 最终批准。SIR 还要接受同行评审和定期外部评估，并发布年度报告。

这些都是重要制衡，但“可以上诉”并没有回答运行状态。

提出上诉是否自动停止暂停？Council 是否可以批准临时停止执行？上诉期间，运营者能否继续不受影响的部分服务？若上诉成功，原有状态是自动恢复，还是要另行通过技术准备度检查？若安全漏洞已经修复，谁确认修复足以解除重大威胁？若问题只解决了一部分，应当缩小措施还是延长暂停？

程序审查和网络运行使用不同的时钟。调查与答辩可能持续数日甚至更久，安全隔离可能在数分钟内就必须执行。完整制度不能要求两者使用同一速度，而要把三个状态分开：即时控制、上诉期间的临时状态、最终实体决定。

如果这些状态散落在 SIR、Council、DNR、IANA 和运营者自己的记录中，第一宗争议案件就会迫使参与者依赖电话、聊天和机构记忆。关键基础设施最不应该在此时缺少共同状态。

公开权力，不等于公开漏洞

RSSAC062 对透明度的边界给出了实用答案。该文件把可报告安全事件限定为对 RSS 的可用性、完整性或保密性造成重大不利影响的事件，并明确说报告流程不应干扰事件缓解，首要任务是解决事件。

详细报告可以使用 Traffic Light Protocol 标记。任何可能帮助未来攻击者的信息都应排除。提交通道应有身份验证，并保护敏感资料。同时，治理结构应及时发布 TLP:Clear 的公开版本。

暂停—恢复记录完全可以采用同一分层。公众无需看到私钥、内部拓扑、未经匿名化的查询日志、尚未修补的漏洞细节或攻击复现步骤。公众需要看到的是：哪一个列举权力被使用、一般触发类别是什么、措施触及什么、何时复核、当前是继续、缩小、恢复还是转入 DNR。

受保护附件保存取证材料和详细修复证据。公开记录可以列出附件的保管角色、访问级别，并在安全可行时保存完整性哈希，而不公开其内容。

这不是在安全和透明之间折中，而是在区分两类信息：公开权力的状态，以及可能扩大攻击面的技术事实。

最有力的辩护，正是完成闭环的理由

为模型作最强辩护，可以说它本来就不是每一种事件的操作手册。详细章程和流程被留到 Establishment Phase，是为了让真正熟悉根服务、事件响应、IANA 协调和机密证据的人完成设计。这种分阶段安排比在高层报告里假装穷尽所有情况更诚实。

模型也已设置多重限制：只有极端情况和重大威胁才可暂停；职能相互分离；上诉由 Council 处理；永久移除前要给予纠正机会；SIR 有同行和外部审查；全面授权前还要公开评估和咨询。

此外，RSS 的冗余和多样性意味着，在确有重大威胁时，暂时隔离一个运营者可能比让风险扩散更能保护全球服务。没有应急工具本身也可能构成治理缺陷。

但这些理由支持的是完成程序，而不是允许无期限空白。Milestone 7 要建立安全政策、事件响应和升级流程；Milestone 8 要定义指定、移除、正当程序和上诉；Milestone 10 要补足问责和其他复核机制。它们应当共同产出从紧急暂停到恢复或 DNR 的一条连续链。

Heng Lu 的 Running-Code Primacy 在这里提供了一个范围测试：制度性权力应当以运行网络所需的最小、可验证技术作用为依据。若“暂停”无法指向明确运行变化，它就可能停留在象征权力层，却被不同参与者执行出不同后果。

其“保护账本而非守门人”的连续性判断也可谨慎应用。根系统需要保护的是服务、记录、安全链和下游用户，而不是自动维护治理者的全部权力，也不是无条件维持每一个运营者的地位。为保护整体而暂停一方可以正当；同样为了整体，暂停必须拥有可核验的恢复或永久移除路径。

建立“暂停—恢复连续性记录”

在 Milestone 12 之前，Council 应批准一份贯穿 SIR、Council、DNR 以及必要时 IANA/RZM 的版本化记录。事件发生时先创建最小条目，风险稳定后逐步补齐，绝不能让填表拖慢缓解。

公开层应包括：

  • 稳定案件编号和受影响 RSO；
  • 决策职能、权力依据、政策版本和负责角色；
  • 不泄露敏感事实的触发类别，以及是否使用紧急程序；
  • 对治理资格、服务义务、基础设施范围和根源状态的精确作用；
  • 生效时间、初始最长期限和下一次强制复核；
  • 保障整体 RSS 连续性的措施；
  • 纠正措施及其公开完成状态；
  • 受保护证据的保管与分类；
  • 上诉、停止执行申请和实际决定；
  • 恢复资格的权力主体和判断标准；
  • 技术准备度检查、同行或独立复核；
  • 每次延期的日期、新决定和理由；
  • 最终状态：恢复、缩小、被其他措施替代，或正式移交 DNR；
  • 任何 IANA、RZM 或根源动作的单独授权及撤回状态。

字段语义必须严格。“已经上诉”不等于“已经停止执行”；“已经纠正”不等于“已经批准恢复”；“已移交 DNR”不等于“已批准移除”；“已批准移除”也不等于“三项根源已经修改”。

否定状态也要明写：未采取根源动作、未提出上诉、恢复决定仍待作出。空白字段无法区分“没有发生”“仍在等待”和“无人负责”。

这份记录不会给 RSO 否决权，不会让公众指挥事件响应，也不会公开攻击方法。它只要求每一个强制状态都有明确的主人、范围、时钟和终点。

证据边界

现有材料不能证明 ICANN Board 已正式采纳最终模型，不能证明 Governance Phase 已开始，也不能证明任何 RSO 曾依据该模型被暂停。本文没有对现任运营者作出违规、安全或能力判断。

全文没有明确恢复资格一词，并不等于未来章程无法补写程序。它只意味着程序应成为授权前的核验条件。由于“暂停运营”的技术对象未定义，本文也不声称它必然修改 root hints 文件、根区或 root-servers.net 区。

公开记录的对象是权力和状态。可能帮助攻击者或暴露正当运营机密的证据，仍可保留在受保护层。

来源

  1. ICANN——《根服务器系统治理结构》，2026 年 2 月 18 日
  2. ICANN——《根服务器系统治理原则》
  3. Brad Verd——GWG 最终报告及交付材料
  4. Tripti Sinha——ICANN Board 主席对 GWG 的回函
  5. ICANN 公众意见征询——根服务器系统治理功能模型
  6. RSSAC030——DNS 根源条目声明
  7. RSSAC058——RSS 治理结构成功标准
  8. RSSAC062——安全事件报告
  9. RSSAC055——公共根服务器系统运行原则
  10. ICANN——FY2027–2031 运营与财务计划草案
  11. Heng Lu——Running-Code Primacy
  12. Heng Lu——The Registry Continuity Fallacy
  13. Heng Lu——On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile