Internet Engineering Task Force (IETF) O. Kolkman
Request for Comments: 6781 W. Mekking
Obsoletes: 4641 NLnet Labs
Category: Informational R. Gieben
ISSN: 2070-1721 SIDN Labs
December 2012
Internet Engineering Task Force (IETF) O. Kolkman
Request for Comments: 6781 W. Mekking
Obsoletes: 4641 NLnet Labs
Category: Informational R. Gieben
ISSN: 2070-1721 SIDN Labs
December 2012
DNSSEC Operational Practices, Version 2
DNSSEC操作规程，第2版
Abstract
摘要
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
本文档描述了使用安全扩展（DNSSEC）操作DNS的一组实践。目标受众是部署DNSSEC的区域管理员。
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
本文档讨论了在DNS中使用密钥和签名的操作方面。它讨论了密钥生成、密钥存储、签名生成、密钥滚动和相关策略等问题。
This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.
本文件淘汰了RFC 4641，因为它涵盖了更多的操作基础，并给出了有关关键尺寸和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/rfc6781.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6781.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. The Use of the Term 'key' ..................................5
1.2. Time Definitions ...........................................6
2. Keeping the Chain of Trust Intact ...............................6
3. Key Generation and Storage ......................................7
3.1. Operational Motivation for Zone Signing Keys and
Key Signing Keys ...........................................8
3.2. Practical Consequences of KSK and ZSK Separation ..........10
3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
3.2.3. The Use of the SEP Flag ............................12
3.3. Key Effectivity Period ....................................12
3.4. Cryptographic Considerations ..............................14
3.4.1. Signature Algorithm ................................14
3.4.2. Key Sizes ..........................................14
3.4.3. Private Key Storage ................................16
3.4.4. Key Generation .....................................17
3.4.5. Differentiation for 'High-Level' Zones? ............17
1. Introduction ....................................................4
1.1. The Use of the Term 'key' ..................................5
1.2. Time Definitions ...........................................6
2. Keeping the Chain of Trust Intact ...............................6
3. Key Generation and Storage ......................................7
3.1. Operational Motivation for Zone Signing Keys and
Key Signing Keys ...........................................8
3.2. Practical Consequences of KSK and ZSK Separation ..........10
3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
3.2.3. The Use of the SEP Flag ............................12
3.3. Key Effectivity Period ....................................12
3.4. Cryptographic Considerations ..............................14
3.4.1. Signature Algorithm ................................14
3.4.2. Key Sizes ..........................................14
3.4.3. Private Key Storage ................................16
3.4.4. Key Generation .....................................17
3.4.5. Differentiation for 'High-Level' Zones? ............17
4. Signature Generation, Key Rollover, and Related Policies .......18
4.1. Key Rollovers .............................................18
4.1.1. Zone Signing Key Rollovers .........................18
4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
4.1.1.2. Double-Signature Zone Signing Key Rollover 21
4.1.1.3. Pros and Cons of the Schemes ..............23
4.1.2. Key Signing Key Rollovers ..........................23
4.1.2.1. Special Considerations for RFC 5011
KSK Rollover ..............................26
4.1.3. Single-Type Signing Scheme Key Rollover ............26
4.1.4. Algorithm Rollovers ................................28
4.1.4.1. Single-Type Signing Scheme
Algorithm Rollover ........................32
4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
4.1.4.3. Single Signing Type Algorithm
Rollover, RFC 5011 Style ..................33
4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
4.1.5. Considerations for Automated Key Rollovers .........34
4.2. Planning for Emergency Key Rollover .......................35
4.2.1. KSK Compromise .....................................35
4.2.1.1. Emergency Key Rollover Keeping the
Chain of Trust Intact .....................36
4.2.1.2. Emergency Key Rollover Breaking
the Chain of Trust ........................37
4.2.2. ZSK Compromise .....................................37
4.2.3. Compromises of Keys Anchored in Resolvers ..........38
4.2.4. Stand-By Keys ......................................38
4.3. Parent Policies ...........................................39
4.3.1. Initial Key Exchanges and Parental Policies
Considerations .....................................39
4.3.2. Storing Keys or Hashes? ............................40
4.3.3. Security Lameness ..................................40
4.3.4. DS Signature Validity Period .......................41
4.3.5. Changing DNS Operators .............................42
4.3.5.1. Cooperating DNS Operators .................42
4.3.5.2. Non-Cooperating DNS Operators .............44
4.4. Time in DNSSEC ............................................46
4.4.1. Time Considerations ................................46
4.4.2. Signature Validity Periods .........................48
4.4.2.1. Maximum Value .............................48
4.4.2.2. Minimum Value .............................49
4.4.2.3. Differentiation between RRsets ............50
4. Signature Generation, Key Rollover, and Related Policies .......18
4.1. Key Rollovers .............................................18
4.1.1. Zone Signing Key Rollovers .........................18
4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
4.1.1.2. Double-Signature Zone Signing Key Rollover 21
4.1.1.3. Pros and Cons of the Schemes ..............23
4.1.2. Key Signing Key Rollovers ..........................23
4.1.2.1. Special Considerations for RFC 5011
KSK Rollover ..............................26
4.1.3. Single-Type Signing Scheme Key Rollover ............26
4.1.4. Algorithm Rollovers ................................28
4.1.4.1. Single-Type Signing Scheme
Algorithm Rollover ........................32
4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
4.1.4.3. Single Signing Type Algorithm
Rollover, RFC 5011 Style ..................33
4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
4.1.5. Considerations for Automated Key Rollovers .........34
4.2. Planning for Emergency Key Rollover .......................35
4.2.1. KSK Compromise .....................................35
4.2.1.1. Emergency Key Rollover Keeping the
Chain of Trust Intact .....................36
4.2.1.2. Emergency Key Rollover Breaking
the Chain of Trust ........................37
4.2.2. ZSK Compromise .....................................37
4.2.3. Compromises of Keys Anchored in Resolvers ..........38
4.2.4. Stand-By Keys ......................................38
4.3. Parent Policies ...........................................39
4.3.1. Initial Key Exchanges and Parental Policies
Considerations .....................................39
4.3.2. Storing Keys or Hashes? ............................40
4.3.3. Security Lameness ..................................40
4.3.4. DS Signature Validity Period .......................41
4.3.5. Changing DNS Operators .............................42
4.3.5.1. Cooperating DNS Operators .................42
4.3.5.2. Non-Cooperating DNS Operators .............44
4.4. Time in DNSSEC ............................................46
4.4.1. Time Considerations ................................46
4.4.2. Signature Validity Periods .........................48
4.4.2.1. Maximum Value .............................48
4.4.2.2. Minimum Value .............................49
4.4.2.3. Differentiation between RRsets ............50
5. "Next Record" Types ............................................51
5.1. Differences between NSEC and NSEC3 ........................51
5.2. NSEC or NSEC3 .............................................52
5.3. NSEC3 Parameters ..........................................53
5.3.1. NSEC3 Algorithm ....................................53
5.3.2. NSEC3 Iterations ...................................53
5.3.3. NSEC3 Salt .........................................54
5.3.4. Opt-Out ............................................54
6. Security Considerations ........................................54
7. Acknowledgments ................................................55
8. Contributors ...................................................55
9. References .....................................................56
9.1. Normative References ......................................56
9.2. Informative References ....................................56
Appendix A. Terminology ...........................................59
Appendix B. Typographic Conventions ...............................61
Appendix C. Transition Figures for Special Cases of Algorithm
Rollovers .............................................64
Appendix D. Transition Figure for Changing DNS Operators ..........68
Appendix E. Summary of Changes from RFC 4641 ......................70
5. "Next Record" Types ............................................51
5.1. Differences between NSEC and NSEC3 ........................51
5.2. NSEC or NSEC3 .............................................52
5.3. NSEC3 Parameters ..........................................53
5.3.1. NSEC3 Algorithm ....................................53
5.3.2. NSEC3 Iterations ...................................53
5.3.3. NSEC3 Salt .........................................54
5.3.4. Opt-Out ............................................54
6. Security Considerations ........................................54
7. Acknowledgments ................................................55
8. Contributors ...................................................55
9. References .....................................................56
9.1. Normative References ......................................56
9.2. Informative References ....................................56
Appendix A. Terminology ...........................................59
Appendix B. Typographic Conventions ...............................61
Appendix C. Transition Figures for Special Cases of Algorithm
Rollovers .............................................64
Appendix D. Transition Figure for Changing DNS Operators ..........68
Appendix E. Summary of Changes from RFC 4641 ......................70
This document describes how to run a DNS Security (DNSSEC)-enabled environment. It is intended for operators who have knowledge of the DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035 [RFC4035], and RFC 5155 [RFC5155]). The focus of the document is on serving authoritative DNS information and is aimed at zone owners, name server operators, registries, registrars, and registrants. It assumes that there is no direct relationship between those entities and the operators of validating recursive name servers (validators).
本文档描述如何运行启用DNS安全性（DNSSEC）的环境。它适用于了解DNS（参见RFC 1034[RFC1034]和RFC 1035[RFC1035]）并希望部署DNSSEC（RFC 4033[RFC4033]、RFC 4034[RFC4034]、RFC 4035[RFC4035]和RFC 5155[RFC5155]）的运营商。本文档的重点是提供权威DNS信息，面向区域所有者、名称服务器运营商、注册中心、注册者和注册者。它假定这些实体与验证递归名称服务器（验证器）的操作员之间没有直接关系。
During workshops and early operational deployment, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these experiences into a set of practices for zone administrators. Although the DNS Root has been signed since July 15, 2010 and now more than 80 secure delegations are provisioned in the root, at the time of this writing there still exists relatively little experience with DNSSEC in production environments below the Top-Level Domain (TLD) level; this document should therefore explicitly not be seen as representing 'Best Current Practices'. Instead, it describes the decisions that should be made when deploying DNSSEC, gives the choices available for each one, and provides some operational guidelines. The document does not give strong recommendations. That may be the subject for a future version of this document.
在研讨会和早期操作部署期间，操作员和系统管理员获得了使用安全扩展（DNSSEC）操作DNS的经验。本文档将这些经验转化为区域管理员的一组实践。尽管DNS根目录自2010年7月15日起已签署，并且现在根目录中提供了80多个安全委托，但在撰写本文时，在顶级域（TLD）级别以下的生产环境中使用DNSSEC的经验仍然相对较少；因此，本文件不应被明确视为代表“当前最佳实践”。相反，它描述了部署DNSSEC时应做出的决策，给出了每个决策的可用选项，并提供了一些操作指南。这份文件没有给出有力的建议。这可能是本文件未来版本的主题。
The procedures herein are focused on the maintenance of signed zones (i.e., signing and publishing zones on authoritative servers). It is intended that maintenance of zones, such as re-signing or key rollovers, be transparent to any verifying clients.
本文中的程序侧重于维护已签名区域（即，权威服务器上的签名和发布区域）。区域的维护（如重新签名或密钥翻转）对任何验证客户端都是透明的。
The structure of this document is as follows. In Section 2, we discuss the importance of keeping the "chain of trust" intact. Aspects of key generation and storage of keys are discussed in Section 3; the focus in this section is mainly on the security of the private part of the key(s). Section 4 describes considerations concerning the public part of the keys. Sections 4.1 and 4.2 deal with the rollover, or replacement, of keys. Section 4.3 discusses considerations on how parents deal with their children's public keys in order to maintain chains of trust. Section 4.4 covers all kinds of timing issues around key publication. Section 5 covers the considerations regarding selecting and using the NSEC or NSEC3 [RFC5155] Resource Record.
本文件的结构如下。在第2节中，我们将讨论保持“信任链”完整性的重要性。第3节讨论了密钥生成和密钥存储的各个方面；本节的重点主要是密钥私有部分的安全性。第4节描述了有关密钥公共部分的注意事项。第4.1节和第4.2节涉及钥匙的翻转或更换。第4.3节讨论了父母如何处理子女的公钥以维持信任链的考虑事项。第4.4节涵盖了围绕关键出版物的各种时间安排问题。第5节介绍了有关选择和使用NSEC或NSEC3[RFC5155]资源记录的注意事项。
The typographic conventions used in this document are explained in Appendix B.
附录B解释了本文件中使用的印刷惯例。
Since we describe operational suggestions and there are no protocol specifications, the RFC 2119 [RFC2119] language does not apply to this document, though we do use quotes from other documents that do include the RFC 2119 language.
由于我们描述了操作建议，并且没有协议规范，因此RFC 2119[RFC2119]语言不适用于本文件，尽管我们引用了其他包含RFC 2119语言的文件。
This document obsoletes RFC 4641 [RFC4641].
本文件废除了RFC 4641[RFC4641]。
It is assumed that the reader is familiar with the concept of asymmetric cryptography, or public-key cryptography, on which DNSSEC is based (see the definition of 'asymmetric cryptography' in RFC 4949 [RFC4949]). Therefore, this document will use the term 'key' rather loosely. Where it is written that 'a key is used to sign data', it is assumed that the reader understands that it is the private part of the key pair that is used for signing. It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record (DNSKEY RR) and that it is the public part that is used in signature verification.
假设读者熟悉DNSSEC所基于的非对称加密或公钥加密的概念（参见RFC 4949[RFC4949]中“非对称加密”的定义）。因此，本文件将不严格地使用术语“键”。在写入“密钥用于对数据签名”的情况下，假定读取器理解用于签名的是密钥对的私有部分。还假设读者理解密钥对的公共部分发布在DNSKEY资源记录（DNSKEY RR）中，并且签名验证中使用的是公共部分。
In this document, we will be using a number of time-related terms. The following definitions apply:
在本文档中，我们将使用一些与时间相关的术语。以下定义适用：
Signature validity period: The period that a signature is valid. It starts at the (absolute) time specified in the signature inception field of the RRSIG RR and ends at the (absolute) time specified in the expiration field of the RRSIG RR. The document sometimes also uses the term 'validity period', which means the same.
签名有效期：签名的有效期。它从RRSIG RR的签名起始字段中指定的（绝对）时间开始，到RRSIG RR的到期字段中指定的（绝对）时间结束。文件有时也使用“有效期”一词，意思相同。
Signature publication period: The period that a signature is published. It starts at the time the signature is introduced in the zone for the first time and ends at the time when the signature is removed or replaced with a new signature. After one stops publishing an RRSIG in a zone, it may take a while before the RRSIG has expired from caches and has actually been removed from the DNS.
签名发布周期：签名发布的周期。它从签名第一次引入区域时开始，到签名被删除或替换为新签名时结束。停止在区域中发布RRSIG后，RRSIG可能需要一段时间才能从缓存中过期并实际从DNS中删除。
Key effectivity period: The period during which a key pair is expected to be effective. It is defined as the time between the earliest inception time stamp and the last expiration date of any signature made with this key, regardless of any discontinuity in the use of the key. The key effectivity period can span multiple signature validity periods.
密钥有效期：密钥对预计有效的期间。它被定义为使用此密钥进行的任何签名的最早起始时间戳和最后到期日期之间的时间，无论密钥使用中存在任何中断。密钥有效期可以跨越多个签名有效期。
Maximum/Minimum Zone Time to Live (TTL): The maximum or minimum value of the TTLs from the complete set of RRs in a zone, that are used by validators or resolvers. Note that the minimum TTL is not the same as the MINIMUM field in the SOA RR. See RFC 2308 [RFC2308] for more information.
最大/最小区域生存时间（TTL）：验证程序或解析程序使用的区域中完整RRs集合中TTL的最大或最小值。请注意，最小TTL与SOA RR中的最小字段不同。有关更多信息，请参阅RFC 2308[RFC2308]。
Maintaining a valid chain of trust is important because broken chains of trust will result in data being marked as Bogus (as defined in RFC 4033 [RFC4033] Section 5), which may cause entire (sub)domains to become invisible to verifying clients. The administrators of secured zones need to realize that, to verifying clients, their zone is part of a chain of trust.
维护有效的信任链非常重要，因为断开的信任链将导致数据被标记为伪数据（如RFC 4033[RFC4033]第5节中的定义），这可能导致整个（子）域对验证客户端不可见。安全区域的管理员需要意识到，对于验证客户机，他们的区域是信任链的一部分。
As mentioned in the introduction, the procedures herein are intended to ensure that maintenance of zones, such as re-signing or key rollovers, will be transparent to the verifying clients on the Internet.
如引言中所述，本文中的程序旨在确保区域的维护（如重新签名或密钥转移）对互联网上的验证客户端是透明的。
Administrators of secured zones will need to keep in mind that data published on an authoritative primary server will not be immediately seen by verifying clients; it may take some time for the data to be transferred to other (secondary) authoritative name servers and clients may be fetching data from caching non-authoritative servers. In this light, note that the time until the data is available on the slave can be negligible when using NOTIFY [RFC1996] and Incremental Zone Transfer (IXFR) [RFC1995]. It increases when Authoritative (full) Zone Transfers (AXFRs) are used in combination with NOTIFY. It increases even more if you rely on the full zone transfers being based only on the SOA timing parameters for refresh.
安全区域的管理员需要记住，验证客户端不会立即看到在权威主服务器上发布的数据；数据传输到其他（辅助）权威名称服务器可能需要一些时间，客户端可能正在从缓存非权威服务器获取数据。有鉴于此，请注意，在使用NOTIFY[RFC1996]和增量区域传输（IXFR）[RFC1995]时，从机上获得数据的时间可以忽略不计。当权威（完整）区域传输（AXFRs）与NOTIFY结合使用时，它会增加。如果您依赖于仅基于刷新的SOA定时参数的完整区域传输，则会增加更多。
For the verifying clients, it is important that data from secured zones can be used to build chains of trust, regardless of whether the data came directly from an authoritative server, a caching name server, or some middle box. Only by carefully using the available timing parameters can a zone administrator ensure that the data necessary for verification can be obtained.
对于验证客户端，重要的是可以使用来自安全区域的数据来构建信任链，而不管数据是直接来自权威服务器、缓存名称服务器还是某个中间框。只有仔细使用可用的定时参数，区域管理员才能确保获得验证所需的数据。
The responsibility for maintaining the chain of trust is shared by administrators of secured zones in the chain of trust. This is most obvious in the case of a 'key compromise' when a tradeoff must be made between maintaining a valid chain of trust and replacing the compromised keys as soon as possible. Then zone administrators will have to decide between keeping the chain of trust intact -- thereby allowing for attacks with the compromised key -- or deliberately breaking the chain of trust and making secured subdomains invisible to security-aware resolvers (also see Section 4.2).
维护信任链的责任由信任链中安全区域的管理员分担。这在“密钥泄露”的情况下最为明显，此时必须在维护有效的信任链和尽快更换泄露的密钥之间进行权衡。然后，区域管理员必须决定是保持信任链完好无损（从而允许使用受损密钥进行攻击），还是故意破坏信任链并使安全子域对安全感知解析程序不可见（另请参见第4.2节）。
This section describes a number of considerations with respect to the use of keys. For the design of an operational procedure for key generation and storage, a number of decisions need to be made:
本节介绍了有关使用密钥的一些注意事项。为了设计密钥生成和存储的操作程序，需要做出一些决策：
o Does one differentiate between Zone Signing Keys and Key Signing Keys or is the use of one type of key sufficient?
o 是否区分区域签名密钥和密钥签名密钥，或者使用一种类型的密钥就足够了？
o Are Key Signing Keys (likely to be) in use as trust anchors [RFC4033]?
o 密钥签名密钥（可能）是否用作信任锚[RFC4033]？
o What are the timing parameters that are allowed by the operational requirements?
o 运行要求允许的定时参数是什么？
o What are the cryptographic parameters that fit the operational need?
o 什么是适合操作需要的加密参数？
The following section discusses the considerations that need to be taken into account when making those choices.
下一节讨论在做出这些选择时需要考虑的因素。
The DNSSEC validation protocol does not distinguish between different types of DNSKEYs. The motivations to differentiate between keys are purely operational; validators will not make a distinction.
DNSSEC验证协议不区分不同类型的DNSKEY。区分钥匙的动机纯粹是操作性的；验证器不会进行区分。
For operational reasons, described below, it is possible to designate one or more keys to have the role of Key Signing Keys (KSKs). These keys will only sign the apex DNSKEY RRset in a zone. Other keys can be used to sign all the other RRsets in a zone that require signatures. They are referred to as Zone Signing Keys (ZSKs). In cases where the differentiation between the KSK and ZSK is not made, i.e., where keys have the role of both KSK and ZSK, we talk about a Single-Type Signing Scheme.
出于如下所述的操作原因，可以指定一个或多个密钥作为密钥签名密钥（KSK）的角色。这些键仅对区域中的apex DNSKEY RRset进行签名。其他密钥可用于对区域中需要签名的所有其他RRSET进行签名。它们被称为区域签名密钥（ZSK）。在没有区分KSK和ZSK的情况下，即密钥同时具有KSK和ZSK的角色，我们讨论单一类型的签名方案。
If the two functions are separated, then for almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the RRset can be used as ZSKs. If there has been an event that increases the risk that a ZSK is compromised, it can be simply replaced with a ZSK rollover. The new RRset is then re-signed with the KSK.
如果这两个功能是分开的，那么对于几乎任何密钥管理和区域签名方法，KSK的使用频率都低于ZSK。一旦使用KSK对DNSKEY RRset进行签名，RRset中的所有密钥都可以用作ZSK。如果发生了增加ZSK受损风险的事件，可以简单地将其替换为ZSK翻车。然后用KSK重新签署新的RRset。
Changing a key that is a Secure Entry Point (SEP) [RFC4034] for a zone can be relatively expensive, as it involves interaction with third parties: When a key is only pointed to by a Delegation Signer (DS) [RFC4034] record in the parent zone, one needs to complete the interaction with the parent and wait for the updated DS record to appear in the DNS. In the case where a key is configured as a trust anchor, one has to wait until one has sufficient confidence that all trust anchors have been replaced. In fact, it may be that one is not able to reach the complete user-base with information about the key rollover.
更改作为区域安全入口点（SEP）[RFC4034]的密钥可能相对昂贵，因为它涉及与第三方的交互：当密钥仅由父区域中的委派签名者（DS）[RFC4034]记录指向时，您需要完成与父级的交互，并等待更新的DS记录出现在DNS中。在密钥被配置为信任锚的情况下，必须等待，直到有足够的信心相信所有信任锚都已被替换。事实上，这可能是一个无法达到完整的用户群与信息的关键滚动。
Given the assumption that for KSKs the SEP flag is set, the KSK can be distinguished from a ZSK by examining the flag field in the DNSKEY RR: If the flag field is an odd number, it is a KSK; otherwise, it is a ZSK.
假设设置了KSK的SEP标志，则可以通过检查DNSKEY RR中的标志字段来区分KSK和ZSK：如果标志字段为奇数，则为KSK；否则，它就是ZSK。
There is also a risk that keys can be compromised through theft or loss. For keys that are installed on file-systems of name servers that are connected to the network (e.g., for dynamic updates), that risk is relatively high. Where keys are stored on Hardware Security Modules (HSMs) or stored off-line, such risk is relatively low. However, storing keys off-line or with more limitations on access control has a negative effect on the operational flexibility. By
钥匙也有可能因被盗或丢失而受损。对于安装在连接到网络的名称服务器的文件系统上的密钥（例如，用于动态更新），风险相对较高。如果密钥存储在硬件安全模块（HSM）上或离线存储，则此类风险相对较低。然而，离线存储钥匙或在访问控制方面有更多限制会对操作灵活性产生负面影响。通过
separating the KSK and ZSK functionality, these risks can be managed while making the tradeoff against the involved costs. For example, a KSK can be stored off-line or with more limitations on access control than ZSKs, which need to be readily available for operational purposes such as the addition or deletion of zone data. A KSK stored on a smartcard that is kept in a safe, combined with a ZSK stored on a file-system accessible by operators for daily routine use, may provide better protection against key compromise without losing much operational flexibility. It must be said that some HSMs give the option to have your keys online, giving more protection and hardly affecting the operational flexibility. In those cases, a KSK-ZSK split is not more beneficial than the Single-Type Signing Scheme.
分离KSK和ZSK功能，可以在权衡相关成本的同时管理这些风险。例如，KSK可以离线存储，或者在访问控制方面比ZSK有更多限制，ZSK需要随时可用于操作目的，例如添加或删除区域数据。存储在保险箱中的智能卡上的KSK，与存储在操作员日常使用可访问的文件系统上的ZSK相结合，可以提供更好的密钥泄露保护，而不会失去很大的操作灵活性。必须指出的是，一些HSM提供了钥匙在线的选项，提供了更多的保护，几乎不影响操作灵活性。在这些情况下，KSK-ZSK拆分并不比单一类型签名方案更有利。
It is worth mentioning that there's not much point in obsessively protecting the key if you don't protect the zone files, which also live on the file-systems.
值得一提的是，如果不保护区域文件（也存在于文件系统中），那么痴迷地保护密钥没有多大意义。
Finally, there is a risk of cryptanalysis of the key material. The costs of such analysis are correlated to the length of the key. However, cryptanalysis arguments provide no strong motivation for a KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK, whereby the KSK effectivity period is X times the ZSK effectivity period. Then, in order for the resistance to cryptanalysis to be the same for the KSK and the ZSK, the KSK needs to be X times stronger than the ZSK. Since for all practical purposes X will be somewhere on the order of 10 to 100, the associated key sizes will vary only by about a byte in size for symmetric keys. When translated to asymmetric keys, the size difference is still too insignificant to warrant a key-split; it only marginally affects the packet size and signing speed.
最后，存在对关键材料进行密码分析的风险。这种分析的成本与密钥的长度相关。然而，密码分析的论点并没有为KSK/ZSK分裂提供强有力的动机。假设区分KSK和ZSK，其中KSK有效期是ZSK有效期的X倍。然后，为了使KSK和ZSK对密码分析的抵抗力相同，KSK需要比ZSK强X倍。由于出于所有实际目的，X将在10到100之间的某个位置，因此对于对称密钥，相关密钥大小将仅变化约一个字节。当转换为非对称密钥时，大小差异仍然太小，无法保证密钥分割；它对数据包大小和签名速度的影响很小。
The arguments for differentiation between the ZSK and KSK are weakest when:
在以下情况下，区分ZSK和KSK的论据最弱：
o the exposure to risk is low (e.g., when keys are stored on HSMs);
o 风险敞口较低（例如，当钥匙存储在HSMs上时）；
o one can be certain that a key is not used as a trust anchor;
o 可以确定密钥没有用作信任锚；
o maintenance of the various keys cannot be performed through tools (is prone to human error); and
o 各种钥匙的维护不能通过工具进行（容易出现人为错误）；和
o the interaction through the child-parent provisioning chain -- in particular, the timely appearance of a new DS record in the parent zone in emergency situations -- is predictable.
o 通过子-父供应链的交互——特别是在紧急情况下在父区域中及时出现新DS记录——是可预测的。
If the above arguments hold, then the costs of the operational complexity of a KSK-ZSK split may outweigh the costs of operational flexibility, and choosing a Single-Type Signing Scheme is a reasonable option. In other cases, we advise that the separation between KSKs and ZSKs is made.
如果上述论点成立，那么KSK-ZSK拆分的操作复杂性成本可能超过操作灵活性成本，选择单一类型的签名方案是一个合理的选择。在其他情况下，我们建议将KSK和ZSK分开。
A key that acts only as a Zone Signing Key is used to sign all the data except the DNSKEY RRset in a zone on a regular basis. When a ZSK is to be rolled, no interaction with the parent is needed. This allows for a relatively short key effectivity period.
仅用作区域签名密钥的密钥用于定期对区域中除DNSKEY RRset之外的所有数据进行签名。当要滚动ZSK时，不需要与父级交互。这允许相对较短的关键有效期。
A key with only the Key Signing Key role is to be used to sign the DNSKEY RRs in a zone. If a KSK is to be rolled, there may be interactions with other parties. These can include the administrators of the parent zone or administrators of verifying resolvers that have the particular key configured as secure entry points. In the latter case, everyone relying on the trust anchor needs to roll over to the new key, a process that may be subject to stability costs if automated trust anchor rollover mechanisms (e.g., RFC 5011 [RFC5011]) are not in place. Hence, the key effectivity period of these keys can and should be made much longer.
仅具有密钥签名密钥角色的密钥将用于对区域中的DNSKEY RRs进行签名。如果要滚动KSK，可能会与其他方进行交互。这些可以包括父区域的管理员或验证将特定密钥配置为安全入口点的解析程序的管理员。在后一种情况下，依赖信任锚的每个人都需要滚动到新密钥，如果自动信任锚滚动机制（例如，RFC 5011[RFC5011]）不到位，该过程可能会受到稳定性成本的影响。因此，这些密钥的密钥有效期可以而且应该更长。
There are three schools of thought on rolling a KSK that is not a trust anchor:
有三种观点认为KSK不是信托锚：
1. It should be done frequently and regularly (possibly every few months), so that a key rollover remains an operational routine.
1. 应该经常和定期（可能每几个月）进行，以便关键的过渡仍然是一个操作例行程序。
2. It should be done frequently but irregularly. "Frequently" means every few months, again based on the argument that a rollover is a practiced and common operational routine; "irregular" means with a large jitter, so that third parties do not start to rely on the key and will not be tempted to configure it as a trust anchor.
2. 应该经常但不定期地做。“频繁”是指每隔几个月一次，再次基于滚动是一种实践和常见的操作程序的论点；“不规则”是指具有较大的抖动，因此第三方不会开始依赖密钥，也不会试图将其配置为信任锚。
3. It should only be done when it is known or strongly suspected that the key can be or has been compromised, or in conjunction with operator change policies and procedures, like when a new algorithm or key storage is required.
3. 只有在已知或强烈怀疑密钥可能或已被泄露时，或与操作员更改策略和程序结合使用时，如需要新算法或密钥存储时，才应执行此操作。
There is no widespread agreement on which of these three schools of thought is better for different deployments of DNSSEC. There is a stability cost every time a non-anchor KSK is rolled over, but it is possibly low if the communication between the child and the parent is
对于DNSSEC的不同部署，这三种思想流派中的哪一种更好，目前还没有达成广泛共识。每次滚动非锚KSK时都会产生稳定成本，但如果子级和父级之间的通信中断，则稳定成本可能较低
good. On the other hand, the only completely effective way to tell if the communication is good is to test it periodically. Thus, rolling a KSK with a parent is only done for two reasons: to test and verify the rolling system to prepare for an emergency, and in the case of (preventing) an actual emergency.
好的另一方面，判断通信是否良好的唯一完全有效的方法是定期测试。因此，与家长一起滚动KSK仅出于两个原因：测试和验证滚动系统以准备紧急情况，以及（防止）实际紧急情况。
Finally, in most cases a zone administrator cannot be fully certain that the zone's KSK is not in use as a trust anchor somewhere. While the configuration of trust anchors is not the responsibility of the zone administrator, there may be stability costs for the validator administrator that (wrongfully) configured the trust anchor when the zone administrator rolls a KSK.
最后，在大多数情况下，区域管理员无法完全确定该区域的KSK没有在某处用作信任锚。虽然信任锚点的配置不是区域管理员的责任，但是当区域管理员滚动KSK时（错误地）配置信任锚点的验证器管理员可能会有稳定成本。
The same operational concerns apply to the rollover of KSKs that are used as trust anchors: If a trust anchor replacement is done incorrectly, the entire domain that the trust anchor covers will become Bogus until the trust anchor is corrected.
同样的操作问题也适用于用作信任锚点的KSK的滚动：如果信任锚点更换不正确，则信任锚点覆盖的整个域将成为伪造域，直到信任锚点得到纠正。
In a large number of cases, it will be safe to work from the assumption that one's keys are not in use as trust anchors. If a zone administrator publishes a DNSSEC signing policy and/or a DNSSEC practice statement [DNSSEC-DPS], that policy or statement should be explicit regarding whether or not the existence of trust anchors will be taken into account. There may be cases where local policies enforce the configuration of trust anchors on zones that are mission critical (e.g., in enterprises where the trust anchor for the enterprise domain is configured in the enterprise's validator). It is expected that the zone administrators are aware of such circumstances.
在很多情况下，假设一个人的密钥没有被用作信任锚，那么工作起来是安全的。如果区域管理员发布了DNSSEC签名政策和/或DNSSEC实践声明[DNSSEC-DPS]，则该政策或声明应明确说明是否将考虑信任锚的存在。在某些情况下，本地策略会强制在任务关键区域上配置信任锚（例如，在企业中，企业域的信任锚是在企业的验证器中配置的）。预计区域管理员会意识到这种情况。
One can argue that because of the difficulty of getting all users of a trust anchor to replace an old trust anchor with a new one, a KSK that is a trust anchor should never be rolled unless it is known or strongly suspected that the key has been compromised. In other words, the costs of a KSK rollover are prohibitively high because some users cannot be reached.
有人可能会说，由于很难让信任锚的所有用户用新的信任锚替换旧的信任锚，因此作为信任锚的KSK永远不应该滚动，除非已知或强烈怀疑密钥已被泄露。换句话说，KSK滚动的成本高得令人望而却步，因为无法联系到某些用户。
However, the "operational habit" argument also applies to trust anchor reconfiguration at the clients' validators. If a short key effectivity period is used and the trust anchor configuration has to be revisited on a regular basis, the odds that the configuration tends to be forgotten are smaller. In fact, the costs for those users can be minimized by automating the rollover with RFC 5011 [RFC5011] and by rolling the key regularly (and advertising such) so
然而，“操作习惯”的论点也适用于客户端验证器上的信任锚重配置。如果使用较短的密钥有效期，并且必须定期重新访问信任锚点配置，则忘记配置的可能性较小。事实上，通过使用RFC 5011[RFC5011]自动进行滚动，并定期滚动密钥（以及广告），可以将这些用户的成本降至最低
that the operators of validating resolvers will put the appropriate mechanism in place to deal with these stability costs: In other words, budget for these costs instead of incurring them unexpectedly.
验证解析器的操作员将采取适当的机制来处理这些稳定性成本：换句话说，预算这些成本，而不是意外发生这些成本。
It is therefore preferable to roll KSKs that are expected to be used as trust anchors on a regular basis if and only if those rollovers can be tracked using standardized (e.g., RFC 5011 [RFC5011]) mechanisms.
因此，如果且仅当可以使用标准化（如RFC 5011[RFC5011]）机制跟踪这些滚动时，最好定期滚动预期用作信任锚的KSK。
The so-called SEP [RFC4035] flag can be used to distinguish between keys that are intended to be used as the secure entry point into the zone when building chains of trust, i.e., they are (to be) pointed to by parental DS RRs or configured as a trust anchor.
所谓的SEP[RFC4035]标志可用于区分在构建信任链时用作区域安全入口点的密钥，即，它们（将）由父母DS RRs指向或配置为信任锚。
While the SEP flag does not play any role in validation, it is used in practice for operational purposes such as for the rollover mechanism described in RFC 5011 [RFC5011]. The common convention is to set the SEP flag on any key that is used for key exchanges with the parent and/or potentially used for configuration as a trust anchor. Therefore, it is suggested that the SEP flag be set on keys that are used as KSKs and not on keys that are used as ZSKs, while in those cases where a distinction between a KSK and ZSK is not made (i.e., for a Single-Type Signing Scheme), it is suggested that the SEP flag be set on all keys.
虽然SEP标志在验证中不起任何作用，但它在实践中用于操作目的，如RFC 5011[RFC5011]中描述的翻转机制。常见的约定是在任何密钥上设置SEP标志，该密钥用于与父密钥交换和/或可能用于配置为信任锚。因此，建议在用作KSK的密钥上设置SEP标志，而不是在用作ZSK的密钥上设置SEP标志，而在未区分KSK和ZSK的情况下（即，对于单一类型签名方案），建议在所有密钥上设置SEP标志。
Note: Some signing tools may assume a KSK/ZSK split and use the (non-)presence of the SEP flag to determine which key is to be used for signing zone data; these tools may get confused when a Single-Type Signing Scheme is used.
注意：一些签名工具可能假设KSK/ZSK拆分，并使用SEP标志（不存在）来确定哪个密钥用于签名区域数据；当使用单一类型的签名方案时，这些工具可能会混淆。
In general, the available key length sets an upper limit on the key effectivity period. For all practical purposes, it is sufficient to define the key effectivity period based on purely operational requirements and match the key length to that value. Ignoring the operational perspective, a reasonable effectivity period for KSKs that have corresponding DS records in the parent zone is on the order of two decades or longer. That is, if one does not plan to test the rollover procedure, the key should be effective essentially forever and only rolled over in case of emergency.
通常，可用密钥长度会设置密钥有效期的上限。出于所有实际目的，仅根据运营要求定义关键有效期并将关键长度与该值相匹配就足够了。忽略操作角度，在父区域中具有相应DS记录的KSK的合理有效期约为20年或更长。也就是说，如果不打算测试翻车程序，钥匙基本上永远有效，只有在紧急情况下才能翻车。
When one opts for a regular key rollover, a reasonable key effectivity period for KSKs that have a parent zone is one year, meaning you have the intent to replace them after 12 months. The key effectivity period is merely a policy parameter and should not be
如果选择定期密钥展期，则具有父区域的KSK的合理密钥有效期为一年，这意味着您打算在12个月后更换它们。关键有效期仅是一个政策参数，不应
considered a constant value. For example, the real key effectivity period may be a little bit longer than 12 months, because not all actions needed to complete the rollover could be finished in time.
被认为是一个常量。例如，实际关键有效期可能比12个月稍长一点，因为并非所有完成展期所需的行动都能及时完成。
As argued above, this annual rollover gives an operational practice of rollovers for both the zone and validator administrators. Besides, in most environments a year is a time span that is easily planned and communicated.
如上所述，每年的展期为区域管理员和验证器管理员提供了展期的操作实践。此外，在大多数环境中，一年是一个容易计划和沟通的时间跨度。
Where keys are stored online and the exposure to various threats of compromise is fairly high, an intended key effectivity period of a month is reasonable for Zone Signing Keys.
如果密钥在线存储，并且暴露于各种泄露威胁的风险相当高，则区域签名密钥的预期密钥有效期为一个月是合理的。
Although very short key effectivity periods are theoretically possible, when replacing keys one has to take into account the rollover considerations discussed in Sections 4.1 and 4.4. Key replacement endures for a couple of Maximum Zone TTLs, depending on the rollover scenario. Therefore, a multiple of Maximum Zone TTL durations is a reasonable lower limit on the key effectivity period. Forcing a shorter key effectivity period will result in an unnecessary and inconveniently large DNSKEY RRset published in the zone.
虽然理论上很短的钥匙有效期是可能的，但更换钥匙时，必须考虑第4.1节和第4.4节中讨论的翻车注意事项。根据翻滚场景，钥匙更换会持续几个最大区域TTL。因此，最大区域TTL持续时间的倍数是关键有效期的合理下限。强制缩短密钥有效期将导致在区域中发布不必要且不方便的大型DNSKEY RRset。
The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that it is more likely that operators have more frequent read access to the ZSK than to the KSK. Thus, in cases where the ZSK cannot be afforded the same level of protection as the KSK (such as when zone keys are kept online), and where the risk of unauthorized disclosure of the ZSK's private key is not negligible (e.g., when HSMs are not in use), the ZSK's effectivity period should be kept shorter than the KSK's effectivity period.
使ZSK有效期短于KSK有效期的动机源于运营考虑，即运营商对ZSK的读访问比KSK更频繁。因此，如果无法为ZSK提供与KSK相同级别的保护（如区域密钥保持在线），并且未经授权泄露ZSK私钥的风险不可忽略（如HSM未使用），则ZSK的有效期应短于KSK的有效期。
In fact, if the risk of loss, theft, or other compromise is the same for a ZSK and a KSK, there is little reason to choose different effectivity periods for ZSKs and KSKs. And when the split between ZSKs and KSKs is not made, the argument is redundant.
事实上，如果ZSK和KSK的损失、被盗或其他损害风险相同，则几乎没有理由为ZSK和KSK选择不同的有效期。当zsk和ksk之间没有进行分割时，参数是多余的。
There are certainly cases in which the use of a Single-Type Signing Scheme with a long key effectivity period is a good choice, for example, where the costs and risks of compromise, and the costs and risks involved with having to perform an emergency roll, are low.
当然，在某些情况下，使用具有长密钥有效期的单一类型签名方案是一个不错的选择，例如，在这些情况下，妥协的成本和风险以及执行紧急登记所涉及的成本和风险都很低。
At the time of this writing, there are three types of signature algorithms that can be used in DNSSEC: RSA, Digital Signature Algorithm (DSA), and GOST. Proposals for other algorithms are in the making. All three are fully specified in many freely available documents and are widely considered to be patent-free. The creation of signatures with RSA and DSA takes roughly the same time, but DSA is about ten times slower for signature verification. Also note that, in the context of DNSSEC, DSA is limited to a maximum of 1024-bit keys.
在撰写本文时，DNSSEC中可以使用三种类型的签名算法：RSA、数字签名算法（DSA）和GOST。其他算法的建议正在制定中。所有这三项都在许多免费提供的文件中详细说明，并被广泛认为是无专利的。使用RSA和DSA创建签名所需的时间大致相同，但DSA的签名验证速度要慢十倍左右。还请注意，在DNSSEC的上下文中，DSA限制为最多1024位密钥。
We suggest the use of RSA/SHA-256 as the preferred signature algorithm and RSA/SHA-1 as an alternative. Both have advantages and disadvantages. RSA/SHA-1 has been deployed for many years, while RSA/SHA-256 has only begun to be deployed. On the other hand, it is expected that if effective attacks on either algorithm appear, they will appear for RSA/SHA-1 first. RSA/MD5 should not be considered for use because RSA/MD5 will very likely be the first common-use signature algorithm to be targeted for an effective attack.
我们建议使用RSA/SHA-256作为首选签名算法，使用RSA/SHA-1作为替代方案。两者都有优点和缺点。RSA/SHA-1已经部署多年，而RSA/SHA-256才刚刚开始部署。另一方面，如果出现对任一算法的有效攻击，则RSA/SHA-1将首先出现攻击。不应考虑使用RSA/MD5，因为RSA/MD5很可能是第一个针对有效攻击的常用签名算法。
At the time of publication, it is known that the SHA-1 hash has cryptanalysis issues, and work is in progress to address them. The use of public-key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256) is recommended, if these algorithms are available in implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]).
在发布时，已知SHA-1哈希存在密码分析问题，目前正在解决这些问题。如果这些算法在实现中可用（请参阅RFC 5702[RFC5702]和RFC 4509[RFC4509]），则建议使用基于比SHA-1（例如SHA-256）更强的散列的公钥算法。
Also, at the time of publication, digital signature algorithms based on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933], Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are being standardized and implemented. The use of EC has benefits in terms of size. On the other hand, one has to balance that against the amount of validating resolver implementations that will not recognize EC signatures and thus treat the zone as insecure. Beyond the observation of this tradeoff, we will not discuss this further.
此外，在出版时，基于DNSSEC的椭圆曲线（EC）加密的数字签名算法（GOST[RFC5933]，椭圆曲线数字签名算法（ECDSA）[RFC6605]）正在标准化和实现。使用EC在尺寸方面有好处。另一方面，我们必须平衡这一点和验证解析器实现的数量，这些解析器实现将无法识别EC签名，因此将区域视为不安全的。除了观察这一权衡之外，我们将不再进一步讨论这一问题。
This section assumes RSA keys, as suggested in the previous section.
本节假设RSA密钥，如前一节所述。
DNSSEC signing keys should be large enough to avoid all known cryptographic attacks during the effectivity period of the key. To date, despite huge efforts, no one has broken a regular 1024-bit key; in fact, the best completed attack is estimated to be the equivalent of a 700-bit key. An attacker breaking a 1024-bit signing key would need to expend phenomenal amounts of networked computing power in a
DNSSEC签名密钥应足够大，以避免密钥有效期内的所有已知加密攻击。迄今为止，尽管付出了巨大的努力，但还没有人破解一个常规的1024位密钥；事实上，估计完成得最好的攻击相当于700位密钥。攻击者破解1024位签名密钥需要在一个特定的时间内消耗大量的网络计算能力
way that would not be detected in order to break a single key. Because of this, it is estimated that most zones can safely use 1024-bit keys for at least the next ten years. (A 1024-bit asymmetric key has an approximate equivalent strength of a symmetric 80-bit key.)
断开一把钥匙时无法检测到的方式。因此，估计大多数区域至少在未来十年内可以安全地使用1024位密钥。（1024位非对称密钥的强度近似等于对称80位密钥的强度。）
Depending on local policy (e.g., owners of keys that are used as extremely high value trust anchors, or non-anchor keys that may be difficult to roll over), it may be advisable to use lengths longer than 1024 bits. Typically, the next larger key size used is 2048 bits, which has the approximate equivalent strength of a symmetric 112-bit key (RFC 3766 [RFC3766]). Signing and verifying with a 2048-bit key takes longer than with a 1024-bit key. The increase depends on software and hardware implementations, but public operations (such as verification) are about four times slower, while private operations (such as signing) are about eight times slower.
根据本地策略（例如，用作极高值信任锚点的密钥的所有者，或可能难以滚动的非锚点密钥），建议使用长度大于1024位的密钥。通常，使用的下一个较大的密钥大小是2048位，其具有对称112位密钥（RFC 3766[RFC3766]）的近似等效强度。使用2048位密钥进行签名和验证比使用1024位密钥需要更长的时间。增长取决于软件和硬件实现，但公共操作（如验证）的速度大约慢四倍，而私人操作（如签名）的速度大约慢八倍。
Another way to decide on the size of a key to use is to remember that the effort it takes for an attacker to break a 1024-bit key is the same, regardless of how the key is used. If an attacker has the capability of breaking a 1024-bit DNSSEC key, he also has the capability of breaking one of the many 1024-bit Transport Layer Security (TLS) [RFC5246] trust anchor keys that are currently installed in web browsers. If the value of a DNSSEC key is lower to the attacker than the value of a TLS trust anchor, the attacker will use the resources to attack the latter.
决定要使用的密钥大小的另一种方法是记住，无论如何使用该密钥，攻击者破解1024位密钥所需的努力是相同的。如果攻击者能够破解1024位DNSSEC密钥，那么他还能够破解当前安装在web浏览器中的多个1024位传输层安全（TLS）[RFC5246]信任锚密钥之一。如果攻击者认为DNSSEC密钥的值低于TLS信任锚的值，则攻击者将使用资源攻击TLS信任锚。
It is possible that there will be an unexpected improvement in the ability for attackers to break keys and that such an attack would make it feasible to break 1024-bit keys but not 2048-bit keys. If such an improvement happens, it is likely that there will be a huge amount of publicity, particularly because of the large number of 1024-bit TLS trust anchors built into popular web browsers. At that time, all 1024-bit keys (both ones with parent zones and ones that are trust anchors) can be rolled over and replaced with larger keys.
攻击者破解密钥的能力可能会有意外的提高，这种攻击可能会使破解1024位密钥而不是2048位密钥成为可能。如果出现这样的改进，很可能会有大量的宣传，特别是因为流行的web浏览器中内置了大量1024位TLS信任锚。此时，所有1024位密钥（包括具有父区域的密钥和作为信任锚点的密钥）都可以滚动并替换为较大的密钥。
Earlier documents (including the previous version of this document) urged the use of longer keys in situations where a particular key was "heavily used". That advice may have been true 15 years ago, but it is not true today when using RSA algorithms and keys of 1024 bits or higher.
早期文件（包括本文件的前一版本）敦促在“大量使用”特定钥匙的情况下使用更长的钥匙。这个建议在15年前可能是正确的，但在今天使用RSA算法和1024位或更高的密钥时就不正确了。
It is preferred that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off-line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC/NSEC3 RRs. Then the augmented file can be transferred to the master.
在可能的情况下，最好仅在离线、非网络连接、物理安全的机器中保存和使用区域私钥和要签名的区域文件主副本。可以定期运行应用程序，通过添加RRSIG和NSEC/NSEC3 RRs向区域添加身份验证。然后，可以将扩充文件传输到主文件。
When relying on dynamic update [RFC3007] or any other update mechanism that runs at a regular interval to manage a signed zone, be aware that at least one private key of the zone will have to reside on the master server or reside on an HSM to which the server has access. This key is only as secure as the amount of exposure the server receives to unknown clients and on the level of security of the host. Although not mandatory, one could administer a zone using a "hidden master" scheme to minimize the risk. In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset. The name servers in the NS RRset are able to receive zone updates through IXFR, AXFR, or an out-of-band distribution mechanism, possibly in combination with NOTIFY or another mechanism to trigger zone replication.
当依靠动态更新[RFC3007]或任何其他定期运行的更新机制来管理签名区域时，请注意，该区域的至少一个私钥必须驻留在主服务器上或驻留在服务器有权访问的HSM上。此密钥的安全性取决于服务器对未知客户端的暴露量以及主机的安全级别。虽然不是强制性的，但可以使用“隐藏主”方案管理区域，以将风险降至最低。在该布置中，处理更新的主名称服务器对于因特网上的普通主机不可用；它未列在NS RRset中。NS RRset中的名称服务器能够通过IXFR、AXFR或带外分发机制（可能与NOTIFY或其他触发区域复制的机制结合使用）接收区域更新。
The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network-mediated communication.
理想的情况是向网络提供单向信息流，以避免网络篡改的可能性。让区域主机在网络上保持在线，并通过离线签名者简单地将其循环使用，并不能做到这一点。如果在线版本所在的主机被破坏，在线版本仍然可能被篡改。为了最大限度地提高安全性，区域文件的主副本应为离线，并且不应基于不安全的网络中介通信进行更新。
The ideal situation may not be achievable because of economic tradeoffs between risks and costs. For instance, keeping a zone file off-line is not practical and will increase the costs of operating a DNS zone. So, in practice, the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield the master copy against unauthorized access in order to prevent modification of DNS data before it is signed.
由于风险和成本之间的经济权衡，理想情况可能无法实现。例如，使区域文件脱机是不实际的，并且会增加DNS区域的操作成本。因此，在实践中，维护区域文件的机器将连接到网络。建议运营商采取安全措施保护主副本，防止未经授权的访问，以防止在签署DNS数据之前对其进行修改。
Similarly, the choice for storing a private key in an HSM will be influenced by a tradeoff between various concerns:
类似地，在HSM中存储私钥的选择将受到各种关注点之间权衡的影响：
o The risks that an unauthorized person has unnoticed read access to the private key.
o 未经授权的人对私钥有未被注意到的读访问权的风险。
o The remaining window of opportunity for the attacker.
o 攻击者的剩余机会窗口。
o The economic impact of the possible attacks (for a TLD, that impact will typically be higher than for an individual user).
o 可能攻击的经济影响（对于TLD，这种影响通常比单个用户更大）。
o The costs of rolling the (compromised) keys. (The cost of rolling a ZSK is lowest, and the cost of rolling a KSK that is in wide use as a trust anchor is highest.)
o 滚动（泄露）密钥的成本。（滚动ZSK的成本最低，滚动广泛用作信任锚的KSK的成本最高。）
o The costs of buying and maintaining an HSM.
o 购买和维护HSM的成本。
For dynamically updated secured zones [RFC3007], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line.
对于动态更新的安全区域[RFC3007]，更新的RRs上用于更新签名的主副本和私钥都需要在线。
Careful generation of all keys is a sometimes overlooked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in RFC 4086 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In particular, one should carefully assess whether the random number generator used during key generation adheres to these suggestions. Typically, HSMs tend to provide a good facility for key generation.
在任何加密安全系统中，仔细地生成所有密钥有时是一个被忽略但绝对必要的元素。如果对手能够猜出足够多的信息来降低可能的密钥空间的大小，以便对其进行彻底搜索，那么使用最长密钥的最强算法仍然没有用处。生成随机密钥的技术建议见RFC 4086[RFC4086]和NIST SP 800-90A[NIST-SP-800-90A]。特别是，应该仔细评估密钥生成过程中使用的随机数生成器是否符合这些建议。通常，HSM倾向于为密钥生成提供良好的工具。
Keys with a long effectivity period are particularly sensitive, as they will represent a more valuable target and be subject to attack for a longer time than short-period keys. It is preferred that long-term key generation occur off-line in a manner isolated from the network via an air gap or, at a minimum, high-level secure hardware.
具有长有效期的密钥特别敏感，因为它们将代表一个更有价值的目标，并且比短周期密钥更容易受到攻击。优选地，长期密钥生成以通过气隙或至少高级安全硬件与网络隔离的方式离线发生。
An earlier version of this document (RFC 4641 [RFC4641]) made a differentiation between key lengths for KSKs used for zones that are high in the DNS hierarchy and those for KSKs used lower down in the hierarchy.
本文档的早期版本（RFC 4641[RFC4641]）对用于DNS层次结构中较高区域的KSK的密钥长度和用于层次结构中较低区域的KSK的密钥长度进行了区分。
This distinction is now considered irrelevant. Longer key lengths for keys higher in the hierarchy are not useful because the cryptographic guidance is that everyone should use keys that no one can break. Also, it is impossible to judge which zones are more or less valuable to an attacker. An attack can only take place if the key compromise goes unnoticed and the attacker can act as a man-in-the-middle (MITM). For example, if example.com is compromised, and the attacker forges answers for somebank.example.com. and sends them out during an MITM, when the attack is discovered it will be simple to prove that example.com has been compromised, and the KSK will be rolled.
这种区别现在被认为是无关紧要的。对于层次结构中较高的密钥，更长的密钥长度是没有用的，因为密码指南是每个人都应该使用没有人可以破解的密钥。此外，无法判断哪些区域对攻击者的价值大小。只有在未注意到密钥泄露且攻击者可以充当中间人（MITM）时，才会发生攻击。例如，如果example.com遭到破坏，攻击者会伪造somebank.example.com的答案。并在MITM期间发送它们，当发现攻击时，很容易证明example.com已被破坏，KSK将被推出。
Regardless of whether a zone uses periodic key rollovers or only rolls keys in case of an irregular event, key rollovers are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account the fact that data published in previous versions of their zone still lives in caches. When deploying DNSSEC, this becomes an important consideration; ignoring data that may be in caches may lead to loss of service for clients.
无论分区是使用定期关键点翻转还是在发生不规则事件时仅滚动关键点，使用DNSSEC时关键点翻转都是事实。正在滚动密钥的区域管理员必须考虑以下事实：在其区域的早期版本中发布的数据仍然存在于缓存中。在部署DNSSEC时，这成为一个重要的考虑因素；忽略缓存中的数据可能会导致客户端的服务丢失。
The most pressing example of this occurs when zone material signed with an old key is being validated by a resolver that does not have the old zone key cached. If the old key is no longer present in the current zone, this validation fails, marking the data Bogus. Alternatively, an attempt could be made to validate data that is signed with a new key against an old key that lives in a local cache, also resulting in data being marked Bogus.
最紧迫的例子发生在使用旧密钥签名的区域材质由未缓存旧区域密钥的解析程序验证时。如果旧密钥不再存在于当前区域中，则此验证将失败，标记为数据伪造。或者，可以尝试验证使用新密钥签名的数据与驻留在本地缓存中的旧密钥，这也会导致数据被标记为伪造。
The typographic conventions used in the diagrams below are explained in Appendix B.
附录B解释了下图中使用的排版惯例。
If the choice for splitting ZSKs and KSKs has been made, then those two types of keys can be rolled separately, and ZSKs can be rolled without taking into account DS records from the parent or the configuration of such a key as the trust anchor.
如果选择了拆分ZSK和KSK，则可以分别滚动这两种类型的密钥，并且可以滚动ZSK，而不考虑来自父级的DS记录或此类密钥（如信任锚）的配置。
For "Zone Signing Key rollovers", there are two ways to make sure that during the rollover data still cached can be verified with the new key sets or newly generated signatures can be verified with the keys still in caches. One scheme, described in Section 4.1.1.1, uses
对于“区域签名密钥翻转”，有两种方法可以确保在翻转期间仍然缓存的数据可以用新密钥集进行验证，或者新生成的签名可以用仍然缓存的密钥进行验证。第4.1.1.1节中描述的一个方案使用
key pre-publication; the other uses double signatures, as described in Section 4.1.1.2. The pros and cons are described in Section 4.1.1.3.
关键预发布；另一个使用双重签名，如第4.1.1.2节所述。第4.1.1.3节描述了利弊。
This section shows how to perform a ZSK rollover without the need to sign all the data in a zone twice -- the "Pre-Publish key rollover". This method has advantages in the case of a key compromise. If the old key is compromised, the new key has already been distributed in the DNS. The zone administrator is then able to quickly switch to the new key and remove the compromised key from the zone. Another major advantage is that the zone size does not double, as is the case with the Double-Signature ZSK rollover.
本节介绍如何执行ZSK滚动，而无需对区域中的所有数据进行两次签名——“预发布密钥滚动”。这种方法在密钥泄露的情况下具有优势。如果旧密钥被泄露，则新密钥已在DNS中分发。然后，区域管理员可以快速切换到新密钥，并从区域中删除受损密钥。另一个主要优点是，区域大小不会像双签名ZSK滚动那样翻倍。
Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves four stages as follows:
从DNSKEY_Z_10到DNSKEY_Z_11的预发布密钥翻转包括以下四个阶段：
------------------------------------------------------------
initial new DNSKEY new RRSIGs
------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
------------------------------------------------------------
initial new DNSKEY new RRSIGs
------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
------------------------------------------------------------
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
DNSKEY removal
------------------------------------------------------------
SOA_3
RRSIG_Z_11(SOA)
------------------------------------------------------------
DNSKEY removal
------------------------------------------------------------
SOA_3
RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_Z_11
DNSKEY_K_1 DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
------------------------------------------------------------
RRSIG_K_1(DNSKEY)
------------------------------------------------------------
Figure 1: Pre-Publish Key Rollover
图1：预发布键滚动
initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., it is the Zone Signing Key.
初始：区域的初始版本：DNSKEY_K_1是密钥签名密钥。DNSKEY_Z_10用于对区域的所有数据进行签名，即它是区域签名密钥。
new DNSKEY: DNSKEY_Z_11 is introduced into the key set (note that no signatures are generated with this key yet, but this does not secure against brute force attacks on its public key). The minimum duration of this pre-roll phase is the time it takes for the data to propagate to the authoritative servers, plus the TTL value of the key set.
新的DNSKEY:DNSKEY_Z_11被引入密钥集中（请注意，此密钥尚未生成签名，但这无法防止对其公钥的暴力攻击）。此预滚动阶段的最短持续时间是数据传播到权威服务器所需的时间，加上密钥集的TTL值。
new RRSIGs: At the "new RRSIGs" stage, DNSKEY_Z_11 is used to sign the data in the zone exclusively (i.e., all the signatures from DNSKEY_Z_10 are removed from the zone). DNSKEY_Z_10 remains published in the key set. This way, data that was loaded into caches from the zone in the "new DNSKEY" step can still be verified with key sets fetched from this version of the zone. The minimum time that the key set including DNSKEY_Z_10 is to be published is the time that it takes for zone data from the previous version of the zone to expire from old caches, i.e., the time it takes for this zone to propagate to all authoritative servers, plus the Maximum Zone TTL value of any of the data in the previous version of the zone.
新RRSIGs：在“新RRSIGs”阶段，DNSKEY_Z_11用于以独占方式对区域中的数据进行签名（即，来自DNSKEY_Z_10的所有签名将从区域中删除）。DNSKEY_Z_10仍在密钥集中发布。这样，在“new DNSKEY”步骤中从区域加载到缓存中的数据仍然可以使用从此版本的区域获取的密钥集进行验证。要发布包括DNSKEY_Z_10在内的密钥集的最短时间是来自以前版本区域的区域数据从旧缓存过期所需的时间，即此区域传播到所有权威服务器所需的时间，加上以前版本区域中任何数据的最大区域TTL值。
DNSKEY removal: DNSKEY_Z_10 is removed from the zone. The key set, now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with DNSKEY_K_1.
DNSKEY移除：DNSKEY_Z_10从区域移除。密钥集现在只包含DNSKEY_K_1和DNSKEY_Z_11，使用DNSKEY_K_1重新签名。
The above scheme can be simplified by always publishing the "future" key immediately after the rollover. The scheme would look as follows (we show two rollovers); the future key is introduced in "new DNSKEY" as DNSKEY_Z_12 and again a newer one, numbered 13, in "new DNSKEY (II)":
通过总是在翻滚后立即发布“future”密钥，可以简化上述方案。该方案如下所示（我们展示了两次滚动）；未来密钥在“新DNSKEY”中作为DNSKEY_Z_12引入，在“新DNSKEY（II）”中再次引入编号为13的新密钥：
initial new RRSIGs new DNSKEY
-----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
initial new RRSIGs new DNSKEY
-----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11
DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11
DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA_3 SOA_4
RRSIG_Z_12(SOA) RRSIG_Z_12(SOA)
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA_3 SOA_4
RRSIG_Z_12(SOA) RRSIG_Z_12(SOA)
DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_11 DNSKEY_Z_12
DNSKEY_Z_12 DNSKEY_Z_13
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_11 DNSKEY_Z_12
DNSKEY_Z_12 DNSKEY_Z_13
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
Figure 2: Pre-Publish Zone Signing Key Rollover, Showing Two Rollovers
图2：预发布区域签名密钥滚动，显示两个滚动
Note that the key introduced in the "new DNSKEY" phase is not used for production yet; the private key can thus be stored in a physically secure manner and does not need to be 'fetched' every time a zone needs to be signed.
注意，“新DNSKEY”阶段引入的钥匙尚未用于生产；因此，私钥可以以物理安全的方式存储，并且不需要在每次需要签名区域时“获取”。
This section shows how to perform a ZSK rollover using the double zone data signature scheme, aptly named "Double-Signature rollover".
本节介绍如何使用双区域数据签名方案执行ZSK滚动，该方案被恰当地命名为“双签名滚动”。
During the "new DNSKEY" stage, the new version of the zone file will need to propagate to all authoritative servers and the data that exists in (distant) caches will need to expire, requiring at least the propagation delay plus the Maximum Zone TTL of previous versions of the zone.
在“新DNSKEY”阶段，区域文件的新版本将需要传播到所有权威服务器，并且（远程）缓存中存在的数据将需要过期，至少需要传播延迟加上区域先前版本的最大区域TTL。
Double-Signature ZSK rollover involves three stages as follows:
双重签名ZSK展期包括以下三个阶段：
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
Figure 3: Double-Signature Zone Signing Key Rollover
图3：双重签名区域签名密钥翻转
initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., it is the Zone Signing Key.
初始：区域的初始版本：DNSKEY_K_1是密钥签名密钥。DNSKEY_Z_10用于对区域的所有数据进行签名，即它是区域签名密钥。
new DNSKEY: At the "new DNSKEY" stage, DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need to continue until all data from version 0 (i.e., the version of the zone data containing SOA_0) of the zone has been replaced in all secondary servers and then has expired from remote caches. This will take at least the propagation delay plus the Maximum Zone TTL of version 0 of the zone.
新DNSKEY：在“新DNSKEY”阶段，DNSKEY_Z_11被引入密钥集中，区域中的所有数据都用DNSKEY_Z_10和DNSKEY_Z_11签名。滚动期将需要继续，直到区域版本0（即包含SOA_0的区域数据版本）中的所有数据在所有辅助服务器中被替换，然后从远程缓存中过期。这至少需要传播延迟加上区域版本0的最大区域TTL。
DNSKEY removal: DNSKEY_Z_10 is removed from the zone, as are all signatures created with it. The key set, now only containing DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11.
DNSKEY删除：DNSKEY_Z_10将从区域中删除，使用它创建的所有签名也是如此。密钥集现在只包含DNSKEY_Z_11，并用DNSKEY_K_1和DNSKEY_Z_11重新签名。
At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRset from the current version and vice versa. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the propagation delay to secondary servers plus the Maximum Zone TTL of the previous version of the zone.
在任何情况下，都可以使用当前版本的DNSKEY RRset验证以前版本的区域的RRSIG，反之亦然。“新DNSKEY”阶段的持续时间和翻滚之间的时间应至少为到辅助服务器的传播延迟加上区域先前版本的最大区域TTL。
Note that in this example we assumed for simplicity that the zone was not modified during the rollover. In fact, new data can be introduced at any time during this period, as long as it is signed with both keys.
请注意，在本例中，为了简单起见，我们假设在滚动期间未修改分区。事实上，在此期间的任何时候都可以引入新数据，只要使用两个密钥签名即可。
Pre-Publish key rollover: This rollover does not involve signing the zone data twice. Instead, before the actual rollover, the new key is published in the key set and thus is available for cryptanalysis attacks. A small disadvantage is that this process requires four stages. Also, the Pre-Publish scheme involves more parental work when used for KSK rollovers, as explained in Section 4.1.2.
预发布密钥滚动：此滚动不涉及对区域数据进行两次签名。相反，在实际翻滚之前，新密钥在密钥集中发布，因此可用于密码分析攻击。一个小缺点是这个过程需要四个阶段。此外，如第4.1.2节所述，当用于KSK滚动时，预发布方案涉及更多的家长工作。
Double-Signature ZSK rollover: The drawback of this approach is that during the rollover the number of signatures in your zone doubles; this may be prohibitive if you have very big zones. An advantage is that it only requires three stages.
双重签名ZSK展期：这种方法的缺点是，在展期期间，您所在区域的签名数量加倍；如果你有非常大的区域，这可能是禁止的。优点是它只需要三个阶段。
For the rollover of a Key Signing Key, the same considerations as for the rollover of a Zone Signing Key apply. However, we can use a Double-Signature scheme to guarantee that old data (only the apex key set) in caches can be verified with a new key set and vice versa. Since only the key set is signed with a KSK, zone size considerations do not apply.
对于密钥签名密钥的滚动，适用与区域签名密钥滚动相同的注意事项。然而，我们可以使用双重签名方案来保证缓存中的旧数据（仅apex密钥集）可以用新密钥集进行验证，反之亦然。由于只有密钥集使用KSK签名，因此区域大小考虑不适用。
Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing trust anchors) and the ensuing delay while waiting for it.
请注意，KSK转期和ZSK转期的不同之处在于，KSK转期需要与父级交互（可能需要更换信任锚点）以及等待时的延迟。
---------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
---------------------------------------------------------------------
Parent:
SOA_0 -----------------------------> SOA_1 ------------------------>
RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
DS_K_1 ----------------------------> DS_K_2 ----------------------->
RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->
---------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
---------------------------------------------------------------------
Parent:
SOA_0 -----------------------------> SOA_1 ------------------------>
RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
DS_K_1 ----------------------------> DS_K_2 ----------------------->
RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->
Child:
SOA_0 SOA_1 -----------------------> SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)
Child:
SOA_0 SOA_1 -----------------------> SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)
DNSKEY_K_1 DNSKEY_K_1 ------------------>
DNSKEY_K_2 ------------------> DNSKEY_K_2
DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10
RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ---------->
RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
---------------------------------------------------------------------
DNSKEY_K_1 DNSKEY_K_1 ------------------>
DNSKEY_K_2 ------------------> DNSKEY_K_2
DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10
RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ---------->
RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
---------------------------------------------------------------------
Figure 4: Stages of Deployment for a Double-Signature Key Signing Key Rollover
图4：双签名密钥滚动的部署阶段
initial: Initial version of the zone. The parental DS points to DNSKEY_K_1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- it is needed during the rollover, and we refer to the value as TTL_DS.
初始：区域的初始版本。家长DS指向DNSKEY_K_1。在翻滚开始之前，子级必须验证指向DNSKEY_K_1的DS RR的TTL是什么——翻滚期间需要它，我们将该值称为TTL_DS。
new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY_K_2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches.
新建DNSKEY：在“新建DNSKEY”阶段，区域管理员生成第二个KSK，DNSKEY_K_2。密钥将提供给父级，子级必须等待生成指向DNSKEY_K_2的新DS RR。在父区域的所有权威服务器上发布DS RR后，区域管理员必须至少等待TTL_DS，以确保旧DS RR已从缓存中过期。
DS change: The parent replaces DS_K_1 with DS_K_2.
DS更改：父级将DS_K_1替换为DS_K_2。
DNSKEY removal: DNSKEY_K_1 has been removed.
DNSKEY移除：DNSKEY_K_1已移除。
The scenario above puts the responsibility for maintaining a valid chain of trust with the child. It also is based on the premise that the parent only has one DS RR (per algorithm) per zone. An alternative mechanism has been considered. Using an established trust relationship, the interaction can be performed in-band, and the removal of the keys by the child can possibly be signaled by the parent. In this mechanism, there are periods where there are two DS
上面的场景将负责维护与孩子的有效信任链。它还基于这样一个前提，即父级每个区域只有一个DS RR（每个算法）。已经考虑了另一种机制。使用已建立的信任关系，可以在频带内执行交互，并且可以由父级发出由子级移除密钥的信号。在这种机制中，存在两个D的周期
RRs at the parent. This is known as a KSK Double-DS rollover and is shown in Figure 5. This method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks.
RRs在父级。这称为KSK双DS翻转，如图5所示。这种方法对于KSK有一些缺点。我们首先描述滚动方案，然后指出这些缺点。
--------------------------------------------------------------------
initial new DS new DNSKEY DS removal
--------------------------------------------------------------------
Parent:
SOA_0 SOA_1 ------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
DS_K_1 DS_K_1 ----------------------->
DS_K_2 -----------------------> DS_K_2
RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS)
--------------------------------------------------------------------
initial new DS new DNSKEY DS removal
--------------------------------------------------------------------
Parent:
SOA_0 SOA_1 ------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
DS_K_1 DS_K_1 ----------------------->
DS_K_2 -----------------------> DS_K_2
RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS)
Child:
SOA_0 -----------------------> SOA_1 ---------------------------->
RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>
Child:
SOA_0 -----------------------> SOA_1 ---------------------------->
RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>
DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
--------------------------------------------------------------------
DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
--------------------------------------------------------------------
Figure 5: Stages of Deployment for a Double-DS Key Signing Key Rollover
图5：双DS密钥签名密钥翻转的部署阶段
When the child zone wants to roll, it notifies the parent during the "new DS" phase and submits the new key (or the corresponding DS) to the parent. The parent publishes DS_K_1 and DS_K_2, pointing to DNSKEY_K_1 and DNSKEY_K_2, respectively. During the rollover ("new DNSKEY" phase), which can take place as soon as the new DS set propagated through the DNS, the child replaces DNSKEY_K_1 with DNSKEY_K_2. If the old key has expired from caches, at the "DS removal" phase the parent can be notified that the old DS record can be deleted.
当子区域想要滚动时，它会在“新DS”阶段通知父区域，并将新密钥（或相应的DS）提交给父区域。父对象发布DS_K_1和DS_K_2，分别指向DNSKEY_K_1和DNSKEY_K_2。在滚动（“新DNSKEY”阶段）期间（新DS集通过DNS传播后立即发生），子级将DNSKEY_K_1替换为DNSKEY_K_2。如果旧密钥已从缓存中过期，则在“DS删除”阶段，可以通知父级可以删除旧DS记录。
The drawbacks of this scheme are that during the "new DS" phase, the parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 using the DNS, as DNSKEY_K_2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.3.3). Finally, the child-parent interaction consists of two steps. The "Double Signature" method only needs one interaction.
此方案的缺点是，在“新DS”阶段，父级无法使用DNS验证DS_K_2 RR和DNSKEY_K_2之间的匹配，因为DNSKEY_K_2尚未发布。此外，我们还引入了“安全lame”密钥（见第4.3.3节）。最后，子-父交互包括两个步骤。“双重签名”方法只需要一次交互。
The scenario sketched above assumes that the KSK is not in use as a trust anchor but that validating name servers exclusively depend on the parental DS record to establish the zone's security. If it is known that validating name servers have configured trust anchors, then that needs to be taken into account. Here, we assume that zone administrators will deploy RFC 5011 [RFC5011] style rollovers.
上面概述的场景假设KSK没有用作信任锚，但验证名称服务器完全依赖于父DS记录来建立区域的安全性。如果已知验证名称服务器已配置信任锚，则需要考虑这一点。这里，我们假设区域管理员将部署RFC 5011[RFC5011]样式的滚动。
RFC 5011 style rollovers increase the duration of key rollovers: The key to be removed must first be revoked. Thus, before the DNSKEY_K_1 removal phase, DNSKEY_K_1 must be published for one more Maximum Zone TTL with the REVOKE bit set. The revoked key must be self-signed, so in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1.
RFC 5011样式的滚动增加了密钥滚动的持续时间：必须首先撤销要删除的密钥。因此，在DNSKEY_K_1删除阶段之前，必须为设置了REVOKE位的另一个最大区域TTL发布DNSKEY_K_1。吊销的密钥必须是自签名的，因此在此阶段，DNSKEY RRset还必须使用DNSKEY_K_1进行签名。
The rollover of a key when a Single-Type Signing Scheme is used is subject to the same requirement as the rollover of a KSK or ZSK: During any stage of the rollover, the chain of trust needs to continue to validate for any combination of data in the zone as well as data that may still live in distant caches.
使用单一类型签名方案时，密钥的展期与KSK或ZSK的展期受相同要求的约束：在展期的任何阶段，信任链都需要继续验证区域中的任何数据组合以及可能仍位于远程缓存中的数据。
There are two variants for this rollover. Since the choice for a Single-Type Signing Scheme is motivated by operational simplicity, we describe the most straightforward rollover scheme first.
此翻转有两种变体。由于选择单一类型的签名方案是出于操作简单性的考虑，因此我们首先描述最简单的滚动方案。
-------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
-------------------------------------------------------------------
Parent:
SOA_0 --------------------------> SOA_1 ---------------------->
RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
DS_S_1 -------------------------> DS_S_2 --------------------->
RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->
-------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
-------------------------------------------------------------------
Parent:
SOA_0 --------------------------> SOA_1 ---------------------->
RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
DS_S_1 -------------------------> DS_S_2 --------------------->
RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->
Child:
SOA_0 SOA_1 ----------------------> SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------->
RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 ----------------->
DNSKEY_S_2 -----------------> DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
-------------------------------------------------------------------
Child:
SOA_0 SOA_1 ----------------------> SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------->
RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 ----------------->
DNSKEY_S_2 -----------------> DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
-------------------------------------------------------------------
Figure 6: Stages of the Straightforward Rollover in a Single-Type Signing Scheme
图6：单一类型签名方案中的直接滚动阶段
initial: Parental DS points to DNSKEY_S_1. All RRsets in the zone are signed with DNSKEY_S_1.
首字母：家长DS指向DNSKEY_S_1。区域中的所有RRSET均与DNSKEY_S_1签署。
new DNSKEY: A new key (DNSKEY_S_2) is introduced, and all the RRsets are signed with both DNSKEY_S_1 and DNSKEY_S_2.
新DNSKEY：引入了一个新密钥（DNSKEY_S_2），所有RRSET都使用DNSKEY_S_1和DNSKEY_S_2进行签名。
DS change: After the DNSKEY RRset with the two keys had time to propagate into distant caches (that is, the key set exclusively containing DNSKEY_S_1 has been expired), the parental DS record can be changed.
DS更改：具有两个密钥的DNSKEY RRset有时间传播到远程缓存后（即，专门包含DNSKEY_S_1的密钥集已过期），可以更改父DS记录。
DNSKEY removal: After the DS RRset containing DS_S_1 has expired from distant caches, DNSKEY_S_1 can be removed from the DNSKEY RRset.
DNSKEY删除：包含DS_S_1的DS RRset从远程缓存过期后，可以从DNSKEY RRset中删除DNSKEY_S_1。
In this first variant, the new signatures and new public key are added to the zone. Once they are propagated, the DS at the parent is switched. If the old DS has expired from the caches, the old signatures and old public key can be removed from the zone.
在第一种变体中，新签名和新公钥被添加到区域中。一旦它们被传播，父级的DS将被切换。如果旧DS已从缓存中过期，则可以从区域中删除旧签名和旧公钥。
This rollover has the drawback that it introduces double signatures over all data of the zone. Taking these zone size considerations into account, it is possible to not introduce the signatures made with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an additional stage between the "DS change" and "DNSKEY removal" step: After the DS RRset containing DS_S_1 has expired from distant caches, the signatures can be swapped. Only after the new signatures made with DNSKEY_S_2 have been propagated can the old public key DNSKEY_S_1 be removed from the DNSKEY RRset.
此滚动有一个缺点，即它在区域的所有数据上引入了双重签名。考虑到这些区域大小因素，可以不在“新DNSKEY”步骤中引入使用DNSKEY_S_2生成的签名。相反，在“DS更改”和“DNSKEY删除”步骤之间的另一个阶段，DNSKEY_S_1的签名替换为DNSKEY_S_2的签名：在包含DS_S_1的DS RRset从远程缓存过期后，可以交换签名。只有在传播了使用DNSKEY__2生成的新签名后，才能从DNSKEY RRset中删除旧公钥DNSKEY__1。
The second variant of the Single-Type Signing Scheme Key rollover is the Double-DS rollover. In this variant, one introduces a new DNSKEY into the key set and submits the new DS to the parent. The new key is not yet used to sign RRsets. The signatures made with DNSKEY_S_1 are replaced with signatures made with DNSKEY_S_2 at the moment that DNSKEY_S_2 and DS_S_2 have been propagated.
单类型签名方案密钥翻转的第二个变体是双DS翻转。在此变体中，将新的DNSKEY引入密钥集中，并将新的DS提交给父级。新密钥尚未用于签署RRSET。在传播DNSKEY_S_2和DS_S_2时，使用DNSKEY_S_1生成的签名将替换为使用DNSKEY_S_2生成的签名。
-----------------------------------------------------------------------
initial new DS new RRSIG DS removal
-----------------------------------------------------------------------
Parent:
SOA_0 SOA_1 -------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
DS_S_1 DS_S_1 ------------------------>
DS_S_2 ------------------------> DS_S_2
RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS)
-----------------------------------------------------------------------
initial new DS new RRSIG DS removal
-----------------------------------------------------------------------
Parent:
SOA_0 SOA_1 -------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
DS_S_1 DS_S_1 ------------------------>
DS_S_2 ------------------------> DS_S_2
RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS)
Child:
SOA_0 SOA_1 SOA_2 SOA_3
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA)
Child:
SOA_0 SOA_1 SOA_2 SOA_3
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2
RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
-----------------------------------------------------------------------
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2
RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
-----------------------------------------------------------------------
Figure 7: Stages of Deployment for a Double-DS Rollover in a Single-Type Signing Scheme
图7：单类型签名方案中双DS滚动的部署阶段
A special class of key rollovers is the one needed for a change of signature algorithms (either adding a new algorithm, removing an old algorithm, or both). Additional steps are needed to retain integrity during this rollover. We first describe the generic case; special considerations for rollovers that involve trust anchors and single-type keys are discussed later.
更改签名算法（添加新算法、删除旧算法或两者兼而有之）需要一类特殊的密钥翻转。需要额外的步骤来保持此翻滚期间的完整性。我们首先描述了一般情况；涉及信任锚和单一类型密钥的翻滚的特殊注意事项将在后面讨论。
There exist both a conservative and a liberal approach for algorithm rollover. This has to do with Section 2.2 of RFC 4035 [RFC4035]:
对于算法翻转，既有保守的方法，也有自由的方法。这与RFC 4035[RFC4035]第2.2节有关：
There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).
在区域顶点DNSKEY RRset中，每个RRset必须使用每个算法的至少一个DNSKEY具有RRSIG。apex DNSKEY RRset本身必须由位于委派父级（如果有）的DS RRset中出现的每个算法签名。
The conservative approach interprets this section very strictly, meaning that it expects that every RRset has a valid signature for every algorithm signaled by the zone apex DNSKEY RRset, including RRsets in caches. The liberal approach uses a more loose interpretation of the section and limits the rule to RRsets in the zone at the authoritative name servers. There is a reasonable argument for saying that this is valid, because the specific section is a subsection of Section 2 ("Zone Signing") of RFC 4035.
保守的方法对本节的解释非常严格，这意味着它期望每个RRset对zone apex DNSKEY RRset发出信号的每个算法都有一个有效的签名，包括缓存中的RRset。自由的方法对该部分使用了更为宽松的解释，并将规则限制为权威名称服务器区域中的RRSET。有合理的理由认为这是有效的，因为具体章节是RFC 4035第2节（“区域签署”）的一个子节。
When following the more liberal approach, algorithm rollover is just as easy as a regular Double-Signature KSK rollover (Section 4.1.2). Note that the Double-DS KSK rollover method cannot be used, since that would introduce a parental DS of which the apex DNSKEY RRset has not been signed with the introduced algorithm.
当采用更自由的方法时，算法翻转与常规双签名KSK翻转一样容易（第4.1.2节）。请注意，不能使用双DS KSK滚动方法，因为这将引入一个父DS，其apex DNSKEY RRset未使用引入的算法进行签名。
However, there are implementations of validators known to follow the more conservative approach. Performing a Double-Signature KSK algorithm rollover will temporarily make your zone appear as Bogus by such validators during the rollover. Therefore, the rollover described in this section will explain the stages of deployment and will assume that the conservative approach is used.
然而，有一些验证程序的实现采用了更保守的方法。执行双重签名KSK算法滚动将使您的区域在滚动期间暂时被此类验证器视为伪造。因此，本节中描述的滚动将解释部署的各个阶段，并假设使用保守的方法。
When adding a new algorithm, the signatures should be added first. After the TTL of RRSIGs has expired and caches have dropped the old data covered by those signatures, the DNSKEY with the new algorithm can be added.
添加新算法时，应首先添加签名。在RRSIGs的TTL过期并且缓存丢弃了这些签名所覆盖的旧数据之后，可以添加具有新算法的DNSKEY。
After the new algorithm has been added, the DS record can be exchanged using Double-Signature KSK rollover.
添加新算法后，可以使用双重签名KSK滚动来交换DS记录。
When removing an old algorithm, the DS for the algorithm should be removed from the parent zone first, followed by the DNSKEY and the signatures (in the child zone).
删除旧算法时，应首先从父区域删除该算法的DS，然后再删除DNSKEY和签名（在子区域中）。
Figure 8 describes the steps.
图8描述了这些步骤。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_2（DNSKEY）
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
------------------->
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_11 DNSKEY_Z_11
------------------->
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
------------------->
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_11 DNSKEY_Z_11
------------------->
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 8: Stages of Deployment during an Algorithm Rollover
图8：算法滚动期间的部署阶段
initial: Describes the state of the zone before any transition is done. The number of the keys may vary, but all keys (in DNSKEY records) for the zone use the same algorithm.
初始：描述完成任何转换之前区域的状态。密钥的数量可能会有所不同，但区域的所有密钥（在DNSKEY记录中）都使用相同的算法。
new RRSIGs: The signatures made with the new key over all records in the zone are added, but the key itself is not. This step is needed to propagate the signatures created with the new algorithm to the caches. If this is not done, it is possible for a resolver to retrieve the new DNSKEY RRset (containing the new algorithm) but to have RRsets in its cache with signatures created by the old DNSKEY RRset (i.e., without the new algorithm).
新RRSIGs：在区域中的所有记录上使用新密钥生成的签名都会被添加，但密钥本身不会。这一步需要将使用新算法创建的签名传播到缓存。如果不这样做，解析器可以检索新的DNSKEY RRset（包含新算法），但在其缓存中有RRset，其签名由旧的DNSKEY RRset创建（即，没有新算法）。
The RRSIG for the DNSKEY RRset does not need to be pre-published (since these records will travel together) and does not need special processing in order to keep them synchronized.
DNSKEY RRset的RRSIG不需要预先发布（因为这些记录将一起传输），也不需要进行特殊处理以保持同步。
new DNSKEY: After the old data has expired from caches, the new key can be added to the zone.
新DNSKEY：旧数据从缓存中过期后，可以将新密钥添加到区域中。
new DS: After the cache data for the old DNSKEY RRset has expired, the DS record for the new key can be added to the parent zone and the DS record for the old key can be removed in the same step.
新DS：旧DNSKEY RRset的缓存数据过期后，可以将新密钥的DS记录添加到父区域，并在同一步骤中删除旧密钥的DS记录。
DNSKEY removal: After the cache data for the old DS RRset has expired, the old algorithm can be removed. This time, the old key needs to be removed first, before removing the old signatures.
DNSKEY删除：旧DS RRset的缓存数据过期后，可以删除旧算法。这一次，在删除旧签名之前，需要先删除旧密钥。
RRSIGs removal: After the cache data for the old DNSKEY RRset has expired, the old signatures can also be removed during this step.
RRSIGs删除：在旧DNSKEY RRset的缓存数据过期后，也可以在此步骤中删除旧签名。
Below, we deal with a few special cases of algorithm rollovers:
下面，我们将讨论算法翻转的一些特殊情况：
1: Single-Type Signing Scheme Algorithm rollover: when there is no differentiation between ZSKs and KSKs (Section 4.1.4.1).
1：单一类型签名方案算法滚动：当ZSK和KSK之间没有区别时（第4.1.4.1节）。
2: RFC 5011 Algorithm rollover: when trust anchors can track the roll via RFC 5011 style rollover (Section 4.1.4.2).
2:RFC 5011算法滚动：当信任锚可以通过RFC 5011样式的滚动跟踪滚动时（第4.1.4.2节）。
3: 1 and 2 combined: when a Single-Type Signing Scheme Algorithm rollover is performed RFC 5011 style (Section 4.1.4.3).
3:1和2组合：当执行RFC 5011样式的单一类型签名方案算法滚动时（第4.1.4.3节）。
In addition to the narrative below, these special cases are represented in Figures 12, 13, and 14 in Appendix C.
除了下面的叙述外，这些特殊情况在附录C的图12、13和14中也有描述。
If one key is used that acts as both ZSK and KSK, the same scheme and figure as above (Figure 8 in Section 4.1.4) applies, whereby all DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are replaced with RRSIG_S_*. All DNSKEY_K_* records are replaced with DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*. The requirement to sign with both algorithms and make sure that old RRSIGs have the opportunity to expire from distant caches before introducing the new algorithm in the DNSKEY RRset is still valid.
如果使用一个密钥同时充当ZSK和KSK，则上述相同的方案和图（第4.1.4节中的图8）适用，即删除表中的所有DNSKEY_Z_*记录，并用RRSIG_S_*替换所有RRSIG_Z_*记录。所有DNSKEY_K_*记录替换为DNSKEY_S_*记录，所有RRSIG_K_*记录替换为RRSIG_S_*记录。在DNSKEY RRset中引入新算法之前，使用这两种算法签名并确保旧RRSIG有机会从远程缓存中过期的要求仍然有效。
This is shown in Figure 12 in Appendix C.
这如附录C中的图12所示。
Trust anchor algorithm rollover is almost as simple as a regular RFC 5011-based rollover. However, the old trust anchor must be revoked before it is removed from the zone.
信任锚算法滚动几乎和基于RFC 5011的常规滚动一样简单。但是，旧的信任锚点必须在从区域中删除之前撤销。
The timeline (see Figure 13 in Appendix C) is similar to that of Figure 8 above, but after the "new DS" step, an additional step is required where the DNSKEY is revoked. The details of this step ("revoke DNSKEY") are shown in Figure 9 below.
时间表（参见附录C中的图13）与上面的图8类似，但在“新DS”步骤之后，如果撤销DNSKEY，则需要额外的步骤。此步骤的详细信息（“撤销DNSKEY”）如下图9所示。
---------------------------------
revoke DNSKEY
---------------------------------
Parent:
----------------------------->
----------------------------->
----------------------------->
----------------------------->
---------------------------------
revoke DNSKEY
---------------------------------
Parent:
----------------------------->
----------------------------->
----------------------------->
----------------------------->
Child: SOA_3 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
孩子：SOA_3 RRSIG_Z_10（SOA）RRSIG_Z_11（SOA）
DNSKEY_K_1_REVOKED DNSKEY_K_2
DNSKEY_K_1_撤销DNSKEY_K_2
DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
---------------------------------
DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
---------------------------------
Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm Rollover when RFC 5011 Is in Use
图9:RFC5011使用时添加到算法滚动的Revoke DNSKEY状态
There is one exception to the requirement from RFC 4035 quoted in Section 4.1.4 above: While all zone data must be signed with an unrevoked key, it is permissible to sign the key set with a revoked key. The somewhat esoteric argument is as follows:
上述第4.1.4节中引用的RFC 4035要求有一个例外：虽然所有区域数据必须使用未撤销的密钥签名，但允许使用撤销的密钥对密钥集进行签名。有点深奥的论点如下：
Resolvers that do not understand the RFC 5011 REVOKE flag will handle DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1. In other words, they will handle the revoked key as a normal key, and thus RRsets signed with this key will validate. As a result, the signature matches the algorithm listed in the DNSKEY RRset.
不理解RFC 5011 REVOKE标志的解析程序将处理DNSKEY_K_1_REVOKE，就像处理DNSKEY_K_1一样。换句话说，它们将把被撤销的密钥作为普通密钥处理，因此使用该密钥签名的RRSET将进行验证。因此，签名与DNSKEY RRset中列出的算法匹配。
Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the set of trust anchors. That is okay, since they have already added DNSKEY_K_2 as the new trust anchor. Thus, algorithm 2 is the only signaled algorithm by now. That is, we only need RRSIG_K_2(DNSKEY) to authenticate the DNSKEY RRset, and we are still compliant with Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
实现RFC 5011的解析器将从信任锚集中删除DNSKEY_K_1。这没关系，因为他们已经添加了DNSKEY_K_2作为新的信任锚。因此，算法2是目前唯一有信号的算法。也就是说，我们只需要RRSIG_K_2（DNSKEY）来验证DNSKEY RRset，并且我们仍然符合RFC 4035的第2.2节：每个RRset必须有一个RRSIG，使用区域apex DNSKEY RRset中每个算法的至少一个DNSKEY。
If a decision is made to perform an RFC 5011 style rollover with a Single Signing Scheme key, it should be noted that Section 2.1 of RFC 5011 states:
如果决定使用单个签名方案密钥执行RFC 5011样式的滚动，应注意RFC 5011第2.1节规定：
Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRset specifically for the purpose of validating the revocation.
一旦冲突解决程序看到撤销位，它不得将此密钥用作信任锚或用于任何其他目的，除非验证它在DNSKEY RRset上签名的RRSIG，该RRSIG专门用于验证撤销。
This means that once DNSKEY_S_1 is revoked, it cannot be used to validate its signatures over non-DNSKEY RRsets. Thus, those RRsets should be signed with a shadow key, DNSKEY_Z_10, during the algorithm rollover. The shadow key can be removed at the same time the revoked DNSKEY_S_1 is removed from the zone. In other words, the zone must temporarily fall back to a KSK/ZSK split model during the rollover.
这意味着一旦撤销DNSKEY_S_1，它就不能用于验证非DNSKEY RRSET上的签名。因此，在算法翻转期间，这些RRSET应使用阴影密钥DNSKEY_Z_10进行签名。可以在从区域中删除吊销的DNSKEY_S_1的同时删除阴影关键点。换句话说，在翻滚期间，分区必须临时回落到KSK/ZSK分割模型。
In other words, the rule that at every RRset there must be at least one signature for each algorithm used in the DNSKEY RRset still applies. This means that a different key with the same algorithm, other than the revoked key, must sign the entire zone. Thus, more operations are needed if the Single-Type Signing Scheme is used. Before rolling the algorithm, a new key must be introduced with the same algorithm as the key that is a candidate for revocation. That key can than temporarily act as a ZSK during the algorithm rollover.
换句话说，对于DNSKEY RRset中使用的每个算法，每个RRset必须至少有一个签名的规则仍然适用。这意味着具有相同算法的不同密钥（已撤销密钥除外）必须对整个区域进行签名。因此，如果使用单类型签名方案，则需要更多操作。在滚动算法之前，必须使用与候选撤销密钥相同的算法引入新密钥。在算法滚动期间，该密钥可以临时充当ZSK。
As with algorithm rollover RFC 5011 style, while all zone data must be signed with an unrevoked key, it is permissible to sign the key set with a revoked key using the same esoteric argument given in Section 4.1.4.2.
与算法滚动RFC 5011样式一样，虽然所有区域数据都必须使用未撤销密钥进行签名，但允许使用第4.1.4.2节中给出的相同深奥参数使用撤销密钥对密钥集进行签名。
The lesson of all of this is that a Single-Type Signing Scheme algorithm rollover using RFC 5011 is as complicated as the name of the rollover implies: Reverting to a split-key scheme for the duration of the rollover may be preferable.
所有这一切的教训是，使用RFC 5011的单一类型签名方案算法滚动与滚动名称所暗示的一样复杂：在滚动期间恢复到分割密钥方案可能更可取。
A special case is the rollover from an NSEC signed zone to an NSEC3 signed zone. In this case, algorithm numbers are used to signal support for NSEC3 but they do not mandate the use of NSEC3. Therefore, NSEC records should remain in the zone until the rollover to a new algorithm has completed and the new DNSKEY RRset has populated distant caches, at the end of the "new DNSKEY" stage. At that point, the validators that have not implemented NSEC3 will treat the zone as unsecured as soon as they follow the chain of trust to the DS that points to a DNSKEY of the new algorithm, while validators that support NSEC3 will happily validate using NSEC. Turning on NSEC3 can then be done during the "new DS" step: increasing the serial number, introducing the NSEC3PARAM record to signal that NSEC3-authenticated data related to denial of existence should be served, and re-signing the zone.
一种特殊情况是从NSEC签名区域过渡到NSEC3签名区域。在这种情况下，算法编号用于表示支持NSEC3，但并不强制使用NSEC3。因此，NSEC记录应保留在区域中，直到在“新DNSKEY”阶段结束时完成向新算法的过渡，并且新DNSKEY RRset已填充远程缓存。在这一点上，未实现NSEC3的验证器将在遵循指向新算法DNSKEY的DS信任链时将区域视为不安全，而支持NSEC3的验证器将乐于使用NSEC进行验证。然后，可以在“新DS”步骤中打开NSEC3：增加序列号，引入NSEC3PARAM记录以表示应提供与拒绝存在相关的NSEC3身份验证数据，并对区域重新签名。
In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm rollover whereby NSEC is used all the time and only after that rollover finished NSEC3 needs to be deployed. The procedures are also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155].
总之，NSEC到NSEC3的滚动是一种普通的算法滚动，其中NSEC始终使用，并且只有在滚动完成后才需要部署NSEC3。RFC 5155[RFC5155]第10.4节和第10.5节也列出了这些程序。
As keys must be renewed periodically, there is some motivation to automate the rollover process. Consider the following:
由于密钥必须定期更新，因此有一些动机自动执行滚动过程。考虑以下事项：
o ZSK rollovers are easy to automate, as only the child zone is involved.
o ZSK滚动很容易自动化，因为只涉及子区域。
o A KSK rollover needs interaction between the parent and child. Data exchange is needed to provide the new keys to the parent; consequently, this data must be authenticated, and integrity must be guaranteed in order to avoid attacks on the rollover.
o KSK滚动需要父级和子级之间的交互。需要进行数据交换以向父级提供新密钥；因此，必须对该数据进行身份验证，并且必须保证完整性，以避免对滚动的攻击。
This section deals with preparation for a possible key compromise. It is advisable to have a documented procedure ready for those times when a key compromise is suspected or confirmed.
本节讨论可能的关键折衷方案的准备工作。建议在怀疑或确认关键危害时准备一个书面程序。
When the private material of one of a zone's keys is compromised, it can be used by an attacker for as long as a valid trust chain exists. A trust chain remains intact for
当区域密钥之一的私有资料被泄露时，只要存在有效的信任链，攻击者就可以使用该资料。一个信任链在未来几年内保持不变
o as long as a signature over the compromised key in the trust chain is valid, and
o 只要信任链中受损密钥上的签名有效，以及
o as long as the DS RR in the parent zone points to the (compromised) key signing the DNSKEY RRset, and
o 只要父区域中的DS RR指向签署DNSKEY RRset的（泄露）密钥，以及
o as long as the (compromised) key is anchored in a resolver and is used as a starting point for validation (this is generally the hardest to update).
o 只要（泄露的）密钥锚定在解析器中并用作验证的起点（这通常是最难更新的）。
While a trust chain to a zone's compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key. Zone administrators have to make a decision as to whether the abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone administrator chooses to break the trust chain to the compromised key, data in caches signed with this key cannot be validated. However, if the zone administrator chooses to take the path of a regular rollover, during the rollover the malicious key holder can continue to spoof data so that it appears to be valid.
虽然存在到区域受损密钥的信任链，但您的命名空间很容易被非法拥有该密钥的任何人滥用。区域管理员必须做出决定，确定滥用受损密钥是否比在无法验证的缓存中存储数据更糟糕。如果区域管理员选择断开与受损密钥的信任链，则无法验证使用此密钥签名的缓存中的数据。但是，如果区域管理员选择常规滚动路径，则在滚动期间，恶意密钥持有者可以继续欺骗数据，使其看起来有效。
A compromised KSK can be used to sign the key set of an attacker's version of the zone. That zone could be used to poison the DNS.
受损的KSK可用于对攻击者版本的区域密钥集进行签名。该区域可用于毒害DNS。
A zone containing a DNSKEY RRset with a compromised KSK is vulnerable as long as the compromised KSK is configured as the trust anchor or a DS record in the parent zone points to it.
只要受损的KSK被配置为信任锚或父区域中的DS记录指向它，则包含带有受损KSK的DNSKEY RRset的区域就容易受到攻击。
Therefore, when the KSK has been compromised, the trust anchor or the parent DS record should be replaced as soon as possible. It is local policy whether to break the trust chain during the emergency rollover. The trust chain would be broken when the compromised KSK is removed from the child's zone while the parent still has a DS record pointing to the compromised KSK. The assumption is that there
因此，当KSK被破坏时，应尽快更换信任锚或父DS记录。在紧急过渡期间是否中断信任链是当地的政策。当受损的KSK从孩子的区域中移除时，而家长仍然有指向受损KSK的DS记录，信任链就会断开。假设有
is only one DS record at the parent. If there are multiple DS records, this does not apply, although the chain of trust of this particular key is broken.
父级上只有一条DS记录。如果有多个DS记录，则不适用，尽管此特定密钥的信任链已断开。
Note that an attacker's version of the zone still uses the compromised KSK, and the presence of the corresponding DS record in the parent would cause the data in this zone to appear as valid. Removing the compromised key would cause the attacker's version of the zone to appear as valid and the original zone as Bogus. Therefore, we advise administrators not to remove the KSK before the parent has a DS record for the new KSK in place.
请注意，攻击者版本的区域仍然使用受损的KSK，并且父级中存在相应的DS记录将导致此区域中的数据显示为有效数据。删除受损密钥将导致攻击者的区域版本显示为有效，而原始区域显示为伪造。因此，我们建议管理员在父级拥有新KSK的DS记录之前不要删除KSK。
If it is desired to perform an emergency key rollover in a manner that keeps the chain of trust intact, the timing of the replacement of the KSK is somewhat critical. The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. This means ensuring that the signature made with a new KSK over the key set that contains the compromised KSK expires just after the new DS appears at the parent. Expiration of that signature will cause expiration of that key set from the caches.
如果希望以保持信任链完整的方式执行紧急钥匙翻转，则更换KSK的时间安排有点关键。目标是在新DS RR在父级可用时立即删除受损的KSK。这意味着确保在包含受损KSK的密钥集上使用新的KSK生成的签名在新DS出现在父密钥集中后立即过期。该签名过期将导致缓存中的密钥集过期。
The procedure is as follows:
程序如下：
1. Introduce a new KSK into the key set; keep the compromised KSK in the key set. Lower the TTL for DNSKEYs so that the DNSKEY RRset will expire from caches sooner.
1. 在密钥集中引入一个新的KSK；将受损的KSK保留在密钥集中。降低DNSKEY的TTL，以便DNSKEY RRset从缓存中更快过期。
2. Sign the key set, with a short validity period. The validity period should expire shortly after the DS is expected to appear in the parent and the old DSs have expired from caches. This provides an upper limit on how long the compromised KSK can be used in a replay attack.
2. 在密钥集上签名，有效期短。有效期应在预期DS出现在父级中且旧DSs已从缓存中过期后不久到期。这提供了在重播攻击中可以使用受损KSK的时间上限。
3. Upload the DS for this new key to the parent.
3. 将此新密钥的DS上载到父密钥。
4. Follow the procedure of the regular KSK rollover: Wait for the DS to appear at the authoritative servers, and then wait as long as the TTL of the old DS RRs. If necessary, re-sign the DNSKEY RRset and modify/extend the expiration time.
4. 遵循常规KSK滚动的过程：等待DS出现在权威服务器上，然后等待旧DS RRs的TTL。如有必要，重新签署DNSKEY RRset并修改/延长到期时间。
5. Remove the compromised DNSKEY RR from the zone, and re-sign the key set using your "normal" TTL and signature validity period.
5. 从区域中删除受损的DNSKEY RR，并使用“正常”TTL和签名有效期对密钥集重新签名。
An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate-looking DNSKEY/DS rollover and/or name server changes at the parent. When that happens, the domain may be in dispute. An authenticated out-of-band and secure notify mechanism to contact a parent is needed in this case.
密钥泄露的另一个危险是，泄露的密钥可能被用于促进父级上看起来合法的DNSKEY/DS滚动和/或名称服务器更改。当这种情况发生时，域名可能会有争议。在这种情况下，需要一个经过身份验证的带外安全通知机制来联系父级。
Note that this is only a problem when the DNSKEY and/or DS records are used to authenticate communication with the parent.
请注意，只有当DNSKEY和/或DS记录用于验证与父级的通信时，这才是一个问题。
There are two methods to perform an emergency key rollover in a manner that breaks the chain of trust. The first method causes the child zone to appear Bogus to validating resolvers. The other causes the child zone to appear Insecure. These are described below.
有两种方法可以以打破信任链的方式执行紧急密钥翻转。第一种方法导致子区域在验证解析程序中显示为虚假。另一个导致子区域看起来不安全。下文对这些问题进行了说明。
In the method that causes the child zone to appear Bogus to validating resolvers, the child zone replaces the current KSK with a new one and re-signs the key set. Next, it sends the DS of the new key to the parent. Only after the parent has placed the new DS in the zone is the child's chain of trust repaired. Note that until that time, the child zone is still vulnerable to spoofing: The attacker is still in possession of the compromised key that the DS points to.
在导致子区域在验证解析程序中显示为虚假的方法中，子区域将用新的KSK替换当前KSK并重新签名密钥集。接下来，它将新密钥的DS发送给父密钥。只有在父级将新DS放入区域后，子级的信任链才会修复。请注意，在此之前，子区域仍然容易受到欺骗：攻击者仍然拥有DS指向的受损密钥。
An alternative method of breaking the chain of trust is by removing the DS RRs from the parent zone altogether. As a result, the child zone would become Insecure. After the DS has expired from distant caches, the keys and signatures are removed from the child zone, new keys and signatures are introduced, and finally, a new DS is submitted to the parent.
打破信任链的另一种方法是将DS RRs从父区域中完全移除。因此，子区域将变得不安全。DS从远程缓存过期后，将从子区域中删除密钥和签名，引入新密钥和签名，最后将新DS提交给父区域。
Primarily because there is no interaction with the parent required when a ZSK is compromised, the situation is less severe than with a KSK compromise. The zone must still be re-signed with a new ZSK as soon as possible. As this is a local operation and requires no communication between the parent and child, this can be achieved fairly quickly. However, one has to take into account that -- just as with a normal rollover -- the immediate disappearance of the old compromised key may lead to verification problems. Also note that until the RRSIG over the compromised ZSK has expired, the zone may still be at risk.
主要是因为ZSK受损时不需要与父级交互，因此情况不如KSK受损时严重。该区域仍必须尽快用新的ZSK重新签署。由于这是一个本地操作，不需要父级和子级之间的通信，因此可以相当快地实现。然而，我们必须考虑到——就像正常的翻滚一样——旧的泄露密钥立即消失可能会导致验证问题。还请注意，在受损ZSK上的RRSIG到期之前，该区域可能仍处于风险之中。
A key can also be pre-configured in resolvers as a trust anchor. If trust anchor keys are compromised, the administrators of resolvers using these keys should be notified of this fact. Zone administrators may consider setting up a mailing list to communicate the fact that a SEP key is about to be rolled over. This communication will of course need to be authenticated by some means, e.g., by using digital signatures.
密钥也可以在解析器中预先配置为信任锚。如果信任锚密钥受损，则应将此情况通知使用这些密钥的解析程序的管理员。区域管理员可以考虑设置邮件列表来传达SEP密钥即将被翻转的事实。当然，这种通信需要通过某种方式进行认证，例如使用数字签名。
End-users faced with the task of updating an anchored key should always verify the new key. New keys should be authenticated out-of-band, for example, through the use of an announcement website that is secured using Transport Layer Security (TLS) [RFC5246].
面临更新锚定密钥任务的最终用户应始终验证新密钥。新密钥应在带外进行身份验证，例如，通过使用使用传输层安全性（TLS）保护的公告网站[RFC5246]。
Stand-by keys are keys that are published in your zone but are not used to sign RRsets. There are two reasons why someone would want to use stand-by keys. One is to speed up the emergency key rollover. The other is to recover from a disaster that leaves your production private keys inaccessible.
备用密钥是在您的区域中发布但不用于签署RRSET的密钥。有两个原因可以解释为什么有人想使用备用钥匙。一个是加速紧急钥匙翻转。另一种方法是从导致生产私钥无法访问的灾难中恢复。
The way to deal with stand-by keys differs for ZSKs and KSKs. To make a stand-by ZSK, you need to publish its DNSKEY RR. To make a stand-by KSK, you need to get its DS RR published at the parent.
zsk和ksk处理备用密钥的方式不同。要制作备用ZSK，您需要发布其DNSKEY RR。要制作备用KSK，需要在父级发布其DS RR。
Assuming you have your normal DNS operation, to prepare stand-by keys you need to:
假设您有正常的DNS操作，要准备备用密钥，您需要：
o Generate a stand-by ZSK and KSK. Store them safely in a location different than the place where the currently used ZSK and KSK are held.
o 生成备用ZSK和KSK。将其安全存放在与当前使用的ZSK和KSK存放地点不同的位置。
o Pre-publish the DNSKEY RR of the stand-by ZSK in the zone.
o 在区域中预发布备用ZSK的DNSKEY RR。
o Pre-publish the DS of the stand-by KSK in the parent zone.
o 在父区域中预发布备用KSK的DS。
Now suppose a disaster occurs and disables access to the currently used keys. To recover from that situation, follow these procedures:
现在假设发生灾难并禁用对当前使用的密钥的访问。要从这种情况中恢复，请遵循以下步骤：
o Set up your DNS operations and introduce the stand-by KSK into the zone.
o 设置DNS操作并将备用KSK引入区域。
o Post-publish the disabled ZSK and sign the zone with the stand-by keys.
o 发布禁用的ZSK并使用备用键对区域进行签名。
o After some time, when the new signatures have been propagated, the old keys, old signatures, and the old DS can be removed.
o 一段时间后，当新签名被传播时，旧密钥、旧签名和旧DS可以被删除。
o Generate a new stand-by key set at a different location and continue "normal" operation.
o 在不同位置生成新的备用密钥集，并继续“正常”操作。
The initial key exchange is always subject to the policies set by the parent. It is specifically important in a registry-registrar-registrant model where a registry maintains the parent zone, and the registrant (the user of the child-domain name) deals with the registry through an intermediary called a registrar (see [RFC3375] for a comprehensive definition). The key material is to be passed from the DNS operator to the parent via a registrar, where both the DNS operator and registrar are selected by the registrant and might be different organizations. When designing a key exchange policy, one should take into account that the authentication and authorization mechanisms used during a key exchange should be as strong as the authentication and authorization mechanisms used for the exchange of delegation information between the parent and child. That is, there is no implicit need in DNSSEC to make the authentication process stronger than it is for regular DNS.
初始密钥交换始终遵循父级设置的策略。在注册中心-注册中心-注册中心-注册中心模型中，注册中心维护父区域，注册中心（子域名的用户）通过称为注册中心的中介机构处理注册中心事务，这一点尤为重要（有关全面定义，请参见[RFC3375]）。关键材料将通过注册商从DNS运营商传递给母公司，其中DNS运营商和注册商均由注册人选择，可能是不同的组织。在设计密钥交换策略时，应考虑到密钥交换期间使用的身份验证和授权机制应与用于在父级和子级之间交换委托信息的身份验证和授权机制一样强大。也就是说，DNSSEC中没有隐含的需要使身份验证过程比常规DNS更强大。
Using the DNS itself as the source for the actual DNSKEY material has the benefit that it reduces the chances of user error. A DNSKEY query tool can make use of the SEP bit [RFC4035] to select the proper key(s) from a DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is sent. It can validate the self-signature over a key, thereby verifying the ownership of the private key material. Fetching the DNSKEY from the DNS ensures that the chain of trust remains intact once the parent publishes the DS RR indicating that the child is secure.
使用DNS本身作为实际DNSKEY材料的源有一个好处，即减少了用户出错的机会。DNSKEY查询工具可以利用SEP位[RFC4035]从DNSSEC密钥集中选择正确的密钥，从而减少发送错误DNSKEY的机会。它可以验证密钥上的自签名，从而验证私钥材料的所有权。从DNS获取DNSKEY可确保在父级发布指示子级安全的DS RR后，信任链保持完整。
Note: Out-of-band verification is still needed when the key material is fetched for the first time, even via DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed.
注意：当第一次获取关键材料时，即使是通过DNS，仍然需要带外验证。家长永远无法确定DNSKEY RRs是否被欺骗。
With some types of key rollovers, the DNSKEY is not pre-published, and a DNSKEY query tool is not able to retrieve the successor key. In this case, the out-of-band method is required. This also allows the child to determine the digest algorithm of the DS record.
对于某些类型的密钥翻转，DNSKEY不会预发布，DNSKEY查询工具无法检索后续密钥。在这种情况下，需要带外方法。这还允许子级确定DS记录的摘要算法。
When designing a registry system, one should consider whether to store the DNSKEYs and/or the corresponding DSs. Since a child zone might wish to have a DS published using a message digest algorithm not yet understood by the registry, the registry can't count on being able to generate the DS record from a raw DNSKEY. Thus, we suggest that registry systems should be able to store DS RRs, even if they also store DNSKEYs (see also "DNSSEC Trust Anchor Configuration and Maintenance" [DNSSEC-TRUST-ANCHOR]).
在设计注册表系统时，应该考虑是否存储DNSKEY和/或相应的DSS。由于子区域可能希望使用注册表尚未理解的消息摘要算法发布DS，因此注册表不能指望能够从原始DNSKEY生成DS记录。因此，我们建议注册表系统应该能够存储DS RRs，即使它们也存储DNSKEY（另请参见“DNSSEC信任锚配置和维护”[DNSSEC-Trust-ANCHORK]）。
The storage considerations also relate to the design of the customer interface and the method by which data is transferred between the registrant and registry: Will the child-zone administrator be able to upload DS RRs with unknown hash algorithms, or does the interface only allow DNSKEYs? When registries support the Extensible Provisioning Protocol (EPP) [RFC5910], that can be used for registrar-registry interactions, since that protocol allows the transfer of both DS and, optionally, DNSKEY RRs. There is no standardized way to move the data between the customer and the registrar. Different registrars have different mechanisms, ranging from simple web interfaces to various APIs. In some cases, the use of the DNSSEC extensions to EPP may be applicable.
存储注意事项还涉及客户界面的设计以及在注册人和注册中心之间传输数据的方法：子区域管理员是否能够使用未知的哈希算法上载DS RRs，或者该界面是否只允许DNSKEY？当注册表支持可扩展配置协议（EPP）[RFC5910]时，该协议可用于注册器-注册表交互，因为该协议允许传输DS和（可选）DNSKEY RRs。没有标准化的方法在客户和注册商之间移动数据。不同的注册者有不同的机制，从简单的web界面到各种API。在某些情况下，可将DNSSEC扩展应用于EPP。
Having an out-of-band mechanism such as a registry directory (e.g., Whois) to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting.
使用带外机制（如注册表目录（如WHOI））来确定哪些键用于为特定所有者和/或区域生成DS资源记录，也可能有助于进行故障排除。
Security lameness is defined as the state whereby the parent has a DS RR pointing to a nonexistent DNSKEY RR. Security lameness may occur temporarily during a Double-DS rollover scheme. However, care should be taken that not all DS RRs are pointing to a nonexistent DNSKEY RR, which will cause the child's zone to be marked Bogus by verifying DNS clients.
安全跛行定义为父级具有指向不存在的DNSKEY RR的DS RR的状态。在双DS翻滚方案期间，可能会暂时出现安全漏洞。但是，应注意的是，并非所有DS RR都指向不存在的DNSKEY RR，这将通过验证DNS客户端而导致孩子的区域被标记为伪造。
As part of a comprehensive delegation check, the parent could, at key exchange time, verify that the child's key is actually configured in the DNS. However, if a parent does not understand the hashing algorithm used by the child, the parental checks are limited to only comparing the key id.
作为全面委派检查的一部分，父级可以在密钥交换时验证子级的密钥是否在DNS中实际配置。但是，如果父级不了解子级使用的哈希算法，则父级检查仅限于比较密钥id。
Child zones should be very careful in removing DNSKEY material -- specifically, SEP keys -- for which a DS RR exists.
子区域在删除DNSKEY材质（特别是SEP键）时应非常小心，因为存在DS RR。
Once a zone is "security lame", a fix (e.g., removing a DS RR) will take time to propagate through the DNS.
一旦某个区域出现“安全漏洞”，修复（例如，删除DS RR）将需要时间通过DNS传播。
Since the DS can be replayed as long as it has a valid signature, a short signature validity period for the DS RRSIG minimizes the time that a child is vulnerable in the case of a compromise of the child's KSK(s). A signature validity period that is too short introduces the possibility that a zone is marked Bogus in the case of a configuration error in the signer. There may not be enough time to fix the problems before signatures expire (this is a generic argument; also see Section 4.4.2). Something as mundane as zone administrator unavailability during weekends shows the need for DS signature validity periods longer than two days. Just like any signature validity period, we suggest an absolute minimum for the DS signature validity period of a few days.
由于只要DS具有有效的签名，就可以重放DS，因此DS RRSIG的短签名有效期可最大限度地减少儿童在KSK受损的情况下易受攻击的时间。如果签名有效期太短，则在签名者出现配置错误的情况下，区域可能被标记为伪造。在签名过期之前，可能没有足够的时间修复问题（这是一个通用参数；另请参见第4.4.2节）。一些常见的情况，如周末区域管理员不可用，表明DS签名有效期需要超过两天。与任何签名有效期一样，我们建议DS签名的绝对最低有效期为几天。
The maximum signature validity period of the DS record depends on how long child zones are willing to be vulnerable after a key compromise. On the other hand, shortening the DS signature validity period increases the operational risk for the parent. Therefore, the parent may have a policy to use a signature validity period that is considerably longer than the child would hope for.
DS记录的最大签名有效期取决于密钥泄露后，子区域愿意受到攻击的时间长度。另一方面，缩短DS签名有效期会增加母公司的运营风险。因此，父母可能有一项使用签名有效期的政策，该有效期比孩子希望的要长得多。
A compromise between the policy/operational constraints of the parent and minimizing damage for the child may result in a DS signature validity period somewhere between a week and several months.
父母的政策/操作限制与尽量减少对孩子的伤害之间的折衷可能导致DS签名有效期在一周到几个月之间。
In addition to the signature validity period, which sets a lower bound on the number of times the zone administrator will need to sign the zone data and an upper bound on the time that a child is vulnerable after key compromise, there is the TTL value on the DS RRs. Shortening the TTL reduces the damage of a successful replay attack. It does mean that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRsets in caches, thereby increasing the speed with which updated DS RRsets propagate through the DNS.
除了签名有效期（设置了区域管理员需要对区域数据签名的次数下限和密钥泄露后儿童易受攻击的时间上限）之外，DS RRs上还有TTL值。缩短TTL可以降低成功重放攻击的伤害。这确实意味着权威服务器将看到更多的查询。但另一方面，较短的TTL会降低缓存中DS RRSET的持久性，从而提高更新的DS RRSET通过DNS传播的速度。
The parent-child relationship is often described in terms of a registry-registrar-registrant model, where a registry maintains the parent zone and the registrant (the user of the child-domain name) deals with the registry through an intermediary called a registrar [RFC3375]. Registrants may outsource the maintenance of their DNS system, including the maintenance of DNSSEC key material, to the registrar or to another third party, referred to here as the DNS operator.
亲子关系通常用注册中心注册人模型来描述，其中注册中心维护父区域，注册人（子域名的用户）通过称为注册中心的中介与注册中心进行交易[RFC3375]。注册人可将其DNS系统的维护（包括DNSSEC密钥材料的维护）外包给注册人或另一第三方（此处称为DNS运营商）。
For various reasons, a registrant may want to move between DNS operators. How easy this move will be depends principally on the DNS operator from which the registrant is moving (the losing operator), as the losing operator has control over the DNS zone and its keys. The following sections describe the two cases: where the losing operator cooperates with the new operator (the gaining operator), and where the two do not cooperate.
出于各种原因，注册人可能希望在DNS运营商之间移动。此移动是否容易主要取决于注册人移动的DNS运营商（丢失运营商），因为丢失运营商可以控制DNS区域及其密钥。以下各节描述了两种情况：损失运营商与新运营商（收益运营商）合作，以及两者不合作。
In this scenario, it is assumed that the losing operator will not pass any private key material to the gaining operator (that would constitute a trivial case) but is otherwise fully cooperative.
在这种情况下，假设丢失的运营商不会将任何私钥材料传递给获得的运营商（这将构成一个小案例），但在其他方面是完全合作的。
In this environment, the change could be made with a Pre-Publish ZSK rollover, whereby the losing operator pre-publishes the ZSK of the gaining operator, combined with a Double-Signature KSK rollover where the two registrars exchange public keys and independently generate a signature over those key sets that they combine and both publish in their copy of the zone. Once that is done, they can use their own private keys to sign any of their zone content during the transfer.
在这种环境下，可以通过预发布ZSK滚动来进行更改，即丢失的运营商预发布获得的运营商的ZSK，结合双重签名KSK滚动，两个注册商交换公钥，并在他们组合的密钥集上独立生成签名，并在其区域副本中发布。完成后，他们可以使用自己的私钥在传输期间对其任何区域内容进行签名。
------------------------------------------------------------
initial | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_A
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
------------------------------------------------------------
initial | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_A
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_A NS_B RRSIG_Z_A（NS）NS_B RRSIG_Z_B（NS）RRSIG_Z_A（NS）
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A（SOA）RRSIG_Z_B（SOA）RRSIG_Z_B（SOA）
NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_B NS_B NS_B RRSIG_Z_B（NS）RRSIG_Z_B（NS）RRSIG_Z_B（NS）
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Figure 10: Rollover for Cooperating Operators
图10：合作运营商的滚动
In this figure, A denotes the losing operator and B the gaining operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is produced with a KSK, and the appended A or B indicates the producers of the key pair. "Child at A" is how the zone content is represented by the losing DNS operator, and "Child at B" is how the zone content is represented by the gaining DNS operator.
在该图中，A表示丢失运算符，B表示获得运算符。RRSIG_Z是由ZSK产生的RRSIG，RRSIG_K是由KSK产生的，附加的a或B表示密钥对的产生者。“A处的子级”是丢失的DNS运营商表示区域内容的方式，“B处的子级”是获得的DNS运营商表示区域内容的方式。
The zone is initially delegated from the parent to the name servers of operator A. Operator A uses his own ZSK and KSK to sign the zone. The cooperating operator A will pre-publish the new NS record and the ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset generated by the KSK of operator B. Operator B needs to publish the same DNSKEY RRset. When that DNSKEY RRset has populated the caches, the re-delegation can be made, which involves adjusting the NS and DS records in the parent zone to point to operator B. And after all DNSSEC records related to operator A have expired from the caches, operator B can stop publishing the keys and signatures belonging to operator A, and vice versa.
该区域最初由父级委托给运营商A的名称服务器。运营商A使用自己的ZSK和KSK签署该区域。合作运营商A将预发布新的NS记录以及运营商B的ZSK和KSK，包括运营商B的KSK生成的DNSKEY RRset上的RRSIG。运营商B需要发布相同的DNSKEY RRset。当该DNSKEY RRset已填充缓存时，可以进行重新委派，这涉及调整父区域中的NS和DS记录以指向操作员B。在与操作员A相关的所有DNSSEC记录从缓存中过期后，操作员B可以停止发布属于操作员A的密钥和签名，反之亦然。
The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only do the operators have to exchange public keys but they also have to exchange the signatures of the new DNSKEY RRset. This drawback does not exist if the Double-Signature KSK rollover is replaced with a Double-DS KSK rollover. See Figure 15 in Appendix D for the diagram.
交换签名的要求有几个缺点。这需要更多的操作开销，因为运营商不仅必须交换公钥，还必须交换新DNSKEY RRset的签名。如果用双DS KSK滚动替换双签名KSK滚动，则不存在此缺陷。图见附录D中的图15。
Thus, if the registry and registrars allow DS records to be published that do not point to a published DNSKEY in the child zone, the Double-DS KSK rollover is preferred (see Figure 5), in combination with the Pre-Publish ZSK rollover. This does not require sharing the KSK signatures between the operators, but both operators still have to publish each other's ZSKs.
因此，如果注册表和注册器允许发布不指向子区域中已发布DNSKEY的DS记录，则首选双DS KSK滚动（见图5），并结合预发布ZSK滚动。这不需要在运营商之间共享KSK签名，但两个运营商仍然必须发布彼此的ZSK。
In the non-cooperating case, matters are more complicated. The losing operator may not cooperate and leave the data in the DNS as is. In extreme cases, the losing operator may become obstructive and publish a DNSKEY RR with a high TTL and corresponding signature validity period so that registrar A's DNSKEY could end up in caches for (in theory at least) decades.
在不合作的情况下，情况更加复杂。丢失的运营商可能不合作，将数据保留在DNS中。在极端情况下，丢失的运营商可能会变得阻塞，并发布具有高TTL和相应签名有效期的DNSKEY RR，以便注册商a的DNSKEY可能最终在缓存中保存（理论上至少）几十年。
The problem arises when a validator tries to validate with the losing operator's key and there is no signature material produced with the losing operator available in the delegation path after re-delegation from the losing operator to the gaining operator has taken place. One could imagine a rollover scenario where the gaining operator takes a copy of all RRSIGs created by the losing operator and
当验证器尝试使用丢失的操作员的密钥进行验证，并且在从丢失的操作员重新委托给获得的操作员之后，委托路径中没有丢失的操作员生成的签名材料可用时，就会出现问题。我们可以想象一个滚动场景，在该场景中，获得运营商获取丢失运营商创建的所有RRSIG的副本，然后
publishes those in conjunction with its own signatures, but that would not allow any changes in the zone content. Since a re-delegation took place, the NS RRset has by definition changed, so such a rollover scenario will not work. Besides, if zone transfers are not allowed by the losing operator and NSEC3 is deployed in the losing operator's zone, then the gaining operator's zone will not have certainty that all of the losing operator's RRSIGs have been copied.
将其与自己的签名一起发布，但这不允许对区域内容进行任何更改。由于发生了重新委托，NS RRset的定义发生了变化，因此这种滚动场景将不起作用。此外，如果丢失运营商不允许区域传输，并且NSEC3部署在丢失运营商的区域中，则获得运营商的区域将无法确定所有丢失运营商的RRSIG都已被复制。
The only viable operation for the registrant is to have his zone go Insecure for the duration of the change. The registry should be asked to remove the DS RR pointing to the losing operator's DNSKEY and to change the NS RRset to point to the gaining operator. Once this has propagated through the DNS, the registry should be asked to insert the DS record pointing to the (newly signed) zone at operator B.
注册人唯一可行的操作是在变更期间使其区域不安全。应要求注册表删除指向丢失运营商的DNSKEY的DS RR，并将NS RRset更改为指向获得运营商。一旦这已通过DNS传播，应要求注册表插入指向操作员B处（新签名）区域的DS记录。
Note that some behaviors of resolver implementations may aid in the process of changing DNS operators:
请注意，解析程序实现的某些行为可能有助于更改DNS运算符：
o TTL sanity checking, as described in RFC 2308 [RFC2308], will limit the impact of the actions of an obstructive losing operator. Resolvers that implement TTL sanity checking will use an upper limit for TTLs on RRsets in responses.
o 如RFC 2308[RFC2308]所述，TTL健全性检查将限制操作员行动的影响。实现TTL健全性检查的解析器将在响应中使用RRSET上TTL的上限。
o If RRsets at the zone cut (are about to) expire, the resolver restarts its search above the zone cut. Otherwise, the resolver risks continuing to use a name server that might be un-delegated by the parent.
o 如果区域切割处的RRSET（即将）过期，解析程序将在区域切割上方重新启动搜索。否则，冲突解决程序可能会继续使用父级可能未委派的名称服务器。
o Limiting the time that DNSKEYs that seem to be unable to validate signatures are cached and/or trying to recover from cases where DNSKEYs do not seem to be able to validate data also reduce the effects of the problem of non-cooperating registrars.
o 限制似乎无法验证签名的DNSKEY被缓存的时间和/或尝试从DNSKEY似乎无法验证数据的情况中恢复，也可以减少不合作注册者问题的影响。
However, there is no operational methodology to work around this business issue, and proper contractual relationships between all involved parties seem to be the only solution to cope with these problems. It should be noted that in many cases, the problem with temporary broken delegations already exists when a zone changes from one DNS operator to another. Besides, it is often the case that when operators are changed, the services that are referenced by that zone also change operators, possibly involving some downtime.
然而，没有任何操作方法来解决这个业务问题，所有相关方之间的适当合同关系似乎是解决这些问题的唯一办法。应该注意的是，在许多情况下，当一个区域从一个DNS运营商更改为另一个DNS运营商时，临时中断授权的问题已经存在。此外，通常情况下，当操作员发生更改时，该区域引用的服务也会更改操作员，可能涉及一些停机时间。
In any case, to minimize such problems, the classic configuration is to have relatively short TTLs on all involved Resource Records. That will solve many of the problems regarding changes to a zone, regardless of whether DNSSEC is used.
在任何情况下，为了尽量减少此类问题，经典的配置是在所有涉及的资源记录上都有相对较短的TTL。这将解决与区域更改有关的许多问题，而不管是否使用DNSSEC。
Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time that has elapsed after a slave server synchronized with a master server. The TTL value and the SOA RR minimum TTL parameter [RFC2308] are used to determine how long a forwarder should cache data (or negative responses) after it has been fetched from an authoritative server. By using a signature validity period, DNSSEC introduces the notion of an absolute time in the DNS. Signatures in DNSSEC have an expiration date after which the signature is marked as invalid and the signed data is to be considered Bogus.
如果没有DNSSEC，DNS中的所有时间都是相对的。SOA字段REFRESH、RETRY和EXPIRATION是计时器，用于确定从服务器与主服务器同步后经过的时间。TTL值和SOA RR最小TTL参数[RFC2308]用于确定从权威服务器获取数据（或否定响应）后，转发器应缓存数据的时间。通过使用签名有效期，DNSSEC在DNS中引入了绝对时间的概念。DNSSEC中的签名有一个到期日期，在此日期之后，签名被标记为无效，并且签名的数据将被视为伪造的。
The considerations in this section are all qualitative and focused on the operational and managerial issues. A more thorough quantitative analysis of rollover timing parameters can be found in "DNSSEC Key Timing Considerations" [DNSSEC-KEY-TIMING].
本节中的考虑因素都是定性的，并侧重于运营和管理问题。在“DNSSEC关键定时注意事项”[DNSSEC-Key-timing]中可以找到翻滚定时参数的更全面的定量分析。
Because of the expiration of signatures, one should consider the following:
由于签名期满，应考虑以下事项：
o We suggest that the Maximum Zone TTL value of your zone data be smaller than your signature validity period.
o 我们建议您的区域数据的最大区域TTL值小于您的签名有效期。
If the TTL duration was similar to that of the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 8.1 of RFC 4033 [RFC4033] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result, the query load on authoritative servers would peak at the signature expiration time, as this is also the time at which records simultaneously expire from caches.
如果TTL持续时间与签名有效期的持续时间相似，则在有效期内获取的所有RRSET都将被缓存，直到签名过期。RFC 4033[RFC4033]第8.1节建议“解析器可以使用已签名RRset的签名有效期到期前的剩余时间作为TTL的上限”。因此，权威服务器上的查询负载将在签名过期时达到峰值，因为这也是记录从缓存同时过期的时间。
Having a TTL that is at least a few times smaller than your signature validity period avoids query load peaks.
拥有比签名有效期小几倍的TTL可以避免查询负载峰值。
o We suggest that the signature publication period end at least one Maximum Zone TTL duration (but preferably a minimum of a few days) before the end of the signature validity period.
o 我们建议签名发布期在签名有效期结束前至少结束一个最大区域TTL持续时间（但最好至少几天）。
Re-signing a zone shortly before the end of the signature validity period may cause the simultaneous expiration of data from caches. This in turn may lead to peaks in the load on authoritative servers. To avoid this, schemes are deployed
在签名有效期结束前不久对区域重新签名可能会导致缓存中的数据同时过期。这反过来可能导致权威服务器上的负载达到峰值。为了避免这种情况，需要部署方案
whereby the zone is periodically visited for a re-signing operation, and those signatures that are within a so-called Refresh Period from signature expiration are recreated. Also see Section 4.4.2 below.
定期访问该区域进行重新签名操作，并重新创建从签名过期起的所谓刷新周期内的签名。另见下文第4.4.2节。
In the case of an operational error, you would have one Maximum Zone TTL duration to resolve the problem. Re-signing a zone a few days before the end of the signature validity period ensures that the signatures will survive at least a (long) weekend in case of such operational havoc. This is called the Refresh Period (see Section 4.4.2).
在操作错误的情况下，您将有一个最大区域TTL持续时间来解决问题。在签名有效期结束前几天重新签署一个区域，以确保签名在发生此类操作破坏的情况下至少能生存一个（长）周末。这称为刷新周期（见第4.4.2节）。
o We suggest that the Minimum Zone TTL be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated [NIST-Workshop] that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems:
o 我们建议最小区域TTL的长度应足以获取和验证信任链中的所有RRs。在车间环境中，已证明[NIST车间]低TTL（低于5到10分钟）会因以下两个问题而导致中断：
1. During validation, some data may expire before the validation is complete. The validator should be able to keep all data until it is completed. This applies to all RRs needed to complete the chain of trust: DS, DNSKEY, RRSIG, and the final answers, i.e., the RRset that is returned for the initial query.
1. 在验证期间，某些数据可能在验证完成之前过期。验证器应该能够保存所有数据，直到完成。这适用于完成信任链所需的所有RRs：DS、DNSKEY、RRSIG和最终答案，即为初始查询返回的RRset。
2. Frequent verification causes load on recursive name servers. Data at delegation points, DS, DNSKEY, and RRSIG RRs benefits from caching. The TTL on those should be relatively long. Data at the leaves in the DNS tree has less impact on recursive name servers.
2. 频繁的验证会导致递归名称服务器上的负载。委托点、DS、DNSKEY和RRSIG RRs上的数据受益于缓存。这些设备上的TTL应相对较长。DNS树中叶子上的数据对递归名称服务器的影响较小。
o Slave servers will need to be able to fetch newly signed zones well before the RRSIGs in the zone served by the slave server pass their signature expiration time.
o 从属服务器需要能够在从属服务器服务的区域中的RRSIG通过其签名过期时间之前获取新签名的区域。
When a slave server is out of synchronization with its master and data in a zone is signed by expired signatures, it may be better for the slave server not to give out any answer.
当从属服务器与其主服务器不同步，并且区域中的数据由过期的签名签名时，从属服务器最好不要给出任何答案。
Normally, a slave server that is not able to contact a master server for an extended period will expire a zone. When that happens, the server will respond differently to queries for that zone. Some servers issue SERVFAIL, whereas others turn off the AA bit in the answers. The time of expiration is set in the SOA record and is relative to the last successful refresh between the master and the slave servers. There exists no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA.
通常，如果从属服务器在较长时间内无法与主服务器联系，则该区域将过期。当这种情况发生时，服务器将对该区域的查询做出不同的响应。一些服务器发出SERVFAIL，而另一些服务器则关闭答案中的AA位。过期时间在SOA记录中设置，并与主服务器和从服务器之间的最后一次成功刷新相关。区域中RRSIG的签名过期与SOA中的expire参数之间不存在耦合。
If the server serves a DNSSEC-secured zone, then it may happen that the signatures expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this by modifying the SOA parameters.
如果服务器服务于DNSSEC安全区域，则签名可能在SOA过期计时器倒计时为零之前过期。通过修改SOA参数不可能完全防止这种情况。
However, the effects can be minimized where the SOA expiration time is equal to or shorter than the Refresh Period (see Section 4.4.2).
但是，如果SOA过期时间等于或小于刷新周期，则可以将影响降至最低（参见第4.4.2节）。
The consequence of an authoritative server not being able to update a zone for an extended period of time is that signatures may expire. In this case, non-secure resolvers will continue to be able to resolve data served by the particular slave servers, while security-aware resolvers will experience problems because of answers being marked as Bogus.
权威服务器长时间无法更新区域的结果是签名可能会过期。在这种情况下，非安全解析程序将继续能够解析特定从属服务器提供的数据，而安全感知解析程序将遇到问题，因为答案被标记为伪造。
We suggest that the SOA expiration timer be approximately one third or a quarter of the signature validity period. It will allow problems with transfers from the master server to be noticed before signatures time out.
我们建议SOA过期计时器大约为签名有效期的三分之一或四分之一。它将允许在签名超时之前注意到来自主服务器的传输问题。
We also suggest that operators of name servers that supply secondary services develop systems to identify upcoming signature expirations in zones they slave and take appropriate action where such an event is detected.
我们还建议提供辅助服务的名称服务器的运营商开发系统，以识别其从属区域中即将到来的签名过期，并在检测到此类事件时采取适当的措施。
When determining the value for the expiration parameter, one has to take the following into account: What are the chances that all secondaries expire the zone? How quickly can the administrators of the secondary servers be reached to load a valid zone? These questions are not DNSSEC-specific but may influence the choice of your signature validity periods.
在确定expiration参数的值时，必须考虑以下因素：所有二级服务器使区域过期的可能性有多大？辅助服务器的管理员加载有效区域的速度有多快？这些问题不是DNSSEC特有的，但可能会影响您对签名有效期的选择。
The first consideration for choosing a maximum signature validity period is the risk of a replay attack. For low-value, long-term stable resources, the risks may be minimal, and the signature validity period may be several months. Although signature validity periods of many years are allowed, the same "operational habit" arguments as those given in Section 3.2.2 play a role: When a zone is re-signed with some regularity, then zone administrators remain conscious of the operational necessity of re-signing.
选择最大签名有效期的第一个考虑因素是重放攻击的风险。对于低价值、长期稳定的资源，风险可能最小，签名有效期可能为几个月。尽管允许签名有效期为多年，但第3.2.2节中给出的“操作习惯”论点也起到了一定作用：当区域以某种规律重新签名时，区域管理员仍意识到重新签名的操作必要性。
The minimum value of the signature validity period is set for the time by which one would like to survive operational failure in provisioning: At what time will a failure be noticed, and at what time is action expected to be taken? By answering these questions, availability of zone administrators during (long) weekends or time taken to access backup media can be taken into account. The result could easily suggest a minimum signature validity period of a few days.
签名有效期的最小值是为希望在供应过程中避免操作故障的时间设置的：何时会发现故障，何时会采取行动？通过回答这些问题，可以考虑区域管理员在（长）周末的可用性或访问备份介质所需的时间。结果很容易表明签名的最短有效期为几天。
Note, however, that the argument above is assuming that zone data has just been signed and published when the problem occurred. In practice, it may be that a zone is signed according to a frequency set by the Re-Sign Period, whereby the signer visits the zone content and only refreshes signatures that are within a given amount of time (the Refresh Period) of expiration. The Re-Sign Period must be smaller than the Refresh Period in order for zone data to be signed in a timely fashion.
但是，请注意，上面的参数假设问题发生时区域数据刚刚被签名和发布。在实践中，可能是根据重新签名周期设置的频率对区域进行签名，由此签名者访问区域内容，并且仅刷新在到期的给定时间量（刷新周期）内的签名。重新签名周期必须小于刷新周期，以便及时对区域数据进行签名。
If an operational problem occurs during re-signing, then the signatures in the zone to expire first are the ones that have been generated longest ago. In the worst case, these signatures are the Refresh Period minus the Re-Sign Period away from signature expiration.
如果在重新签名期间出现操作问题，则首先过期的区域中的签名是最早之前生成的签名。在最坏的情况下，这些签名是刷新周期减去签名到期后的重新签名周期。
To make matters slightly more complicated, some signers vary the signature validity period over a small range (the jitter interval) so that not all signatures expire at the same time.
让事情稍微复杂一点，一些签名者在一个小范围内（抖动间隔）改变签名有效期，因此并非所有签名都同时过期。
In other words, the minimum signature validity period is set by first choosing the Refresh Period (usually a few days), then defining the Re-Sign Period in such a way that the Refresh Period minus the Re-Sign Period, minus the maximum jitter sets the time in which operational havoc can be resolved.
换句话说，通过首先选择刷新周期（通常为几天），然后定义重新签名周期，以使刷新周期减去重新签名周期，再减去最大抖动设置可以解决操作破坏的时间，来设置最小签名有效期。
The relationship between signature times is illustrated in Figure 11.
签名时间之间的关系如图11所示。
Inception Signing Expiration
time time time
| | | | |
|------------------|---------------------------------|.....|.....|
| | | | |
+/-jitter
Inception Signing Expiration
time time time
| | | | |
|------------------|---------------------------------|.....|.....|
| | | | |
+/-jitter
| Inception offset | |
|<---------------->| Validity Period |
| |<---------------------------------------->|
| Inception offset | |
|<---------------->| Validity Period |
| |<---------------------------------------->|
Inception Signing Reuse Reuse Reuse New Expiration
time time RRSIG time
| | | | | | |
|------------------|-------------------------------|-------|
| | | | | | |
<-----> <-----> <-----> <----->
Re-Sign Period
Inception Signing Reuse Reuse Reuse New Expiration
time time RRSIG time
| | | | | | |
|------------------|-------------------------------|-------|
| | | | | | |
<-----> <-----> <-----> <----->
Re-Sign Period
| Refresh |
|<----------->|
| Period |
| Refresh |
|<----------->|
| Period |
Figure 11: Signature Timing Parameters
图11：签名定时参数
Note that in the figure the validity of the signature starts shortly before the signing time. That is done to deal with validators that might have some clock skew. This is called the inception offset, and it should be chosen so that false negatives are minimized to a reasonable level.
请注意，在图中，签名的有效性在签名时间前不久开始。这样做是为了处理可能有一些时钟偏差的验证器。这称为起始偏移量，应选择该偏移量，以便将误报降至合理水平。
It is possible to vary signature validity periods between signatures over different RRsets in the zone. In practice, this could be done when zones contain highly volatile data (which may be the case in dynamic-update environments). Note, however, that the risk of replay (e.g., by stale secondary servers) should be the leading factor in determining the signature validity period, since the TTLs on the data itself are still the primary parameter for cache expiry.
可以在区域中不同RRSET上的签名之间改变签名有效期。实际上，当区域包含高度不稳定的数据时（在动态更新环境中可能是这种情况），可以执行此操作。但是，请注意，在确定签名有效期时，重放风险（例如，由过时的辅助服务器重放）应该是主要因素，因为数据本身上的TTL仍然是缓存过期的主要参数。
In some cases, the risk of replaying existing data might be different from the risk of replaying the denial of data. In those cases, the signature validity period on NSEC or NSEC3 records may be tweaked accordingly.
在某些情况下，重放现有数据的风险可能与重放拒绝数据的风险不同。在这些情况下，NSEC或NSEC3记录上的签名有效期可能会相应调整。
When a zone contains secure delegations, then a relatively short signature validity period protects the child against replay attacks in the case where the child's key is compromised (see Section 4.3.4). Since there is a higher operational risk for the parent registry when choosing a short validity period and a higher operational risk for the child when choosing a long validity period, some (price) differentiation may occur for validity periods between individual DS RRs in a single zone.
当一个区域包含安全授权时，相对较短的签名有效期可在儿童密钥受损的情况下保护儿童免受重播攻击（见第4.3.4节）。由于在选择较短有效期时，母公司注册处的运营风险较高，而在选择较长有效期时，子公司的运营风险较高，因此，单个区域内各个DS RRs的有效期可能会出现一些（价格）差异。
There seem to be no other arguments for differentiation in validity periods.
对于有效期的区分似乎没有其他论据。
One of the design tradeoffs made during the development of DNSSEC was to separate the signing and serving operations instead of performing cryptographic operations as DNS requests are being serviced. It is therefore necessary to create records that cover the very large number of nonexistent names that lie between the names that do exist.
DNSSEC开发过程中进行的设计权衡之一是将签名和服务操作分离，而不是在DNS请求被服务时执行加密操作。因此，有必要创建包含大量不存在名称的记录，这些名称位于确实存在的名称之间。
There are two mechanisms to provide authenticated proof of nonexistence of domain names in DNSSEC: a clear-text one and an obfuscated-data one. Each mechanism:
有两种机制可以提供DNSSEC中不存在域名的身份验证证明：一种是明文证明，另一种是模糊数据证明。每个机制：
o includes a list of all the RRTYPEs present, which can be used to prove the nonexistence of RRTYPEs at a certain name;
o 包括存在的所有RRTYPE的列表，该列表可用于证明在特定名称下不存在RRTYPE；
o stores only the name for which the zone is authoritative (that is, glue in the zone is omitted); and
o 仅存储区域具有权威性的名称（即忽略区域中的胶水）；和
o uses a specific RRTYPE to store information about the RRTYPEs present at the name: The clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3.
o 使用特定的RRTYPE存储有关名称中存在的RRTYPE的信息：明文机制使用NSEC，模糊数据机制使用NSEC3。
The clear-text mechanism (NSEC) is implemented using a sorted linked list of names in the zone. The obfuscated-data mechanism (NSEC3) is similar but first hashes the names using a one-way hash function, before creating a sorted linked list of the resulting (hashed) strings.
明文机制（NSEC）是使用区域中名称的排序链表实现的。模糊化数据机制（NSEC3）类似，但在创建结果（散列）字符串的排序链表之前，首先使用单向散列函数对名称进行散列。
The NSEC record requires no cryptographic operations aside from the validation of its associated signature record. It is human readable and can be used in manual queries to determine correct operation. The disadvantage is that it allows for "zone walking", where one can request all the entries of a zone by following the linked list of NSEC RRs via the "Next Domain Name" field. Though all agree that DNS
NSEC记录除了验证其相关签名记录外，不需要任何加密操作。它是人类可读的，可用于手动查询以确定正确的操作。缺点是它允许“区域漫游”，即可以通过“下一个域名”字段跟随NSEC RRs的链接列表来请求区域的所有条目。虽然大家都同意DNS
data is accessible through query mechanisms, for some zone administrators this behavior is undesirable for policy, regulatory, or other reasons.
数据可以通过查询机制访问，对于某些区域管理员来说，由于策略、法规或其他原因，这种行为是不可取的。
Furthermore, NSEC requires a signature over every RR in the zone file, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zone file containing many delegations, very few of which are to signed zones, this may produce unacceptable additional overhead, especially where insecure delegations are subject to frequent updates (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals between two secure delegations to "opt out", in which case they may contain one or more insecure delegations, thus reducing the size and cryptographic complexity of the zone at the expense of the ability to cryptographically deny the existence of names in a specific span.
此外，NSEC要求对区域文件中的每个RR进行签名，从而确保对任何拒绝存在进行加密签名。但是，在包含许多委派的大型区域文件中，很少有委派到已签名的区域，这可能会产生不可接受的额外开销，特别是在不安全的委派需要频繁更新的情况下（典型示例可能是TLD操作员，很少有注册人使用安全委派）。NSEC3允许两个安全委托之间的间隔“选择退出”，在这种情况下，它们可能包含一个或多个不安全的委托，从而减少区域的大小和加密复杂性，但牺牲了以加密方式拒绝特定范围内名称存在的能力。
The NSEC3 record uses a hashing method of the requested name. To increase the workload required to guess entries in the zone, the number of hashing iterations can be specified in the NSEC3 record. Additionally, a salt can be specified that also modifies the hashes. Note that NSEC3 does not give full protection against information leakage from the zone (you can still derive the size of the zone, which RRTYPEs are in there, etc.).
NSEC3记录使用请求名称的哈希方法。为了增加猜测区域中条目所需的工作负载，可以在NSEC3记录中指定哈希迭代次数。此外，还可以指定一个salt来修改散列。请注意，NSEC3并没有针对区域的信息泄漏提供完全的保护（您仍然可以导出区域的大小，其中包含哪些RRTYPE，等等）。
The first motivation to deploy NSEC3 -- prevention of zone enumeration -- only makes sense when zone content is not highly structured or trivially guessable. Highly structured zones, such as in-addr.arpa., ip6.arpa., and e164.arpa., can be trivially enumerated using ordinary DNS properties, while for small zones that only contain records in the apex of the zone and a few common names such as "www" or "mail", guessing zone content and proving completeness is also trivial when using NSEC3. In these cases, the use of NSEC is preferred to ease the work required by signers and validating resolvers.
部署NSEC3的第一个动机——防止区域枚举——只有在区域内容不是高度结构化或不容易猜测的情况下才有意义。高度结构化的区域，如addr.arpa.、ip6.arpa.和e164.arpa.，可以使用普通DNS属性进行简单的枚举，而对于仅在区域顶端包含记录和一些常见名称（如“www”或“mail”）的小区域，在使用NSEC3时猜测区域内容和证明完整性也很简单。在这些情况下，最好使用NSEC来简化签名者和验证解析器所需的工作。
For large zones where there is an implication of "not readily available" names, such as those where one has to sign a non-disclosure agreement before obtaining it, NSEC3 is preferred. The second reason to consider NSEC3 is "Opt-Out", which can reduce the number of NSEC3 records required. This is discussed further below (Section 5.3.4).
对于包含“不易获得”名称的大型区域，如在获得保密协议之前必须签署保密协议的区域，首选NSEC3。考虑NSEC3的第二个原因是“选择退出”，这可以减少所需的NSEC3记录的数量。下文将对此进行进一步讨论（第5.3.4节）。
NSEC3 is controlled by a number of parameters, some of which can be varied: This section discusses the choice of those parameters.
NSEC3由许多参数控制，其中一些参数可以变化：本节讨论这些参数的选择。
The NSEC3 hashing algorithm is performed on the Fully Qualified Domain Name (FQDN) in its uncompressed form. This ensures that brute force work done by an attacker for one FQDN cannot be reused for another FQDN attack, as these entries are by definition unique.
NSEC3哈希算法在未压缩形式的完全限定域名（FQDN）上执行。这确保了攻击者对一个FQDN所做的暴力工作不能再用于另一个FQDN攻击，因为根据定义，这些条目是唯一的。
At the time of this writing, there is only one NSEC3 hash algorithm defined. [RFC5155] specifically states: "When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined". Therefore, this document does not consider NSEC3 hash algorithm transition.
在撰写本文时，只定义了一个NSEC3哈希算法。[RFC5155]特别指出：“当指定用于NSEC3的新哈希算法时，还必须定义转换机制”。因此，本文不考虑NSEC3哈希算法的转换。
One of the concerns with NSEC3 is that a pre-calculated dictionary attack could be performed in order to assess whether or not certain domain names exist within a zone. Two mechanisms are introduced in the NSEC3 specification to increase the costs of such dictionary attacks: iterations and salt.
NSEC3的一个问题是，为了评估某个区域内是否存在某些域名，可能会执行预先计算的字典攻击。NSEC3规范中引入了两种机制来增加此类字典攻击的成本：迭代和salt。
The iterations parameter defines the number of additional times the hash function has been performed. A higher value results in greater resiliency against dictionary attacks, at a higher computational cost for both the server and resolver.
迭代次数参数定义执行哈希函数的额外次数。值越高，针对字典攻击的恢复能力越强，服务器和冲突解决程序的计算成本越高。
RFC 5155 Section 10.3 [RFC5155] considers the tradeoffs between incurring cost during the signing process and imposing costs to the validating name server, while still providing a reasonable barrier against dictionary attacks. It provides useful limits of iterations for a given RSA key size. These are 150 iterations for 1024-bit keys, 500 iterations for 2048-bit keys, and 2,500 iterations for 4096-bit keys. Choosing a value of 100 iterations is deemed to be a sufficiently costly, yet not excessive, value: In the worst-case scenario, the performance of name servers would be halved, regardless of key size [NSEC3-HASH-PERF].
RFC 5155第10.3节[RFC5155]考虑了签名过程中产生的成本和向验证名称服务器施加成本之间的权衡，同时仍然提供了防止字典攻击的合理屏障。它为给定的RSA密钥大小提供了有用的迭代限制。这是1024位密钥的150次迭代，2048位密钥的500次迭代，以及4096位密钥的2500次迭代。选择100个迭代次数的值被认为是一个足够昂贵但不过分的值：在最坏的情况下，名称服务器的性能将减半，而不管密钥大小[NSEC3-HASH-PERF]。
While the NSEC3 iterations parameter increases the cost of hashing a dictionary word, the NSEC3 salt reduces the lifetime for which that calculated hash can be used. A change of the salt value by the zone administrator would cause an attacker to lose all pre-calculated work for that zone.
虽然NSEC3迭代次数参数增加了对字典单词进行散列的成本，但NSEC3 salt减少了计算出的散列可以使用的生存期。区域管理员更改salt值将导致攻击者丢失该区域所有预先计算的工作。
There must be a complete NSEC3 chain using the same salt value, that matches the salt value in the NSEC3PARAM record. NSEC3 salt changes do not need special rollover procedures. Since changing the salt requires that all the NSEC3 records be regenerated and thus requires generating new RRSIGs over these NSEC3 records, it makes sense to align the change of the salt with a change of the Zone Signing Key, as that process in itself already usually requires that all RRSIGs be regenerated. If there is no critical dependency on incremental signing and the zone can be signed with little effort, there is no need for such alignment.
必须有一个完整的NSEC3链使用相同的salt值，与NSEC3PARAM记录中的salt值匹配。NSEC3盐变化不需要特殊的滚动程序。由于更改salt需要重新生成所有NSEC3记录，因此需要在这些NSEC3记录上生成新的RRSIG，因此将salt的更改与区域签名密钥的更改对齐是有意义的，因为该过程本身通常已经要求重新生成所有RRSIG。如果不存在对增量签名的关键依赖，并且可以轻松地对区域进行签名，那么就不需要进行这种对齐。
The Opt-Out mechanism was introduced to allow for a gradual introduction of signed records in zones that contain mostly delegation records. The use of the Opt-Out flag changes the meaning of the NSEC3 span from authoritative denial of the existence of names within the span to proof that DNSSEC is not available for the delegations within the span. This allows for the addition or removal of the delegations covered by the span without recalculating or re-signing RRs in the NSEC3 RR chain.
引入了选择退出机制，以便在主要包含委派记录的区域中逐步引入签名记录。选择退出标志的使用改变了NSEC3 span的含义，即权威性地拒绝span内的名称，以证明DNSSEC不适用于span内的代表团。这允许在不重新计算或重新签署NSEC3 RR链中的RRs的情况下添加或删除span涵盖的授权。
Opt-Out is specified to be used only over delegation points and will therefore only bring relief to zones with a large number of insecure delegations. This consideration typically holds for large TLDs and similar zones; in most other circumstances, Opt-Out should not be deployed. Further considerations can be found in Section 12.2 of RFC 5155 [RFC5155].
选择退出被指定为仅在授权点上使用，因此只会缓解有大量不安全授权的区域。这种考虑通常适用于大型TLD和类似区域；在大多数其他情况下，不应部署选择退出。更多注意事项见RFC 5155[RFC5155]第12.2节。
DNSSEC adds data origin authentication and data integrity to the DNS, using digital signatures over Resource Record sets. DNSSEC does not protect against denial-of-service attacks, nor does it provide confidentiality. For more general security considerations related to DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035].
DNSSEC使用资源记录集上的数字签名向DNS添加数据源身份验证和数据完整性。DNSSEC不针对拒绝服务攻击提供保护，也不提供机密性。有关DNSSEC的更多一般安全注意事项，请参阅RFC 4033[RFC4033]、RFC 4034[RFC4034]和RFC 4035[RFC4035]。
This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. When performing key rollovers, it is important to keep in mind that it takes time for the data to be propagated to the verifying clients. It is also important to note that this data may be cached. Not taking into account the 'data propagation' properties in the DNS may cause validation failures, because cached data may mismatch data fetched from the authoritative servers; this will make secured zones unavailable to security-aware resolvers.
本文件试图评估维持稳定和安全的DNSSEC服务的操作注意事项。执行密钥翻转时，请务必记住，将数据传播到验证客户端需要时间。还需要注意的是，这些数据可能会被缓存。不考虑DNS中的“数据传播”属性可能会导致验证失败，因为缓存的数据可能与从权威服务器获取的数据不匹配；这将使具有安全意识的解析程序无法使用安全区域。
Significant parts of the text of this document are copied from RFC 4641 [RFC4641]. That document was edited by Olaf Kolkman and Miek Gieben. Other people that contributed or were otherwise involved in that work were, in random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette, Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, Peter Koch, Mike StJohns, Emma Bretherick, Adrian Bedford, Lindy Foster, and O. Courtay.
本文件正文的重要部分摘自RFC 4641[RFC4641]。该文件由Olaf Kolkman和Miek Gieben编辑。其他贡献或参与这项工作的人按随机顺序排列：里普·卢米斯、奥拉富·古德蒙德森、韦斯利·格里芬、迈克尔·理查森、斯科特·罗斯、里克·范雷恩、蒂姆·麦金尼斯、吉勒斯·盖特、奥利维尔·考蒂、萨姆·韦勒、杰尔特·詹森、尼尔·奥赖利、霍尔格·祖勒格、埃德·刘易斯、希拉里·奥曼、马科斯·桑兹、彼得·科赫、，迈克·斯特约翰斯、艾玛·布雷瑟里克、阿德里安·贝德福德、林迪·福斯特和O·考蒂。
For this version of the document, we would like to acknowledge people who were actively involved in the compilation of the document. In random order: Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin Verschuren, Marc Lampo, George Barwood, Sebastian Castro, Suresh Krishnaswamy, Eric Rescorla, Stephen Morris, Olafur Gudmundsson, Ondrej Sury, and Rickard Bellgrim.
对于这一版本的文件，我们要感谢积极参与编写该文件的人。按随机顺序排列：马克·安德鲁斯、帕特里克·法尔茨特罗姆、托尼·芬奇、阿尔弗雷德·霍恩斯、比尔·曼宁、斯科特·罗斯、沃特·维恩加德斯、安托因·维斯楚伦、马克·兰波、乔治·巴伍德、塞巴斯蒂安·卡斯特罗、苏雷什·克里希纳斯瓦米、埃里克·雷索拉、斯蒂芬·莫里斯、奥拉弗尔·古德蒙德森、昂德雷·苏里和里卡德·贝尔格林。
Significant contributions to this document were from:
对本文件的重要贡献来自：
Paul Hoffman, who contributed on the choice of cryptographic parameters and addressing some of the trust anchor issues;
Paul Hoffman，他在选择密码参数和解决一些信任锚问题方面做出了贡献；
Jelte Jansen, who provided the initial text in Section 4.1.4;
Jelte Jansen，他在第4.1.4节中提供了初始文本；
Paul Wouters, who provided the initial text for Section 5, and Alex Bligh, who improved it.
Paul Wouters为第5节提供了初始文本，Alex Bligh对其进行了改进。
The figure in Section 4.4.2 was adapted from the OpenDNSSEC user documentation.
第4.4.2节中的图改编自OpenDNSSEC用户文档。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509]Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，2006年5月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，2009年10月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002.
[RFC3375]Hollenbeck，S.，“通用注册登记协议要求”，RFC 3375，2002年9月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641]Kolkman，O.和R.Gieben，“DNSSEC运营实践”，RFC 46412006年9月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007.
[RFC5011]StJohns，M.，“DNS安全（DNSSEC）信任锚的自动更新”，RFC5011，2007年9月。
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010.
[RFC5910]Gould，J.和S.Hollenbeck，“可扩展资源调配协议（EPP）的域名系统（DNS）安全扩展映射”，RFC 59102010年5月。
[RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, July 2010.
[RFC5933]Dolmatov，V.，Chuprina，A.，和I.Ustinov，“在DNSSEC的DNSKEY和RRSIG资源记录中使用GOST签名算法”，RFC 59332010年7月。
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, April 2012.
[RFC6605]Hoffman，P.和W.Wijngaards，“DNSSEC的椭圆曲线数字签名算法（DSA）”，RFC 6605，2012年4月。
[NIST-Workshop] Rose, S., "NIST DNSSEC workshop notes", July 2001, <http://www.ietf.org/mail-archive/web/dnsop/current/ msg01020.html>.
[NIST研讨会]罗斯，S.，“NIST DNSSEC研讨会笔记”，2001年7月<http://www.ietf.org/mail-archive/web/dnsop/current/ msg01020.html>。
[NIST-SP-800-90A] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012.
[NIST-SP-800-90A]Barker，E.和J.Kelsey，“使用确定性随机位生成器生成随机数的建议”，NIST特别出版物800-90A，2012年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[DNSSEC-KEY-TIMING] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing Considerations", Work in Progress, July 2012.
[DNSSEC-关键时间安排]Morris，S.，Ihren，J.，和J.Dickinson，“DNSSEC关键时间安排考虑”，正在进行的工作，2012年7月。
[DNSSEC-DPS] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", Work in Progress, November 2012.
[DNSSEC-DPS]Ljunggren，F.，Eklund Lowinder，AM.，和T.Okubo，“DNSSEC政策框架和DNSSEC实践声明”，正在进行的工作，2012年11月。
[DNSSEC-TRUST-ANCHOR] Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", Work in Progress, October 2010.
[DNSSEC-TRUST-ANCHOR]Larson，M.和O.Gudmundsson，“DNSSEC信任锚配置和维护”，正在进行的工作，2010年10月。
[NSEC3-HASH-PERF] Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs document 2010-002, March 2010.
[NSEC3-HASH-PERF]Schaeffer，Y.，“NSEC3哈希性能”，NLnet实验室文件2010-002，2010年3月。
In this document, there is some jargon used that is defined in other documents. In most cases, we have not copied the text from the documents defining the terms but have given a more elaborate explanation of the meaning. Note that these explanations should not be seen as authoritative.
在本文档中，使用了一些在其他文档中定义的术语。在大多数情况下，我们没有从定义术语的文件中复制文本，而是对其含义进行了更详细的解释。请注意，这些解释不应被视为权威。
Anchored key: A DNSKEY configured in resolvers around the globe. This key is hard to update, hence the term 'anchored'.
锚定键：在全球的解析器中配置的DNSKEY。此密钥很难更新，因此术语“锚定”。
Bogus: Also see Section 5 of RFC 4033 [RFC4033]. An RRset in DNSSEC is marked "Bogus" when a signature of an RRset does not validate against a DNSKEY.
伪造：另见RFC 4033[RFC4033]第5节。当RRset的签名未针对DNSKEY进行验证时，DNSSEC中的RRset被标记为“伪造”。
Key rollover: A key rollover (also called key supercession in some environments) is the act of replacing one key pair with another at the end of a key effectivity period.
密钥翻转：密钥翻转（在某些环境中也称为密钥置换）是在密钥有效期结束时用另一个密钥对替换一个密钥对的行为。
Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used exclusively for signing the apex key set. The fact that a key is a KSK is only relevant to the signing tool.
密钥签名密钥或KSK：密钥签名密钥（KSK）是专门用于对apex密钥集进行签名的密钥。密钥是KSK这一事实仅与签名工具相关。
Key size: The term 'key size' can be substituted by 'modulus size' throughout the document for RSA keys. It is mathematically more correct to use modulus size for RSA keys, but as this is a document directed at operators we feel more at ease with the term 'key size'.
密钥大小：在整个文档中，RSA密钥的术语“密钥大小”可以替换为“模数大小”。从数学上讲，对RSA密钥使用模大小更为正确，但由于这是一份针对运营商的文档，我们对“密钥大小”这一术语感到更轻松。
Private and public keys: DNSSEC secures the DNS through the use of public-key cryptography. Public-key cryptography is based on the existence of two (mathematically related) keys, a public key and a private key. The public keys are published in the DNS by the use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private.
私钥和公钥：DNSSEC通过使用公钥加密来保护DNS。公钥密码基于两个（数学上相关的）密钥的存在，一个公钥和一个私钥。公钥通过使用DNSKEY资源记录（DNSKEY RR）在DNS中发布。私钥应该保持私有。
Refresh Period: The period before the expiration time of the signature, during which the signature is refreshed by the signer.
刷新周期：签名到期前的一段时间，签名人在此期间刷新签名。
Re-Sign Period: This refers to the frequency with which a signing pass on the zone is performed. The Re-Sign Period defines when the zone is exposed to the signer. And on the signer, not all signatures in the zone have to be regenerated: That depends on the Refresh Period.
重新签名周期：指在区域上执行签名传递的频率。重新签名周期定义区域向签名者公开的时间。对于签名者，并非区域中的所有签名都必须重新生成：这取决于刷新周期。
Secure Entry Point (SEP) key: A KSK that has a DS record in the parent zone pointing to it or that is configured as a trust anchor. Although not required by the protocol, we suggest that the SEP flag [RFC4034] be set on these keys.
安全入口点（SEP）密钥：在父区域中具有指向它的DS记录或配置为信任锚点的KSK。虽然协议没有要求，但我们建议在这些密钥上设置SEP标志[RFC4034]。
Self-signature: This only applies to signatures over DNSKEYs; a signature made with DNSKEY x over DNSKEY x is called a self-signature. Note: Without further information, self-signatures convey no trust. They are useful to check the authenticity of the DNSKEY, i.e., they can be used as a hash.
自签名：仅适用于DNSKEY上的签名；使用DNSKEY x在DNSKEY x上进行的签名称为自签名。注：如果没有进一步的信息，自签名不表示信任。它们用于检查DNSKEY的真实性，也就是说，它们可以用作哈希。
Signing jitter: A random variation in the signature validity period of RRSIGs in a zone to prevent all of them from expiring at the same time.
签名抖动：区域中RRSIG签名有效期的随机变化，以防止所有RRSIG同时过期。
Signer: The system that has access to the private key material and signs the Resource Record sets in a zone. A signer may be configured to sign only parts of the zone, e.g., only those RRsets for which existing signatures are about to expire.
签名者：可以访问私钥材料并对区域中的资源记录集进行签名的系统。签名者可被配置为仅对区域的部分进行签名，例如，仅对现有签名即将过期的RRSET进行签名。
Singing the zone file: The term used for the event where an administrator joyfully signs its zone file while producing melodic sound patterns.
唱区域文件：用于管理员在产生旋律模式的同时愉快地签署其区域文件的事件的术语。
Single-Type Signing Scheme: A signing scheme whereby the distinction between Zone Signing Keys and Key Signing Keys is not made.
单一类型签名方案：一种不区分区域签名密钥和密钥签名密钥的签名方案。
Zone administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server.
区域管理员：负责对区域进行签名并将其发布到主权威服务器上的“角色”。
Zone Signing Key (ZSK): A key that is used for signing all data in a zone (except, perhaps, the DNSKEY RRset). The fact that a key is a ZSK is only relevant to the signing tool.
区域签名密钥（ZSK）：用于对区域中的所有数据（DNSKEY RRset除外）进行签名的密钥。密钥是ZSK这一事实仅与签名工具相关。
The following typographic conventions are used in this document:
本文件使用了以下印刷惯例：
Key notation: A key is denoted by DNSKEY_x_y, where x is an identifier for the type of key: K for Key Signing Key, Z for Zone Signing Key, and S when there is no distinction made between KSKs and ZSKs but the key is used as a secure entry point. The 'y' denotes a number or an identifier; y could be thought of as the key id.
密钥表示法：密钥由DNSKEY_x_y表示，其中x是密钥类型的标识符：K表示密钥签名密钥，Z表示区域签名密钥，S表示KSK和ZSK之间没有区别，但密钥用作安全入口点。“y”表示数字或标识符；y可以被认为是密钥id。
RRsets ignored: If the signatures of non-DNSKEY RRsets have the same parameters as the SOA, then those are not mentioned; e.g., in the example below, the SOA is signed with the same parameters as the foo.example.com A RRset and the latter is therefore ignored in the abbreviated notation.
RRsets被忽略：如果非DNSKEY RRsets的签名具有与SOA相同的参数，则不提及这些参数；e、 例如，在下面的示例中，SOA使用与foo.example.com A RRset相同的参数进行签名，因此后者在缩写符号中被忽略。
RRset notations: RRs are only denoted by the type. All other information -- owner, class, rdata, and TTL -- is left out. Thus: "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRsets are a list of RRs. An example of this would be "A1, A2", specifying the RRset containing two "A" records. This could again be abbreviated to just "A".
RRset符号：RRs仅由类型表示。所有其他信息——所有者、类、rdata和TTL——都被忽略了。因此，“192.0.2.1中的example.com 3600”减少为“A”。RRsets是RRs的列表。例如“A1，A2”，指定包含两个“A”记录的RRset。这可以再次缩写为“A”。
Signature notation: Signatures are denoted as RRSIG_x_y(type), which means that the RRset with the specific RRTYPE 'type' is signed with DNSKEY_x_y. Signatures in the parent zone are denoted as RRSIG_par(type).
签名表示法：签名表示为RRSIG_x_y（type），这意味着具有特定RRTYPE“type”的RRset使用DNSKEY_x_y签名。父区域中的签名表示为RRSIG_par（类型）。
SOA representation: SOAs are represented as SOA_x, where x is the serial number.
SOA表示：SOA表示为SOA_x，其中x是序列号。
DS representation: DSs are represented as DS_x_y, where x and y are identifiers similar to the key notation: x is an identifier for the type of key the DS record refers to; y is the 'key id' of the key it refers to.
DS表示：DSs表示为DS_x_y，其中x和y是与密钥表示法类似的标识符：x是DS记录引用的密钥类型的标识符；y是它引用的密钥的“密钥id”。
Zone representation: Using the above notation we have simplified the representation of a signed zone by leaving out all unnecessary details, such as the names, and by representing all data by "SOA_x".
区域表示法：使用上述表示法，我们省略了所有不必要的细节（如名称），并用“SOA_x”表示所有数据，从而简化了签名区域的表示。
Using this notation, the following signed zone:
使用此符号，以下带符号区域：
example.com. 3600 IN SOA ns1.example.com. olaf.example.net. ( 2005092303 ; serial 450 ; refresh (7 minutes 30 seconds) 600 ; retry (10 minutes) 345600 ; expire (4 days) 300 ; minimum (5 minutes) ) 3600 RRSIG SOA 5 2 3600 20120824013000 ( 20100424013000 14 example.com. NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo ... OMY3rTMA2qorupQXjQ== ) 3600 NS ns1.example.com. 3600 NS ns2.example.com. 3600 NS ns3.example.com. 3600 RRSIG NS 5 2 3600 20120824013000 ( 20100424013000 14 example.com. p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz ... +SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4 zAgaJM/MeG08KpeHhg== ) 3600 TXT "Net::DNS domain" 3600 RRSIG TXT 5 2 3600 20120824013000 ( 20100424013000 14 example.com. o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp ... BcQ1o99vwn+IS4+J1g== ) 300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY 300 RRSIG NSEC 5 2 300 20120824013000 ( 20100424013000 14 example.com. JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+ ... PkXNI/Vgf4t3xZaIyw== ) 3600 DNSKEY 256 3 5 ( AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX ... sAuryjQ/HFa5r4mrbhkJ ) ; key id = 14 3600 DNSKEY 257 3 5 ( AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO ... oy88Nh+u2c9HF1tw0naH ) ; key id = 15
example.com。3600在SOA ns1.example.com中。olaf.example.net。（2005092303；序列号450；刷新（7分30秒）600；重试（10分钟）345600；过期（4天）300；最短（5分钟）3600 RRSIG SOA 5 2 3600 20120824013000。3600 NS ns2.example.com。3600 NS ns3.example.com。3600 RRSIG NS 5 2 3600 20120824013000（201004240130014 example.com.p0cj3wzgopftfzj3jekgk6wglwy6mcbez…+SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4 zAgaJM/meg08kpehg==）3600 TXT“Net:：DNS domain”3600 RRSIG TXT 5 2 3600 2012082401300（201004240130014 example.com.o7eP8LISK2TEutFQRvK/+aqqqpqqqqqqvq14=+bciqvq14）300 NSEC foo.example.com。NS SOA TXT RRSIG NSEC DNSKEY 300 RRSIG NSEC 5 2 300 20120824013000（201004240130014 example.com.JtHm8ta0diCWYGu/tdre1oshbln2i/IX+…PkXNI/Vgf4t3xZaIyw==）3600 DNSKEY 256 3 5（AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX…sAuryjQ/hfa5mrbhkj）；密钥id=143600 DNSKEY 257 3 5（AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO…oy88Nh+u2c9HF1tw0naH）；密钥id=15
3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 20100424013000 14 example.com. HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U ... QhhmMwV3tIxJk2eDRQ== ) 3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 20100424013000 15 example.com. P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE ... JWL70YiUnUG3m9OL9w== ) foo.example.com. 3600 IN A 192.0.2.2 3600 RRSIG A 5 3 3600 20120824013000 ( 20100424013000 14 example.com. xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO ... JPV/SA4BkoFxIcPrDQ== ) 300 NSEC example.com. A RRSIG NSEC 300 RRSIG NSEC 5 3 300 20120824013000 ( 20100424013000 14 example.com. Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF ... Qe000JyzObxx27pY8A== )
3600 RRSIG DNSKE5 2 3600 20120824013000（201004240130014 example.com.HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U…qhhmmw3tixjk2edrq=）3600 RRSIG DNSKE5 2 3600 20120824013000（201004240130015 example.com.P47CUy/xpv8qieuua4tmkg6ei3lq8ry3twe…jwl70yiunug9ol9w=）foo.example.com。3600在192.0.2.2 3600 RRSIG A 5 3 3600 20120824013000（201004240130014 example.com.xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO…JPV/SA4BkoFxIcPrDQ==）300 NSEC example.com。RRSIG NSEC 300 RRSIG NSEC 5300 20120824013000（201004240130014 example.com.aaa4kgkhqy7lzjq3rlplfidymobek1t6vuf…Qe000JyzObxx27pY8A==）
is reduced to the following representation:
简化为以下表示形式：
SOA_2005092303 RRSIG_Z_14(SOA_2005092303) DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14(DNSKEY) RRSIG_Z_15(DNSKEY)
SOA_2005092303 RRSIG_Z_14（SOA_2005092303）DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14（DNSKEY）RRSIG_Z_15（DNSKEY）
The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_14.
其余区域数据具有与SOA记录相同的签名，即使用DNSKEY_K_14创建的RRSIG。
The figures in this appendix complement and illustrate the special cases of algorithm rollovers as described in Section 4.1.4.
本附录中的图补充并说明了第4.1.4节所述的算法翻转的特殊情况。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
DNSKEY__1 DNSKEY__1 DNSKEY__1 DNSKEY_2 RRSIG__1（DNSKEY）RRSIG__1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_2（DNSKEY）RRSIG_2（DNSKEY）
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_S_1(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_S_1(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
------------------->
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
------------------->
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
Figure 12: Single-Type Signing Scheme Algorithm Roll
图12：单类型签名方案算法
Also see Section 4.1.4.1.
另见第4.1.4.1节。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_2 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_2 RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_2（DNSKEY）
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
-------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
-------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
-------------------> DNSKEY_K_1_REVOKED
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_2 DNSKEY_Z_2
-------------------> RRSIG_K_1(DNSKEY)
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
-------------------> DNSKEY_K_1_REVOKED
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_2 DNSKEY_Z_2
-------------------> RRSIG_K_1(DNSKEY)
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
Child: SOA_5 RRSIG_Z_2(SOA)
子女：SOA_5 RRSIG_Z_2（SOA）
DNSKEY_K_2
DNSKEY___2
DNSKEY_Z_2
DNSKEY_Z_2
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 13: RFC 5011 Style Algorithm Roll
图13:RFC 5011样式的滚动算法
Also see Section 4.1.4.2.
另见第4.1.4.2节。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA)
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA)
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_2 RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_1（DNSKEY）RRSIG_2（DNSKEY）RRSIG_2（DNSKEY）
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
-------------------> DNSKEY_S_1_REVOKED
-------------------> DNSKEY_Z_10
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
-------------------> DNSKEY_S_1_REVOKED
-------------------> DNSKEY_Z_10
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
Child: SOA_5
儿童：SOA_5
RRSIG_S_2(SOA)
RRSIG_S_2（SOA）
DNSKEY_S_2
DNSKEY_S_2
RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
Figure 14: RFC 5011 Algorithm Roll in a Single-Type Signing Scheme Environment
图14：单类型签名方案环境中的RFC 5011算法滚动
Also see Section 4.1.4.3.
另见第4.1.4.3节。
The figure in this Appendix complements and illustrates the special case of changing DNS operators as described in Section 4.3.5.1.
本附录中的图补充并说明了第4.3.5.1节所述更改DNS运营商的特殊情况。
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_A NS_B RRSIG_Z_A（NS）NS_B RRSIG_Z_B（NS）RRSIG_Z_A（NS）
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_A DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_A DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A（SOA）RRSIG_Z_B（SOA）RRSIG_Z_B（SOA）
NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_B NS_B NS_B RRSIG_Z_B（NS）RRSIG_Z_B（NS）RRSIG_Z_B（NS）
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Figure 15: An Alternative Rollover Approach for Cooperating Operators
图15：合作运营商的替代滚动方法
This document differs from RFC 4641 [RFC4641] in the following ways:
本文件与RFC 4641[RFC4641]的不同之处如下：
o Addressed the errata listed on <http://www.rfc-editor.org/errata_search.php./rfc4641>.
o 解决了上列出的勘误表<http://www.rfc-editor.org/errata_search.php./rfc4641>.
o Recommended RSA/SHA-256 in addition to RSA/SHA-1.
o 除了RSA/SHA-1之外，建议使用RSA/SHA-256。
o Did a complete rewrite of Section 3.5 of RFC 4641 (Section 3.4.2 of this document), removing the table and suggesting a key size of 1024 for keys in use for less than 8 years, issued up to at least 2015.
o 对RFC 4641第3.5节（本文件第3.4.2节）进行了完全重写，删除了该表，并建议至少在2015年之前发布的使用时间少于8年的密钥的密钥大小为1024。
o Removed the KSK for high-level zones consideration.
o 出于高级别区域考虑，移除了KSK。
o Added text on algorithm rollover.
o 在算法滚动上添加了文本。
o Added text on changing (non-cooperating) DNS registrars.
o 添加了关于更改（非合作）DNS注册器的文本。
o Did a significant rewrite of Section 3, whereby the argument is made that the timescales for rollovers are made purely on operational arguments.
o 对第3节进行了重大改写，其中的论点是，展期的时间表完全是根据运营参数制定的。
o Added Section 5.
o 增加了第5节。
o Introduced Single-Type Signing Scheme terminology and made the arguments for the choice of a Single-Type Signing Scheme more explicit.
o 介绍了单类型签名方案术语，并使选择单类型签名方案的参数更加明确。
o Added a section about stand-by keys.
o 添加了关于备用键的部分。
Authors' Addresses
作者地址
Olaf M. Kolkman NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
荷兰阿姆斯特丹400号奥拉夫M.科尔克曼NLnet实验室科技园1098 XH
EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
W.（Matthijs）Mekking NLnet实验室科技园400阿姆斯特丹1098 XH荷兰
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
R. (Miek) Gieben SIDN Labs Meander 501 Arnhem 6825 MD The Netherlands
R.（Miek）Gieben SIDN实验室蜿蜒501荷兰马里兰州阿纳姆6825
EMail: miek.gieben@sidn.nl
URI: http://www.sidn.nl
EMail: miek.gieben@sidn.nl
URI: http://www.sidn.nl