摘要
- ICANN 2018 年 10 月的根 DNSSEC 密钥签名密钥滚动更改了由 DNSSEC 验证解析器用于验证 DNS 根的公开信任锚。ICANN 的滚动页面指出，没有当前根信任锚的解析器在更改后将无法解析 DNS 查询，这使就绪状态成为连续性问题，而非狭窄的加密维护任务。
- 最强的问责事实是延迟。ICANN 最初计划于 2017 年 10 月进行滚动，但在新可用的 RFC 8145 遥测表明大量由 ISP 和网络运营商使用的解析器可能尚未就绪后，推迟了滚动。该决定将一个隐藏的运营商就绪问题转化为公开的治理记录。
- 随后，ICANN 在董事会批准、公开评论、持续外展、技术分析和修订计划后，于 2018 年 10 月 11 日执行了滚动。ICANN 在事件后宣布，观察到的少数问题迅速得到缓解，并未表明需要回滚的系统性故障。
- 实际控制是分布式的。ICANN 和 Public Technical Identifiers 控制了根 KSK 仪式流程、发布、文档、外展和最终滚动决策；Verisign 担任根区域维护者角色；解析器运营商控制信任锚配置和软件行为；供应商控制 RFC 5011 实现质量；公共机构和企业为其自身网络控制应急计划。
- 问责制的教训是，全球互联网基础设施变更需要可观察的就绪状态、已发布的决策标准、社区评论、安全回滚思维以及当遥测破坏信心时足够谦逊地延迟。滚动之所以成功，是因为它被当作公开运营风险处理，而非因为风险是虚构的。
根密钥虽小，但依赖关系却是全球性的
如果将其简化为替换一个加密密钥，根 DNSSEC 密钥签名密钥滚动听起来像是一个微观事件。在运营术语中，它是一次全球依赖关系测试。DNS 根是公共域名系统委派体系结构的顶端。DNSSEC 验证解析器使用信任锚来验证已签名的 DNS 数据。如果根 KSK 更改后验证解析器中的根信任锚过时，解析器可能将有效答案视为虚假，导致其用户无法进行普通名称解析。
ICANN 专用的根区域 KSK 滚动页面是锚点来源。它解释说，ICANN 于 2018 年 10 月 11 日执行了滚动，滚动 KSK 意味着生成新的公钥和私钥对，并将公钥分发给验证解析器的运营商，并指出保持最新 KSK 至关重要，因为如果没有当前根区域的 KSK，DNSSEC 验证解析器将无法解析 DNS 查询。这就是用通俗语言表达的整个问责问题。当分散的运营商尚未更新本地验证状态时，中央信任对象的更改就会变成用户服务中断。
KSK 并非孤立存在。ICANN 的滚动页面将最初的规划描述为根区域管理伙伴的工作：ICANN 作为 IANA 职能运营商，Verisign 作为根区域维护者，以及美国商务部 NTIA 在 2016 年 10 月 1 日 NTIA 角色结束前作为根区域管理员。IANA 根区域管理页面提供根区域管理的当前公开入口点，而IANA DNSSEC 根区域 KSK 页面则提供信任锚和 KSK 仪式信息。因此，运营记录位于 ICANN 治理、PTI/IANA 职能、Verisign 根区域运营以及众多使用根信任锚的独立解析器运营商的交叉点。
DNSSEC 自身的技术架构解释了该事件为何重要。RFC 4033定义了 DNSSEC 简介和要求，RFC 4034定义了 DNSSEC 使用的资源记录，而RFC 4035定义了协议修改。这些标准并非 ICANN 特定事件的证据。它们解释了使根密钥具有重要意义的验证链。验证解析器要么拥有其接受的信任路径，要么没有。与可由一个运营商为一项服务替换的网站证书不同，根信任锚是共享基础设施。
因此，公共连续性利害关系非常广泛。ISP、企业、大学、公共机构、递归 DNS 提供商、注册局、注册商、云网络、软件分发商、设备供应商和普通用户并不都是 ICANN 的直接客户。然而，他们的 DNS 解析可能取决于其递归解析器是否已做好准备。这就是为什么 ICANN 在 2017 年推迟的公告中估计，全球约四分之一的互联网用户（约 7.5 亿人）依赖 DNSSEC 验证解析器，并可能受到执行不当的滚动的影响。这个数字并非预测所有这些用户都会出现故障。它是对依赖人群的衡量。
这种区别很重要。滚动并非服务中断。它是在可能发生中断之前进行的一次问责测试。公共基础设施治理往往仅在失败后才受到评判。在这里，治理记录之所以有意义，是因为 ICANN 在失败前就推迟了，重新开放了计划，收集了更多证据，扩大了外展，并在后来明确接受风险的情况下做出了启动决定。
延迟是问责制的关键
记录中最重要的事件发生在成功滚动之前。ICANN 的2017 年 9 月 27 日推迟公告称，更改用于帮助保护 DNS 的加密密钥的计划被推迟。ICANN 解释说，最近获得的数据显示，大量由 ISP 和网络运营商使用的解析器尚未就绪。它将这种新的可见性与一项最近的 DNS 协议功能联系起来，该功能允许解析器向根服务器报告其配置了哪些密钥。
该功能是RFC 8145，它为验证解析器定义了一种信号传递已配置信任锚的方法。该协议并未给 ICANN 提供完全了解。它创建了一个嘈杂、部分、运营上敏感的 就绪视图。某些信号可能来自配置错误的系统、测试环境、转发器、过时软件、陈旧配置或未为大量用户提供服务的解析器。但不完美遥测的存在本身仍是一个治理事件。ICANN 必须决定是尽管某些解析器的信号显示过时仍按计划推进，还是推迟并让社区解读数据、加大外展。
ICANN 选择了推迟。事后看来，这个决定很容易受到赞扬，因为后来的滚动成功了。但当时，它有其自身的代价。推迟可能会破坏对计划的信心，延长两类密钥并存的时间，延迟 ICANN 的 DNSSEC 实践声明所要求的运营演练，并向已为 2017 年日期做好准备的运营商发出不确定性信号。然而，贸然推进将冒着让解析器运营商及其用户在名称解析停止时才发 现就绪问题的风险。
对于基础设施治理而言，推迟公告异常坦率。公告称，运营商可能有多重原因未安装新密钥，包括解析器软件未正确配置，以及最近在一个广泛使用的解析器程序中发现的一个问题，该程序似乎未按预期自动更新密钥。公告还提到，ICANN 正在接触社区，包括 SSAC、区域互联网注册机构、网络运营商团体等。公告引用了 ICANN 首席执行官的话，称在识别出可能对成功和最终用户连通性产生不利影响的新问题后，继续推进将是不负责任的。
这种表述创造了一个公开标准。ICANN 并未承诺每个验证解析器都能正常工作。它承诺的是，新发现的就绪证据将改变决策。在基础设施运营中，这就是按日历驱动的更改与按证据驱动的更改之间的区别。
推迟也为解析器运营商保留了问责制。ICANN 无法登录到每个递归解析器并安装信任锚。ISP、企业、政府网络和 DNS 服务的运营商控制着自己的解析器软件和配置。通过推迟，ICANN 使就绪问题公开化，并为这些运营商提供了额外时间。这并没有将所有责任都转移给他们，但使共享控制模式变得可见。
RFC 5011 自动化有用，但并非魔法
这次滚动严重依赖于自动信任锚更新行为。RFC 5011定义了 DNSSEC 信任锚的自动更新。RFC 5011 的吸引力很明显：验证解析器可以在添加保持期内观察新密钥，并自动将其接受为信任锚。如果没有这种机制，每个验证解析器运营商都需要在互联网规模下手动安装密钥。
然而，自动化本身永远不是问责制。它是代码和配置在现实世界多样性下做出的承诺。解析器必须正确实现算法、保持状态、拥有与保持过程兼容的时钟和正常运行时间模式、接收并验证相关的 DNSKEY 材料，并避免会破坏自动更新的本地配置选择。运营商还必须知道其解析器是否确实在验证、是否转发到另一个解析器、其软件包版本行为是否正确，以及配置管理系统是否会覆盖信任锚状态。
Verisign 的KSK 滚动页面从根区域维护者和根服务器角度捕捉了这种区别。该页面称，每个 DNSSEC 验证器都需要一个信任锚，并且 RFC 5011 从未在根 KSK 滚动的生产环境中被测试过。它还表示，Verisign 作为根名称服务器运营商，接收了一些 RFC 8145 数据，并对其进行分析以识别那些看起来信任锚配置已过时的来源。这很重要，因为它表明遥测并不仅仅是 ICANN 的中央仪表盘。根服务器运营商也可以看到并就绪信号采取行动。
自动化使滚动成为可能，但公共问责制需要独立的证据来证明自动化已经起作用。这些证据包括信任锚信号、解析器软件测试、对似乎过时的运营商进行外展、公开评论、邮件列表讨论和事后监控。它还包括如果出现足够普遍的故障，愿意为回滚设定阈限。
根区域 KSK 滚动设计团队最终报告是有用的背景资料，因为它在 2017 年推迟之前为首次根 KSK 滚动制定了一套设计流程。它建议进行审慎的阶段划分、沟通和测量，正是因为互联网此前从未经历过运营性的根信任锚滚动。后来的推迟并未证明设计团队失败了。它证明了设计假设是正确的：首次滚动需要观察和分步决策。
教训不在于 RFC 5011 不可靠。教训在于，当分布式自动更新机制保护共享基础设施时，需要遥测和社会协调。标准可以定义一个状态机。但它无法让每个运营商都了解该状态机是否在其网络中正确运行。
公开评论将技术更改转化为治理记录
推迟之后，ICANN 并没有简单地私下选择一个新的日期。其重启根密钥签名密钥滚动流程计划公开评论页面将修订后的计划提交给了社区审查。公开评论页面称，该计划包括更多关于准备情况的宣传、更多就绪数据分析以及实际的 2018 年 10 月 11 日滚动。相关的继续根 KSK 滚动计划 PDF描述了在早前推迟后提议的重启。
这一步很重要，因为技术合法性和机构合法性是不同的问题。ICANN 可能在技术上能够更改密钥，但如果忽视了社区关于就绪的证据，在政治上仍是不负责任的。反过来，社区可能会要求无限期推迟，但无限期推迟也会产生运营债务。公开评论迫使分歧成为记录：应该信任哪些数据，什么样的外展才足够，应该使用什么故障阈限，以及谁将做出最终决定。
关于计划草案评论的员工报告就是这种转化步骤的证据。它并没有让所有风险消失。它表明，ICANN 在向董事会提交计划之前收集并回复了评论。基础设施问责通常不是为了达成普遍共识，而是为了让证据和异议在权力机构采取行动之前可见。
ICANN 的董事会批准公告称，董事会已批准了保护 DNS 根的加密密钥首次更改计划，并指示该组织于 2018 年 10 月 11 日推进。公告承认，无法完全确保每个网络运营商的解析器都正确配置，但表示 ICANN 预期绝大多数用户都能访问根区域。公告还提到，最坏情况下，运营商可以通过关闭 DNSSEC 验证、安装新密钥并重新启用验证来解决。
底层的2018 年 9 月 16 日 ICANN 董事会决议是正式的治理文件。它们很重要，因为启动决策不仅仅是技术人员的行动。这是由一家使命包括 DNS 安全、稳定性和弹性的公益公司做出的机构决定。董事会并未运营每个解析器，但它根据修订后的计划和磋商结果批准了中央更改。
公正的叙述不应假装公开评论消除了风险。它改变了举证责任。ICANN 必须解释为什么在 2018 年 10 月推进比进一步推迟更好。运营商必须利用额外的一年时间验证自己的就绪情况。社区必须接受共享信任锚不可能仅在不确定性为零时才滚动，因为零不确定性永远不会到来。
沟通是控制的一部分，而非公共关系
ICANN 的外展材料是运营控制手段。滚动页面链接了在 DNS 验证解析器中检查当前信任锚和使用最新信任锚更新验证解析器的资源。这些文件不是营销材料。它们是为控制就绪“最后一英里”的运营商提供的实用指南。
在根 KSK 滚动期间预期事项综合指南提供了另一种形式的控制：期望管理。运营商需要知道什么将改变、何时改变、症状如何表现，以及如果验证失败该怎么做。一次沉默的中央更改将使每次中断调查都必须从头开始。公开指南为帮助台、网络团队和安全人员提供了一个共享框架。
DNS-OARC KSK 滚动材料及相关运营商社区场所出于同样的原因至关重要。DNS-OARC 不是 ICANN，其角色不应被夸大为中央治理机构。它作为公共技术社区渠道是有用的，解析器运营商和 DNS 专家可在此分享测试和观察结果。互联网基础设施变更往往通过这种半正式协调网络取得成功：标准机构定义机制，ICANN 管理根功能，根运营商观察流量，运营商社区将风险转化为可部署的行动。
沟通还需要覆盖公共部门网络。清单标签“公共部门连续性”之所以合适，是因为政府服务、学校、医院、应急管理办公室和公共机构通常依赖于由中央 IT 组织或供应商配置的递归 DNS。在这种环境中，一个过时的验证解析器不会被视为一次 DNSSEC 教育练习。而是会被体验为无法访问服务。
公共部门连续性的教训是，当信任锚更新对服务所有者隐藏时，安全改进可能会带来可用性风险。一个城市机构可能不知道其上游解析器是否验证。医院网络团队可能依赖一个托管 DNS 设备。学区可能继承 ISP 解析器的行为。ICANN 的公开材料无法强迫这些组织进行测试，但它们为这些组织提供了一种提出正确问题的方式。
沟通也必须避免恐慌。ICANN 需要警告未准备好的验证解析器可能出现故障，同时不暗示整个互联网都会中断。它需要解释大多数非验证解析器不会直接受到影响，同时不阻碍 DNSSEC 的采用。它需要将禁用验证描述为紧急恢复选项，同时不将该选项默认为首选。这种平衡在操作上很困难。警报太少会导致不作为。警报太多会导致对安全机制本身的不信任。
启动决定接受了残余风险
2018 年 9 月的批准并不意味着 ICANN 已经证明每个解析器都是安全的。这意味着在加强了外展、分析和社区磋商之后，ICANN 接受了残余风险。这种区别对问责制至关重要。
ICANN 的批准公告称，研究表明成千上万的网络运营商已启用 DNSSEC 验证，约四分之一的互联网用户依赖它们。公告还表示，几乎可以肯定某些地方的至少少数运营商没有做好准备。这是异常诚实的风险用语。它没有承诺一次完美无缺的滚动。它解释了为什么推进仍然是合理的：预期的故障足够小、足够可恢复，而且被执行密钥滚动流程的必要性所胜过。
公开记录还包含回滚概念。ICANN 的首次滚动成功完成公告后来表示，出现的少数问题迅速得到缓解，没有一个表明存在达到启动回滚的社区定义阈值水平的系统性故障。这句话很重要，因为它表明成功是根据明确的运营阈值评估的，而不仅仅是基于事后乐观。
在 DNSSEC 中，回滚并非微不足道。在验证器更改状态后回滚根 KSK 可能会带来其自身的复杂性。然而，设定回滚阈值迫使领导者定义何种程度的损害会改变决策。没有这样的阈值，团队可能会被变更的势头所困。有了阈值，组织至少有了一个公开的标准，来判断何时稳定性比完成更 重要。
因此，启动决定属于 ICANN 领导层和董事会治理，但它建立在分布式证据之上。已更新信任锚的解析器运营商创造了就绪。实现行为正确的软件供应商创造了就绪。分析信号的根运营商创造了就绪。挑战假设的社区审核者创造了就绪。ICANN 协调并做出决策，但它并未凭一己之力使分布式系统就绪。
这就是核心的问责制地图。ICANN 拥有中央根 KSK 运营的权力，并负责外展和决策治理。解析器运营商对自己验证配置负责。供应商对实现负责。公共部门和企业网络所有者对连续性规划负责。没有任何一方掌握整个系统，因此问责制必须是明确的，而非假设的。
事件本身很平静，因为准备工作并不平静
2018 年 10 月 11 日，ICANN 执行了滚动。ICANN 于 10 月 15 日发布的事件后公告称，在对可用数据进行评估后，似乎没有大量互联网最终用户受到持续且有负面影响。公告表示，出现的少数问题迅速得到缓解，并未表明存在需要回滚的系统性故障。公告还提到，ICANN 将在 2019 年第一季度的下一次密钥仪式上撤销旧 KSK，即 KSK-2010。
后来的2018 年 DNSSEC KSK 滚动审查是最有力的事后来源。它将 KSK-2010 定义为在 2018 年滚动之前使用的信任锚，将 KSK-2017 定义为于 2018 年 10 月 11 日首次用于签署根区域的密钥。它还记录了首次生产级滚动的教训。审查报告并未使 ICANN 成为自身工作的中立观察者，但它比宣布胜利更有价值，因为它为下一次滚动创建了持久记录。
事件的平静不应被误认为是风险被夸大的证据。许多基础设施变更之所以变得平静，正是因为运营商推迟了、测试了、沟通了并监控了。一座桥梁在垮塌前发现弱点的负载测试并非虚假警报。这正是测试的意义所在。因此，2017 年的推迟是 2018 年成功的一部分，而非与之分离的瑕疵。
事后记录也限制了宣称的范围。它没有说没有人受到影响。它说的是没有大量持续性的最终用户负面影响，也没有系统性故障。这对于全球基础设施变更而言是正确的程度。一些个别运营商可能出现过局部问题。相关问题是根信任锚更改是否导致了广泛、持续的 DNS 解析故障。
旧密钥撤销步骤也很重要。滚动并不仅仅因为使用了新密钥就结束了。旧信任锚必须以确认验证器已接受新状态的方式退役。ICANN 的审查和随后的仪式材料表明，滚动是一个序列，而非单一时间点。
即使没有重新委派任何域名，DNS 委派权力也是真实的
清单标签“DNS 委派权力”通常让人联想到对根区域条目、顶级域委派、注册商关系和名称所有权的控制。KSK 滚动显示了另一种形式的委派权力：对根区域验证信任链的控制。ICANN 没有重新委派一个顶级域，也没有更改注册人的域名。它更改了验证解析器用来决定已签名的根数据是否可信的加密密钥。
这种权力受到约束。ICANN 在技术实践声明、社区审查、董事会治理、IANA 职能期望、根区域伙伴协调和全球监督下运营。但它仍然是权力。一次糟糕的中央密钥操作可能会使正确签名的数据在验证器看来无效，或迫使运营商紧急禁用验证。密钥是加密的事实并不意味着决策纯粹是技术性的。
根区域 KSK 运营商 DNSSEC 实践声明之所以相关，是因为它设定了根 KSK 运营商如何执行密钥管理的期望。实践声明是枯燥的文件，但它们是问责工具。它们定义了仪式、角色、控制和期望，使社区能够评估运营商是否按照已发布的程序行事。当 ICANN 滚动密钥时，它并非简单地行使自由裁量权；它是在行使一项记录在案的运营责任。
IANA 信任锚 XML及相关的根锚公开位置也是该权力的一部分。它们以机器可读和人类可检查的形式公开提供信任锚材料。发布本身不足以确保采用，但如果没有发布和稳定的分发，解析器运营商就无法可靠地做好准备。
当存在从决策到工件再到运营商行动的公开链条时，DNS 委派权力就变得可问责。滚动决策被记录在案。公钥被发布。预期的运营商行为被描述。遥测被讨论。董事会批准被记录。事后审查被公布。该链条并不能消除损害，但它使权力的行使变得可检查。
与私有平台中断的对比是有用的。一个私有 SaaS 提供商有时可以仅与客户沟通并很少发布信息。ICANN 没有以同样方式拥有这种选择。根 KSK 是一个公共互联网依赖项。问责渠道必须是公开的，因为依赖人群是公开的。
解析器运营商也是可问责的
仅责怪或赞扬 ICANN 的中央分析会遗漏一半系统。解析器运营商在自己的网络中使滚动变得安全或危险。如果一家 ISP 为数百万用户启用了 DNSSEC 验证，它就控制着其解析器是否更新、监控和测试。如果一家企业使用验证解析器进行内部和外部解析，它就控制着变更管理是否包含根信任锚就绪。如果一家公共机构将 DNS 外包给供应商，它就控制着供应商问题和连续性期望。
ICANN 的检查当前信任锚文件和使用最新信任锚更新验证解析器文件提供了实用步骤，但运营商必须使用它们。中央组织无法永远补偿本地的疏忽。一个已启用验证但没有对 DNSSEC 故障进行监控的解析器是一个潜在的连续性风险。一个信任锚文件被配置管理覆盖的解析器是一个潜在的连续性风险。一个错误实现 RFC 5011 的供应商设备是一个潜在的连续性风险。
公共部门维度使这一点具体化。政府机构和关键公共服务通常从共享服务、云提供商、托管安全供应商、网络集成商或电信合同中继承 DNS 选择。这些机构可能不是 DNS 专家，但它们仍然可以要求供应商提供证据：DNSSEC 验证是否启用、使用何种解析器软件、根信任锚如何更新、验证故障如何监控以及紧急变更如何获准。
运营商还控制着恢复路径。ICANN 的董事会批准公告将关闭 DNSSEC 验证、安装新密钥并重新启用验证描述为未准备运营商的最坏情况修复方案。这条紧急路径并不理想，因为禁用验证会移除一项安全控制，即使是暂时的。但这比让用户无法解析名称要好。问责问题是运营商是否在更改之前已将这条路径文档化，而非他们是否在危机中发现它。
这就是为什么滚动属于风险与问责系列，而不仅仅是 DNSSEC 历史。该事件测试了分布式运营商是否能将其本地实践与中央安全更改对齐。一项全球安全控制的弹性，仅与依赖它维持连续性的、准备最不充分的组织相当。
遥测产生了解读责任，而非确定性
RFC 8145 信任锚信号是故事中最有趣的部分之一，因为它同时创造了可见性和不确定性。信号可以指示解析器相信自己配置了哪些信任锚。但根服务器看到的是 DNS 流量，而非组织意图。一个可见的源地址可能代表许多用户或一个实验室。某些信号可能已过时。某些解析器可能不发信号。某些网络可能经过多层转发，掩盖了实际的验证解析器。
2017 年的推迟表明，ICANN 将遥测视为与决策相关的，即使它并不完美。这是良好的治理，但它也产生了解释解读的责任。如果遥测暗示风险，领导者必须决定风险是否足够真实以推迟。如果之后的遥测仍显示某些过时信号，领导者必须决定这些信号是代表重大的用户影响还是可管理的残余噪声。
滚动审查和技术更新显示了这种分析负担。ICANN 滚动资源页面将技术更新、审查材料和运营商指导集中在一处。2017 年 12 月 18 日关于根 KSK 滚动项目的更新记录了推迟后的分析状态。此类文件的要点不在于产生完美的信心。而在于防止决策变为由谣言驱动。
遥测问责有两个方面。ICANN 和根运营商需要避免过度宣称信号的意义。解析器运营商需要避免忽略它。如果一个网络的解析器在发出旧信任锚信号，那么运营商不能合理地期望中央社区在没有合作的情况下识别并修复本地配置。相反，在不说明为什么观察到的过期信号并不意味着不可接受的全球故障的情况下，ICANN 不能合理地推进。
这种平衡在 DNS 之外日益重要。现代基础设施变更通常涉及来自分布式客户端、代理、解析器、证书、包管理器或端点的嘈杂遥测。KSK 滚动的教训是，不完美的证据既不应导致瘫痪，也不应被忽视。它应该引发透明的解读和可问责的决策标准。
ICANN 控制了什么，没控制什么
ICANN 通过其 IANA 职能和 Public Technical Identifiers 角色控制了中央 KSK 流程，包括密钥仪式、发布、规划文件、社区磋商、外展、技术指导、董事会升级、启动/不启动建议、监控和事后审查。ICANN 没有控制每一个验证解析器、每一个软件包、每一个 ISP 变更窗口、每一个企业配置或每一个公共部门 DNS 合同。
Verisign 控制了根区域维护者职能，并运营与观察和协调相关的根服务器基础设施。它没有控制每个网络内部的本地验证器状态。解析器软件项目控制着 RFC 5011 行为和 DNSSEC 验证的实现质量。设备供应商和操作系统发行版控制着打包和默认行为。网络运营商控制着部署。公共机构和企业控制着采购、监控和应急计划。
最终用户几乎不控制任何这些。一位 ISP 解析器验证失败的市民不会知道原因是信任锚过时、DNSSEC 故障、路由问题、应用程序问题还是网站中断。一家使用托管路由器的小企业不会知道其 DNS 设备是否已接受 KSK-2017。这种不对称正是问责制必须落在基础设施运营商而非用户身上的原因。
因此，问责问题不是“谁拥有互联网？”没有人拥有。问题是谁控制了滚动的每个关键部分。ICANN 控制了中央权力和公共协调。运营商控制了就绪。供应商控制了代码。公共机构控制了连续性期望。每方都有不同的职责。
这种分层的图谱也防止了浅薄的成功叙事。ICANN 在推迟后根据证据推进，做得很好。但未来的滚动不应每次依赖英勇的外展。解析器运营商应将信任锚清查制度化。供应商应使验证状态可见。公共机构应要求提供商提供 DNSSEC 连续性证据。根区域治理应继续发布计划和审查。成功应成为可重复的实践，而非一次性的记忆。
下一次滚动应继承证据，而非运气
ICANN 当前的根区域 KSK 算法滚动页面表明，根区域加密维护仍在继续。未来的算法滚动与 2018 年的密钥滚动不同，因为它更改的是加密算法，而不仅仅是用另一个 RSA 密钥替换一个 RSA 密钥。这项未来工作使得 2018 年的问责记录更有价值，而非更少。首次滚动为公开规划、外展、遥测、董事会批准、运营商指导和事后审查创建了模板。
该模板应得到改进。首先，遥测应让运营商更容易与自己的基础设施联系起来。如果运营商无法判断哪个设备产生了信号，中央信号的价值就会降低。其次，解析器软件应以普通网络团队可监控的方式暴露信任锚状态。第三，公共部门和企业采购应将递归 DNS 视为连续性基础设施。第四，紧急禁用验证应作为最后手段进行演练，并在之后恢复，而不是将其标准化为长期变通方案。第五，ICANN 应继续提前发布决策标准，以便未来的推迟或启动决定可以根据已知标准进行评估。
2018 年的滚动还展示了有限信心的价值。ICANN 在承认一些运营商不会准备好的情况下推进。这是诚实的。关键基础设施不能等待每个参与者都完美遵守。但诚实的残余风险应与恢复证据相伴：谁在监控、问题将如何被检测、什么阈值会触发回滚、运营商如何获得帮助，以及事后教训如何发布。
同样的标准应适用于公共部门网络。各机构应知道谁提供递归 DNS、是否启用验证、根信任锚是否自动更新、是否存在 DNSSEC 故障警报，以及在根区域加密变更期间如何联系提供商。如果一个公共机构无法回答这些问题，它就已委派了连续性，却没有保留问责制。
持久的教训
ICANN 2016-2018 年的根 KSK 滚动记录是运营问责制的一个有力例子，因为它包含了令人不安的中间过程：计划、警告信号、推迟、公开评论、修订计划、董事会批准、执行、监控和审查。故事并非“ICANN 更改了一个密钥，然后什么都没发生”。故事是，ICANN 和 DNS 社区将密钥更改视为一种全球运营风险，并使风险足够可见以进行管理。
根据 ICANN 公开的事后声明，滚动在没有重大持续性最终用户影响的情况下取得了成功。这一成功应同样归功于分布式准备以及中央协调。ICANN 控制了根 KSK 流程和决策。Verisign 和其他根运营商贡献了运营观察。解析器供应商和运营商使验证在现场发挥作用。公共和私人网络所有者对自身的连续性负责。
问责教训是持久的。中央信任锚是一个公开承诺，而非一个私有配置项。当它发生更改时，拥有中央权力的组织必须发布计划，倾听遥测，在证据确凿时推迟，定义故障阈值，传达实用的运营商步骤，并审查结果。依赖信任锚的运营商必须了解自己的系统，测试就绪，监控故障，并准备恢复。
首次 DNSSEC 根 KSK 滚动并未证明未来的根加密更改是无风险的。它证明了，当权力与证据相结合，并且技术信心保持足够谦逊以停止日程表时，共享基础设施变更可以负责任地进行。这就是下一次滚动应达到的问责标准。