摘要
- ICANN 于 2018 年 10 月的 DNSSEC 根区密钥签名密钥（KSK）轮换，更换了 DNSSEC 验证解析器用来验证 DNS 根区的公共信任锚点。ICANN 的轮换页面指出，未配置当前根信任锚点的解析器在轮换后将无法解析 DNS 查询，这使得准备就绪成为一项业务连续性问题，而非仅仅是狭隘的加密维护任务。
- 最有力的问责事实在于推迟。ICANN 在获得新的 RFC 8145 遥测数据后，推迟了原定于 2017 年 10 月的轮换，因为数据表明众多 ISP 和网络运营商使用的解析器可能尚未准备就绪。这一决定将一个隐藏的运营商准备不足问题，转化为一个公开的治理记录。
- ICANN 随后在获得董事会批准、公开征求意见、持续外联、技术分析以及修订计划后，于 2018 年 10 月 11 日实施了轮换。事后 ICANN 宣布，所观察到的少量问题已迅速缓解，并未表明存在需要回滚的系统性故障。
- 实际的控制是分布式的。ICANN 和公共技术标识符（PTI）掌控着根 KSK 仪式流程、公开、文档、外联以及最终推行决策；Verisign 承担根区维护者角色；解析器运营商控制信任锚配置和软件行为；供应商控制 RFC 5011 的实现质量；公共机构和企业则控制自家网络的应急规划。
- 问责方面的教训是，全球互联网基础设施的变更，需要可观测的准备就绪状态、公开的决策标准、社区评审、安全的回滚思路，以及在遥测数据动摇信心时足够谦逊地推迟。此次轮换之所以成功，是因为它被当作公开的运营风险来处理，而非风险纯属想象。
根密钥虽小，依赖却是全球性的
如果将 DNSSEC 根密钥签名密钥（KSK）的轮换简化为更换一个加密密钥，这听起来像是一件微不足道的事件。但从运营角度看，它是一次全球依赖关系测试。DNS 根区位于公共域名系统委托层级的顶端。DNSSEC 验证解析器使用信任锚点来验证已签名的 DNS 数据。如果在根 KSK 更换后，验证解析器中的根信任锚点过时，解析器就可能会将有效的应答视为伪造，导致用户的常规名称解析失败。
ICANN 专门的根区 KSK 轮换页面是主要的信息来源。该页面说明，ICANN 于 2018 年 10 月 11 日执行了这次轮换，轮换 KSK 意味着生成一对新的公钥和私钥，并将公钥部分分发给验证解析器的运营商，而且维持最新的 KSK 至关重要，因为未能持有当前根区 KSK 会导致 DNSSEC 验证解析器无法解析 DNS 查询。这就是整个问责问题的通俗表述。当一个中心化的信任对象发生变更时，若分布式的运营商未更新本地的验证状态，就会导致用户服务中断。
KSK 并非孤立存在。ICANN 的轮换页面描述初始计划是由根区管理伙伴们共同制定的：ICANN 作为 IANA 职能运营商，Verisign 作为根区维护者，以及美国商务部的 NTIA 在 2016 年 10 月 1 日其角色结束前担任根区管理员。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 和网络运营商使用的解析器尚未准备就绪。ICANN 将这种新的可见性归因于一项最近的 DNS 协议特性，该特性允许解析器向根服务器报告它们配置了哪些密钥。
该特性就是RFC 8145，它定义了一种让验证解析器能够发出已配置信任锚信号的方式。该协议并没有给 ICANN 带来完美的认知。它构建的是一幅嘈杂的、片面的、且对运营敏感的准备就绪图景。一些信号可能来自配置错误的系统、测试环境、转发器、过时软件、陈旧配置，或者并非为大量用户提供服务的解析器。但即便是不完美的遥测信号，仍构成了一次治理事件。ICANN 必须决定，是尽管有信号表明部分解析器状态过旧仍按原计划推进，还是推迟行动，让社区解读数据并加强外联。
ICANN 选择了推迟。这一决定事后看来很容易获得赞誉，因为后来的轮换成功了。但在当时，它有其自身的代价。推迟可能削弱对计划的信心，延长双密钥发布的时期，推迟 ICANN 的《DNSSEC 实践声明》所要求的运营演练，并向已为 2017 年日期做好准备的运营商发出不确定信号。然而，若当时推进，则可能让解析器运营商及其用户仅在域名无法解析时才发现就绪问题。
这次推迟公告对于基础设施治理而言，出奇地坦率。公告称，运营商未安装新密钥的原因可能有多种，包括解析器软件未正确配置，以及最近在一款广泛使用的解析器程序中发现的一个问题，该程序似乎未能如预期那样自动更新密钥。公告还称，ICANN 正在与社区进行接触，包括 SSAC、区域互联网注册管理机构、网络运营商组织等。公告引述了 ICANN 首席执行官的话，表示在发现可能对成功和最终用户连接产生不利影响的新问题后，继续推进将是不负责任的。
这种表述创造了一个公开的标准。ICANN 并非承诺每一个验证解析器都能正常工作。它承诺的是，新发现的就绪证据将改变决策。在基础设施运营中，这正是按日历驱动的变更与按证据驱动的变更之间的区别。
推迟也保留了解析器运营商的问责。ICANN 无法登录每一台递归解析器并安装信任锚。ISP、企业、政府网络和 DNS 服务的运营商控制着他们自己的解析器软件和配置。通过推迟，ICANN 将就绪问题公之于众，并给予这些运营商更多时间。这并非将所有责任转移给他们，而是使得这种共享控制模型变得可见。
RFC 5011 自动化是有用的，但不是魔法
此次轮换在很大程度上依赖于信任锚的自动更新行为。RFC 5011定义了 DNSSEC 信任锚的自动更新。RFC 5011 的吸引力显而易见：验证解析器可以在添加保持期（add-hold-down period）内观察新密钥，并自动将其接受为信任锚。若没有这样的机制，每一位验证解析器运营商都必须在互联网规模上手动安装密钥。
然而，自动化本身从来都不是问责。它是代码和配置在现实世界各种变化下所作出的承诺。解析器必须正确实现算法，持久保存状态，拥有与保持期过程兼容的时钟和运行时间模式，接收并验证相关的 DNSKEY 材料，并避免那些会破坏自动更新的本地配置选择。运营商还必须了解自己的解析器是否确实在验证，它是否转发到另一台解析器，其软件包版本的行为是否正确，以及配置管理系统是否会覆盖信任锚状态。
Verisign 的KSK 轮换页面从根区维护者和根服务器运营者的视角捕捉了这一区别。该页面称，每个 DNSSEC 验证器都需要一个信任锚，且 RFC 5011 在根 KSK 轮换方面从未在生产环境中得到过测试。它还指出，Verisign 作为根域名服务器运营商，接收了一些 RFC 8145 数据，并对其进行分析，以识别配置有旧版信任锚的来源。这一点很重要，因为它表明遥测数据并非只在 ICANN 的中心仪表盘上可见。根服务器运营商同样能够看到就绪信号并采取行动。
自动化使轮换成为可能，但公共问责制需要独立的证据来证明自动化确实有效。这些证据包括信任锚信号、解析器软件测试、针对那些表现出旧态运营商的外联、公开征求的意见、邮件列表讨论以及事后监控。其中还包括愿意定义一个回滚阈值——以备故障范围足够大时所用。
根区 KSK 轮换设计团队的最终报告提供了一个有用的背景，因为它为 2017 年推迟之前的第一次根 KSK 轮换制定了一个设计流程。它之所以建议精心分阶段、沟通和测量，恰恰是因为互联网此前从未经历过一次运营中的根信任锚轮换。后来的推迟并不证明设计团队失败了，恰恰证明了其设计假设是正确的：首次轮换需要观察和分阶段的决策。
教训不在于 RFC 5011 不可靠。教训在于，当分布式自动更新机制保护的是共享基础设施时，它们需要遥测和社会层面的协调。一项标准可以定义一个状态机，但它无法让每个运营商都明白，这台状态机是否在他们的网络中正确运行。
公开征求意见让技术变更成为治理记录
推迟之后，ICANN 并没有简单地私下选定一个新日期。其《重启根密钥签名密钥（KSK）轮换流程计划》的公开征求意见页面将修订后的计划提交给社区审查。该征求意见页面称，修订后的计划包括更多的就绪状态宣传、更多的就绪数据分析，以及于 2018 年 10 月 11 日实际进行轮换。相关的《继续根 KSK 轮换计划》PDF描述了在先前推迟之后拟议的重启方案。
这一步很重要，因为技术合法性和机构合法性是不同的问题。ICANN 可能在技术上有能力更换密钥，但如果忽视社区关于就绪状态的证据，它在政治上仍可能是不负责任的。反过来，社区本可以要求无限期推迟，但无限期推迟也会造成运营负债。公开征求意见将分歧强行纳入记录：应该信任哪些数据，外联做到什么程度才算足够，应该使用怎样的故障阈值，以及谁来做出最终决定。
关于计划草案意见的员工报告正是这一转化步骤的证据。它并没有消除所有风险。它表明，ICANN 在将计划提交给董事会之前，收集并回应了意见。基础设施的问责，往往不在于达成普遍共识，而在于在权威机构行动之前，让证据和反对意见都公开可见。
ICANN 的董事会批准公告称，董事会已批准首次更换保护 DNS 根区的加密密钥的计划，指示该组织于 2018 年 10 月 11 日推进。公告承认，无法完全确保每家网络运营商都已正确配置解析器，但表示 ICANN 预期绝大多数网络都能访问根区。公告还指出，对于运营商而言，最糟糕情况下的补救措施是关闭 DNSSEC 验证，安装新密钥，然后重新开启验证。
作为基础的ICANN 董事会 2018 年 9 月 16 日的决议则是正式的治理产物。它们之所以重要，是因为“推行”决定不仅仅是技术人员的行动，更是一家以 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-2010。
后来的《2018 年 DNSSEC KSK 轮换回顾》是最有力的事后资源。它将 KSK-2010 定义为 2018 年轮换前一直使用的信任锚，将 KSK-2017 定义为 2018 年 10 月 11 日首次用于签名根区的密钥，还记录了首次生产环境轮换的经验教训。一份回顾报告并不会让 ICANN 成为自身工作的中立观察者，但比一份胜利公告更有价值，因为它为下一次轮换创建了持久的记录。
这次事件的平静，不应被误认为是风险被夸大的证明。许多基础设施变更之所以变得平静，恰恰是因为运营商进行了推迟、测试、沟通和监控。一座桥梁的负载测试在坍塌前发现了弱点，这并非假警报，正是测试的意义所在。因此，2017 年的推迟是 2018 年成功的一部分，而非与之割裂的污点。
事后记录还限制了声明的范围。它没有说没有人受到影响，而是说没有出现大量持续性的负面终端用户影响，也没有发生系统性故障。对于一次全球性的基础设施变更来说，这是正确的表述水平。个别运营商可能遇到了局部问题。但相关的问题是，根信任锚的变更是否导致了广泛、持续的 DNS 解析故障。
旧密钥撤销步骤也很重要。仅因为新密钥投入使用，轮换并不算完成。必须以某种方式使旧的信任锚退役，以确认验证器已接受新状态。ICANN 的回顾和随后的仪式材料表明，轮换是一个序列，而非单一的时间点。
即便没有域名被重新授权，DNS 授权权力也是真实存在的
“DNS 授权权力”这个标签，通常令人联想到对根区条目、顶级域（TLD）授权、注册商关系和域名所有权的控制。而此次 KSK 轮换则展示了另一种形式的授权权力：对根区验证信任链的控制。ICANN 既没有重新授权一个 TLD，也没有更改某个注册人的域名，它更改的是验证解析器用来判断已签名根区数据是否可信的那把加密密钥。
这种权力是受到约束的。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 职能和公共技术标识符（PTI）的角色，控制了中心化的 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 轮换并没有证明未来的根加密变更没有风险，但它证明了，当权威与证据相结合，并且技术上的信心足够谦逊从而能停下日历脚步时，共享基础设施的变更是可以负责任地进行的。这就是下一次轮演必须达到的问责标准。