轮换Root KSK：更换DNS的信任根
9月16日，ICANN理事会通过了一项决议，指示ICANN组织按计划继续轮换Root KSK，定于2018年10月11日16:00 UTC更换Root KSK。
2018年10月11日，根密钥签名密钥（Root KSK）即将更换――这是历史上第一次，这是用于验证所有DNSSEC响应的单一信任根。还没有了解并开始使用新密钥的验证解析系统将把所有响应视作无效，因而导致它们停止回答所有查询，从而让用户无法正常访问互联网。
你准备好了吗？
引言/DNSSEC是什么？
域名系统安全扩展（DNSSEC）于1997年推出，首次描述DNSSEC的RFC2065同年发布。DNSSEC为域名系统（DNS）的使用者使用公钥加密来验证响应提供了一种方法。在1997年到2010年7月1日，DNSSEC被一些DNS授权运营商所使用。然而，当时没有一个信任锚（trust anchor），这是可用来验证响应的权威实体。2010年7月1日，互联网名称与数字地址分配机构（ICANN）、Verisign以及国家电信和信息管理局（NTIA）完成了对DNS根区域进行签名的过程。这样一来，单个信任根就可以用来验证所有DNSSEC响应，假设DNS链上的每个区域都已签名。
自2010年7月以来，DNSSEC信任根（又叫根密钥签名密钥，Root KSK）没有变过。 DNSSEC验证中其他地方使用的许多密钥已经轮换――类似网站的TLS证书，这对于任何公钥系统来说很常见。在引入目前使用的密钥KSK-2010的前后，负责维护DNS根区域的组织：互联网号码分配机构（IANA）编制了《根区域KSK运营商DNSSEC实践声明》文档。该文档概述了根区域的DNSSEC操作，呼吁5年后轮换Root KSK。与之相仿，在2013年，ICANN的安全性和稳定性咨询委员会发布了一份公告，呼吁轮换Root KSK。轮换Root KSK的过程应该在2015年开始，但直到2016年10月才开始。促使KSK-2017创建的Root KSK生成过程开启了Root KSK的轮换，原计划在2017年10月完成。
有一种自动方法可以验证解析系统以了解和安装新的Root KSK（RFC5011）。然而，验证解析系统不仅需要支持更新方法，还需要能够观察密钥至少30天，并将该密钥存储在永久存储设备中。在某些情况下，解析系统无法写入到永久存储设备，也无法保留新密钥。如上所述，不使用新密钥的验证递归解析系统将停止回答查询，从而让用户无法正常访问互联网。由于无法可靠地衡量有多少解析系统没有安装新密钥，因此ICANN理事会作出了决定：推迟部署，以便做好更多的研究和通知工作。延期一年；现在我们离2018年10月11日这个重大日子越来越近了。
诸有关方已认真考虑了轮换Root KSK的计划，包括ICANN下面的首席技术官办公室以及安全性和稳定性咨询委员会（通过ICANN托管的KSK Roll邮件列表）。意见不一，有的强烈支持今年轮换密钥，有的强烈反对。争论双方都发现需要更多的数据、外联和方法，帮助减小对最终用户造成的影响。 ICANN理事会正在考虑他们在下一次理事会会议（到时做出要不要搞的决定）之前征集的意见，会在下周的某个时间告知社区。决定公布后，我们会更新此文。
会发生什么？
如果Root KSK轮换按计划进行，信任锚Root KSK将从2018年10月11日开始由KSK-2010换成KSK-2017。这将导致响应由根DNS域名服务器来处理，返回现在与新的Root KSK联系起来的响应。由于根域名服务器的响应中设置了48小时的生存时间（TTL），因此一些最终用户可能会在10月11日到10月13日的某个时间段受到影响。受影响的时间主要取决于解析系统上的缓存到期失效的速度多快。受影响的最终用户可能一开始会遇到主机未找到错误或表明DNS解析无法正常工作的其他征兆；随着更多缓存条目到期失效，故障似乎会扩散到其他域。对于遇到故障的用户来说，使用ping之类的工具、找到IP地址而不是域名有助于排除常规的连接问题。对于管理员来说，访问资源时使用IP地址可以用作某些应用的权宜之计，直到解析故障被解决。
ICANN的首席技术官办公室及其他机构估计，由于此次轮换，Root KSK轮换将给互联用户带来不到1%的拒绝服务（DoS）。这些报告承认，由于根本上无法衡量DNS的某些方面，存在一定程度的不确定性。过去两年已作出了努力以改进衡量，但新数据不如我们预期的那样具有结论性。
我如何准备Root KSK轮换？
如果你是最终用户，就得依赖DNS服务提供商（通常是你的ISP），或公共开放解析系统服务，比如Google DNS（8.8.8.8）、Open DNS（208.67.222.222和208.67.220.220）或Quad 9（9.9.9.9），以便正确处理密钥轮换。如果用户使用Akamai的ETP、AnswerX托管平台以及最新版本的AnswerX（v2017.1或更高版本）或启用DNSSEC验证功能的Nominum产品，会发现新的Root KSK信任锚已配置好，轮换发生时，解析应该会继续顺利进行。
想测试自己会不会受Root KSK轮换的影响，第一步可以尝试访问http://dnssec-failed.org。如果你能够解析并加载网页，表明你用于测试的那台计算机未配置验证解析系统，Root KSK轮换应该对该系统没有影响。请注意，这仅验证访问URL的设备是不是在使用DNSSEC验证，物联网设备等其他设备可能使用不同的递归解析系统，没有简单的方法来测试。
对于使用验证的解析系统的用户来说，有一个IETF草案，通常名为KSK Sentinel，它定义了一组特别设计的查询，最终用户可以用这些查询来检查解析系统是否为Root KSK轮换做好了准备。已设立了网站https://www.ksk-test.net，帮助最终用户测试解析系统是否验证DNSSEC、是否支持KSK Sentinel，以及是否已配置好了新的信任锚。KSK Sentinel比较新，仅部署到了少数递归解析系统。使用这个方法好不好，就看运气了，但到目前为止，除了联系你的递归解析系统运营商外，它是唯一可用来测试递归解析系统是否为Root KSK轮换做好准备的方法了。
如果你是递归解析系统运营商，ICANN提供的网页可帮助你逐步检查及/或更新大量解析系统平台上的信任锚。运营商可能还应该考虑检查自己的平台是否支持RFC5011，这种协议可自动更新和配置新的信任猫。如果这次Root KSK轮换按计划进行，RFC5011更新将无济于事，因为该协议需要30天才能完成，因此2018年9月10日是可以启用该功能的最后一天。
此外，网络运营商应检查电子邮件，看看有没有主题行是“关于ASXXXXX中未准备好的DNSSSEC验证解析系统的重要DNS信息”的邮件，其中XXXXX换成你的自治系统（AS）编号。这类电子邮件让运营商对于出现在根域名服务器的日志中的解析系统有一番了解，这些服务器对于是否支持新的Root KSK并不确定。一些根域名服务器处理的请求常常与可能没有为Root KSK轮换做好准备的验证解析系统关联起来，这些服务器已看到出现在这些报告中的IP地址。收到这些报告的管理员应利用ICANN提供的程序来检查及/或更新解析系统。由于客户端可能通过非验证递归解析系统发出同样的查询，因此可能会出现误报。
面对Root KSK轮换，权威域名服务器的运营商受客户端使用的递归解析系统的支配，这意味着无法通过修改权威服务来纠正解析故障。
