摘要

  • 根区第一把 DNSSEC 密钥签名密钥并非在签名根区上线时才生成。6 月 16 日，Culpeper 的第一场仪式生成 KSK-2010；7 月 12 日，El Segundo 的第二场仪式将密钥纳入西部设施，并完成另一组操作步骤。
  • IANA 将首个生产签名根区的日期定为 2010 年 7 月 15 日。脚本、分工、外部代表、摄像、哈希和日志让部分密钥保管过程可供核查，但不能证明全球解析器都已进行 DNSSEC 验证。

三个日期代表三种动作

2010 年 7 月 15 日，IANA 宣布根区已完成签名。公告描述的是根区发布数据的变化，并没有声称世界各地的递归解析器都开启了验证。仪式也无法替独立运营者作出这个决定。

IANA 的档案把这个节点与此前两场仪式分开记录。第一场于 6 月 16 日在弗吉尼亚州 Culpeper 的东部密钥管理设施举行；第二场于 7 月 12 日在加利福尼亚州 El Segundo 的西部设施举行；随后，7 月 15 日首个签名根区进入生产。受控生成和使用密钥、让另一处设施具备运行能力，以及启动生产签名链条，是不同的工作。

第一场仪式于 6 月 16 日 17:00 UTC 开始，并跨过午夜。ICANN 当时的一份演示材料记录其于 6 月 17 日 00:25 UTC 结束。后来材料把密钥生成日期写为 6 月 17 日，指的是同一场会议的 UTC 收尾时间，不一定是另一场活动。

Culpeper：生成密钥，也留下可检查的证据

第一场仪式公布的目标很具体：启用东部密钥管理设施、生成 KSK-2010，并为 2010 年第三季度签署区签名密钥（ZSK）。根区 KSK 签署根区 DNSKEY 密钥集；根区维护方另用 ZSK 签署根区记录。DNSSEC 把各层签名连接起来，但不代表 KSK 直接签署每一条 DNS 记录。

IANA 留存了操作脚本、SHA-256 清单、ISO 镜像、三段摄像录像，以及名为 kskgen-20100616-211906.log 的密钥生成日志。外部读者可以把公开步骤与这些文件相互核对。档案无法让远程读者成为每个现场动作的独立目击者，也不能单独证明镜头之外从未发生其他事情。它的价值更具体：为操作留下可复核的文档轨迹。

人员分工同样是控制措施的一部分。ICANN 6 月 7 日的公告称，有 14 名 Trusted Community Representatives 参与，他们不受雇于 ICANN、VeriSign 或美国商务部，各自承担不同的密钥管理职责。ICANN38 的同期演示后来按现场角色统计了 16 名代表，包括 Crypto Officers、Recovery Key Share Holders 和候补人员。一个数字描述项目公布的志愿代表，另一个描述现场角色配置，不能混成一个确切总人数。现场还包括机构员工、审计人员、VeriSign 代表和摄像人员。

El Segundo：让第二处设施进入运行链条

第二场仪式于 7 月 12 日在 El Segundo 西部设施举行。IANA 记录的开始时间为 20:00 UTC，目标包括启用该设施、导入 KSK-2010，并签署 2010 年第四季度的 ZSK。档案中有脚本、校验和、录像，以及 ksrsigner-20100712-224426.log 日志。

IANA 的启动进展说明，密钥材料被送到西部，密钥在该处导入或复制，第四季度的签名过程也继续推进；VeriSign 接受了签名响应。由此可见，第二个房间进入了实际操作链，而非仅有象征意义。材料并不支持“密钥整个生命周期始终只有一份副本”的说法；公开记录描述的是由多处设施组成、受控管理的安排。

两地设置服务于持续运行，也带来新的控制难题：必须确认复制的是什么、谁能授权使用，以及一处设施失效后怎样恢复。副本和参与者增加，管理责任也随之增加。角色分离、预演、安全设备、日志和审计意在让单人擅自操作更困难，并让正常流程可以重复执行。

根区签名不等于全球部署

7 月 15 日公告之后，根区变更曾短暂停止至 7 月 20 日，以便观察影响、处理问题。这段时间说明，生成签名和安全运行签名是两件事。签名数据还要经过发布与分发；解析器运营者仍需自行决定是否验证答案。

美国国家电信和信息管理局（NTIA）5 月 28 日的报告描述了当时的分工：IANA/ICANN 管理 KSK，VeriSign 用 ZSK 签署并分发完整根区，NTIA 则依照当时的安排批准根区变更。这份上线前报告还说，部分授权测试在 5 月底尚未完成。因此，它能证明当时计划怎样分工、哪些工作仍在推进，不能证明所有检查在那时已通过。7 月的后续进展记录了上线完成。

摄像、哈希、独立代表和审计材料，让不可避免地需要保密的密钥操作留下公共可查的边界。它们支持外界比较预定流程和实际留下的记录，却不能解决根区治理的所有政治问题，也不能证明全球采用。没有开启验证的解析器，不会因为密钥仪式执行严谨就自动获得 DNSSEC 的保护。

因此，历史结论应保持在证据支持的尺度上。仪式没有以公告命令互联网信任某个机构；它是在有记录的程序中生成密钥，第二处设施加入保管和签名链，随后生产系统发布签名根区。用 Heng Lu 的思路看，协调程序要接受运行结果检验：根区维护方接受了签名响应，根区随后得以分发。公开记录对这一结论的支持，强于对“全球已采用”的任何推断。

2016—2018 年的轮换与之后的 KSK 替换，讨论的是如何换掉已经部署的密钥，并验证解析器跟上了变化。2010 年的问题更靠前：怎样生成、保存、转运并使用第一把根密钥，同时留下足够证据供他人检查？

资料来源

补充的后续背景，不作为 2010 年事件的证据