Niko Soikkeli/Unsplash摄影自2010年以来，DNS树的根一直使用DNSSEC来保护区域内容。DNSSEC只是一种机制，用于在可以验证的DNS记录旁边提供加密签名，即证明答案是正确的并且没有被篡改。要了解DNSSEC为什么如此重要，您可以阅读我们之前的博客文章。今天，根区域是用2048位的RSA"Trust Anchor"密钥签名的。此密钥用于对其他密钥进行签名，并用于建立当前存在于公共DNS中的信任链。通过访问这个根信任锚定点，可以重新签署DNS树并篡改任何域上的DNS记录的内容，实现路径上的DNS攻击…而不会导致递归器和解析程序认为数据无效。正如在这个博客中所解释的，钥匙被眼睛扫描器和指纹识别器保护得很好，还有喷火龙在门口巡逻（好吧，也许不是龙）。但是在操作上，根区域使用两个不同的密钥，即所提到的信任锚定密钥（简称为密钥签名密钥或KSK）和区域签名密钥（ZSK）。ZSK（区域签名密钥）用于为区域中的所有资源记录（rr）生成签名。您可以查询"的DNSSEC签名（RRSIG记录）"www.cloudflare.com网站"使用你友好的挖掘命令。$挖网站+dnssec公司；；问题部分：;。在一个；；答案部分：。A 198.41.215.162中的4。A 198.41.214.162中的4。4英寸RRSIG A 13 3 5 20180207170906 20180205150906 35273cloudflare.com网站. 4W4mJXJRnd/WHNDYNO5明VZY6HVNSXINTUI+pO6fzhnkpsEp1ko8K7 1PQ6r0s9SwLgrgfneqXyPs4b5X0YDw==这里显示的两个A记录可以使用区域中的RRSIG和ZSK进行加密验证。ZSK本身可以使用KSK进行验证，依此类推……这将沿着"信任链"继续向上，直到找到根KSK。这个工具可用于帮助可视化如何对internet上的任何域执行此验证，例如，以下是"的信任链"www.cloudflare.com网站".验证RRSIG是否开启"www.cloudflare.com网站"我们需要以相反的顺序对图表上的签名进行加密验证。第一个"cloudflare.com网站，然后是"com"，最后是"."-根区域。如果您能够访问用于对根进行签名的密钥，那么就有可能欺骗解析器验证"伪造"的答案。虽然这个DNSSEC签名已经部署在根区域上，但是有一个操作从未尝试过：滚动密钥签名密钥。这意味着生成一个新的密钥，并更新互联网上需要它的DNS基础设施的每个部分，将旧密钥完全作废。自2010年以来，ZSK（区域签名密钥）每季度都会被严格地滚动，但是滚动密钥签名密钥是一个更可怕的操作。如果出现错误，它可能会使根区域签名无效，这意味着大部分internet将不信任任何内容，从而有效地使DNS脱机以验证解析程序。DNSSEC设计完成后，设计了一种机制，用于在RFC5011中推出新的密钥签名密钥，此操作通常称为5011翻滚。什么是密钥翻转？所有加密密钥都有一个可用状态表示的生命周期：Generated==创建了密钥，但只有"所有者"知道它的属性。Published==密钥已作为公钥或其哈希公开。Active==密钥正在使用中Retired==已退出服务，但仍在发布Revoked==密钥已被标记为不再受信任。删除==从出版物中删除根据使用情况，不同的密钥以不同的方式在状态中移动，例如，某些密钥从不被吊销，只要删除它们就足够了，例如根ZSK的永远不会被吊销。当滚动时，根KSK将通过所有状态。为什么根KSK不同？对于DNS中使用的大多数密钥，信任是由父区域和子区域之间的关系派生的。父级发布一个特殊的记录，即DS（委托签名者），它包含与实际密钥（散列）的加密强绑定。子级在其区域的顶部有一个DNSKEY RRset，它至少有一个键与父级中的一个DS记录匹配。要完成信任链，DNSKEY RRset必须由该密钥签名。根区域没有父区域，因此无法以相同的方式派生信任。相反，必须使用根信任锚点配置验证解析器。此锚点必须在密钥滚动期间刷新，否则在旧的KSK（从2010年起）退出服务后，验证解析程序将不信任它在根区域中看到的任何内容。信任锚可以通过多种方式进行更新，例如手动更新、软件更新或带内更新。首选的更新机制是前面提到的带内更新机制RFC5011 roll。RFC 5011中概述的过程依赖于两个因素，第一，新密钥发布在DNSKEY RRset中，由旧KSK签署，并至少保留30天。验证遵循该过程的解析器将经常检查DNSKEY集中是否有新的KSK。新密钥是可信的，因为它是用已在服务中的密钥签名的。当有一个新的密钥时，它被置于PendingAddition状态，如果在任何一点上从DNSKEY集中删除了其中一个密钥，解析程序就会忘记它。这意味着，如果钥匙再次出现，它将开始新的30天的压制期。当密钥连续30天处于挂起状态后，它将被接受为活动状态，并将被信任为根签名DNSKEY集。从这一点开始，可以使用新密钥对区域签名密钥进行签名，然后再对根区域内容本身进行签名。为什么我们要滚动根密钥信任锚？主要有两个原因；社区希望确保RFC5011机制在实践中起作用。知道了这一点，将来的展期交割成为可能，风险也降低了。定期的滚动是为了保持良好的密钥卫生，比如定期更改密码允许考虑切换到不同的算法。具有大密钥大小的RSA是一种强大的算法，但是使用它会导致DNS数据包更大。还有其他一些算法，比如Cloudflare使用的基于椭圆曲线的算法，密钥更小，但每比特的安全性更高。切换到一个新的算法需要一个新的密钥。有些人主张同时滚动密钥和更改算法，但这被认为太冒险了。现在开始讨论这个问题的正确时机是在当前的滚动成功结束之后。到目前为止发生了什么？ICANN去年开始了展期过程。新的密钥已经创建并复制到ICANN运行的两个设施中的所有HSM（硬件安全模块）。从现在起，我们将使用术语KSK2010（旧密钥）和KSK2017（新密钥）。在开始滚动过程之前，对RFC5011实现进行了测试，大多数实现都报告了成功。新密钥于2017年7月11日在DNS中发布，因此DNSKEY集合现在包含两个KSK。此时，新密钥/KSK2017已进入发布状态。计划于2017年10月11日启用。任何在7月11日至10月11日窗口期间运行了至少30天的验证解析器都应该在10月11日之前将新的信任锚定置于"活动"状态。但有时事情并没有按计划进行。在滚动更新之前所做的一件事是解析器向权威服务器发出信号的一种方式，即解析程序信任的信任锚定RFC8145。RFC8145在2017年4月才发布，因此在KSK2017密钥发布阶段，默认情况下只有最新版本的Bind-9支持它。该机制由解析器定期向根节点发送一个查询，查询名称的格式类似于"ta-4a5c"或"_ta-4a5c-4f66"。该名称包含信任锚标识符的十六进制编码版本，分别为19036和20326。这至少允许根操作员估计已经实现RFC8145并知道每个信任锚的解析程序的百分比。9月29日，ICANN根据提交报告的解决者提供的证据推迟了登记。令人担忧的是，在4%的情况下，最新和最好的Bind-9版本没有使用新的信任锚定点，这在DNS-OARC演示文稿中有更详细的解释。但这仍然给我们留下了一个问题，为什么？还需要注意的是，尽管RFC8145的其他实现在默认情况下没有启用它，因此大多数报告都是通过Bind-9编写的。此时滚动KSK会导致剩余的解析程序不信任根区域的内容，最终破坏所有DNS解析。操作现实与协议设计在Cloudflare，我们在所有超过120个数据中心运行验证解析器，我们每周监控信任锚定的采用情况，期望一切正常。6周后，我们注意到事情并不顺利，一些解决者已经选择了新的信任锚定，而其他人没有接受新的信任锚定，即使时间已经过去了足够多。首先让我们看看RFC5011所做的假设。解析器是一个长时间运行的进程，它了解时间并可以保持状态解析程序可以访问可在重新启动时工作的持久可写存储。在协议社区中，我们非常担心第一种情况，对于第二种情况，我们发现了两种故障情况：从旧的只读介质配置的机器，和新的机器接管。两者都被认为是非常罕见的，运营商应该知道如何处理这些例外情况。结果表明，RFC5011中的第二个假设的失效模式比社区预期的要多。例如在Bind-9中，它或