第七章：密钥滚动

密钥使用的时间越长，入侵者破解它的机会就越大。随着计算机变得越来越强大，密钥算法需要更新。而且总是有人会偷你的私钥的风险。所有这些问题都有相同的解决方案：更换密钥。这被称为密钥滚动（key rollover）。

滚动密钥是管理DNSSEC中最复杂的部分。密钥滚动是可能的，因为RRSet可以有多个签名。如果名称服务器可以验证这些签名中的任何一个，则数据是安全的。额外的签名不会损害DNS或DNSSEC。

处理并发症的诀窍是让它们成为常规。先做棘手的部分，尽量减少恐惧。我强烈建议您在测试域上部署DNSSEC后立即进行滚动。在您对滚动过程感到非常满意之前，不要在生产域上部署DNSSEC，因为滚动过程非常无聊。

第七章：密钥滚动滚动并发症滚动时间Time-To-Live复制时间父区域更新有效TTL和恢复滚动方法ZSK滚动KSK滚动CSK滚动我应该多久轮换一次？密钥生命周期算法翻转根区域密钥翻转翻转自动化

滚动并发症

最后一章展示了打破信任链如何使区域变得虚假（bogus）。虚假区域从互联网上消失了。不假思索地放弃KSK、ZSK或CSK会破坏信任链。在我执行过的所有系统管理员任务中，DNSSEC密钥轮转是最需要严格遵守正确流程的任务。主要的复杂性来自DNS缓存。你必须对所有内容进行计时，这样解析器就不会试图使用过时的密钥。

您可能会考虑通过创建尽可能强的密钥、签署区域并且从不更改任何内容来完全避免这种风险。这是可能的。有人尝试过。您的密钥使用的时间越长，就越有可能有人暴力破解您的私钥并欺骗您的DNS。2011年最坚固的密钥在2021年会破得可笑。

一些类似的应用程序从不更改其密钥。一个普通的SSH服务器在安装时会生成一个密钥对。这是常见的做法。但是，您应该持续更新SSH服务器以消除新的安全漏洞。其中一些更新添加了新算法并弃用了旧算法。此外，互联网上的SSH服务器每隔几年就会被更换、升级或渗透和销毁。我管理自二十世纪以来一直在使用的区域文件。如果我在20世纪90年代签署了该区域，并且从未更改过密钥，那么任何廉价的手机都可以破解其加密。

好吧，好吧，但人们真的会打破密钥吗？在现实世界中？答案是：是的。它每年都会出现几次新闻。我最喜欢的故事发生在2012年，当时一位研究人员破解了谷歌的电子邮件密钥。这些密钥是几年前创建、部署和遗忘的。幸运的是，伪造者（forger）只使用它们伪造（forge）了谷歌创始人告诉运营团队升级密钥的电子邮件。

DNSSEC密钥翻转过程旨在避免此类威胁。

滚动时间

密钥滚动的唯一最重要的目标是确保世界各地的所有客户端都可以随时验证您的区域。递归名称服务器可能仍然在缓存中有您的密钥，但需要进行新的查询以获取新的记录及其签名。如果签名与密钥不匹配，则验证失败。围绕区域缓存时间制定滚动计划。需要考虑的时间包括区域的生存时间、辅助复制时间和父区域传播时间。

Time-To-Live

关键数字是该区域的生存时间（Time To Live —— TTL）。这是递归名称服务器在再次查询之前缓存区域数据的时间。您需要一份关于该区域TTL的权威声明。

如果您查询递归服务器以查找区域的TTL，它将告诉您任何缓存的答案将在缓存中保留多长时间。如果该区域有一个小时的TTL，但递归服务器在59分钟前查找了该区域，则递归服务器将报告一分钟的TTL。建立在一分钟TTL基础上的滚动计划将失败。始终向权威服务器查询TTL。

在这里，我通过查询权威服务器来检查我所在区域的TTL。我添加 +nocomment 以去除额外的调试输出，并添加 +norecuse 以确保我得到权威的答案。（禁用递归不应该是必要的，但作为实践，我总是认为我搞砸了。）TTL出现在SOA中的区域名称之后和类之前。

TTL为3600秒，即一小时。你可以现实地期望世界各地的域名服务器在一小时内查询新数据。

区域中的单个条目也可以有自己的TTL。大多数情况下，这些是动态系统的短期条目。这种短暂的条目不需要担心展期。然而，具有超长TTL的条目令人担忧。使用dig无法识别过长的异常；如果您怀疑它们存在，则必须检查区域文件。

您的区域的DS记录不在您的区域中，而是在父区域中。查询父区域的权威名称服务器以获取该记录。在这里，我检查了我所在区域的DS记录上的TTL。

您还可以在区域中的单个条目上设置TTL。

此DS记录的TTL为86400，即一天。递归名称服务器在检查新记录之前，将缓存我们的DS记录多达24次。

假设我为我的区域创建了一个新的KSK或CSK，用新密钥对我的区域进行签名，立即发布新的DS记录，并删除旧的DS记录。一切都完成了，砰的一声，老板会很高兴的！

与此同时，互联网上其他地方的人一直在刷新我的网站。在过去24小时的某个时刻，他们的递归名称服务器缓存了我所在区域的DS记录。在最后一个小时内，他们缓存了我所在区域的A和RRSIG记录。

DS记录上的TTL是A和RRSIG记录的24倍，因此DS记录在A和RRSIG记录之前过期的可能性大约为4%。如果发生这种情况，他们的递归名称服务器将获取新的DS记录。DS记录将与新密钥匹配。我的区域将是安全的，网站将继续工作。

然而，A和RRSIG记录在DS记录之前过期的可能性为96%。递归名称服务器将获取用新密钥签名的A和RRSIG记录。新密钥将与旧的缓存DS记录不匹配。此递归名称服务器将声明该区域为假。

一个拙劣的密钥翻转不会使你的区域普遍虚假。缓存数据混合不方便的客户端会声明你的区域是伪造的，而其他客户端会很好地验证你的区域。在按键翻转过程中发现故障报告表明您更改过快。

在安排密钥滚动之前，请检查您所在区域的TTL和其中的任何特殊条目，以及您所在区域DS记录的TTL。围绕最长的TTL构建您的滚动时间表。如果您的区域中的默认TTL为一小时，而DS记录的TTL为六小时，但该区域中的几个条目的TTL为一天，请根据一天的TTL安排一切。

复制时间

现代主名称服务器使用NOTIFY协议通知辅助服务器区域已更新，它们应该刷新其副本。不过，NOTIFY协议没有机制告诉任何一方消息是否失败，因此辅助服务器会定期检查更新。

如果您同时控制主名称服务器和辅助名称服务器，并且知道何时发布新密钥，则可以监视区域传输，并在失败时强制更新。（BIND用户可以通过向 rndc retransfer 命令提供区域名称来实现这一点。）不过，可靠的 NOTIFY 可以节省很多精力。

如何验证NOTIFY是否有效？更新区域。几秒钟后，比较主服务器和辅助服务器上的序列号。相同的序列号表示该区域已更新。

如果您不控制辅助名称服务器，并且没有可靠的NOTIFY服务，则必须在DNSSEC轮转计划中考虑区域复制时间。复制时间在SOA中设置。

序列号后三次立即设置区域复制定时。

该区域的 refresh 值是辅助服务器向主服务器查询该区域新副本的频率。这里的刷新时间为3600秒，即一小时。

仅当辅助服务器在刷新时无法访问主服务器时，才使用 retry 值。这是刷新检查失败后二次检查返回的频率。此区域的重试时间为900秒，即15分钟。如果辅助服务器在主名称服务器脱机时正在刷新，则辅助服务器将每十五分钟重试一次。

expire 时间显示辅助服务器何时放弃为该区域提供服务。这里的过期时间是3600000秒，也就是不到六周。如果辅助服务器在这段时间内无法到达主服务器，它会宣布该区域已过时并停止回答对它的查询。希望在那个半月的某个时候，你会注意到主服务器处于离线状态，并对此采取行动。

如果您依赖于主服务器和辅助服务器之间的基于时间的复制，请持悲观态度（be pessimistic）。每次更新区域时，假设辅助服务器在更改在主服务器上生效前的一瞬间检查了更新。辅助服务器将在整个刷新时间内继续提供旧数据。递归名称服务器将缓存旧数据，直到区域刷新。

这意味着用于规划目的的TTL是区域TTL加上刷新时间。在这个例子中，这两个都是一个小时。递归名称服务器在两个小时内不会完全更新其在您的区域上的记录。在这种情况下，两个小时没有区别；DS记录上的六小时TTL胜过一切。但是，如果您的刷新时间很长，则必须考虑到这一点。

如果您的辅助复制不可靠，则必须使其可靠，或者在验证复制的区域之前不要开始任何倒计时。并修复你的辅助。

父区域更新

如果这个密钥滚动涉及更改注册表中的DS记录，则必须考虑两次超出您控制范围的情况：注册表需要更新父区域的时间，以及父区域需要复制更改的时间。

如果您告诉注册商您的 .com 域名有一个新的DS记录，该记录需要多长时间才能出现在 .com 中？

理论上，父区域更新发生得很快。当你注册一个新域名时，你希望它立即可用。注册商希望在几分钟内更新区域。然而，这并不总是发生。同样，人们希望 .com 等区域的名称服务器能够快速复制。你不能假设他们会。

检查父区域上的TTL和刷新时间。考虑更新和复制的延迟将如何影响您的计划。对于我的区域，DS记录上的TTL远远超过了父区域的刷新时间。如果您的区域对业务至关重要，并且间歇性DNS错误会导致会议，请在您的流程中包括“验证DS记录”和“验证父区域复制”。

有效TTL和恢复

考虑到所有的时间因素，你可以计算出你的“effective TTL”，或者你必须等待的时间，以确保所有缓存都有你的新数据。请慷慨地估计一下。如果你认为你有一个8小时的TTL，就称之为一整天。

如果您的DNS出现故障，无论是否使用DNSSEC，此TTL也是恢复所需的时间。您可能会立即修复该区域，但任何捕获错误数据的递归都会缓存它，直到TTL到期。TTL与您的平均恢复时间成正比，如果这远远超过一天，您应该重新考虑您的区域时间。

在正常情况下，我使用一天有效的TTL。如果入侵者捕获了您的私钥，您必须尽快滚动您的KSK和ZSK，请坚持使用您从区域TTL中添加的有效TTL。根据您的威胁模型以及入侵者可能通过欺骗您的DNS所做的事情，您甚至可以立即删除此类密钥，并向注册商发布新的DS，从而降低可用性以保持完整性。

在讨论展期时，将“TTL”理解为“根据您的区域和环境确定的完全传播数据的时间”

滚动方法

翻转过程是围绕首选优化构建的。减少与父区域的交互次数可以加快操作速度，但代价是增加区域大小和DNS流量。最小化区域大小会增加进程所需的时间长度以及与父区域的交互次数。标准的滚动方法并不那么简单，但这是所有事情背后的一个重大权衡。

要滚动密钥，您可以在使用之前对所有内容进行双重签名或发布新密钥。细节略有不同，具体取决于您是在ZSK还是KSK上滚动。其他标准也存在，但它们要么适用于非常特定的情况，要么与这两种标准相比没有优势。

ZSK滚动

区域签名密钥（Zone Signing Key）滚动完全是内部的，不需要与父区域交互。在不中断服务的情况下滚动ZSK的两种标准方法称为双重签名（double signature）和预发布（pre-publishing）。

在双重签名（double signature）方法中，该区域同时使用新旧密钥进行签名，从而创建多个RRSIG记录。递归客户端获取所有RRSIG记录。权威服务器会维护这些多个签名，直到TTL通过，因此所有客户端都将丢弃仅用一个密钥签名的记录，并在缓存中保存新的双签名RRSIG记录。此时，您可以删除旧密钥和旧签名。

双重签名无疑是安全的。由于您在本地签署所有内容，因此没有破坏信任链的风险。然而，它几乎将此密钥签名的所有内容的大小增加了一倍。大多数组织对此并不关心。如果你有一个巨大的区域，或者你处理了很多查询，DNS带宽可能是一个问题。

使用预发布（pre-publishing）方法，您可以在使用区域的新DNSKEY对任何RRSet进行签名之前使其可用。一旦TTL通过，记录传播到所有客户端，您就可以删除旧签名，并使用新密钥创建新签名。

预发布方法比双重签名更优雅（elegant）。它不会使你的区域大小翻倍。它在签名过期时替换签名，而不是对所有内容进行两次签名，并在任何地方留下大量RRSIG记录。然而，它更复杂，复杂会导致中断。

还存在一种称为双RRSIG（double-RRSIG）的滚动方法，但它结合了双签名的缺点和预发布的缺点，对两者都没有好处，因此我们将忽略它。

最佳实践要求对ZSK展期使用预发布。ZSK没有DS记录，因此滚动只会更改DNSKEY和RRSIG记录。

KSK滚动

密钥签名密钥有两个作用。这是DS记录的目标，它签署了ZSK。更改KSK意味着更改DS记录，因此您必须与RIR或域名注册商进行交互，这使得它们比ZSK轮转更复杂。KSK翻转的三种标准方法是双KSK（double-KSK）、双DS（double-DS）和双RRSet（double-RRSet）。

在 double-KSK 方法中，新的公钥被添加到DNSKEY RRSet中。RRSet使用旧密钥和新密钥进行签名。您等待一个TTL，让旧的RRSet从每个人的缓存中过期，然后转到注册器添加新的DS记录并删除旧的。等待另一个TTL，让新的DS记录渗透到缓存中，然后从RRSet中删除旧密钥。double-KSK 的优点是，您只需要与注册商交互一次。缺点是在滚动期间，您的DNSKEY记录稍大。

在 double-DS 方法中，首先转到注册商并在上一个DS记录旁边发布新的DS记录。等待TTL，以便此更改在所有缓存中传播。在一次操作中，激活新密钥并移除旧密钥。

double-RRSet 方法一次完成所有事情，但具有其他两种方法的所有缺点。您保留旧密钥，但激活新密钥，用两个密钥对所有内容进行签名，并立即发布DS记录。TTL通过后，您将删除旧的DS记录和旧密钥。

你应该使用哪一种？我更喜欢 double-KSK 方法。这允许您发布新密钥，并在取消发布旧DS记录和删除旧密钥之前，验证远程名称服务器是否可以使用该密钥验证您的区域。如果你在紧急情况下，比如从入侵者那里恢复过来，double-RRSet 方法是最好的。然而，这三种方法都有效。

CSK滚动

组合签名密钥（Combined Signing Key —— CSK）履行KSK和CSK的职责。因此，翻转结合了两者使用的方法。为了最小化您的区域和父区域交互的大小，CSK使用ZSK的预发布方法和KSK的双KSK方法的元素。一切都始于发布新的DNSKEY。

更改CSK需要与父区域交互，因此它具有与KSK翻转相同的时间考虑因素。

我应该多久轮换一次？

知识渊博的（Knowledgeable）人对钥匙应该多久轮换一次意见不一。

风险承受能力低的人声明，ZSK应每三个月轮换一次，KSK应每年轮换一次。持续时间随着你的风险承受能力而增加，随着你的区域价值的降低而减少。它很软（squishy）。之前的根区域密钥使用了十多年，但私钥保持离线状态，并以我们大多数人即使负担得起也不会费心的方式进行保护。

有些人说你永远不应该轮换你的密钥。毕竟，你多久轮换一次SSH服务器密钥？

这归结为：你的威胁概况是什么？

有人会攻击你的个人域名吗？也许。这取决于你造成的麻烦类型和你支持的原因。这些攻击者是否有足够的计算能力在合理的时间内破解你的密钥，以及他们对此的了解？也许。但是，DNSSEC在您的区域上的存在可能会阻止您的敌人进行DNS欺骗，使他们侵入您的web服务器。

我知道不止一家大型金融机构十年来没有改变他们的RSASHA1密钥。那是个糟糕的选择。

当你的签名算法磨损时，你必须轮换你的密钥。如果您的签名使用RSASHA1，请尽快使用现代算法。最终，即使是RSASHA256也会失败，但这个最终（eventually）可能需要很长时间。

使用CSK的小型站点应根据其威胁情况设置轮换需求。每隔几年，我会轮换我的个人域，包括我的博客和我写的冗长的垃圾书清单。我会说，一家存储客户个人数据的电子商务公司应该至少经常轮换密钥。不过，看看 .co.uk 的做法：并不是每个人都同意。选择你的风险，并与之共存。

无论您多么频繁地轮换区域的密钥，您都必须对轮换过程感到满意。系统管理员讨厌做不熟悉的任务，尤其是当它们可能引发用户投诉时。您的公司应该有一个反映生产环境设置的测试区，并频繁地轮换其密钥，使程序成为常规。否则，当灾难发生时，您现在必须立即轮换生产区的密钥，您将遭受不必要的痛苦。

密钥生命周期

滚动意味着密钥被创建、使用、弃用和销毁。RFC 7583提供了描述DNSSEC密钥状态的正式语言，但其中许多并没有被广泛使用。一个键有四个重要日期：publish（发布）、activate（激活）、inactivate（停用）和delete（删除）。

如果您正在运行BIND，则密钥文件包含已设置的任何日期。

该密钥于2021年8月24日创建，并立即发布和激活。它于2021年9月22日停用，计划于2021年10月2日删除。如果密钥被泄露，你可能会看到一个“Revoked（撤销）”日期，你必须赶紧轮换。SyncPublish日期适用于CDS和CDNSKEY记录，我们将在本章稍后的“Automation（自动化）”中讨论。

算法翻转

加密算法不会随着时间的推移而变弱，但我们攻击它们的能力每天都在增加。最终，所有算法都会变得脆弱，必须用更强大的算法来取代。

当我第一次部署DNSSEC时，密钥使用了SHA1。这些钥匙现在非常不安全。如果你自本书第一版以来没有更新过你的密钥，或者如果有人发现你使用的现代密钥算法存在弱点，你必须执行算法翻转（algorithm rollover）。算法翻转不仅会切换密钥，还会切换这些密钥使用的算法——比如，旧密钥使用算法8（RSASHA256），但新密钥需要算法13（ECDSAP256SHA256）。

将算法翻转视为一种新的DNSSEC部署。在您的区域上启用新算法，并在发布DS记录之前确保区域中的所有内容都使用新算法进行签名。一旦新的DS到处传播，您就可以删除旧的算法。

在DNSSEC的早期，算法翻转很棘手。您将看到许多关于软件兼容性和密钥生成问题以及各种头痛问题的文章和帖子。好消息是，大多数域名服务器已经解决了这些问题。大部分。

验证器只接受子区域中所有密钥的DS记录中给出的算法。假设您使用算法13成功部署了一个新的KSK。ZSK还必须使用算法13。算法滚动的诀窍是同时滚动KSK和ZSK。名称服务器应首先添加新签名（new signatures），然后添加密钥记录（key records），最后才应发布DS记录。

根区域密钥翻转

从理论上讲，目前用于签署根区域的密钥应该有效多年。计划滚动根区域密钥并替换信任锚需要几年时间。不过，争论会发生，所以我们将简要讨论一下。

与任何其他KSK或ZSK一样，根区域密钥使用算法和私钥。如果该算法开始显示其年龄或私钥被泄露，则必须滚动密钥并将新的信任锚点分发到验证递归服务器。RFC 5011中记录了用于滚动上一个根区域密钥的过程。大多数名称服务器支持RFC 5011中记录的信任锚轮转。

新的信任锚作为DNS记录发布，由旧的信任锚签名。新的信任锚公钥提前几年发布，以便软件供应商可以在更新中包含它们。如果您保持DNS服务器的更新，则密钥翻转不是问题。

最后一次信任锚展期是2018年10月11日。大多数网站都很好。一些网站就保持DNS服务器更新的重要性得到了简短而深刻的教训。

下一次轮转会使用RFC 5011吗？也许 吧。下一次预定的展期将于何时进行？还没有。但它要么会提前几年宣布，要么某个大师级窃贼泄露了根区密钥。

翻转自动化

密钥翻转的薄弱环节是通知注册商新的DS记录。这似乎是一个非常适合自动化的操作，不是吗？

确实如此。遗憾的是，在首次部署DNSSEC之前，我们没有确定一种标准的自动化方法。许多注册商实施了自己独特的API来与客户沟通。许多域名服务器采用软件与少数特定的注册商进行通信。结果是标准和方法的混杂。

2017年，标准机构就权威名称服务器通过新的记录类型（CDS和CDNSKEY记录）与注册商通信的方法达成一致。

CDS记录显示了该地区希望其DS记录是什么样子的。CDNSKEY记录给出了区域希望其DNSKEY记录的样子。两者均由当前的KSK或CSK签署。

父区域应每周轮询其子区域，以检查更新的CDS和CDNSKEY记录。如果记录被找到、验证并且通常是连贯和合理的，则父区域应更新其DS记录。

CDS和CDNSKEY记录需要注册机构而非注册商的支持。然而，目前只有少数注册表支持CDS和CDNSKEY记录。目前，您一直在寻找其他方法来自动与注册商通信。

KSK更新不频繁。任何不经常运行的自动化都是脆弱的。如果您支持如此多的区域，以至于您将定期使用自动化，请务必使用注册商推荐的方法自动化DS记录。如果没有，请手动更新您的记录，并要求您的注册商支持CDS记录。

现在你已经有了理论，让我们来看看BIND政策的翻转。