Internet Engineering Task Force (IETF) S. Morris
Request for Comments: 7583 ISC
Category: Informational J. Ihren
ISSN: 2070-1721 Netnod
J. Dickinson
Sinodun
W. Mekking
Dyn
October 2015
Internet Engineering Task Force (IETF) S. Morris
Request for Comments: 7583 ISC
Category: Informational J. Ihren
ISSN: 2070-1721 Netnod
J. Dickinson
Sinodun
W. Mekking
Dyn
October 2015
DNSSEC Key Rollover Timing Considerations
DNSSEC关键翻滚时间注意事项
Abstract
摘要
This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.
本文档描述了DNSSEC安全区域中密钥滚动事件的时间安排问题。它给出了键滚动的时间线，并明确确定了影响该过程的各种参数之间的关系。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7583.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7583.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Key Rolling Considerations .................................3
1.2. Types of Keys ..............................................4
1.3. Terminology ................................................4
1.4. Limitation of Scope ........................................5
2. Rollover Methods ................................................5
2.1. ZSK Rollovers ..............................................5
2.2. KSK Rollovers ..............................................7
3. Key Rollover Timelines ..........................................8
3.1. Key States .................................................8
3.2. ZSK Rollover Timelines ....................................10
3.2.1. Pre-Publication Method .............................10
3.2.2. Double-Signature Method ............................12
3.3. KSK Rollover Timelines ....................................14
3.3.1. Double-KSK Method ..................................14
3.3.2. Double-DS Method ...................................17
3.3.3. Double-RRset Method ................................20
3.3.4. Interaction with Configured Trust Anchors ..........22
3.3.5. Introduction of First Keys .........................24
4. Standby Keys ...................................................24
5. Algorithm Considerations .......................................25
6. Summary ........................................................26
7. Security Considerations ........................................26
8. Normative References ...........................................26
Appendix A. List of Symbols ......................................28
Acknowledgements ..................................................31
Authors' Addresses ................................................31
1. Introduction ....................................................3
1.1. Key Rolling Considerations .................................3
1.2. Types of Keys ..............................................4
1.3. Terminology ................................................4
1.4. Limitation of Scope ........................................5
2. Rollover Methods ................................................5
2.1. ZSK Rollovers ..............................................5
2.2. KSK Rollovers ..............................................7
3. Key Rollover Timelines ..........................................8
3.1. Key States .................................................8
3.2. ZSK Rollover Timelines ....................................10
3.2.1. Pre-Publication Method .............................10
3.2.2. Double-Signature Method ............................12
3.3. KSK Rollover Timelines ....................................14
3.3.1. Double-KSK Method ..................................14
3.3.2. Double-DS Method ...................................17
3.3.3. Double-RRset Method ................................20
3.3.4. Interaction with Configured Trust Anchors ..........22
3.3.5. Introduction of First Keys .........................24
4. Standby Keys ...................................................24
5. Algorithm Considerations .......................................25
6. Summary ........................................................26
7. Security Considerations ........................................26
8. Normative References ...........................................26
Appendix A. List of Symbols ......................................28
Acknowledgements ..................................................31
Authors' Addresses ................................................31
When a zone is secured with DNSSEC, the zone manager must be prepared to replace ("roll") the keys used in the signing process. The rolling of keys may be caused by compromise of one or more of the existing keys, or it may be due to a management policy that demands periodic key replacement for security or operational reasons. In order to implement a key rollover, the keys need to be introduced into and removed from the zone at the appropriate times. Considerations that must be taken into account are:
当区域由DNSSEC保护时，区域经理必须准备更换（“滚动”）签名过程中使用的密钥。密钥滚动可能是由于一个或多个现有密钥的泄露造成的，也可能是由于出于安全或操作原因需要定期更换密钥的管理策略造成的。为了实现钥匙翻转，需要在适当的时间将钥匙引入区域并从区域中取出。必须考虑的因素包括：
o DNSKEY records and associated information (such as the DS records or RRSIG records created with the key) are not only held at the authoritative nameserver, they are also cached by resolvers. The data on these systems can be interlinked, e.g., a validating resolver may try to validate a signature retrieved from a cache with a key obtained separately.
o DNSKEY记录和相关信息（例如使用密钥创建的DS记录或RRSIG记录）不仅保存在权威名称服务器中，还由解析程序缓存。这些系统上的数据可以互连，例如，验证解析器可以尝试使用单独获得的密钥验证从缓存检索的签名。
o Zone "bootstrapping" events, where a zone is signed for the first time, can be common in configurations where a large number of zones are being served. Procedures should be able to cope with the introduction of keys into the zone for the first time as well as "steady-state", where the records are being replaced as part of normal zone maintenance.
o 第一次签署区域的区域“引导”事件在为大量区域提供服务的配置中很常见。程序应能够处理首次将钥匙引入区域以及“稳态”的情况，其中记录被替换为正常区域维护的一部分。
o To allow for an emergency re-signing of the zone as soon as possible after a key compromise has been detected, standby keys (additional keys over and above those used to sign the zone) need to be present.
o 为了在检测到密钥泄露后尽快对区域进行紧急重新签名，需要提供备用密钥（用于对区域进行签名的密钥之外的其他密钥）。
o A query for the DNSKEY RRset returns all DNSKEY records in the zone. As there is limited space in the UDP packet (even with EDNS0 support), key records no longer needed must be periodically removed. (For the same reason, the number of standby keys in the zone should be restricted to the minimum required to support the key management policy.)
o 对DNSKEY RRset的查询将返回区域中的所有DNSKEY记录。由于UDP数据包中的空间有限（即使支持EDNS0），因此不再需要的密钥记录必须定期删除。（出于同样的原因，区域中的备用密钥数量应限制在支持密钥管理策略所需的最小值。）
Management policy, e.g., how long a key is used for, also needs to be considered. However, the point of key management logic is not to ensure that a rollover is completed at a certain time but rather to ensure that no changes are made to the state of keys published in the zone until it is "safe" to do so ("safe" in this context meaning that at no time during the rollover process does any part of the zone ever go bogus). In other words, although key management logic enforces policy, it may not enforce it strictly.
还需要考虑管理策略，例如密钥的使用时间。但是，密钥管理逻辑的要点不是确保在某个时间完成翻滚，而是确保在“安全”之前不会对区域中发布的密钥的状态进行任何更改（“安全”在本文中指的是，在翻滚过程中，区域的任何部分都不会伪造）。换句话说，尽管密钥管理逻辑强制执行策略，但它可能不会严格强制执行策略。
A high-level overview of key rollover can be found in [RFC6781]. In contrast, this document focuses on the low-level timing detail of two classes of operations described there, the rollover of Zone Signing Keys (ZSKs), and the rollover of Key Signing Keys (KSKs).
在[RFC6781]中可以找到关键翻滚的高级概述。与此相反，本文档重点关注此处描述的两类操作的低级计时细节，即区域签名密钥（ZSK）的滚动和密钥签名密钥（KSK）的滚动。
Note that the process for the introduction of keys into a zone is different from that of rolling a key; see Section 3.3.5 for more information.
请注意，将键引入区域的过程与滚动键的过程不同；详见第3.3.5节。
Although DNSSEC validation treats all keys equally, [RFC4033] recognizes the broad classification of ZSKs and KSKs. A ZSK is used to authenticate information within the zone; a KSK is used to authenticate the zone's DNSKEY RRset. The main implication for this distinction concerns the consistency of information during a rollover.
尽管DNSSEC验证同等对待所有密钥，[RFC4033]承认ZSK和KSK的广泛分类。ZSK用于验证区域内的信息；KSK用于验证区域的DNSKEY RRset。这一区别的主要含义涉及滚动期间信息的一致性。
During operation, a validating resolver must use separate pieces of information to perform an authentication. At the time of authentication, each piece of information may be in its cache or may need to be retrieved from an authoritative server. The rollover process needs to happen in such a way that the information is consistent at all times during the rollover. With a ZSK, the information is the RRSIG (plus associated RRset) and the DNSKEY. These are both obtained from the same zone. In the case of the KSK, the information is the DNSKEY and DS RRset with the latter being obtained from a different zone.
在操作过程中，验证解析器必须使用单独的信息来执行身份验证。在进行身份验证时，每条信息可能位于其缓存中，或者可能需要从权威服务器检索。滚动过程需要以这样一种方式进行：在滚动过程中，信息始终保持一致。对于ZSK，信息是RRSIG（加上相关RRset）和DNSKEY。它们都是从同一区域获得的。在KSK的情况下，信息是DNSKEY和DS RRset，后者从不同的区域获得。
Although there are similarities in the algorithms to roll ZSKs and KSKs, there are a number of differences. For this reason, the two types of rollovers are described separately.
虽然滚动ZSK和KSK的算法有相似之处，但也有许多不同之处。因此，将分别描述这两种类型的翻车。
The terminology used in this document is as defined in [RFC4033] and [RFC5011].
本文件中使用的术语定义见[RFC4033]和[RFC5011]。
A number of symbols are used to identify times, intervals, etc. All are listed in Appendix A.
许多符号用于标识时间、间隔等。所有符号均在附录A中列出。
This document represents current thinking at the time of publication. However, the subject matter is evolving and it is not possible for the document to be comprehensive. In particular, it does not cover:
本文件代表了出版时的当前想法。然而，主题正在演变，文件不可能全面。特别是，它不包括：
o Rolling a key that is used as both a ZSK and KSK.
o 滚动同时用作ZSK和KSK的键。
o Algorithm rollovers. Only the rolling of keys of the same algorithm is described here: not transitions between algorithms.
o 算法翻转。这里只描述了相同算法的关键点滚动：而不是算法之间的转换。
o Changing TTLs.
o 更改TTL。
Algorithm rollover is excluded from the document owing to the need for there to be an RRSIG for at least one DNSKEY of each algorithm in the DNSKEY RRset [RFC4035]. This introduces additional constraints on rollovers that are not considered here. Such considerations do not apply where other properties of the key, such as key length, are changed during the rollover: the DNSSEC protocol does not impose any restrictions in these cases.
由于DNSKEY RRset[RFC4035]中每种算法至少有一个DNSKEY需要RRSIG，因此文件中不包括算法滚动[RFC4035]。这将引入此处未考虑的有关翻滚的其他约束。当密钥的其他属性（如密钥长度）在滚动期间发生更改时，这些注意事项不适用：DNSSEC协议在这些情况下不施加任何限制。
Also excluded from consideration is the effect of changing the Time to Live (TTL) of records in a zone. TTLs can be changed at any time, but doing so around the time of a key rollover may have an impact on event timings. In the timelines below, it is assumed that TTLs are constant.
更改分区中记录的生存时间（TTL）的影响也被排除在考虑范围之外。TTL可以在任何时候更改，但在关键点翻转期间这样做可能会影响事件计时。在下面的时间线中，假设TTL是恒定的。
For ZSKs, the issue for the zone operator/signer is to ensure that any caching validator that has access to a particular signature also has access to the corresponding valid ZSK.
对于ZSK，区域操作员/签名者的问题是确保任何可以访问特定签名的缓存验证器也可以访问相应的有效ZSK。
A ZSK can be rolled in one of three ways:
ZSK可以通过以下三种方式之一轧制：
o Pre-Publication: described in [RFC6781], the new key is introduced into the DNSKEY RRset, which is then re-signed. This state of affairs remains in place for long enough to ensure that any cached DNSKEY RRsets contain both keys. At that point, signatures created with the old key can be replaced by those created with the new key. During the re-signing process (which may or may not be atomic depending on how the zone is managed), it doesn't matter with which key an RRSIG record retrieved by a resolver was created; cached copies of the DNSKEY RRset will contain both the old and new keys.
o 预发布：如[RFC6781]所述，将新密钥引入DNSKEY RRset，然后重新签名。这种状态保持足够长的时间，以确保任何缓存的DNSKEY RRSET都包含这两个密钥。此时，使用旧密钥创建的签名可以替换为使用新密钥创建的签名。在重新签名过程中（这可能是原子的，也可能不是原子的，取决于区域的管理方式），创建解析程序检索的RRSIG记录时使用的密钥并不重要；DNSKEY RRset的缓存副本将同时包含旧密钥和新密钥。
Once the zone contains only signatures created with the new key, there is an interval during which RRSIG records created with the old key expire from caches. After this, there will be no signatures anywhere that were created using the old key, and it can be removed from the DNSKEY RRset.
一旦区域仅包含使用新密钥创建的签名，则使用旧密钥创建的RRSIG记录将从缓存中过期。在此之后，将不会有使用旧密钥创建的任何签名，并且可以将其从DNSKEY RRset中删除。
o Double-Signature: also mentioned in [RFC6781], this involves introducing the new key into the zone and using it to create additional RRSIG records; the old key and existing RRSIG records are retained. During the period in which the zone is being signed (again, the signing process may not be atomic), validating resolvers are always able to validate RRSIGs: any combination of old and new DNSKEY RRset and RRSIGs allows at least one signature to be validated.
o 双重签名：也在[RFC6781]中提到，这涉及将新密钥引入区域，并使用它创建额外的RRSIG记录；保留旧密钥和现有RRSIG记录。在区域签名期间（同样，签名过程可能不是原子的），验证解析程序始终能够验证RRSIG：新旧DNSKEY RRset和RRSIG的任何组合都允许至少验证一个签名。
Once the signing process is complete and enough time has elapsed to make sure that all validators that have the DNSKEY and signatures in cache have both the old and new information, the old key and signatures can be removed from the zone. As before, during this period any combination of DNSKEY RRset and RRSIGs will allow validation of at least one signature.
一旦签名过程完成，并且经过足够的时间来确保缓存中具有DNSKEY和签名的所有验证器都具有新旧信息，就可以从区域中删除旧密钥和签名。与之前一样，在此期间，DNSKEY RRset和RRSIG的任何组合都将允许至少一个签名的验证。
o Double-RRSIG: strictly speaking, the use of the term "Double-Signature" above is a misnomer as the method is not only double signature, it is also double key as well. A true Double-Signature method (here called the Double-RRSIG method) involves introducing new signatures in the zone (while still retaining the old ones) but not introducing the new key.
o Double RRSIG：严格来说，使用上面的术语“双重签名”是一个误称，因为该方法不仅是双重签名，也是双重密钥。真正的双重签名方法（此处称为双重RRSIG方法）涉及在区域中引入新签名（同时仍保留旧签名），但不引入新密钥。
Once the signing process is complete and enough time has elapsed to ensure that all caches that may contain an RR and associated RRSIG have a copy of both signatures, the key is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old signatures are removed from the zone.
一旦签名过程完成，并且经过足够的时间来确保可能包含RR和关联RRSIG的所有缓存都具有这两个签名的副本，密钥就会更改。在旧DNSKEY RRset从缓存中过期的另一个间隔之后，旧签名将从区域中删除。
Of the three methods, Double-Signature is conceptually the simplest: introduce the new key and new signatures, then approximately one TTL later remove the old key and old signatures. It is also the fastest, but suffers from increasing the size of the zone and the size of responses.
在这三种方法中，双重签名在概念上是最简单的：引入新密钥和新签名，然后在大约一个TTL之后删除旧密钥和旧签名。它也是最快的，但会增加区域的大小和响应的大小。
Pre-Publication is more complex: introduce the new key, approximately one TTL later sign the records, and approximately one TTL after that remove the old key. It does however keep the zone and response sizes to a minimum.
预发布更复杂：引入新密钥，大约一个TTL在记录上签名，然后大约一个TTL删除旧密钥。但是，它将区域和响应大小保持在最小值。
Double-RRSIG is essentially the reverse of Pre-Publication: introduce the new signatures, approximately one TTL later change the key, and approximately one TTL after that remove the old signatures. However, it has the disadvantage of the Pre-Publication method in terms of time taken to perform the rollover, the disadvantage of the Double-Signature rollover in terms of zone and response sizes, and none of the advantages of either. For these reasons, it is unlikely to be used in any real-world situations and so will not be considered further in this document.
Double RRSIG本质上与预发布相反：引入新签名，大约一个TTL稍后更改密钥，然后大约一个TTL删除旧签名。然而，就执行滚动所需的时间而言，它与预发布方法相比有缺点，就区域和响应大小而言，它与双重签名滚动相比有缺点，并且两者都没有优点。由于这些原因，它不太可能在任何实际情况下使用，因此在本文件中将不作进一步考虑。
In the KSK case, there should be no problem with a caching validator not having access to a signature created with a valid KSK. The KSK is only used for one signature (that over the DNSKEY RRset) and both the key and the signature travel together. Instead, the issue is to ensure that the KSK is trusted.
在KSK的情况下，缓存验证器没有访问使用有效KSK创建的签名的权限应该没有问题。KSK仅用于一个签名（通过DNSKEY RRset），并且密钥和签名一起传输。相反，问题在于确保KSK是可信的。
Trust in the KSK is due to either the existence of a signed and validated DS record in the parent zone or an explicitly configured trust anchor. If the former, the rollover algorithm will need to involve the parent zone in the addition and removal of DS records, so timings are not wholly under the control of the zone manager. If the latter, [RFC5011] timings will be needed to roll the keys. (Even in the case where authentication is via a DS record, the zone manager may elect to include [RFC5011] timings in the key rolling process so as to cope with the possibility that the key has also been explicitly configured as a trust anchor.)
KSK中的信任是由于父区域中存在经过签名和验证的DS记录或显式配置的信任锚。如果是前者，则滚动算法将需要父区域参与DS记录的添加和删除，因此计时不完全由区域管理器控制。如果是后者，则需要[RFC5011]计时来滚动钥匙。（即使在通过DS记录进行身份验证的情况下，区域管理器也可以选择在密钥滚动过程中包括[RFC5011]定时，以应对密钥也被明确配置为信任锚的可能性。）
It is important to note that the need to interact with the parent does not preclude the development of key rollover logic; in accordance with the goal of the rollover logic, being able to determine when a state change is "safe", the only effect of being dependent on the parent is that there may be a period of waiting for the parent to respond in addition to any delay the key rollover logic requires. Although this introduces additional delays, even with a parent that is less than ideally responsive, the only effect will be a slowdown in the rollover state transitions. This may cause a policy violation, but will not cause any operational problems.
需要注意的是，与父级交互的需要并不妨碍关键滚动逻辑的开发；根据滚动逻辑的目标，能够确定状态更改何时是“安全的”，依赖于父级的唯一影响是，除了关键滚动逻辑需要的任何延迟外，可能还有一段等待父级响应的时间。尽管这会引入额外的延迟，即使父级响应不够理想，唯一的影响将是滚动状态转换的速度减慢。这可能会导致违反策略，但不会导致任何操作问题。
Like the ZSK case, there are three methods for rolling a KSK:
与ZSK案例一样，滚动KSK有三种方法：
o Double-KSK: the new KSK is added to the DNSKEY RRset, which is then signed with both the old and new key. After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed. After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset.
o Double KSK：新的KSK被添加到DNSKEY RRset中，然后使用新旧密钥对其进行签名。在等待旧RRset从缓存中过期后，父区域中的DS记录将被更改。在等待该更改在缓存中反映的进一步间隔后，旧密钥将从RRset中删除。
o Double-DS: the new DS record is published. After waiting for this change to propagate into caches, the KSK is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old DS record is removed.
o 双DS：发布新的DS记录。等待此更改传播到缓存后，KSK将被更改。在旧DNSKEY RRset从缓存中过期的另一个时间间隔之后，旧DS记录将被删除。
o Double-RRset: the new KSK is added to the DNSKEY RRset, which is then signed with both the old and new key, and the new DS record is added to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY and DS records are removed.
o Double RRset：将新的KSK添加到DNSKEY RRset，然后使用新旧密钥对其进行签名，并将新的DS记录添加到父区域。在等待旧DS和DNSKEY RRSET从缓存中过期的适当时间间隔后，将删除旧DNSKEY和DS记录。
In essence, Double-KSK means that the new KSK is introduced first and used to sign the DNSKEY RRset. The DS record is changed, and finally the old KSK is removed. It limits interactions with the parent to a minimum but, for the duration of the rollover, the size of the DNSKEY RRset is increased.
实际上，双KSK意味着首先引入新的KSK，并用于对DNSKEY RRset进行签名。DS记录被更改，最后旧的KSK被删除。它将与父级的交互限制在最低限度，但在滚动期间，DNSKEY RRset的大小会增加。
With Double-DS, the order of operations is the other way around: introduce the new DS, change the DNSKEY, then remove the old DS. The size of the DNSKEY RRset is kept to a minimum, but two interactions are required with the parent.
对于双DS，操作顺序是相反的：引入新DS，更改DNSKEY，然后删除旧DS。DNSKEY RRset的大小保持在最小值，但需要与父级进行两次交互。
Finally, Double-RRset is the fastest way to roll the KSK, but has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent.
最后，Double RRset是滚动KSK的最快方法，但也有其他两种方法的缺点：一个更大的DNSKEY RRset和两个与父级的交互。
DNSSEC validation requires both the DNSKEY and information created from it (referred to as "associated data" in this section). In the case of validation of an RR, the data associated with the key is the corresponding RRSIG. Where there is a need to validate a chain of trust, the associated data is the DS record.
DNSSEC验证需要DNSKEY和从中创建的信息（在本节中称为“关联数据”）。在RR验证的情况下，与密钥相关联的数据是相应的RRSIG。如果需要验证信任链，则相关数据为DS记录。
During the rolling process, keys move through different states. The defined states are:
在滚动过程中，关键点在不同的状态下移动。定义的状态为：
Generated Although keys may be created immediately prior to first use, some implementations may find it convenient to create a pool of keys in one operation and draw from it as required. (Note: such a pre-generated pool must be secured against surreptitious use.) In the timelines below, before the first event, the keys are considered to be created but not yet used: they are said to be in the "Generated" state.
生成的密钥虽然可以在第一次使用之前立即创建，但一些实现可能会发现在一次操作中创建密钥池并根据需要从中提取密钥很方便。（注意：必须确保预生成的池不会被秘密使用。）在下面的时间线中，在第一次事件之前，密钥被视为已创建但尚未使用：它们被称为处于“生成”状态。
Published A key enters the published state when either it or its associated data first appears in the appropriate zone.
已发布当密钥或其关联数据首次出现在相应区域中时，密钥将进入已发布状态。
Ready The DNSKEY or its associated data have been published for long enough to guarantee that copies of the key(s) it is replacing (or associated data related to that key) have expired from caches.
就绪DNSKEY或其关联数据已发布足够长的时间，以保证其所替换密钥（或与该密钥相关的关联数据）的副本已从缓存中过期。
Active The data is starting to be used for validation. In the case of a ZSK, it means that the key is now being used to sign RRsets and that both it and the created RRSIGs appear in the zone. In the case of a KSK, it means that it is possible to use it to validate a DNSKEY RRset as both the DNSKEY and DS records are present in their respective zones. Note that when this state is entered, it may not be possible for validating resolvers to use the data for validation in all cases: the zone signing may not have finished or the data might not have reached the resolver because of propagation delays and/or caching issues. If this is the case, the resolver will have to rely on the predecessor data instead.
活动数据已开始用于验证。在ZSK的情况下，这意味着密钥现在正被用于对rrset进行签名，并且它和创建的rrsig都出现在区域中。对于KSK，这意味着可以使用它来验证DNSKEY RRset，因为DNSKEY和DS记录都存在于各自的区域中。请注意，当进入此状态时，验证解析程序可能无法在所有情况下使用数据进行验证：区域签名可能尚未完成，或者由于传播延迟和/或缓存问题，数据可能尚未到达解析程序。如果是这种情况，解析器将不得不依赖前置数据。
Retired The data has ceased to be used for validation. In the case of a ZSK, it means that the key is no longer used to sign RRsets. In the case of a KSK, it means that the successor DNSKEY and DS records are in place. In both cases, the key (and its associated data) can be removed as soon as it is safe to do so, i.e., when all validating resolvers are able to use the new key and associated data to validate the zone. However, until this happens, the current key and associated data must remain in their respective zones.
该数据已停止用于验证。在ZSK的情况下，这意味着不再使用密钥对rrset进行签名。在KSK的情况下，这意味着后续DNSKEY和DS记录已就位。在这两种情况下，只要安全即可删除密钥（及其关联数据），即当所有验证解析程序都能够使用新密钥和关联数据验证区域时。但是，在此之前，当前密钥和关联数据必须保留在各自的区域中。
Dead The key and its associated data are present in their respective zones, but there is no longer information anywhere that requires their presence for use in validation. Hence, they can be removed at any time.
密钥及其相关数据在其各自的区域中存在，但在任何地方都不再有需要其存在以用于验证的信息。因此，它们可以随时移除。
Removed Both the DNSKEY and its associated data have been removed from their respective zones.
已删除DNSKEY及其关联数据已从各自的区域中删除。
Revoked The DNSKEY is published for a period with the "revoke" bit set as a way of notifying validating resolvers that have configured it as a trust anchor, as used in [RFC5011], that it is about to be removed from the zone. This state is used when [RFC5011] considerations are in effect (see Section 3.3.4).
撤销发布DNSKEY一段时间，设置“撤销”位，作为通知已将其配置为信任锚点（如[RFC5011]中所用）的验证解析程序即将从区域中删除的一种方式。当[RFC5011]考虑因素生效时，使用该状态（见第3.3.4节）。
The following sections describe the rolling of a ZSK. They show the events in the lifetime of a key (referred to as "key N") and cover its replacement by its successor (key N+1).
以下各节介绍了ZSK的轧制过程。它们显示密钥（称为“密钥N”）生命周期内的事件，并涵盖其后续密钥（密钥N+1）的替换。
In this method, the new key is introduced into the DNSKEY RRset. After enough time to ensure that any cached DNSKEY RRsets contain both keys, the zone is signed using the new key and the old signatures are removed. Finally, when all signatures created with the old key have expired from caches, the old key is removed.
在该方法中，新密钥被引入DNSKEY RRset。经过足够的时间确保任何缓存的DNSKEY RRSET都包含这两个密钥后，将使用新密钥对区域进行签名，并删除旧签名。最后，当使用旧密钥创建的所有签名从缓存中过期时，旧密钥将被删除。
The following diagram shows the timeline of a Pre-Publication rollover. Time increases along the horizontal scale from left to right and the vertical lines indicate events in the process. Significant times and time intervals are marked.
下图显示了发布前滚动的时间线。时间沿水平比例从左到右增加，垂直线表示过程中的事件。标记有效时间和时间间隔。
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
| | | | | | | |
Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
| | | | | | | |
Key N Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tpub Trdy Tact
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
| | | | | | | |
Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
| | | | | | | |
Key N Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->
---- Time ---->
Figure 1: Timeline for a Pre-Publication ZSK Rollover
图1：出版前ZSK展期时间表
Event 1: Key N's DNSKEY record is put into the zone, i.e., it is added to the DNSKEY RRset, which is then re-signed with the currently active KSKs. The time at which this occurs is the publication time (Tpub), and the key is now said to be published. Note that the key is not yet used to sign records.
事件1：密钥N的DNSKEY记录被放入区域，即，它被添加到DNSKEY RRset，然后用当前活动的KSK重新签名。发生这种情况的时间是发布时间（Tpub），现在称密钥已发布。请注意，密钥尚未用于对记录进行签名。
Event 2: Before it can be used, the key must be published for long enough to guarantee that any cached version of the zone's DNSKEY RRset includes this key.
事件2：在使用该密钥之前，必须将其发布足够长的时间，以确保区域的DNSKEY RRset的任何缓存版本都包含该密钥。
This interval is the publication interval (Ipub) and, for the second or subsequent keys in the zone, is given by:
此间隔是发布间隔（Ipub），对于区域中的第二个或后续键，由以下公式给出：
Ipub = Dprp + TTLkey
Ipub=Dprp+TTLkey
Here, Dprp is the propagation delay -- the time taken for a change introduced at the master to replicate to all nameservers. TTLkey is the TTL for the DNSKEY records in the zone. The sum is therefore the maximum time taken for existing DNSKEY records to expire from caches, regardless of the nameserver from which they were retrieved.
这里，Dprp是传播延迟——在主服务器上引入的更改复制到所有名称服务器所需的时间。TTLkey是区域中DNSKEY记录的TTL。因此，总和是现有DNSKEY记录从缓存过期所用的最长时间，而不管从哪个名称服务器检索它们。
(The case of introducing the first ZSK into the zone is discussed in Section 3.3.5.)
（第3.3.5节讨论了将第一个ZSK引入该区域的情况。）
After a delay of Ipub, the key is said to be ready and could be used to sign records. The time at which this event occurs is key N's ready time (Trdy), which is given by:
Ipub延迟一段时间后，据说密钥已准备就绪，可用于签署记录。此事件发生的时间是按键N的准备时间（Trdy），由以下公式给出：
Trdy(N) = Tpub(N) + Ipub
Trdy(N) = Tpub(N) + Ipub
Event 3: At some later time, the key starts being used to sign RRsets. This point is the activation time (Tact) and after this, key N is said to be active.
事件3：稍后，密钥开始用于对RRSET进行签名。这一点是激活时间（Tact），在此之后，表示键N处于激活状态。
Tact(N) >= Trdy(N)
Tact(N) >= Trdy(N)
Event 4: At some point thought must be given to its successor (key N+1). As with the introduction of the currently active key into the zone, the successor key will need to be published at least Ipub before it is activated. The publication time of key N+1 depends on the activation time of key N:
事件4：在某个时刻，必须考虑其继任者（关键N+1）。与将当前活动密钥引入区域一样，后续密钥需要在激活前至少发布Ipub。密钥N+1的发布时间取决于密钥N的激活时间：
Tpub(N+1) <= Tact(N) + Lzsk - Ipub
Tpub(N+1) <= Tact(N) + Lzsk - Ipub
Here, Lzsk is the length of time for which a ZSK will be used (the ZSK lifetime). It should be noted that in the diagrams, the actual key lifetime is represented; this may differ slightly from the intended lifetime set by key management policy.
这里，Lzsk是使用ZSK的时间长度（ZSK寿命）。应该注意的是，在图中表示了实际的密钥寿命；这可能与密钥管理策略设置的预期生存期略有不同。
Event 5: While key N is still active, its successor becomes ready. From this time onwards, key N+1 could be used to sign the zone.
事件5：当密钥N仍处于活动状态时，其后续密钥将准备就绪。从此时起，可使用N+1键对区域进行签名。
Event 6: When key N has been in use for an interval equal to the ZSK lifetime, it is retired (i.e., it will never again be used to generate new signatures) and key N+1 activated and used to sign the zone. This is the retire time of key N (Tret), and is given by:
事件6：当密钥N的使用时间间隔等于ZSK生存期时，它将失效（即，它将不再用于生成新签名），并且密钥N+1将被激活并用于对区域进行签名。这是密钥N（Tret）的失效时间，由下式给出：
Tret(N) = Tact(N) + Lzsk
Tret(N) = Tact(N) + Lzsk
It is also the activation time of the successor key N+1. Note that operational considerations may cause key N to remain in use for a longer (or shorter) time than the lifetime set by the key management policy.
它也是后继密钥N+1的激活时间。请注意，操作方面的考虑可能会导致密钥N的使用时间比密钥管理策略设置的生存期更长（或更短）。
Event 7: The retired key needs to be retained in the zone whilst any RRSIG records created using this key are still published in the zone or held in caches. (It is possible that a validating resolver could have an old RRSIG record in the cache, but the old DNSKEY RRset has expired when it is asked to provide both to a client. In this case the DNSKEY RRset would need to be looked up again.) This means that once the key is no longer used to sign records, it should be retained in the zone for at least the retire interval (Iret) given by:
事件7：当使用此密钥创建的任何RRSIG记录仍在区域中发布或保存在缓存中时，失效密钥需要保留在区域中。（验证解析程序可能在缓存中有一条旧的RRSIG记录，但当要求旧的DNSKEY RRset向客户端提供这两条记录时，该记录已过期。在这种情况下，需要再次查找DNSKEY RRset。）这意味着一旦不再使用密钥对记录进行签名，应将其保留在区域中至少达到以下规定的失效间隔（Iret）：
Iret = Dsgn + Dprp + TTLsig
Iret = Dsgn + Dprp + TTLsig
Dsgn is the delay needed to ensure that all existing RRsets have been re-signed with the new key. Dprp is the propagation delay, required to guarantee that the updated zone information has reached all slave servers, and TTLsig is the maximum TTL of all the RRSIG records in the zone created with the retiring key.
Dsgn是确保所有现有RRSET已使用新密钥重新签名所需的延迟。Dprp是传播延迟，需要确保更新的区域信息已到达所有从属服务器，TTLsig是使用退休密钥创建的区域中所有RRSIG记录的最大TTL。
The time at which all RRSIG records created with this key have expired from resolver caches is the dead time (Tdea), given by:
使用此密钥创建的所有RRSIG记录从冲突解决程序缓存中过期的时间是死区时间（Tdea），由以下公式给出：
Tdea(N) = Tret(N) + Iret
Tdea(N) = Tret(N) + Iret
... at which point the key is said to be dead.
... 在这一点上，钥匙被认为是死的。
Event 8: At any time after the key becomes dead, it can be removed from the zone's DNSKEY RRset, which must then be re-signed with the current KSK. This time is the removal time (Trem), given by:
事件8：在密钥失效后的任何时候，都可以将其从区域的DNSKEY RRset中删除，然后必须使用当前KSK重新签名。该时间为拆除时间（Trem），由以下公式得出：
Trem(N) >= Tdea(N)
Trem(N) >= Tdea(N)
... at which time the key is said to be removed.
... 此时，据说钥匙已被取下。
In this rollover, a new key is introduced and used to sign the zone; the old key and signatures are retained. Once all cached DNSKEY and/ or RRSIG information contains copies of the new DNSKEY and RRSIGs created with it, the old DNSKEY and RRSIGs can be removed from the zone.
在这个滚动中，引入了一个新的密钥并用于对区域进行签名；旧密钥和签名将被保留。一旦所有缓存的DNSKEY和/或RRSIG信息包含用其创建的新DNSKEY和RRSIG的副本，则可以从区域中删除旧的DNSKEY和RRSIG。
The timeline for a Double-Signature rollover is shown below. The diagram follows the convention described in Section 3.2.1.
双重签名滚动的时间表如下所示。该图遵循第3.2.1节所述惯例。
|1| |2| |3| |4|
| | | |
Key N |<-------Lzsk----------->|<--->|
| | | |
| |<--Iret-->| |
| | | |
Key N+1 | |<----Lzsk------- - -
| | | |
Key N Tact Tdea Trem
Key N+1 Tact
|1| |2| |3| |4|
| | | |
Key N |<-------Lzsk----------->|<--->|
| | | |
| |<--Iret-->| |
| | | |
Key N+1 | |<----Lzsk------- - -
| | | |
Key N Tact Tdea Trem
Key N+1 Tact
---- Time ---->
---- Time ---->
Figure 2: Timeline for a Double-Signature ZSK Rollover
图2：双重签名ZSK展期时间表
Event 1: Key N is added to the DNSKEY RRset and is then used to sign the zone; existing signatures in the zone are not removed. The key is published and active: this is key N's activation time (Tact), after which the key is said to be active.
事件1：密钥N添加到DNSKEY RRset，然后用于对区域进行签名；不会删除区域中的现有签名。密钥已发布并处于激活状态：这是密钥N的激活时间（Tact），在此之后，该密钥被称为处于激活状态。
Event 2: As the current key (key N) approaches the end of its actual lifetime (Lzsk), the successor key (key N+1) is introduced into the zone and starts being used to sign RRsets: neither the current key nor the signatures created with it are removed. The successor key is now also active.
事件2：当当前密钥（密钥N）接近其实际生存期（Lzsk）结束时，后续密钥（密钥N+1）被引入区域并开始用于对RRSET进行签名：当前密钥和使用其创建的签名都不会被删除。后继密钥现在也处于活动状态。
Tact(N+1) = Tact(N) + Lzsk - Iret
Tact(N+1) = Tact(N) + Lzsk - Iret
Event 3: Before key N can be withdrawn from the zone, all RRsets that need to be signed must have been signed by the successor key (key N+1) and any old RRsets that do not include the new key or new RRSIGs must have expired from caches. Note that the signatures are not replaced: each RRset is signed by both the old and new key.
事件3：在密钥N可以从区域中取出之前，所有需要签名的RRSET必须已由后续密钥（密钥N+1）签名，并且任何不包括新密钥或新RRSIG的旧RRSET必须已从缓存中过期。请注意，签名不会被替换：每个RRset都由新旧密钥签名。
This takes Iret, the retire interval, given by the expression:
这将采用Iret，即失效间隔，由以下表达式给出：
Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
As before, Dsgn is the delay needed to ensure that all existing RRsets have been signed with the new key and Dprp is the propagation delay, required to guarantee that the updated zone information has reached all slave servers. The final term (the maximum of TTLkey and TTLsig) is the period to wait for key and signature data associated with key N to expire from caches. (TTLkey is the TTL of the DNSKEY RRset and TTLsig is the maximum TTL of all the RRSIG records in the zone created with the ZSK. The two may be different: although the
如前所述，Dsgn是确保所有现有RRSET已使用新密钥签名所需的延迟，Dprp是传播延迟，是确保更新的区域信息已到达所有从属服务器所需的延迟。最后一项（TTLkey和TTLsig的最大值）是等待与密钥N相关联的密钥和签名数据从缓存中过期的时间。（TTLkey是DNSKEY RRset的TTL，TTLsig是使用ZSK创建的分区中所有RRSIG记录的最大TTL。两者可能不同：虽然
TTL of an RRSIG is equal to the TTL of the RRs in the associated RRset [RFC4034], the DNSKEY RRset only needs to be signed with the KSK.)
RRSIG的TTL等于相关RRset[RFC4034]中RRs的TTL，DNSKEY RRset只需与KSK签名。）
At the end of this interval, key N is said to be dead. This occurs at the dead time (Tdea) so:
在这段时间间隔结束时，据说键N已失效。这发生在死区时间（Tdea），因此：
Tdea(N) = Tact(N+1) + Iret
Tdea(N) = Tact(N+1) + Iret
Event 4: At some later time, key N and the signatures generated with it can be removed from the zone. This is the removal time (Trem), given by:
事件4：稍后，可以从区域中删除密钥N及其生成的签名。这是拆除时间（Trem），由以下公式得出：
Trem(N) >= Tdea(N)
Trem(N) >= Tdea(N)
The following sections describe the rolling of a KSK. They show the events in the lifetime of a key (referred to as "key N") and cover it replacement by its successor (key N+1). (The case of introducing the first KSK into the zone is discussed in Section 3.3.5.)
以下各节介绍了KSK的轧制。它们显示密钥（称为“密钥N”）生命周期内的事件，并涵盖其后续密钥（密钥N+1）的替换。（第3.3.5节讨论了将第一个KSK引入该区域的情况。）
In this rollover, the new DNSKEY is added to the zone. After an interval long enough to guarantee that any cached DNSKEY RRsets contain the new DNSKEY, the DS record in the parent zone is changed. After a further interval to allow the old DS record to expire from caches, the old DNSKEY is removed from the zone.
在此滚动中，新的DNSKEY将添加到分区中。在足够长的时间间隔以保证任何缓存的DNSKEY RRSET包含新的DNSKEY后，父区域中的DS记录将更改。再过一段时间允许旧DS记录从缓存中过期后，旧DNSKEY将从区域中删除。
The timeline for a Double-KSK rollover is shown below. The diagram follows the convention described in Section 3.2.1.
双KSK滚动的时间表如下所示。该图遵循第3.2.1节所述惯例。
|1| |2| |3| |4|
| | | |
Key N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
| | | |
Key N+1 | | | |
| | | |
Key N Tpub Trdy Tsbm Tact
Key N+1
|1| |2| |3| |4|
| | | |
Key N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
| | | |
Key N+1 | | | |
| | | |
Key N Tpub Trdy Tsbm Tact
Key N+1
---- Time ---->
---- Time ---->
(continued ...)
（续……）
|5| |6| |7| |8| |9| |10|
| | | | | |
Key N - - --------------Lksk------->|<-Iret->|<----->|
| | | | | |
Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsbm Tact
|5| |6| |7| |8| |9| |10|
| | | | | |
Key N - - --------------Lksk------->|<-Iret->|<----->|
| | | | | |
Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsbm Tact
---- Time (cont.) ---->
---- Time (cont.) ---->
Figure 3: Timeline for a Double-KSK Rollover
图3：双KSK滚动的时间线
Event 1: Key N is introduced into the zone; it is added to the DNSKEY RRset, which is then signed by all currently active KSKs. (So at this point, the DNSKEY RRset is signed by both key N and its predecessor KSK. If other KSKs were active, it is signed by these as well.) This is the publication time of key N (Tpub); after this, the key is said to be published.
事件1：将N键引入区域；它被添加到DNSKEY RRset，然后由所有当前活动的KSK签名。（因此，此时，DNSKEY RRset由密钥N及其前一个KSK签名。如果其他KSK处于活动状态，则也由它们签名。）这是密钥N的发布时间（Tpub）；在这之后，据说密钥将被发布。
Event 2: Before it can be used, the key must be published for long enough to guarantee that any validating resolver that has a copy of the DNSKEY RRset in its cache will have a copy of the RRset that includes this key: in other words, that any prior cached information about the DNSKEY RRset has expired.
事件2：在可以使用密钥之前，必须发布密钥足够长的时间，以确保任何在其缓存中具有DNSKEY RRset副本的验证解析程序都将具有包含此密钥的RRset副本：换句话说，有关DNSKEY RRset的任何先前缓存信息都已过期。
The interval is the publication interval in the child zone (IpubC) and is given by:
间隔是子区域（IpubC）中的发布间隔，由以下公式给出：
IpubC = DprpC + TTLkey
IpubC=DprpC+TTLkey
... where DprpC is the propagation delay for the child zone (the zone containing the KSK being rolled) and TTLkey the TTL for the DNSKEY RRset. The time at which this occurs is the key N's ready time, Trdy, given by:
... 其中，DprpC是子区域（包含正在滚动的KSK的区域）的传播延迟，TTLkey是DNSKEY RRset的TTL。发生这种情况的时间是键N的准备时间Trdy，由以下公式给出：
Trdy(N) = Tpub(N) + IpubC
Trdy(N) = Tpub(N) + IpubC
Event 3: At some later time, the DS record corresponding to the new KSK is submitted to the parent zone for publication. This time is the submission time, Tsbm:
事件3：稍后，与新KSK对应的DS记录将提交给父区域以供发布。此时间为提交时间，Tsbm:
Tsbm(N) >= Trdy(N)
Tsbm(N) >= Trdy(N)
Event 4: The DS record is published in the parent zone. As this is the point at which all information for authentication -- both DNSKEY and DS record -- is available in the two zones, in analogy with other rollover methods, this is called the activation time of key N (Tact):
事件4：DS记录在父区域中发布。由于这是两个区域中所有身份验证信息（DNSKEY和DS记录）可用的点，与其他滚动方法类似，这称为密钥N的激活时间（Tact）：
Tact(N) = Tsbm(N) + Dreg
Tact(N) = Tsbm(N) + Dreg
... where Dreg is the registration delay, the time taken after the DS record has been submitted to the parent zone manager for it to be placed in the zone. (Parent zones are often managed by different entities, and this term accounts for the organizational overhead of transferring a record. In practice, Dreg will not be a fixed time: instead, the end of Dreg will be signaled by the appearance of the DS record in the parent zone.)
... 如果Dreg是注册延迟，则是DS记录提交给父区域管理器后放置在区域中所用的时间。（父区域通常由不同的实体管理，这一术语解释了传输记录的组织开销。实际上，Dreg不是固定时间：相反，Dreg的结束将由父区域中DS记录的出现来表示。）
Event 5: While key N is active, thought needs to be given to its successor (key N+1). At some time before the scheduled end of the KSK lifetime, the successor KSK is published in the zone. (As before, this means that the DNSKEY RRset is signed by all KSKs.) This time is the publication time of the successor key N+1, given by:
事件5：当N键处于活动状态时，需要考虑其后续键（N+1键）。在KSK生命周期计划结束之前的某个时间，将在区域中发布后续KSK。（与之前一样，这意味着DNSKEY RRset由所有KSK签名。）这一时间是后续密钥N+1的发布时间，由以下公式给出：
Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC
Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC
... where Lksk is the actual lifetime of the KSK, and Dreg the registration delay.
... 其中Lksk是KSK的实际生存期，Dreg是注册延迟。
Event 6: After an interval IpubC, key N+1 becomes ready (in that all caches that have a copy of the DNSKEY RRset have a copy of this key). This time is the ready time of the successor key N+1 (Trdy).
事件6：间隔IpubC后，密钥N+1变为就绪（即所有具有DNSKEY RRset副本的缓存都具有该密钥的副本）。此时间是后继密钥N+1（Trdy）的准备时间。
Event 7: At the submission time of the successor key N+1, Tsbm(N+1), the DS record corresponding to key N+1 is submitted to the parent zone.
事件7：在后续密钥N+1、Tsbm（N+1）提交时，与密钥N+1对应的DS记录被提交到父区域。
Event 8: The successor DS record is published in the parent zone and the current DS record withdrawn. Key N is said to be retired and the time at which this occurs is Tret(N), given by:
事件8：后续DS记录在父区域中发布，当前DS记录被撤回。密钥N被称为失效，发生该情况的时间为Tret（N），由下式给出：
Tret(N) = Tsbm(N+1) + Dreg
Tret(N) = Tsbm(N+1) + Dreg
Event 9: Key N must remain in the zone until any caches that contain a copy of the DS RRset have a copy containing the new DS record. This interval is the retire interval, given by:
事件9：在包含DS RRset副本的任何缓存具有包含新DS记录的副本之前，密钥N必须保留在区域中。该时间间隔是失效时间间隔，由以下公式给出：
Iret = DprpP + TTLds
Iret=DprpP+TTLds
... where DprpP is the propagation delay in the parent zone and TTLds the TTL of a DS record in the parent zone.
... 其中，DprpP是父区域中的传播延迟，TTLds是父区域中DS记录的TTL。
As the key is no longer used for anything, it is said to be dead. This point is the dead time (Tdea), given by:
由于钥匙不再用于任何用途，所以据说它已经死了。该点为死区时间（Tdea），由下式给出：
Tdea(N) = Tret(N) + Iret
Tdea(N) = Tret(N) + Iret
Event 10: At some later time, key N is removed from the zone's DNSKEY RRset (at the remove time Trem); the key is now said to be removed.
事件10：在稍后的某个时间，从区域的DNSKEY RRset中删除键N（在删除时间Trem）；据说钥匙现在被取下了。
Trem(N) >= Tdea(N)
Trem(N) >= Tdea(N)
In this rollover, the new DS record is published in the parent zone. When any caches that contain the DS RRset contain a copy of the new record, the KSK in the zone is changed. After a further interval for the old DNSKEY RRset to expire from caches, the old DS record is removed from the parent.
在此滚动中，新DS记录将在父区域中发布。当包含DS RRset的任何缓存包含新记录的副本时，区域中的KSK将更改。在旧DNSKEY RRset从缓存中过期的另一个时间间隔后，旧DS记录将从父记录中删除。
The timeline for a Double-DS rollover is shown below. The diagram follows the convention described in Section 3.2.1.
双DS滚动的时间表如下所示。该图遵循第3.2.1节所述惯例。
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - -
| | | | |
Key N+1 | | | | |<--Dreg-- - -
| | | | |
Key N Tsbm Tpub Trdy Tact
Key N+1 Tsbm
---- Time ---->
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - -
| | | | |
Key N+1 | | | | |<--Dreg-- - -
| | | | |
Key N Tsbm Tpub Trdy Tact
Key N+1 Tsbm
---- Time ---->
(continued ...)
（续……）
|6| |7| |8| |9| |10|
| | | | |
Key N - ----------Lksk--------->|<-Iret->|<---->|
| | | | |
Key N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - -
| | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact
|6| |7| |8| |9| |10|
| | | | |
Key N - ----------Lksk--------->|<-Iret->|<---->|
| | | | |
Key N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - -
| | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->
---- Time ---->
Figure 4: Timeline for a Double-DS KSK Rollover
图4：双DS KSK滚动的时间线
Event 1: The DS RR is submitted to the parent zone for publication. This time is the submission time, Tsbm.
事件1：DS RR被提交到父区域以供发布。这次是提交时间，Tsbm。
Event 2: After the registration delay, Dreg, the DS record is published in the parent zone. This is the publication time (Tpub) of key N, given by:
事件2：在注册延迟Dreg之后，DS记录在父区域中发布。这是密钥N的发布时间（Tpub），由以下公式给出：
Tpub(N) = Tsbm(N) + Dreg
Tpub(N) = Tsbm(N) + Dreg
As before, in practice, Dreg will not be a fixed time. Instead, the end of Dreg will be signaled by the appearance of the DS record in the parent zone.
和以前一样，在实践中，渣滓不会是固定的时间。相反，Dreg的结束将由父区域中DS记录的出现发出信号。
Event 3: At some later time, any cache that has a copy of the DS RRset will have a copy of the DS record for key N. At this point, key N, if introduced into the DNSKEY RRset, could be used to validate the zone. For this reason, this time is known as the ready time, Trdy, and is given by:
事件3：稍后，任何具有DS RRset副本的缓存都将具有密钥N的DS记录副本。此时，密钥N（如果引入DNSKEY RRset）可用于验证区域。因此，该时间称为准备时间Trdy，由以下公式给出：
Trdy(N) = Tpub(N) + IpubP
Trdy(N) = Tpub(N) + IpubP
IpubP is the publication interval of the DS record (in the parent zone) and is given by the expression:
IpubP是DS记录（在父区域中）的发布间隔，由以下表达式给出：
IpubP = DprpP + TTLds
IpubP=DprpP+TTLds
... where DprpP is the propagation delay for the parent zone and TTLds the TTL assigned to DS records in that zone.
... 其中，DprpP是父区域的传播延迟，TTLds是分配给该区域中DS记录的TTL。
Event 4: At some later time, the key rollover takes place and the new key (key N) is introduced into the DNSKEY RRset and used to sign it. This time is key N's activation time (Tact) and at this point key N is said to be active:
事件4：稍后会发生密钥翻转，新密钥（密钥N）被引入DNSKEY RRset并用于签名。此时为按键N的激活时间（Tact），此时称按键N处于激活状态：
Tact(N) >= Trdy(N)
Tact(N) >= Trdy(N)
Event 5: At some point, thought must be given to key replacement. The DS record for the successor key must be submitted to the parent zone at a time such that when the current key is withdrawn, any cache that contains the zone's DS records has data about the DS record of the successor key. The time at which this occurs is the submission time of the successor key N+1, given by:
事件5：在某个时候，必须考虑更换钥匙。后续密钥的DS记录必须提交到父区域，以便在提取当前密钥时，包含该区域DS记录的任何缓存都具有关于后续密钥DS记录的数据。发生这种情况的时间是后继密钥N+1的提交时间，由以下公式给出：
Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg
Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg
... where Lksk is the actual lifetime of key N (which may differ slightly from the lifetime set in the key management policy) and Dreg is the registration delay.
... 其中，Lksk是密钥N的实际生存期（可能与密钥管理策略中设置的生存期略有不同），Dreg是注册延迟。
Event 6. After an interval Dreg, the successor DS record is published in the zone.
事件6。间隔转储后，后续DS记录将在区域中发布。
Event 7: The successor key (key N+1) enters the ready state, i.e., its DS record is now in caches that contain the parent DS RRset.
事件7：后续密钥（密钥N+1）进入就绪状态，即其DS记录现在位于包含父DS RRset的缓存中。
Event 8: When key N has been active for its lifetime (Lksk), it is replaced in the DNSKEY RRset by key N+1; the RRset is then signed with the new key. At this point, as both the old and new DS records have been in the parent zone long enough to ensure that they are in caches that contain the DS RRset, the zone can be authenticated throughout the rollover. A validating resolver can authenticate either the old or new KSK.
事件8：当密钥N在其生命周期（Lksk）内处于活动状态时，它在DNSKEY RRset中被密钥N+1替换；然后使用新密钥对RRset进行签名。此时，由于旧DS记录和新DS记录在父区域中的时间都足够长，以确保它们位于包含DS RRset的缓存中，因此可以在整个滚动期间对该区域进行身份验证。验证解析器可以对旧的或新的KSK进行身份验证。
This time is the retire time (Tret) of key N, given by:
该时间是密钥N的失效时间（Tret），由以下公式给出：
Tret(N) = Tact(N) + Lksk
Tret(N) = Tact(N) + Lksk
This is also the activation time of the successor key N+1.
这也是后继密钥N+1的激活时间。
Event 9: At some later time, all copies of the old DNSKEY RRset have expired from caches and the old DS record is no longer needed. In analogy with other rollover methods, this is called the dead time, Tdea, and is given by:
事件9：稍后，旧DNSKEY RRset的所有副本都已从缓存中过期，不再需要旧DS记录。与其他翻滚方法类似，这称为停滞时间Tdea，由下式给出：
Tdea(N) = Tret(N) + Iret
Tdea(N) = Tret(N) + Iret
... where Iret is the retire interval of the key, given by:
... 其中Iret是密钥的失效间隔，由以下公式给出：
Iret = DprpC + TTLkey
Iret=DprpC+TTLkey
As before, this term includes DprpC, the time taken to propagate the RRset change through the master-slave hierarchy of the child zone and TTLkey, the time taken for the DNSKEY RRset to expire from caches.
如前所述，该术语包括DprpC（通过子区域的主从层次结构传播RRset更改所需的时间）和TTLkey（DNSKEY RRset从缓存过期所需的时间）。
Event 10: At some later time, the DS record is removed from the parent zone. In analogy with other rollover methods, this is the removal time (Trem), given by:
事件10：稍后，DS记录将从父区域中删除。与其他翻车方法类似，这是拆除时间（Trem），由下式给出：
Trem(N) >= Tdea(N)
Trem(N) >= Tdea(N)
In the Double-RRset rollover, the new DNSKEY and DS records are published simultaneously in the appropriate zones. Once enough time has elapsed for the old DNSKEY and DS RRsets to expire from caches, the old DNSKEY and DS records are removed from their respective zones.
在双RRset滚动更新中，新的DNSKEY和DS记录同时发布在适当的区域中。一旦经过足够的时间使旧DNSKEY和DS RRSET从缓存中过期，旧DNSKEY和DS记录将从各自的区域中删除。
The timeline for this rollover is shown below. The diagram follows the convention described in Section 3.2.1.
此滚动的时间线如下所示。该图遵循第3.2.1节所述惯例。
|1| |2| |3| |4| |5|
| | | | |
Key N |<-----------Lksk---------->|<---->|
| | | | |
| |<------Ipub----->| |
| | | | |
| |<-Dreg->|<-Iret->| |
| | | | |
Key N+1 | | |<----Lksk-------- - -
| | | | |
Key N Tact Tret Tdea Trem
Key N+1 Tpub Tact
|1| |2| |3| |4| |5|
| | | | |
Key N |<-----------Lksk---------->|<---->|
| | | | |
| |<------Ipub----->| |
| | | | |
| |<-Dreg->|<-Iret->| |
| | | | |
Key N+1 | | |<----Lksk-------- - -
| | | | |
Key N Tact Tret Tdea Trem
Key N+1 Tpub Tact
---- Time ---->
---- Time ---->
Figure 5: Timeline for a Double-RRset KSK Rollover
图5：双RRset KSK滚动的时间线
Event 1: The DS and DNSKEY records have appeared in their respective zones and the latter has been used to sign the DNSKEY RRset. The key is published and active: this is key N's activation time (Tact).
事件1：DS和DNSKEY记录已出现在各自的区域中，后者已用于签署DNSKEY RRset。密钥已发布并激活：这是密钥N的激活时间（Tact）。
Event 2: As the current key (key N) approaches the end of its actual lifetime (Lksk), the successor key (key N+1) is introduced into the zone and is used to sign the DNSKEY RRset. At the same time, the successor DS record is submitted to the parent zone. This is the publication time of the successor key (Tpub):
事件2：当当前密钥（密钥N）接近其实际生存期（Lksk）结束时，后继密钥（密钥N+1）被引入区域并用于对DNSKEY RRset进行签名。同时，后续DS记录将提交到父区域。这是后续密钥（Tpub）的发布时间：
Tpub(N+1) <= Tact(N) + Lksk - Ipub
Tpub(N+1) <= Tact(N) + Lksk - Ipub
... where Ipub is defined below.
... 其中Ipub的定义如下。
Event 3: After the registration delay (Dreg), the DS record appears in the parent zone. The DNSKEY record is already in the child zone, so with both the new key and its associated data now visible, this is the key's activation time (Tact) and the key is now said to be active.
事件3：注册延迟（Dreg）后，DS记录出现在父区域中。DNSKEY记录已经在子区域中，因此新密钥及其关联数据现在都可见，这是密钥的激活时间（Tact），现在称密钥为活动密钥。
Tact(N+1) = Tpub(N+1) + Dreg
Tact(N+1) = Tpub(N+1) + Dreg
Event 4: Before key N and its associated data can be withdrawn, all RRsets in the caches of validating resolvers must contain the new DS and/or DNSKEY. The time at which this occurs is the dead time of key N (Tdea), given by:
事件4：在提取密钥N及其相关数据之前，验证解析程序缓存中的所有RRSET必须包含新的DS和/或DNSKEY。发生这种情况的时间是键N（Tdea）的死区时间，由下式给出：
Tdea(N) = Tpub(N+1) + Ipub
Tdea(N) = Tpub(N+1) + Ipub
Ipub is the time it takes to guarantee that any prior cached information about the DNSKEY and the DS RRsets have expired. For the DNSKEY, this is the publication interval of the child (IpubC). For the DS, the publication interval (IpubP) starts once the record appears in the parent zone, which is Dreg after it has been submitted. Hence:
Ipub是保证有关DNSKEY和DS RRSET的任何先前缓存信息已过期所需的时间。对于DNSKEY，这是子项的发布间隔（IpubC）。对于DS，一旦记录出现在父区域中，发布间隔（IpubP）就会开始，而父区域在提交后会被丢弃。因此：
Ipub = max(Dreg + IpubP, IpubC)
Ipub = max(Dreg + IpubP, IpubC)
The parent zone's publication interval is given by:
父区域的发布间隔由以下公式给出：
IpubP = DprpP + TTLds
IpubP=DprpP+TTLds
where DprpP is the parent zone's propagation delay and TTLds is the TTL of the DS record in that zone.
其中，DprpP是父区域的传播延迟，TTLds是该区域中DS记录的TTL。
The child zone's publication interval is given by a similar equation:
子区域的发布间隔由一个类似的等式给出：
IpubC = DprpC + TTLkey
IpubC=DprpC+TTLkey
where DprpC is the propagation delay in the child zone and TTLkey the TTL of a DNSKEY record.
其中，DprpC是子区域中的传播延迟，TTLkey是DNSKEY记录的TTL。
In analogy with other rollovers, we can also define a retire interval -- the interval between a key becoming active and the time at which its predecessor is considered dead. In this case, Iret is given by:
与其他翻滚类似，我们还可以定义一个失效间隔——一个键变为活动状态和它的前一个键被认为已失效的时间之间的间隔。在这种情况下，Iret由以下公式给出：
Iret = Ipub - Dreg
Iret = Ipub - Dreg
In other words, the retire interval of the predecessor key is the greater of the publication interval of the parent, or the publication interval of the child minus the registration delay.
换句话说，前置键的失效间隔是父项的发布间隔或子项的发布间隔减去注册延迟的较大值。
Event 5: At some later time, the key N's DS and DNSKEY records are removed from their respective zones. In analogy with other rollover methods, this is the removal time (Trem), given by:
事件5：稍后，密钥N的DS和DNSKEY记录将从各自的区域中删除。与其他翻车方法类似，这是拆除时间（Trem），由下式给出：
Trem(N) >= Tdea(N)
Trem(N) >= Tdea(N)
Although the preceding sections have been concerned with rolling KSKs, where the trust anchor is a DS record in the parent zone, zone managers may want to take account of the possibility that some validating resolvers may have configured trust anchors directly.
尽管前面的部分涉及滚动KSK，其中信任锚是父区域中的DS记录，但区域管理员可能希望考虑一些验证解析程序可能直接配置了信任锚的可能性。
Rolling a configured trust anchor is dealt with in [RFC5011]. It requires introducing the KSK to be used as the trust anchor into the zone for a period of time before use and retaining it (with the "revoke" bit set) for some time after use.
[RFC5011]中介绍了滚动配置的信任锚点。它要求在使用前将用作信任锚的KSK引入区域一段时间，并在使用后将其保留一段时间（设置“撤销”位）。
When the new key is introduced, the expression for the publication interval of the DNSKEY (IpubC) in the Double-KSK and Double-RRset methods is modified to:
引入新密钥时，双KSK和双RRset方法中DNSKEY（IpubC）的发布间隔表达式修改为：
IpubC >= DprpC + max(Itrp, TTLkey)
IpubC >= DprpC + max(Itrp, TTLkey)
... where the right-hand side of the expression now includes the "trust point" interval. This term is the interval required to guarantee that a resolver configured for the automatic update of keys according to [RFC5011] will accept the new key as a new trust point. That interval is given by:
... 其中表达式的右侧现在包括“信任点”间隔。该术语是保证根据[RFC5011]为密钥自动更新配置的解析器将接受新密钥作为新信任点所需的时间间隔。该间隔由以下公式给出：
Itrp >= queryInterval + AddHoldDownTime + queryInterval
Itrp >= queryInterval + AddHoldDownTime + queryInterval
... where queryInterval is as defined in Section 2.3 of [RFC5011] and AddHoldDownTime is the Add Hold-Down Time defined in Section 2.4.1 of the same document.
... 其中，queryInterval如[RFC5011]第2.3节所定义，AddHoldDownTime是同一文件第2.4.1节所定义的添加保留时间。
The first term of the expression (queryInterval) represents the time after which all validating resolvers can be guaranteed to have obtained a copy of the DNSKEY RRset containing the new key. Once retrieved, a validating resolver needs to wait for AddHoldDownTime. Providing it does not see a validly signed DNSKEY RRset without the new key in that period, it will treat it as a trust anchor the next time it retrieves the RRset, a process that can take up to another queryInterval (the third term).
表达式的第一项（queryInterval）表示可以保证所有验证解析器获得包含新密钥的DNSKEY RRset副本的时间。检索后，验证解析程序需要等待AddHoldDownTime。如果在此期间未看到没有新密钥的有效签名DNSKEY RRset，则在下次检索RRset时将其视为信任锚，该过程可能会占用另一个queryInterval（第三个术语）。
However, the expression for queryInterval given in [RFC5011] contains the DNSKEY's RRSIG expiration interval, a parameter that only the validating resolver can really calculate. In practice, a modified query interval that depends only on TTLkey can be used:
但是，[RFC5011]中给出的queryInterval表达式包含DNSKEY的RRSIG过期时间间隔，这是一个只有验证解析器才能真正计算的参数。实际上，可以使用仅依赖于TTLkey的修改后的查询间隔：
modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
(This is obtained by taking the expression for queryInterval in [RFC5011] and assuming a worst case for RRsigExpirationInterval. It is greater than or equal to queryInterval for all values of the expiration time.) The expression above then becomes (after collecting terms):
（这是通过采用[RFC5011]中queryInterval的表达式并假设RRSIGFirationInterval的最坏情况来获得的。对于过期时间的所有值，它都大于或等于queryInterval。）然后，上述表达式变为（在收集术语之后）：
Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval
Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval
In the Double-DS method, instead of swapping the KSK RRs in a single step, there must now be a period of overlap. In other words, the new KSK must be introduced into the zone at least:
在双DS方法中，现在必须有一段重叠时间，而不是在一个步骤中交换KSK RRs。换句话说，新的KSK必须至少引入区域：
DprpC + max(Itrp, TTLkey)
DprpC+max（Itrp、TTLkey）
... before the switch is made.
... 在切换之前。
The timeline for the removal of the key in all methods is modified by introducing a new state, "revoked". When the key reaches its dead time, instead of being declared "dead", it is revoked; the "revoke" bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed with the current and revoked keys. The key is maintained in this state for the revoke interval, Irev, given by:
在所有方法中删除密钥的时间线都会通过引入一个新状态“已撤销”进行修改。当密钥到达其失效时间时，它将被撤销，而不是被宣布为“失效”；在已发布的DNSKEY RR中设置“revoke”位，并使用当前密钥和已撤销密钥对DNSKEY RRset重新签名。密钥在撤销间隔Irev内保持在此状态，由以下公式给出：
Irev >= DprpC + modifiedQueryInterval
Irev >= DprpC + modifiedQueryInterval
As before, DprpC is the time taken for the revoked DNSKEY to propagate to all slave zones, and modifiedQueryInterval is the time after which it can be guaranteed that all validating resolvers that adhere to RFC 5011 have retrieved a copy of the DNSKEY RRset containing the revoked key.
与前面一样，DprpC是已撤销的DNSKEY传播到所有从属区域所用的时间，modifiedQueryInterval是可以保证遵守RFC 5011的所有验证解析程序已检索到包含已撤销密钥的DNSKEY RRset副本的时间。
After this time, the key is dead and can be removed from the zone.
在此时间之后，密钥将失效，可以从区域中移除。
There are no timing considerations associated with the introduction of the first keys into a zone other that they must be introduced and the zone validly signed before a chain of trust to the zone is created.
将第一个密钥引入区域没有时间方面的考虑，但在创建对区域的信任链之前，必须引入第一个密钥并对区域进行有效签名。
In the case of a secure parent, it means ensuring that the DS record is not published in the parent zone until there is no possibility that a validating resolver can obtain the record yet is not able to obtain the corresponding DNSKEY. In the case of an insecure parent, i.e., the initial creation of a chain of trust or "security apex", it is not possible to guarantee this. It is up to the operator of the validating resolver to wait for the new KSK to appear at all servers for the zone before configuring the trust anchor.
在安全父级的情况下，这意味着确保DS记录不会在父级区域中发布，直到验证解析程序不可能获取该记录但无法获取相应的DNSKEY。对于不安全的父母，即最初建立信任链或“安全顶点”，不可能保证这一点。在配置信任锚之前，由验证解析程序的操作员等待新KSK出现在区域的所有服务器上。
Although keys will usually be rolled according to some regular schedule, there may be occasions when an emergency rollover is required, e.g., if the active key is suspected of being compromised. The aim of the emergency rollover is to allow the zone to be re-signed with a new key as soon as possible. As a key must be in the ready state to sign the zone, having at least one additional key (a standby key) in this state at all times will minimize delay.
虽然钥匙通常会按照一些常规计划滚动，但有时可能需要紧急滚动，例如，如果怀疑活动钥匙被损坏。紧急翻滚的目的是允许尽快使用新钥匙重新签署区域。由于密钥必须处于就绪状态才能对区域进行签名，因此在任何时候至少有一个附加密钥（备用密钥）处于该状态都将最小化延迟。
In the case of a ZSK, a standby key only really makes sense with the Pre-Publication method. A permanent standby DNSKEY RR should be included in the zone or successor keys could be introduced as soon as
在ZSK的情况下，备用键只有在预发布方法中才有意义。区域中应包括永久备用DNSKEY RR，或尽快引入后续密钥
possible after a key becomes active. Either way results in one or more additional ZSKs in the DNSKEY RRset that can immediately be used to sign the zone if the current key is compromised.
可能在某个键激活后。任何一种方式都会在DNSKEY RRset中产生一个或多个额外的ZSK，如果当前密钥被泄露，可以立即使用这些ZSK对区域进行签名。
(Although, in theory, the mechanism could be used with both the Double-Signature and Double-RRSIG methods, it would require pre-publication of the signatures. Essentially, the standby key would be permanently active, as it would have to be periodically used to renew signatures. Zones would also permanently require two sets of signatures.)
（虽然从理论上讲，该机制可以与双重签名和双重RRSIG方法一起使用，但它需要预先发布签名。基本上，备用密钥将永久有效，因为它必须定期用于更新签名。区域也将永久需要两组签名。）
It is also possible to have a standby KSK. The Double-KSK method requires that the standby KSK be included in the DNSKEY RRset; rolling the key then requires just the introduction of the DS record in the parent. Note that the standby KSK should also be used to sign the DNSKEY RRset. As the RRset and its signatures travel together, merely adding the KSK without using it to sign the DNSKEY RRset does not provide the desired time saving: for a KSK to be used in a rollover, the DNSKEY RRset must be signed with it, and this would introduce a delay while the old RRset (not signed with the new key) expires from caches.
也可以有一个备用KSK。双KSK方法要求备用KSK包含在DNSKEY RRset中；然后，滚动键只需要在父级中引入DS记录。请注意，备用KSK还应用于签署DNSKEY RRset。由于RRset及其签名一起移动，仅添加KSK而不使用它对DNSKEY RRset进行签名并不能提供所需的时间节约：对于要在滚动中使用的KSK，必须使用它对DNSKEY RRset进行签名，这将在旧RRset（未使用新密钥签名）从缓存过期时引入延迟。
The idea of a standby KSK in the Double-RRset rollover method effectively means having two active keys (as the standby KSK and associated DS record would both be published at the same time in their respective zones).
在双RRset翻转方法中，备用KSK的概念实际上意味着拥有两个活动密钥（因为备用KSK和相关DS记录将在各自的区域中同时发布）。
Finally, in the Double-DS method of rolling a KSK, it is not a standby key that is present, it is a standby DS record in the parent zone.
最后，在滚动KSK的双DS方法中，存在的不是备用密钥，而是父区域中的备用DS记录。
Whatever algorithm is used, the standby item of data can be included in the zone on a permanent basis, or be a successor introduced as early as possible.
无论使用何种算法，备用数据项都可以永久性地包含在分区中，或者是尽早引入的后续数据项。
The preceding sections have implicitly assumed that all keys and signatures are created using a single algorithm. However, Section 2.2 of [RFC4035] requires that there be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
前面的部分已经隐含地假设所有密钥和签名都是使用单一算法创建的。但是，[RFC4035]第2.2节要求每个RRset都有一个RRSIG，使用区域顶点DNSKEY RRset中每个算法的至少一个DNSKEY。
Except in the case of an algorithm rollover -- where the algorithms used to create the signatures are being changed -- there is no relationship between the keys of different algorithms. This means that they can be rolled independently of one another. In other
除了在算法滚动的情况下——用于创建签名的算法正在更改——不同算法的键之间没有关系。这意味着它们可以彼此独立地滚动。换句话说
words, the key-rollover logic described above should be run separately for each algorithm; the union of the results is included in the zone, which is signed using the active key for each algorithm.
换句话说，上述键翻转逻辑应针对每个算法单独运行；结果的并集包含在区域中，该区域使用每个算法的活动密钥进行签名。
For ZSKs, the Pre-Publication method is generally considered to be the preferred way of rolling keys. As shown in this document, the time taken to roll is wholly dependent on parameters under the control of the zone manager.
对于ZSK，预发布方法通常被认为是滚动键的首选方式。如本文件所示，滚动所需的时间完全取决于区域管理器控制下的参数。
In contrast, the Double-RRset method is the most efficient for KSK rollover due to the ability to have new DS records and DNSKEY RRsets propagate in parallel. The time taken to roll KSKs may depend on factors related to the parent zone if the parent is signed. For zones that intend to comply with the recommendations of [RFC5011], in many cases, the rollover time will be determined by the times defined by RFC 5011. It should be emphasized that this delay is a policy choice and not a function of timing values and that it also requires changes to the rollover process due to the need to manage revocation of trust anchors.
相比之下，双RRset方法对于KSK滚动最有效，因为它能够并行传播新的DS记录和DNSKEY RRset。滚动KSK所需的时间可能取决于与父区域相关的因素（如果父区域已签名）。对于打算遵守[RFC5011]建议的区域，在许多情况下，滚动时间将由RFC 5011规定的时间确定。应该强调的是，这种延迟是一种策略选择，而不是时间值的函数，并且由于需要管理信任锚的撤销，它还需要更改滚动过程。
Finally, the treatment of emergency key rollover is significantly simplified by the introduction of standby keys as standard practice during all types of rollovers.
最后，通过在所有类型的翻车过程中引入备用钥匙作为标准实践，可以显著简化紧急钥匙翻车的处理。
This document does not introduce any new security issues beyond those already discussed in [RFC4033], [RFC4034], [RFC4035], and [RFC5011].
除[RFC4033]、[RFC4034]、[RFC4035]和[RFC5011]中已经讨论的安全问题外，本文档不会引入任何新的安全问题。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 5011，DOI 10.17487/RFC5011，2007年9月<http://www.rfc-editor.org/info/rfc5011>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，DOI 10.17487/RFC6781，2012年12月<http://www.rfc-editor.org/info/rfc6781>.
The document defines a number of symbols, all of which are listed here. All are of the form:
该文档定义了许多符号，所有符号都列在此处。所有文件的格式如下：
<TYPE><id><ZONE>
<TYPE><id><ZONE>
where:
哪里：
<TYPE> is an uppercase character indicating what type the symbol is. Defined types are:
<TYPE>是一个大写字符，指示符号的类型。定义的类型包括：
D delay: interval that is a feature of the process
D延迟：是进程特征的时间间隔
I interval between two events
我知道两件事之间的间隔时间
L lifetime: interval set by the zone manager
L生存期：由区域管理器设置的间隔
T a point in time
这不是一个时间点
TTL TTL of a record
TTL记录的TTL
I, T, and TTL are self-explanatory. Like I, both D and L are time periods, but whereas I values are intervals between two events, a "D" interval (delay) is a feature of the process, probably outside control of the zone manager, and an "L" interval (lifetime) is chosen by the zone manager and is a feature of policy.
一、 T和TTL是不言自明的。与I一样，D和L都是时间段，但I值是两个事件之间的间隔，“D”间隔（延迟）是流程的一个特征，可能在区域管理器的控制之外，“L”间隔（生命周期）由区域管理器选择，是策略的一个特征。
<id> is lowercase and defines what object or event the variable is related to, e.g.,
<id>为小写，定义变量与什么对象或事件相关，例如。，
act activation
动作激活
pub publication
出版物
ret retire
退休
<ZONE> is an optional uppercase letter that distinguishes between the same variable applied to different zones and is one of:
<ZONE>是一个可选大写字母，用于区分应用于不同区域的同一变量，它是：
C child
C儿童
P parent
双亲
Within the rollover descriptions, times may have a number in parentheses affixed to their end indicating the instance of the key to which they apply, e.g., Tact(N) is the activation time of key N, Tpub(N+1) the publication time of key N+1 etc.
在翻滚描述中，时间的末尾可能会有一个括号中的数字，表示其应用的键的实例，例如，Tact（N）是键N的激活时间，Tpub（N+1）是键N+1的发布时间等。
The list of variables used in the text given below.
下文给出的文本中使用的变量列表。
Dprp Propagation delay. The amount of time for a change made at a master nameserver to propagate to all the slave nameservers.
Dprp传播延迟。在主名称服务器上所做的更改传播到所有从属名称服务器的时间量。
DprpC Propagation delay in the child zone.
子区域中的DprpC传播延迟。
DprpP Propagation delay in the parent zone.
父区域中的DprpP传播延迟。
Dreg Registration delay: the time taken for a DS record submitted to a parent zone to appear in it. As a parent zone is often managed by a different organization than that managing the child zone, the delays associated with passing data between organizations is captured by this term.
Dreg注册延迟：提交到父区域的DS记录出现在其中所花费的时间。由于父区域通常由不同于管理子区域的组织管理，因此与在组织之间传递数据相关的延迟由该术语表示。
Dsgn Signing delay. After the introduction of a new ZSK, the amount of time taken for all the RRs in the zone to be signed with it.
Dsgn签名延迟。引入新的ZSK后，与之签署区域内所有RRs所需的时间。
Ipub Publication interval. The amount of time that must elapse after the publication of a DNSKEY and/or its associated data before it can be assumed that any resolvers that have the relevant RRset cached have a copy of the new information.
Ipub发布间隔。DNSKEY和/或其关联数据发布后，在可以假定缓存了相关RRset的任何解析程序都有新信息的副本之前，必须经过的时间量。
IpubC Publication interval in the child zone.
子区域中的IpubC发布间隔。
IpubP Publication interval in the parent zone.
父区域中的IpubP发布间隔。
Iret Retire interval. The amount of time that must elapse after a DNSKEY or associated data enters the retire state for any dependent information (e.g., RRSIG for a ZSK) to be purged from validating resolver caches.
退休间隔时间。DNSKEY或相关数据进入失效状态后，要从验证解析程序缓存中清除的任何依赖信息（例如，ZSK的RRSIG）必须经过的时间量。
Irev Revoke interval. The amount of time that a KSK must remain published with the "revoke" bit set to satisfy considerations of [RFC5011].
Irev撤销间隔。为满足[RFC5011]的考虑，KSK必须在设置“撤销”位的情况下保持发布的时间量。
Itrp Trust-point interval. The amount of time that a trust anchor must be published for in order to guarantee that a resolver configured for an automatic update of keys will see the new key at least twice.
Itrp信任点间隔。必须发布信任锚点的时间量，以确保配置为自动更新密钥的冲突解决程序将至少看到新密钥两次。
Lksk Lifetime of a KSK. This is the actual amount of time for which this particular KSK is regarded as the active KSK. Depending on when the key is rolled over, the actual lifetime may be longer or shorter than the intended key lifetime indicated by management policy.
一个KSK的Lksk寿命。这是将此特定KSK视为活动KSK的实际时间量。根据密钥的滚动时间，实际生存期可能比管理策略指示的预期密钥生存期更长或更短。
Lzsk Lifetime of a ZSK. This is the actual amount of time for which the ZSK is used to sign the zone. Depending on when the key is rolled over, the actual lifetime may be longer or shorter than the intended key lifetime indicated by management policy.
Lzsk—ZSK的寿命。这是ZSK用于签署区域的实际时间量。根据密钥的滚动时间，实际生存期可能比管理策略指示的预期密钥生存期更长或更短。
Tact Activation time. The time at which the key is regarded as the principal key for the zone.
触觉激活时间。密钥被视为区域主密钥的时间。
Tdea Dead time. The time at which any information held in validating resolver caches is guaranteed to contain information related to the successor key. At this point, the current key and its associated information are not longed required for validation purposes.
Tdea死区时间。验证冲突解决程序缓存中保存的任何信息保证包含与后续密钥相关的信息的时间。此时，出于验证目的，不需要当前密钥及其相关信息。
Tpub Publication time. The time that the key or associated data appears in the zone for the first time.
Tpub发布时间。键或关联数据第一次出现在区域中的时间。
Trem Removal time. The time at which the key and its associated information starts being removed from their respective zones.
Trem移除时间。密钥及其相关信息开始从各自区域中删除的时间。
Tret Retire time. The time at which successor information starts being used.
特雷特退休了。后继信息开始使用的时间。
Trdy Ready time. The time at which it can be guaranteed that validating resolvers that have information about the key and/or associated data cached have a copy of the new information.
准备好时间了。可以保证具有有关缓存的密钥和/或关联数据的信息的验证解析程序具有新信息的副本的时间。
Tsbm Submission time. The time at which the DS record of a KSK is submitted to the parent zone.
Tsbm提交时间。KSK的DS记录提交到父区域的时间。
TTLds Time to live of a DS record.
TTLds DS记录的生存时间。
TTLkey Time to live of a DNSKEY record. (By implication, this is also the time to live of the signatures on the DNSKEY RRset.)
这是DNSKEY唱片的生命时刻。（言下之意，这也是DNSKEY RRset上签名的生存时间。）
TTLsig The maximum time to live of all the RRSIG records in the zone that were created with the ZSK.
TTLsig使用ZSK创建的分区中所有RRSIG记录的最长生存时间。
Acknowledgements
致谢
The authors gratefully acknowledge help and contributions from Roy Arends, Tim Wicinski, and Wouter Wijngaards.
作者衷心感谢Roy Arends、Tim Wicinski和Wouter Wijngaards的帮助和贡献。
Authors' Addresses
作者地址
Stephen Morris Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 United States
斯蒂芬·莫里斯互联网系统联合会，美国加利福尼亚州红木市查特街950号，邮编94063
Email: stephen@isc.org
URI: http://www.isc.org
Email: stephen@isc.org
URI: http://www.isc.org
Johan Ihren Netnod Franzengatan 5 Stockholm SE-112 51 Sweden
Johan Ihren Netnod Franzengatan 5斯德哥尔摩SE-112 51瑞典
Email: johani@netnod.se
URI: http://www.netnod.se
Email: johani@netnod.se
URI: http://www.netnod.se
John Dickinson Sinodun Internet Technologies Ltd Magdalen Centre Oxford Science Park Robert Robertson Avenue Oxford, Oxfordshire OX4 4GA United Kingdom
John Dickinson Sinodun互联网技术有限公司Magdalen Centre牛津科技园Robert Robertson Avenue牛津，牛津郡牛津4GA英国
Email: jad@sinodun.com
URI: http://www.sinodun.com
Email: jad@sinodun.com
URI: http://www.sinodun.com
W. (Matthijs) Mekking Dyn, Inc. 150 Dow St Manchester NH 03101 United States
W.（Matthijs）Mekking Dyn，Inc.美国新罕布什尔州曼彻斯特道街150号，邮编：03101
Email: mmekking@dyn.com
URI: https://www.dyn.com
Email: mmekking@dyn.com
URI: https://www.dyn.com