Network Working Group O. Kolkman
Request for Comments: 4641 R. Gieben
Obsoletes: 2541 NLnet Labs
Category: Informational September 2006
Network Working Group O. Kolkman
Request for Comments: 4641 R. Gieben
Obsoletes: 2541 NLnet Labs
Category: Informational September 2006
DNSSEC Operational Practices
DNSSEC操作规程
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification.
本文件淘汰了RFC 2541，因为它涵盖了更多的操作基础，并给出了有关关键尺寸和新DNSSEC规范的更多最新要求。
Table of Contents
目录
1. Introduction ....................................................3
1.1. The Use of the Term 'key' ..................................4
1.2. Time Definitions ...........................................4
2. Keeping the Chain of Trust Intact ...............................5
3. Keys Generation and Storage .....................................6
3.1. Zone and Key Signing Keys ..................................6
3.1.1. Motivations for the KSK and ZSK Separation ..........6
3.1.2. KSKs for High-Level Zones ...........................7
3.2. Key Generation .............................................8
3.3. Key Effectivity Period .....................................8
3.4. Key Algorithm ..............................................9
3.5. Key Sizes ..................................................9
3.6. Private Key Storage .......................................11
4. Signature Generation, Key Rollover, and Related Policies .......12
4.1. Time in DNSSEC ............................................12
4.1.1. Time Considerations ................................12
4.2. Key Rollovers .............................................14
4.2.1. Zone Signing Key Rollovers .........................14
4.2.1.1. Pre-Publish Key Rollover ..................15
4.2.1.2. Double Signature Zone Signing Key
Rollover ..................................17
4.2.1.3. Pros and Cons of the Schemes ..............18
4.2.2. Key Signing Key Rollovers ..........................18
4.2.3. Difference Between ZSK and KSK Rollovers ...........20
4.2.4. Automated Key Rollovers ............................21
4.3. Planning for Emergency Key Rollover .......................21
4.3.1. KSK Compromise .....................................22
4.3.1.1. Keeping the Chain of Trust Intact .........22
4.3.1.2. Breaking the Chain of Trust ...............23
4.3.2. ZSK Compromise .....................................23
4.3.3. Compromises of Keys Anchored in Resolvers ..........24
4.4. Parental Policies .........................................24
4.4.1. Initial Key Exchanges and Parental Policies
Considerations .....................................24
4.4.2. Storing Keys or Hashes? ............................25
4.4.3. Security Lameness ..................................25
4.4.4. DS Signature Validity Period .......................26
5. Security Considerations ........................................26
6. Acknowledgments ................................................26
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Appendix A. Terminology ...........................................30
Appendix B. Zone Signing Key Rollover How-To ......................31
Appendix C. Typographic Conventions ...............................32
1. Introduction ....................................................3
1.1. The Use of the Term 'key' ..................................4
1.2. Time Definitions ...........................................4
2. Keeping the Chain of Trust Intact ...............................5
3. Keys Generation and Storage .....................................6
3.1. Zone and Key Signing Keys ..................................6
3.1.1. Motivations for the KSK and ZSK Separation ..........6
3.1.2. KSKs for High-Level Zones ...........................7
3.2. Key Generation .............................................8
3.3. Key Effectivity Period .....................................8
3.4. Key Algorithm ..............................................9
3.5. Key Sizes ..................................................9
3.6. Private Key Storage .......................................11
4. Signature Generation, Key Rollover, and Related Policies .......12
4.1. Time in DNSSEC ............................................12
4.1.1. Time Considerations ................................12
4.2. Key Rollovers .............................................14
4.2.1. Zone Signing Key Rollovers .........................14
4.2.1.1. Pre-Publish Key Rollover ..................15
4.2.1.2. Double Signature Zone Signing Key
Rollover ..................................17
4.2.1.3. Pros and Cons of the Schemes ..............18
4.2.2. Key Signing Key Rollovers ..........................18
4.2.3. Difference Between ZSK and KSK Rollovers ...........20
4.2.4. Automated Key Rollovers ............................21
4.3. Planning for Emergency Key Rollover .......................21
4.3.1. KSK Compromise .....................................22
4.3.1.1. Keeping the Chain of Trust Intact .........22
4.3.1.2. Breaking the Chain of Trust ...............23
4.3.2. ZSK Compromise .....................................23
4.3.3. Compromises of Keys Anchored in Resolvers ..........24
4.4. Parental Policies .........................................24
4.4.1. Initial Key Exchanges and Parental Policies
Considerations .....................................24
4.4.2. Storing Keys or Hashes? ............................25
4.4.3. Security Lameness ..................................25
4.4.4. DS Signature Validity Period .......................26
5. Security Considerations ........................................26
6. Acknowledgments ................................................26
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Appendix A. Terminology ...........................................30
Appendix B. Zone Signing Key Rollover How-To ......................31
Appendix C. Typographic Conventions ...............................32
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 [1] and RFC 1035 [2]) and want to deploy DNSSEC. See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the newly introduced Resource Records (RRs), and RFC 4035 [6] for the protocol changes.
本文档描述如何运行启用DNS安全性（DNSSEC）的环境。它适用于了解DNS（参见RFC 1034[1]和RFC 1035[2]）并希望部署DNSSEC的运营商。有关DNSSEC的介绍，请参见RFC 4033[4]，新引入的资源记录（RRs）请参见RFC 4034[5]，协议更改请参见RFC 4035[6]。
During workshops and early operational deployment tests, 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. At the time of writing, there exists very little experience with DNSSEC in production environments; this document should therefore explicitly not be seen as representing 'Best Current Practices'.
在研讨会和早期操作部署测试期间，操作员和系统管理员获得了使用安全扩展（DNSSEC）操作DNS的经验。本文档将这些经验转化为区域管理员的一组实践。在撰写本文时，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 on the Internet.
本文中的程序侧重于维护已签名区域（即，权威服务器上的签名和发布区域）。其目的是使区域的维护（如重新签名或密钥滚动）对Internet上的任何验证客户端都是透明的。
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 private keys are discussed in Section 3; the focus in this section is mainly on the private part of the key(s). Section 4 describes considerations concerning the public part of the keys. Since these public keys appear in the DNS one has to take into account all kinds of timing issues, which are discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the rollover, or supercession, of keys. Finally, Section 4.4 discusses considerations on how parents deal with their children's public keys in order to maintain chains of trust.
本文件的结构如下。在第2节中，我们将讨论保持“信任链”完整性的重要性。第3节讨论了密钥生成和私钥存储的各个方面；本节的重点主要是密钥的私有部分。第4节描述了有关密钥公共部分的注意事项。由于这些公钥出现在DNS中，因此必须考虑各种各样的时间问题，这些问题将在第4.1节中讨论。第4.2节和第4.3节涉及键的翻转或替代。最后，第4.4节讨论了父母如何处理子女的公钥以维持信任链的考虑事项。
The typographic conventions used in this document are explained in Appendix C.
附录C解释了本文件中使用的印刷惯例。
Since this is a document with operational suggestions and there are no protocol specifications, the RFC 2119 [7] language does not apply.
由于本文件包含操作建议，且没有协议规范，因此RFC 2119[7]语言不适用。
This document obsoletes RFC 2541 [12] to reflect the evolution of the underlying DNSSEC protocol since then. Changes in the choice of cryptographic algorithms, DNS record types and type names, and the parent-child key and signature exchange demanded a major rewrite and additional information and explanation.
本文件淘汰了RFC 2541[12]，以反映自那时以来基础DNSSEC协议的演变。加密算法的选择、DNS记录类型和类型名称以及父子密钥和签名交换的更改需要进行重大重写，并提供额外的信息和解释。
It is assumed that the reader is familiar with the concept of asymmetric keys on which DNSSEC is based (public key cryptography [17]). 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 and that it is the public part that is used in key exchanges.
假设读者熟悉DNSSEC所基于的非对称密钥的概念（公钥加密[17]）。因此，本文件将不严格地使用术语“键”。在写入“密钥用于对数据进行签名”的情况下，假定读取器理解用于签名的是密钥对的私有部分。还假设读者理解密钥对的公共部分发布在DNSKEY资源记录中，并且密钥交换中使用的是公共部分。
In this document, we will be using a number of time-related terms. The following definitions apply:
在本文档中，我们将使用一些与时间相关的术语。以下定义适用：
o "Signature validity period" The period that a signature is valid. It starts at the time specified in the signature inception field of the RRSIG RR and ends at the time specified in the expiration field of the RRSIG RR.
o “签名有效期”签名的有效期。它从RRSIG RR的签名起始字段中指定的时间开始，到RRSIG RR的到期字段中指定的时间结束。
o "Signature publication period" Time after which a signature (made with a specific key) is replaced with a new signature (made with the same key). This replacement takes place by publishing the relevant RRSIG in the master zone file. 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.
o “签名发布期”指签名（使用特定密钥制作）替换为新签名（使用相同密钥制作）的时间。此替换通过在主区域文件中发布相关RRSIG来实现。停止在区域中发布RRSIG后，RRSIG可能需要一段时间才能从缓存中过期并实际从DNS中删除。
o "Key effectivity period" The period during which a key pair is expected to be effective. This period is defined as the time between the first 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.
o “密钥有效期”密钥对预计有效的期间。此期限定义为使用此密钥进行的任何签名的第一个起始时间戳和最后一个到期日期之间的时间，无论密钥的使用是否存在中断。密钥有效期可以跨越多个签名有效期。
o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum value of the TTLs from the complete set of RRs in a zone. Note that the minimum TTL is not the same as the MINIMUM field in the SOA RR. See [11] for more information.
o “最大/最小区域生存时间（TTL）”区域中完整RRs集合中TTL的最大或最小值。请注意，最小TTL与SOA RR中的最小字段不同。有关更多信息，请参见[11]。
Maintaining a valid chain of trust is important because broken chains of trust will result in data being marked as Bogus (as defined in [4] Section 5), which may cause entire (sub)domains to become invisible to verifying clients. The administrators of secured zones have to realize that their zone is, to verifying clients, part of a chain of trust.
维护有效的信任链非常重要，因为断开的信任链将导致数据被标记为伪数据（定义见[4]第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 have 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 nameservers and clients may be fetching data from caching non-authoritative servers. In this light, note that the time for a zone transfer from master to slave is negligible when using NOTIFY [9] and incremental transfer (IXFR) [8]. It increases when full zone transfers (AXFR) are used in combination with NOTIFY. It increases even more if you rely on full zone transfers based on only the SOA timing parameters for refresh.
安全区域的管理员必须记住，验证客户端不会立即看到在权威主服务器上发布的数据；数据传输到其他二级权威名称服务器可能需要一些时间，客户端可能正在从缓存非权威服务器获取数据。有鉴于此，请注意，当使用NOTIFY[9]和增量传输（IXFR）[8]时，从主设备到从设备的区域传输时间可以忽略不计。当全区域传输（AXFR）与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 nameserver, 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 trade-off between maintaining a valid chain of trust and replacing the compromised keys as soon as possible must be made. Then zone administrators will have to make a trade-off, 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.3.
维护信任链的责任由信任链中安全区域的管理员分担。这在“密钥泄露”的情况下最为明显，因为必须在维护有效的信任链和尽快更换泄露的密钥之间进行权衡。然后，区域管理员必须在保持信任链完好无损（从而允许使用受损密钥进行攻击）或故意破坏信任链和使安全子域对安全感知解析程序不可见之间进行权衡。另见第4.3节。
This section describes a number of considerations with respect to the security of keys. It deals with the generation, effectivity period, size, and storage of private keys.
本节介绍了有关密钥安全性的一些注意事项。它涉及私钥的生成、有效期、大小和存储。
The DNSSEC validation protocol does not distinguish between different types of DNSKEYs. All DNSKEYs can be used during the validation. In practice, operators use Key Signing and Zone Signing Keys and use the so-called Secure Entry Point (SEP) [3] flag to distinguish between them during operations. The dynamics and considerations are discussed below.
DNSSEC验证协议不区分不同类型的DNSKEY。所有DNSKEY均可在验证期间使用。实际上，操作员使用密钥签名和区域签名密钥，并在操作期间使用所谓的安全入口点（SEP）[3]标志来区分它们。下文讨论了动态和注意事项。
To make zone re-signing and key rollover procedures easier to implement, it is possible to use one or more keys as 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 RRSets in a zone and are referred to as Zone Signing Keys (ZSKs). In this document, we assume that KSKs are the subset of keys that are used for key exchanges with the parent and potentially for configuration as trusted anchors -- the SEP keys. In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
为了使区域重新签名和密钥翻转过程更容易实现，可以使用一个或多个密钥作为密钥签名密钥（KSK）。这些键仅对区域中的apex DNSKEY RRSet进行签名。其他密钥可用于对区域中的所有RRSET进行签名，称为区域签名密钥（ZSK）。在本文档中，我们假设KSK是密钥的子集，用于与父级进行密钥交换，并可能用于配置为可信锚（SEP密钥）。在本文档中，我们假设KSK和SEP键之间存在一对一的映射，并假设在所有KSK上设置SEP标志。
Differentiating between the KSK and ZSK functions has several advantages:
区分KSK和ZSK功能有几个优点：
o No parent/child interaction is required when ZSKs are updated.
o 更新ZSK时不需要父/子交互。
o The KSK can be made stronger (i.e., using more bits in the key material). This has little operational impact since it is only used to sign a small fraction of the zone data. Also, the KSK is only used to verify the zone's key set, not for other RRSets in the zone.
o KSK可以变得更强（即在关键材料中使用更多比特）。这对操作的影响很小，因为它只用于签署一小部分区域数据。此外，KSK仅用于验证区域的密钥集，而不用于区域中的其他RRSET。
o As the KSK is only used to sign a key set, which is most probably updated less frequently than other data in the zone, it can be stored separately from and in a safer location than the ZSK.
o 由于KSK仅用于对密钥集进行签名，而密钥集的更新频率很可能低于区域中的其他数据，因此可以将其与ZSK分开存储，并存储在比ZSK更安全的位置。
o A KSK can have a longer key effectivity period.
o KSK可以具有更长的密钥有效期。
For almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a key set is signed with the KSK, all the keys in the key set can be used as ZSKs. If a ZSK is
对于几乎任何密钥管理和区域签名方法，KSK的使用频率都低于ZSK。一旦密钥集使用KSK签名，密钥集中的所有密钥都可以用作ZSK。如果ZSK是
compromised, it can be simply dropped from the key set. The new key set is then re-signed with the KSK.
如果受到损害，它可以简单地从密钥集中删除。然后使用KSK重新签名新密钥集。
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. If it is an even number it is a ZSK.
假设设置了KSK的SEP标志，则可以通过检查DNSKEY RR中的标志字段来区分KSK和ZSK。如果标志字段为奇数，则为KSK。如果是偶数，则为ZSK。
The Zone Signing Key can be used to sign all the data in a zone on a regular basis. When a Zone Signing Key is to be rolled, no interaction with the parent is needed. This allows for signature validity periods on the order of days.
区域签名密钥可用于定期对区域中的所有数据进行签名。当要滚动区域签名密钥时，不需要与父级交互。这允许签名有效期为天。
The Key Signing Key is only to be used to sign the DNSKEY RRs in a zone. If a Key Signing Key is to be rolled over, there will be interactions with parties other than the zone administrator. These can include the registry of the parent zone or administrators of verifying resolvers that have the particular key configured as secure entry points. Hence, the key effectivity period of these keys can and should be made much longer. Although, given a long enough key, the key effectivity period can be on the order of years, we suggest planning for a key effectivity on the order of a few months so that a key rollover remains an operational routine.
密钥签名密钥仅用于对区域中的DNSKEY RRs进行签名。如果要滚动密钥签名密钥，则将与区域管理员以外的其他方进行交互。这些可以包括父区域的注册表或验证将特定密钥配置为安全入口点的解析程序的管理员。因此，这些密钥的密钥有效期可以而且应该更长。虽然，如果关键有效期足够长，关键有效期可以是几年左右，但我们建议规划几个月左右的关键有效期，以便关键过渡仍然是一个操作例行程序。
Higher-level zones are generally more sensitive than lower-level zones. Anyone controlling or breaking the security of a zone thereby obtains authority over all of its subdomains (except in the case of resolvers that have locally configured the public key of a subdomain, in which case this, and only this, subdomain wouldn't be affected by the compromise of the parent zone). Therefore, extra care should be taken with high-level zones, and strong keys should be used.
较高级别的区域通常比较低级别的区域更敏感。任何控制或破坏区域安全的人都可以获得其所有子域的权限（本地配置子域公钥的解析程序除外，在这种情况下，子域不会受到父区域泄露的影响。因此，应特别注意高级区域，并应使用强键。
The root zone is the most critical of all zones. Someone controlling or compromising the security of the root zone would control the entire DNS namespace of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off-line.
根区域是所有区域中最关键的区域。控制或破坏根区域安全性的人将控制使用该根区域的所有解析程序的整个DNS命名空间（本地配置了子域公钥的解析程序除外）。因此，在保护根部区域时必须格外小心。应使用最结实、处理最仔细的钥匙。根区域私钥应始终保持脱机状态。
Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating the trust anchors in an enormous population of resolvers around the world will be extremely difficult.
许多解析程序将在根服务器上启动，以访问和验证DNS数据。安全地更新世界各地大量解析程序中的信任锚将是极其困难的。
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 [14]. One should carefully assess if the random number generator used during key generation adheres to these suggestions.
在任何加密安全系统中，仔细地生成所有密钥有时是一个被忽略但绝对必要的元素。如果对手能够猜出足够多的信息来降低可能的密钥空间的大小，以便对其进行彻底搜索，那么使用最长密钥的最强算法仍然没有用处。有关生成随机密钥的技术建议，请参见RFC 4086[14]。您应该仔细评估密钥生成过程中使用的随机数生成器是否符合这些建议。
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 strongly recommended 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.
具有长有效期的密钥特别敏感，因为它们将代表一个更有价值的目标，并且比短有效期密钥受到攻击的时间更长。强烈建议通过气隙或至少高级安全硬件以与网络隔离的方式离线生成长期密钥。
For various reasons, keys in DNSSEC need to be changed once in a while. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, when key rollovers are too rare an event, they will not become part of the operational habit and there is risk that nobody on-site will remember the procedure for rollover when the need is there.
出于各种原因，DNSSEC中的密钥需要偶尔更改一次。密钥使用的时间越长，由于疏忽、事故、间谍活动或密码分析而被泄露的可能性就越大。此外，当关键翻车事件太少时，它们将不会成为操作习惯的一部分，并且存在这样的风险：当需要翻车时，现场没有人会记住翻车程序。
From a purely operational perspective, a reasonable key effectivity period for Key Signing Keys is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys.
从纯操作的角度来看，密钥签名密钥的合理密钥有效期为13个月，目的是在12个月后更换密钥。对于区域签名密钥，一个月的预期密钥有效期是合理的。
For key sizes that match these effectivity periods, see Section 3.5.
有关与这些有效期相匹配的关键尺寸，请参见第3.5节。
As argued in Section 3.1.2, securely updating trust anchors will be extremely difficult. On the other hand, the "operational habit" argument does also apply to trust anchor reconfiguration. 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 is smaller. The trade-off is against a system that is so dynamic that administrators of the validating clients will not be able to follow the modifications.
如第3.1.2节所述，安全地更新信任锚极为困难。另一方面，“操作习惯”参数也适用于信任锚重配置。如果使用较短的密钥有效期，并且必须定期重新访问信任锚点配置，则该配置被遗忘的可能性较小。这种权衡是针对这样一个系统的，该系统是如此动态，以至于验证客户端的管理员将无法跟踪修改。
Key effectivity periods can be made very short, as in a few minutes. But when replacing keys one has to take the considerations from Section 4.1 and Section 4.2 into account.
关键有效期可以非常短，如几分钟内。但更换钥匙时，必须考虑第4.1节和第4.2节中的考虑因素。
There are currently three different types of algorithms that can be used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The latter is fairly new and has yet to be standardized for usage in DNSSEC.
目前有三种不同类型的算法可用于DNSSEC：RSA、DSA和椭圆曲线加密。后者是相当新的，尚未在DNSSEC中标准化使用。
RSA has been developed in an open and transparent manner. As the patent on RSA expired in 2000, its use is now also free.
RSA是以公开透明的方式开发的。由于RSA的专利在2000年到期，它的使用现在也是免费的。
DSA has been developed by the National Institute of Standards and Technology (NIST). The creation of signatures takes roughly the same time as with RSA, but is 10 to 40 times as slow for verification [17].
DSA由国家标准与技术研究所（NIST）开发。创建签名所需的时间与RSA大致相同，但验证速度是RSA的10到40倍[17]。
We suggest the use of RSA/SHA-1 as the preferred algorithm for the key. The current known attacks on RSA can be defeated by making your key longer. As the MD5 hashing algorithm is showing cracks, we recommend the usage of SHA-1.
我们建议使用RSA/SHA-1作为密钥的首选算法。通过延长密钥长度，可以击败目前已知的RSA攻击。由于MD5哈希算法出现了漏洞，我们建议使用SHA-1。
At the time of publication, it is known that the SHA-1 hash has cryptanalysis issues. There is work in progress on addressing these issues. We recommend the use of public key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256), as soon as these algorithms are available in protocol specifications (see [19] and [20]) and implementations.
在发布时，已知SHA-1哈希存在密码分析问题。解决这些问题的工作正在进行中。我们建议在协议规范（见[19]和[20]）和实现中提供基于比SHA-1（如SHA-256）更强散列的公钥算法后，立即使用这些算法。
When choosing key sizes, zone administrators will need to take into account how long a key will be used, how much data will be signed during the key publication period (see Section 8.10 of [17]), and, optionally, how large the key size of the parent is. As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger then the others. As always, it's the weakest link that defines the strength of the entire chain. Also see Section 3.1.1 for a discussion of how keys serving different roles (ZSK vs. KSK) may need different key sizes.
在选择密钥大小时，区域管理员需要考虑密钥的使用时间、密钥发布期间签名的数据量（见[17]第8.10节），以及父密钥大小（可选）。由于信任链实际上是一条“链条”，因此，将链条中的一把钥匙放大几倍没有多大意义。和往常一样，它是决定整个链条强度的最薄弱环节。另请参见第3.1.1节，了解服务于不同角色（ZSK与KSK）的密钥如何需要不同的密钥大小。
Generating a key of the correct size is a difficult problem; RFC 3766 [13] tries to deal with that problem. The first part of the selection procedure in Section 1 of the RFC states:
生成正确大小的密钥是一个难题；RFC 3766[13]试图解决这个问题。RFC第1节中选择程序的第一部分规定：
1. Determine the attack resistance necessary to satisfy the security requirements of the application. Do this by estimating the minimum number of computer operations that the attacker will be forced to do in order to compromise the
1. 确定满足应用程序安全要求所需的抗攻击能力。要做到这一点，请估计攻击者将被迫执行的最小计算机操作数，以危害安全
security of the system and then take the logarithm base two of that number. Call that logarithm value "n".
然后取该数字的以2为底的对数。把那个对数叫做“n”。
A 1996 report recommended 90 bits as a good all-around choice for system security. The 90 bit number should be increased by about 2/3 bit/year, or about 96 bits in 2005.
1996年的一份报告建议将90位作为系统安全性的良好全面选择。90位数字应每年增加约2/3位，或在2005年增加约96位。
[13] goes on to explain how this number "n" can be used to calculate the key sizes in public key cryptography. This culminated in the table given below (slightly modified for our purpose):
[13] 接着解释如何使用这个数字“n”来计算公钥密码中的密钥大小。这最终导致下表（根据我们的目的稍微修改）：
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
| for attack | key size | modulus size |
| resistance | (bits) | (bits) |
| (bits) | | |
+-------------+-----------+--------------+
| 70 | 70 | 947 |
| 80 | 80 | 1228 |
| 90 | 90 | 1553 |
| 100 | 100 | 1926 |
| 150 | 150 | 4575 |
| 200 | 200 | 8719 |
| 250 | 250 | 14596 |
+-------------+-----------+--------------+
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
| for attack | key size | modulus size |
| resistance | (bits) | (bits) |
| (bits) | | |
+-------------+-----------+--------------+
| 70 | 70 | 947 |
| 80 | 80 | 1228 |
| 90 | 90 | 1553 |
| 100 | 100 | 1926 |
| 150 | 150 | 4575 |
| 200 | 200 | 8719 |
| 250 | 250 | 14596 |
+-------------+-----------+--------------+
The key sizes given are rather large. This is because these keys are resilient against a trillionaire attacker. Assuming this rich attacker will not attack your key and that the key is rolled over once a year, we come to the following recommendations about KSK sizes: 1024 bits for low-value domains, 1300 bits for medium-value domains, and 2048 bits for high-value domains.
给出的键尺寸相当大。这是因为这些密钥具有抵御trillionaire攻击者的弹性。假设此富攻击者不会攻击您的密钥，并且密钥每年滚动一次，我们就KSK大小提出以下建议：1024位用于低值域，1300位用于中等值域，2048位用于高值域。
Whether a domain is of low, medium, or high value depends solely on the views of the zone owner. One could, for instance, view leaf nodes in the DNS as of low value, and top-level domains (TLDs) or the root zone of high value. The suggested key sizes should be safe for the next 5 years.
域是低值、中值还是高值完全取决于区域所有者的意见。例如，可以将DNS中的叶节点视为低值，将顶级域（TLD）或根区域视为高值。建议的密钥大小在未来5年内应该是安全的。
As ZSKs can be rolled over more easily (and thus more often), the key sizes can be made smaller. But as said in the introduction of this paragraph, making the ZSKs' key sizes too small (in relation to the KSKs' sizes) doesn't make much sense. Try to limit the difference in size to about 100 bits.
由于ZSK更容易翻转（因此更频繁），因此关键尺寸可以更小。但正如本段引言中所述，将ZSK的密钥大小设置得太小（相对于KSK的大小）没有多大意义。尝试将大小差异限制在100位左右。
Note that nobody can see into the future and that these key sizes are only provided here as a guide. Further information can be found in [16] and Section 7.5 of [17]. It should be noted though that [16] is already considered overly optimistic about what key sizes are considered safe.
请注意，没有人能够预见未来，这些关键尺寸仅作为指南提供。更多信息见[16]和[17]第7.5节。但应注意的是[16]已经被认为过于乐观，认为哪些键大小是安全的。
One final note concerning key sizes. Larger keys will increase the sizes of the RRSIG and DNSKEY records and will therefore increase the chance of DNS UDP packet overflow. Also, the time it takes to validate and create RRSIGs increases with larger keys, so don't needlessly double your key sizes.
关于键大小的最后一个注释。较大的密钥会增加RRSIG和DNSKEY记录的大小，因此会增加DNS UDP数据包溢出的机会。此外，验证和创建RRSIG所需的时间随着密钥的增大而增加，因此不要不必要地将密钥大小增加一倍。
It is recommended 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 RRs. Then the augmented file can be transferred.
建议在可能的情况下，仅在离线、非网络连接、物理安全的机器上保存和使用区域私钥和要签名的区域文件主副本。可以定期运行应用程序，通过添加RRSIG和NSEC RRs向区域添加身份验证。然后可以传输扩充文件。
When relying on dynamic update to manage a signed zone [10], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RR set, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup.
当依靠动态更新来管理签名区域[10]时，请注意该区域的至少一个私钥必须驻留在主服务器上。此密钥的安全性取决于服务器对未知客户端的暴露量和主机的安全性。虽然不是强制性的，但是可以通过以下方式管理DNS。处理动态更新的主机在Internet上的通用主机上不可用，它未列在NS RR集中，尽管其名称显示在SOA RRs MNAME字段中。NS RRSet中的名称服务器能够通过NOTIFY、IXFR、AXFR或带外分发机制接收区域更新。这种方法称为“隐藏主”设置。
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 file 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.
理想的情况是向网络提供单向信息流，以避免网络篡改的可能性。在网络上保持区域主文件在线，并通过离线签名者简单地循环该文件不会做到这一点。如果在线版本所在的主机被破坏，在线版本仍然可能被篡改。为了最大限度地提高安全性，区域文件的主副本应为离线，并且不应基于不安全的网络中介通信进行更新。
In general, keeping a zone file off-line will not be practical and the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy.
一般来说，使区域文件离线是不现实的，维护区域文件的机器将连接到网络。建议运营商采取安全措施，防止未经授权访问母版。
For dynamically updated secured zones [10], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line.
对于动态更新的安全区域[10]，更新的RRs上用于更新签名的主副本和私钥都需要在线。
Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time elapsed after a slave server synchronized with a master server. The Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] are used to determine how long a forwarder should cache data 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参数[11]用于确定从权威服务器获取数据后，转发器应缓存数据的时间。通过使用签名有效期，DNSSEC在DNS中引入了绝对时间的概念。DNSSEC中的签名有一个到期日期，在此日期之后，签名被标记为无效，并且签名的数据将被视为伪造的。
Because of the expiration of signatures, one should consider the following:
由于签名期满，应考虑以下事项：
o We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period.
o 我们建议您的区域数据的最大区域TTL为您的签名有效期的一小部分。
If the TTL would be of similar order as the signature validity period, then all RRSets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [4] 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, query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches.
如果TTL的顺序与签名有效期相似，那么在有效期内获取的所有RRSET都将被缓存，直到签名过期。[4]第7.1节建议“解析器可以使用已签名RRSet的签名有效期到期前的剩余时间作为TTL的上限”。因此，权威服务器上的查询负载将在签名过期时达到峰值，因为这也是记录从缓存同时过期的时间。
To avoid query load peaks, we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period.
为了避免查询负载高峰，我们建议您所在区域中所有RRs上的TTL至少比您的签名有效期小几倍。
o We suggest the signature publication period to end at least one Maximum Zone TTL duration 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 simultaneous expiration of data from caches. This in turn may lead to peaks in the load on authoritative servers.
在签名有效期结束前不久对区域重新签名可能会导致缓存中的数据同时过期。这反过来可能导致权威服务器上的负载达到峰值。
o We suggest the Minimum Zone TTL to be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated [18] that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems:
o 我们建议最小区域TTL的长度应足以获取和验证信任链中的所有RRs。在车间环境中，已证明[18]由于以下两个问题，低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: DSes, DNSKEYs, RRSIGs, and the final answers, i.e., the RRSet that is returned for the initial query.
1. 在验证期间，某些数据可能在验证完成之前过期。验证器应该能够保存所有数据，直到完成。这适用于完成信任链所需的所有RRs：DSE、DNSKEY、RRSIGs和最终答案，即为初始查询返回的RRSet。
2. Frequent verification causes load on recursive nameservers. Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit from caching. The TTL on those should be relatively long.
2. 频繁的验证会导致递归名称服务器上的负载。委托点、DSE、DNSKEY和RRSIG处的数据受益于缓存。这些设备上的TTL应相对较长。
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 sync 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 zone, then it may well happen that the signatures expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this from happening by tweaking the SOA parameters. However, the effects can be minimized where the SOA expiration time is equal to or shorter than the signature validity period. The consequence of an authoritative server not being able to update
如果服务器为DNSSEC区域提供服务，那么签名很可能在SOA过期计时器倒计时到零之前过期。通过调整SOA参数不可能完全防止这种情况发生。但是，如果SOA过期时间等于或小于签名有效期，则可以将影响降至最低。权威服务器无法更新的后果
a zone, whilst that zone includes expired signatures, is that 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 the SOA expiration timer being approximately one third or one fourth of the signature validity period. It will allow problems with transfers from the master server to be noticed before the actual signature times out. We also suggest that operators of nameservers that supply secondary services develop 'watch dogs' to spot upcoming signature expirations in zones they slave, and take appropriate action.
我们建议SOA过期计时器大约为签名有效期的三分之一或四分之一。它将允许在实际签名超时之前注意到来自主服务器的传输问题。我们还建议提供二级服务的名称服务器的运营商开发“看门狗”，以便在其从属的区域中发现即将到来的签名过期，并采取适当的措施。
When determining the value for the expiration parameter one has to take the following into account: What are the chances that all my secondaries expire the zone? How quickly can I reach an administrator of secondary servers to load a valid zone? These questions are not DNSSEC specific but may influence the choice of your signature validity intervals.
在确定expiration参数的值时，必须考虑以下因素：我的所有二级数据库在区域内过期的可能性有多大？我能以多快的速度联系辅助服务器的管理员以加载有效区域？这些问题不是DNSSEC特有的，但可能会影响您的签名有效期间隔的选择。
A DNSSEC key cannot be used forever (see Section 3.3). So key rollovers -- or supercessions, as they are sometimes called -- are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account 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密钥不能永远使用（见第3.3节）。因此，在使用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".
最紧迫的例子发生在使用旧密钥签名的区域材质由未缓存旧区域密钥的解析程序验证时。如果旧密钥不再存在于当前区域中，此验证将失败，并将数据标记为“伪造”。或者，可以尝试根据本地缓存中的旧密钥验证使用新密钥签名的数据，这也会导致数据被标记为“伪造”。
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 schema, described in Section 4.2.1.2, uses
对于“区域签名密钥翻转”，有两种方法可以确保在翻转期间仍然缓存的数据可以用新密钥集进行验证，或者新生成的签名可以用仍然缓存的密钥进行验证。第4.2.1.2节中描述的一个模式使用
double signatures; the other uses key pre-publication (Section 4.2.1.1). The pros, cons, and recommendations are described in Section 4.2.1.3.
双重签名；另一种使用关键预发布（第4.2.1.1节）。第4.2.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. A small "how-to" for this kind of rollover can be found in Appendix B.
本节介绍如何执行ZSK滚动，而无需对区域中的所有数据进行两次签名——“预发布密钥滚动”。这种方法在密钥泄露的情况下具有优势。如果旧密钥被泄露，则新密钥已在DNS中分发。然后，区域管理员可以快速切换到新密钥，并从区域中删除受损密钥。另一个主要优点是，区域大小不会像双签名ZSK滚动那样翻倍。附录B中给出了此类翻滚的小“操作方法”。
Pre-publish key rollover involves four stages as follows:
预发布密钥滚动涉及以下四个阶段：
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover
预发布密钥翻转
initial: Initial version of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key.
初始：区域的初始版本：DNSKEY 1是密钥签名密钥。DNSKEY 10用于对区域的所有数据进行签名，即区域签名密钥。
new DNSKEY: DNSKEY 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 the 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 TTL value of the key set.
新DNSKEY:DNSKEY 11被引入密钥集。请注意，此密钥尚未生成任何签名，但这无法防止对公钥的暴力攻击。此预滚动阶段的最短持续时间是数据传播到权威服务器所需的时间加上密钥集的TTL值。
new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is used to sign the data in the zone exclusively (i.e., all the signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 remains published in the key set. This way data that was loaded
新RRSIGs：在“新RRSIGs”阶段（SOA序列2），DNSKEY 11用于以独占方式对区域中的数据进行签名（即，来自DNSKEY 10的所有签名将从区域中删除）。DNSKEY 10仍在密钥集中发布。这样就可以加载数据
into caches from version 1 of the zone can still be verified with key sets fetched from version 2 of the zone. The minimum time that the key set including DNSKEY 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.
仍然可以使用从区域版本2获取的密钥集验证从区域版本1进入缓存。包括DNSKEY 10在内的密钥集要发布的最短时间是以前版本的区域数据从旧缓存中过期所需的时间，即此区域传播到所有权威服务器所需的时间加上以前版本的区域中任何数据的最大区域TTL值。
DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the DNSKEY 1.
DNSKEY移除：DNSKEY 10从区域中移除。密钥集（现在仅包含DNSKEY 1和DNSKEY 11）使用DNSKEY 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 12 and again a newer one, numbered 13, in "new DNSKEY (II)":
通过总是在翻滚后立即发布“future”密钥，可以简化上述方案。该方案如下所示（我们展示了两次滚动）；未来密钥在“新DNSKEY”中作为DNSKEY 12引入，在“新DNSKEY（II）”中再次引入编号为13的新密钥：
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11 DNSKEY12
RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11 DNSKEY12
RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA3 SOA4
RRSIG12(SOA3) RRSIG12(SOA4)
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA3 SOA4
RRSIG12(SOA3) RRSIG12(SOA4)
DNSKEY1 DNSKEY1
DNSKEY11 DNSKEY12
DNSKEY12 DNSKEY13
RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
----------------------------------------------------------------
DNSKEY1 DNSKEY1
DNSKEY11 DNSKEY12
DNSKEY12 DNSKEY13
RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover, Showing Two Rollovers
预发布键翻转，显示两个翻转
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 key 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 Maximum Zone TTL.
在“新DNSKEY”阶段，区域文件的新版本将需要传播到所有权威服务器，并且（远程）缓存中存在的数据将需要过期，至少需要最大区域TTL。
Double signature ZSK rollover involves three stages as follows:
双重签名ZSK展期包括以下三个阶段：
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
双重签名区域签名密钥翻转
initial: Initial Version of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key.
初始：区域的初始版本：DNSKEY 1是密钥签名密钥。DNSKEY 10用于对区域的所有数据进行签名，即区域签名密钥。
new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is introduced into the key set and all the data in the zone is signed with DNSKEY 10 and DNSKEY 11. The rollover period will need to continue until all data from version 0 of the zone has expired from remote caches. This will take at least the Maximum Zone TTL of version 0 of the zone.
新DNSKEY：在“新DNSKEY”阶段（SOA序列1），DNSKEY 11被引入密钥集中，区域中的所有数据都用DNSKEY 10和DNSKEY 11签名。滚动期将需要继续，直到来自区域版本0的所有数据从远程缓存中过期。这将至少占用区域版本0的最大区域TTL。
DNSKEY removal: DNSKEY 10 is removed from the zone. All the signatures from DNSKEY 10 are removed from the zone. The key set, now only containing DNSKEY 11, is re-signed with DNSKEY 1.
DNSKEY移除：DNSKEY 10从区域中移除。DNSKEY 10的所有签名将从区域中删除。密钥集（现在仅包含DNSKEY 11）使用DNSKEY 1重新签名。
At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRSet from the current version and the other way around. The data from the current version can be verified with the data from the previous version of the zone. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the Maximum Zone TTL.
在任何情况下，都可以使用当前版本的DNSKEY RRSet验证以前版本的区域的RRSIG，反之亦然。当前版本的数据可以与以前版本的分区数据进行验证。“新DNSKEY”阶段的持续时间和翻车之间的时间应至少为最大区域TTL。
Making sure that the "new DNSKEY" phase lasts until the signature expiration time of the data in initial version of the zone is recommended. This way all caches are cleared of the old signatures. However, this duration could be considerably longer than the Maximum Zone TTL, making the rollover a lengthy procedure.
确保“新DNSKEY”阶段持续到建议区域初始版本中数据的签名过期时间。这样，所有缓存都会清除旧签名。然而，该持续时间可能比最大区域TTL长得多，这使得翻车过程非常漫长。
Note that in this example we assumed that the zone was not modified during the rollover. New data can be introduced in the zone 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 steps. Also the pre-publish scheme involves more parental work when used for KSK rollovers as explained in Section 4.2.3.
预发布密钥滚动：此滚动不涉及对区域数据进行两次签名。相反，在实际翻滚之前，新密钥在密钥集中发布，因此可用于密码分析攻击。一个小缺点是这个过程需要四个步骤。此外，如第4.2.3节所述，当用于KSK滚动时，预发布方案涉及更多的母公司工作。
Double signature ZSK rollover: The drawback of this signing scheme 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 steps.
双重签名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签名，因此区域大小考虑不适用。
--------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 --------> SOA1 -------->
RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
DS1 --------> DS2 -------->
RRSIGpar(DS) --------> RRSIGpar(DS) -------->
--------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 --------> SOA1 -------->
RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
DS1 --------> DS2 -------->
RRSIGpar(DS) --------> RRSIGpar(DS) -------->
Child:
SOA0 SOA1 --------> SOA2
RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
-------->
DNSKEY1 DNSKEY1 --------> DNSKEY2
DNSKEY2 -------->
DNSKEY10 DNSKEY10 --------> DNSKEY10
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
RRSIG2 (DNSKEY) -------->
RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
--------------------------------------------------------------------
Child:
SOA0 SOA1 --------> SOA2
RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
-------->
DNSKEY1 DNSKEY1 --------> DNSKEY2
DNSKEY2 -------->
DNSKEY10 DNSKEY10 --------> DNSKEY10
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
RRSIG2 (DNSKEY) -------->
RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
--------------------------------------------------------------------
Stages of Deployment for a Double Signature Key Signing Key Rollover
双重签名密钥翻滚的部署阶段
initial: Initial version of the zone. The parental DS points to DNSKEY1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY1 -- it is needed during the rollover and we refer to the value as TTL_DS.
初始：区域的初始版本。父DS指向DNSKEY1。在翻滚开始之前，子级必须验证指向DNSKEY1的DS RR的TTL是什么——这是翻滚期间需要的，我们将该值称为TTL_DS。
new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY2. 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 DNSKEY2. 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，DNSKEY2。将密钥提供给父级，子级必须等待生成指向DNSKEY2的新DS RR。在父区域的所有权威服务器上发布DS RR后，区域管理员必须至少等待TTL_DS，以确保旧DS RR已从缓存中过期。
DS change: The parent replaces DS1 with DS2.
DS更改：父级将DS1替换为DS2。
DNSKEY removal: DNSKEY1 has been removed.
DNSKEY移除：DNSKEY1已移除。
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 relation, 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. Since at the moment of writing the protocol for this interaction has not been developed, further discussion is out of scope for this document.
RRs在父级。由于在编写此交互的协议时尚未制定，因此本文件不包括进一步的讨论。
Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing of trust anchors) and the ensuing delay while waiting for it.
请注意，KSK展期和ZSK展期的不同之处在于，KSK展期需要与母公司进行交互（可能需要更换信任锚），并在等待过程中产生延迟。
A zone key rollover can be handled in two different ways: pre-publish (Section 4.2.1.1) and double signature (Section 4.2.1.2).
可以通过两种不同的方式处理区域密钥翻转：预发布（第4.2.1.1节）和双重签名（第4.2.1.2节）。
As the KSK is used to validate the key set and because the KSK is not changed during a ZSK rollover, a cache is able to validate the new key set of the zone. The pre-publish method would also work for a KSK rollover. The records that are to be pre-published are the parental DS RRs. The pre-publish method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks.
由于KSK用于验证密钥集，并且由于KSK在ZSK滚动期间没有更改，因此缓存能够验证分区的新密钥集。预发布方法也适用于KSK滚动。要预发布的记录是父DS RRs。预发布方法对于KSK有一些缺点。我们首先描述滚动方案，然后指出这些缺点。
--------------------------------------------------------------------
initial new DS new DNSKEY DS/DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 SOA1 --------> SOA2
RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
DS1 DS1 --------> DS2
DS2 -------->
RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS)
--------------------------------------------------------------------
initial new DS new DNSKEY DS/DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 SOA1 --------> SOA2
RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
DS1 DS1 --------> DS2
DS2 -------->
RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS)
Child:
SOA0 --------> SOA1 SOA1
RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1)
-------->
DNSKEY1 --------> DNSKEY2 DNSKEY2
-------->
DNSKEY10 --------> DNSKEY10 DNSKEY10
RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
--------------------------------------------------------------------
Child:
SOA0 --------> SOA1 SOA1
RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1)
-------->
DNSKEY1 --------> DNSKEY2 DNSKEY2
-------->
DNSKEY10 --------> DNSKEY10 DNSKEY10
RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
--------------------------------------------------------------------
Stages of Deployment for a Pre-Publish Key Signing Key Rollover
预发布密钥签名密钥滚动的部署阶段
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 DS1 and DS2, pointing to DNSKEY1 and DNSKEY2, 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 DNSKEY1 with DNSKEY2. Immediately after that ("DS/DNSKEY removal" phase), it can notify the parent that the old DS record can be deleted.
当子区域想要滚动时，它会在“新DS”阶段通知父区域，并将新密钥（或相应的DS）提交给父区域。父级发布DS1和DS2，分别指向DNSKEY1和DNSKEY2。在滚动（“新DNSKEY”阶段）期间（新DS集通过DNS传播后立即发生），子级将用DNSKEY2替换DNSKEY1。紧接着（“DS/DNSKEY删除”阶段），它可以通知父级可以删除旧的DS记录。
The drawbacks of this scheme are that during the "new DS" phase the parent cannot verify the match between the DS2 RR and DNSKEY2 using the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.4.3). Finally, the child-parent interaction consists of two steps. The "double signature" method only needs one interaction.
此方案的缺点是，在“新DS”阶段，父级无法使用DNS验证DS2 RR和DNSKEY2之间的匹配，因为DNSKEY2尚未发布。此外，我们还引入了“安全lame”密钥（见第4.4.3节）。最后，子-父交互包括两个步骤。“双重签名”方法只需要一次交互。
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 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. Our advice is to have a documented procedure ready for when a key compromise is suspected or confirmed.
本节讨论可能的关键折衷方案的准备工作。我们的建议是，在怀疑或确认关键泄露时，准备一个书面程序。
When the private material of one of your keys is compromised it can be used 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,
o 只要信任链中受损密钥上的签名有效，
o as long as a parental DS RR (and signature) points to the compromised key,
o 只要家长DS RR（和签名）指向泄露的密钥，
o as long as the 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 your compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key. Zone operators have to make a trade-off if the abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone operator 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, the malicious key holder can spoof data so that it appears to be valid.
虽然存在到受损密钥的信任链，但您的命名空间很容易被非法拥有该密钥的任何人滥用。如果滥用受损密钥比在无法验证的缓存中存储数据更糟糕，区域操作员必须做出权衡。如果区域操作员选择断开与受损密钥的信任链，则无法验证使用此密钥签名的缓存中的数据。但是，如果区域管理员选择常规滚动的路径，恶意密钥持有者可以欺骗数据，使其看起来有效。
A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable as long as the compromised KSK is configured as trust anchor or a parental DS points to it.
只要受损的KSK被配置为信任锚或父DS指向，则包含带有受损KSK的DNSKEY RRSet的区域就容易受到攻击。
A compromised KSK can be used to sign the key set of an attacker's zone. That zone could be used to poison the DNS.
受损的KSK可用于对攻击者区域的密钥集进行签名。该区域可用于毒害DNS。
Therefore, when the KSK has been compromised, the trust anchor or the parental DS 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 pointing to the compromised KSK (the assumption is that there is only one DS at the parent. If there are multiple DSes this does not apply -- however the chain of trust of this particular key is broken).
因此，当KSK受损时，应尽快更换信任锚或父DS。在紧急过渡期间是否中断信任链是当地的政策。当受损的KSK从子级的区域中移除时，信任链将断开，而父级仍然有一个DS指向受损的KSK（假设父级只有一个DS。如果有多个DSE，这不适用——但是此特定密钥的信任链断开）。
Note that an attacker's zone still uses the compromised KSK and the presence of a parental DS would cause the data in this zone to appear as valid. Removing the compromised key would cause the attacker's zone to appear as valid and the child's zone as Bogus. Therefore, we advise not to remove the KSK before the parent has a DS to a new KSK in place.
请注意，攻击者的区域仍然使用受损的KSK，并且存在家长DS将导致此区域中的数据显示为有效数据。删除受损密钥将导致攻击者的区域显示为有效，而孩子的区域显示为伪造。因此，我们建议在母公司将DS安装到新的KSK之前不要移除KSK。
If we follow this advice, 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. And also make sure that the signature made with a new KSK over the key set with the compromised KSK in it expires just after the new DS appears at the parent, thus removing the old cruft in one swoop.
如果我们遵循这一建议，更换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.
1. 在密钥集中引入新的KSK，将受损的KSK保留在密钥集中。
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 DSes have expired from caches.
2. 在密钥集上签名，有效期短。有效期应在预期DS出现在父级中且旧DSE已从缓存中过期后不久到期。
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 in 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" validity interval.
5. 从区域中删除受损的DNSKEY RR，并使用“正常”有效期间隔对密钥集重新签名。
An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate DNSKEY/DS rollover and/or nameserver 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 for authentication at the parent.
请注意，只有当DNSKEY和/或DS记录用于父级身份验证时，这才是一个问题。
There are two methods to break 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.
在导致子区域在验证解析程序中显示为“伪”的方法中，子区域将用新的KSK替换当前KSK并重新签名密钥集。接下来，它将新密钥的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.
打破信任链的另一种方法是将DS RRs从父区域中完全移除。因此，子区域将变得不安全。
Primarily because there is no parental interaction 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
主要是因为ZSK受损时不需要家长互动，因此情况不如KSK受损时严重。该区域仍必须尽快用新的ZSK重新签署。由于这是一个本地操作，不需要父级和子级之间的通信，因此可以相当快地实现。然而，我们也必须考虑到这一点
with a normal rollover the immediate disappearance of the old compromised key may lead to verification problems. Also note that as long as the RRSIG over the compromised ZSK is not expired the zone may be still at risk.
正常翻滚时，旧的受损密钥立即消失可能会导致验证问题。还要注意的是，只要受损的ZSK上的RRSIG未过期，该区域仍有风险。
A key can also be pre-configured in resolvers. For instance, if DNSSEC is successfully deployed the root key may be pre-configured in most security aware resolvers.
也可以在预解析程序中配置密钥。例如，如果成功部署了DNSSEC，则可以在大多数具有安全意识的解析器中预先配置根密钥。
If trust-anchor keys are compromised, the 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, e.g., by using digital signatures.
如果信任锚密钥受损，则应将此情况通知使用这些密钥的解析程序。区域管理员可以考虑设置邮件列表来传达SEP密钥即将被翻转的事实。当然，这种通信需要进行身份验证，例如使用数字签名。
End-users faced with the task of updating an anchored key should always validate the new key. New keys should be authenticated out-of-band, for example, through the use of an announcement website that is secured using secure sockets (TLS) [21].
最终用户面临更新锚定密钥的任务时，应始终验证新密钥。新密钥应在带外进行身份验证，例如，通过使用安全套接字（TLS）保护的公告网站进行身份验证[21]。
The initial key exchange is always subject to the policies set by the parent. 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 parent and child. That is, there is no implicit need in DNSSEC to make the authentication process stronger than it was in DNS.
初始密钥交换始终遵循父级设置的策略。在设计密钥交换策略时，应考虑到密钥交换期间使用的身份验证和授权机制应与用于在父级和子级之间交换委托信息的身份验证和授权机制一样强大。也就是说，DNSSEC中没有隐含的需要使身份验证过程比DNS中更强。
Using the DNS itself as the source for the actual DNSKEY material, with an out-of-band check on the validity of the DNSKEY, has the benefit that it reduces the chances of user error. A DNSKEY query tool can make use of the SEP bit [3] to select the proper key 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 the child is secure.
使用DNS本身作为实际DNSKEY材料的源，并对DNSKEY的有效性进行带外检查，其好处是减少了用户出错的机会。DNSKEY查询工具可以利用SEP位[3]从DNSSEC密钥集中选择正确的密钥，从而减少发送错误DNSKEY的机会。它可以验证密钥上的自签名；从而验证私钥材料的所有权。从DNS获取DNSKEY可确保在父级发布指示子级安全的DS RR后，信任链保持完整。
Note: the out-of-band verification is still needed when the key material is fetched via the DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed.
注意：当通过DNS获取关键材料时，仍然需要带外验证。家长永远无法确定DNSKEY RRs是否被欺骗。
When designing a registry system one should consider which of the DNSKEYs and/or the corresponding DSes to store. 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 recommend that registry systems at least support storing DS records.
在设计注册表系统时，应该考虑哪些DNSKEY和/或相应的DSS来存储。由于子区域可能希望使用注册表尚未理解的消息摘要算法发布DS，因此注册表不能指望能够从原始DNSKEY生成DS记录。因此，我们建议注册表系统至少支持存储DS记录。
It may also be useful to store DNSKEYs, since having them may help during troubleshooting and, as long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal. 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.
存储DNSKEY也可能很有用，因为在故障排除过程中，拥有它们可能会有所帮助，而且只要支持孩子选择的消息摘要，从它们生成DS记录的开销就很小。使用带外机制（例如注册表目录（例如Whois））来找出用于为特定所有者和/或区域生成DS资源记录的键，也可能有助于进行故障排除。
The storage considerations also relate to the design of the customer interface and the method by which data is transferred between 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? In the registry-registrar model, one can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], which allows transfer of DS RRs and optionally DNSKEY RRs.
存储注意事项还涉及客户界面的设计以及在注册人和注册人之间传输数据的方法；子区域管理员是否能够上载具有未知哈希算法的DS RRs，或者该接口是否仅允许DNSKEY？在注册表注册器模型中，可以使用可扩展配置协议（EPP）[15]的DNSSEC扩展，该协议允许传输DS RRs和可选的DNSKEY RRs。
Security lameness is defined as what happens when a parent has a DS RR pointing to a non-existing DNSKEY RR. When this happens, the child's zone may be marked "Bogus" by verifying DNS clients.
安全跛行定义为当父级的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 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材质时应非常小心，特别是存在DS RR的SEP键。
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 over the DS minimizes the time 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 case of a configuration error in the signer. There may not be enough time to fix the problems before signatures expire. Something as mundane as operator unavailability during weekends shows the need for DS signature validity periods longer than 2 days. We recommend an absolute minimum for a DS signature validity period of a few days.
由于只要DS具有有效的签名，就可以重放DS，因此在DS上较短的签名有效期可最大限度地减少儿童在KSK受损的情况下易受攻击的时间。如果签名有效期太短，则可能会在签名者出现配置错误时将区域标记为“伪造”。在签名过期之前，可能没有足够的时间修复问题。周末运营商不可用这一普通情况表明DS签名有效期需要超过2天。我们建议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 interval increases the operational risk for the parent. Therefore, the parent may have policy to use a signature validity interval that is considerably longer than the child would hope for.
DS记录的最大签名有效期取决于密钥泄露后，子区域愿意受到攻击的时间长度。另一方面，缩短DS签名有效期间隔会增加母公司的运营风险。因此，家长可能有使用签名有效期间隔的策略，该间隔比孩子希望的要长得多。
A compromise between the operational constraints of the parent and minimizing damage for the child may result in a DS signature validity period somewhere between a week and months.
父母的操作限制和尽量减少对孩子的伤害之间的折衷可能导致DS签名的有效期在一周到几个月之间。
In addition to the signature validity period, which sets a lower bound on the number of times the zone owner will need to sign the zone data and which sets an upper bound to the time a child is vulnerable after key compromise, there is the TTL value on the DS RRs. Shortening the TTL means 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传播的速度。
DNSSEC adds data integrity to the DNS. This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. Not taking into account the 'data propagation' properties in the DNS will cause validation failures and may make secured zones unavailable to security-aware resolvers.
DNSSEC将数据完整性添加到DNS。本文件试图评估维持稳定和安全的DNSSEC服务的操作注意事项。不考虑DNS中的“数据传播”属性将导致验证失败，并可能使安全区域对具有安全意识的解析程序不可用。
Most of the ideas in this document were the result of collective efforts during workshops, discussions, and tryouts.
本文件中的大多数想法是研讨会、讨论和试用期间集体努力的结果。
At the risk of forgetting individuals who were the original contributors of the ideas, we would like to acknowledge people who
冒着忘记这些想法的原始贡献者的风险，我们要感谢那些
were actively involved in the compilation of this document. 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, and Peter Koch.
我们积极参与了本文件的编写。按随机顺序排列：里普·卢米斯、奥拉弗尔·古德蒙德森、韦斯利·格里芬、迈克尔·理查森、斯科特·罗斯、里克·范雷恩、蒂姆·麦金尼斯、吉莱斯·盖特·奥利维尔·考蒂、萨姆·韦勒、杰尔特·詹森、尼尔·奥赖利、霍尔格·祖莱格、埃德·刘易斯、希拉里·奥曼、马科斯·桑兹和彼得·科赫。
Some material in this document has been copied from RFC 2541 [12].
本文件中的一些材料是从RFC 2541[12]中复制的。
Mike StJohns designed the key exchange between parent and child mentioned in the last paragraph of Section 4.2.2
Mike StJohns设计了第4.2.2节最后一段中提到的父母和孩子之间的密钥交换
Section 4.2.4 was supplied by G. Guette and O. Courtay.
第4.2.4节由G.Guette和O.Courtay提供。
Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of the spelling and style issues.
Emma Bretherick、Adrian Bedford和Lindy Foster纠正了许多拼写和样式问题。
Kolkman and Gieben take the blame for introducing all miscakes (sic).
Kolkman和Gieben为引入所有错误承担责任（原文如此）。
While working on this document, Kolkman was employed by the RIPE NCC and Gieben was employed by NLnet Labs.
在编写本文件时，Kolkman受雇于成熟的NCC，Gieben受雇于NLnet实验室。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004.
[3] Kolkman，O.，Schlyter，J.，和E.Lewis，“域名系统密钥（DNSKEY）资源记录（RR）安全入口点（SEP）标志”，RFC 3757，2004年5月。
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[4] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[5] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[6] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[8] Ohta，M.“DNS中的增量区域转移”，RFC 1995，1996年8月。
[9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[9] Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[10] 威灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[11] Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[12] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999.
[12] Eastlake，D.，“DNS安全操作注意事项”，RFC 25411999年3月。
[13] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[13] Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[14] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.
[15] Hollenbeck，S.，“可扩展供应协议（EPP）的域名系统（DNS）安全扩展映射”，RFC 4310，2005年12月。
[16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", The Journal of Cryptology 14 (255-293), 2001.
[16] Lenstra，A.和E.Verheul，“选择加密密钥大小”，密码学杂志14（255-293），2001年。
[17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., 1996.
[17] Schneier，B.，“应用密码学：C语言中的协议、算法和源代码”，ISBN（精装版）0-471-12845-7，ISBN（平装版）0-471-59756-2，约翰·威利父子公司出版，1996年。
[18] Rose, S., "NIST DNSSEC workshop notes", June 2001.
[18] Rose，S.，“NIST DNSSEC研讨会笔记”，2001年6月。
[19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC", Work in Progress, January 2006.
[19] Jansen，J.，“在DNSSEC中使用RSA/SHA-256 DNSKEY和RRSIG资源记录”，正在进行的工作，2006年1月。
[20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[20] Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，2006年5月。
[21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[21] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
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 [4]. An RRSet in DNSSEC is marked "Bogus" when a signature of an RRSet does not validate against a DNSKEY.
伪造：另见[4]第5节。当RRSet的签名未针对DNSKEY进行验证时，DNSSEC中的RRSet被标记为“伪造”。
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. It is mathematically more correct to use modulus size, but as this is a document directed at operators we feel more at ease with the term key size.
密钥大小：在整个文档中，术语“密钥大小”可替换为“模数大小”。从数学上讲，使用模数大小更为正确，但由于这是一份针对运算符的文档，我们对术语键大小感到更轻松。
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 use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private.
私钥和公钥：DNSSEC通过使用公钥加密来保护DNS。公钥密码基于两个（数学上相关的）密钥的存在，一个公钥和一个私钥。公钥通过使用DNSKEY资源记录（DNSKEY RR）在DNS中发布。私钥应该保持私有。
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.
密钥翻转：密钥翻转（在某些环境中也称为密钥置换）是在密钥有效期结束时用另一个密钥对替换一个密钥对的行为。
Secure Entry Point (SEP) key: A KSK that has a parental DS record pointing to it or is configured as a trust anchor. Although not required by the protocol, we recommend that the SEP flag [3] is set on these keys.
安全入口点（SEP）密钥：具有指向它的父DS记录或配置为信任锚的KSK。尽管协议没有要求，但我们建议在这些密钥上设置SEP标志[3]。
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的真实性，也就是说，它们可以用作哈希。
Singing the zone file: The term used for the event where an administrator joyfully signs its zone file while producing melodic sound patterns.
唱区域文件：用于管理员在产生旋律模式的同时愉快地签署其区域文件的事件的术语。
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进行签名。
Zone Signing Key (ZSK): A key that is used for signing all data in a zone. The fact that a key is a ZSK is only relevant to the signing tool.
区域签名密钥（ZSK）：用于对区域中的所有数据进行签名的密钥。密钥是ZSK这一事实仅与签名工具相关。
Zone administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server.
区域管理员：负责对区域进行签名并将其发布到主权威服务器上的“角色”。
Using the pre-published signature scheme and the most conservative method to assure oneself that data does not live in caches, here follows the "how-to".
使用预先发布的签名方案和最保守的方法来确保数据不存在于缓存中，这里遵循“操作方法”。
Step 0: The preparation: Create two keys and publish both in your key set. Mark one of the keys "active" and the other "published". Use the "active" key for signing your zone data. Store the private part of the "published" key, preferably off-line. The protocol does not provide for attributes to mark a key as active or published. This is something you have to do on your own, through the use of a notebook or key management tool.
步骤0：准备：创建两个密钥并在密钥集中发布这两个密钥。将其中一个键标记为“活动”，另一个键标记为“已发布”。使用“活动”键对区域数据进行签名。存储“已发布”密钥的私有部分，最好离线存储。该协议不提供将密钥标记为活动或已发布的属性。这是你必须自己做的事情，通过使用笔记本或密钥管理工具。
Step 1: Determine expiration: At the beginning of the rollover make a note of the highest expiration time of signatures in your zone file created with the current key marked as active. Wait until the expiration time marked in Step 1 has passed.
步骤1：确定过期时间：在滚动开始时，记下使用标记为活动的当前密钥创建的区域文件中签名的最长过期时间。等待步骤1中标记的过期时间结束。
Step 2: Then start using the key that was marked "published" to sign your data (i.e., mark it "active"). Stop using the key that was marked "active"; mark it "rolled".
第2步：然后开始使用标记为“已发布”的密钥对数据进行签名（即，将其标记为“活动”）。停止使用标记为“活动”的钥匙；将其标记为“滚动”。
Step 3: It is safe to engage in a new rollover (Step 1) after at least one signature validity period.
步骤3：在至少一个签名有效期后，可以安全地进行新的展期（步骤1）。
The following typographic conventions are used in this document:
本文件使用了以下印刷惯例：
Key notation: A key is denoted by DNSKEYx, where x is a number or an identifier, x could be thought of as the key id.
密钥表示法：密钥由DNSKEYx表示，其中x是一个数字或标识符，x可以被认为是密钥id。
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. A 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 RRSIGx(RRSet), which means that RRSet is signed with DNSKEYx.
签名表示法：签名表示为RRSIGx（RRSet），这意味着RRSet是用DNSKEYx签名的。
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 "SOAx"
区域表示法：使用上述表示法，我们省略了所有不必要的细节，如名称，并用“SOAx”表示所有数据，从而简化了签名区域的表示
SOA representation: SOAs are represented as SOAx, where x is the serial number.
SOA表示：SOA表示为SOAx，其中x是序列号。
Using this notation the following signed zone:
使用此符号表示以下有符号区域：
example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 2006022100 ; serial 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 28800 ) ; minimum ( 8 hours) 86400 RRSIG SOA 5 2 86400 20130522213204 ( 20130422213204 14 example.net. cmL62SI6iAX46xGNQAdQ... ) 86400 NS a.iana-servers.net. 86400 NS b.iana-servers.net. 86400 RRSIG NS 5 2 86400 20130507213204 ( 20130407213204 14 example.net. SO5epiJei19AjXoUpFnQ ... ) 86400 DNSKEY 256 3 5 ( EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 86400 DNSKEY 257 3 5 ( gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 20130422213204 14 example.net. J4zCe8QX4tXVGjV4e1r9... )
例如.net。SOANS.example.net中的86400。net。（2006022100；序列号86400；刷新（24小时）7200；重试（2小时）3600000；过期（1000小时）28800）；至少（8小时）86400 RRSIG SOA 5 2 86400 20130522213204（201304222132004 14 example.net.cmL62SI6iAX46xGNQAdQ…）86400 NS a.iana-servers.net。86400 NS b.iana-servers.net。86400 RRSIG NS 5 2 86400 20130507213204（20130407213204 14 example.net.SO5epiJei19AjXoUpFnQ…）86400 DNSKEY 256 3 5（EtRB9MP5/AvOuVO0I8XDxy0…）；id=1486400 DNSKEY 257 3 5（gsPW/YY19GZYY+Gnr8HABU…）；id=15 86400 RRSIG DNSKEY 5 2 86400 20130522213204（201304222132004 14 example.net.J4zCe8QX4tXVGjV4e1r9…）
86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 20130422213204 15 example.net. keVDCOpsSeDReyV6O... ) 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 20130407213204 14 example.net. obj3HEp1GjnmhRjX... ) a.example.net. 86400 IN TXT "A label" 86400 RRSIG TXT 5 3 86400 20130507213204 ( 20130407213204 14 example.net. IkDMlRdYLmXH7QJnuF3v... ) 86400 NSEC b.example.com. TXT RRSIG NSEC 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 20130407213204 14 example.net. bZMjoZ3bHjnEz0nIsPMM... ) ...
86400 RRSIG DNSKEY 5 2 86400 20130522213204（20130422213204 15 example.net.keVDCOpsSeDReyV6O…）86400 RRSIG NSEC 5 2 86400 2013050727213204（20130407213204 14 example.net.obj3HEp1GjnmhRjX…）a.example.net。86400文本“A标签”86400 RRSIG TXT 5 3 86400 20130507213204（20130407213204 14 example.net.IkDMlRdYLmXH7QJnuF3v…）86400 NSEC b.example.com。TXT RRSIG NSEC 86400 RRSIG NSEC 5 3 86400 20130507213204（20130407213204 14 example.net.bZMjoZ3bHjnEz0nIsPMM…）。。。
is reduced to the following representation:
简化为以下表示形式：
SOA2006022100 RRSIG14(SOA2006022100) DNSKEY14 DNSKEY15
SOA2006022100 RRSIG14（SOA2006022100）DNSKEY14 DNSKEY15
RRSIG14(KEY) RRSIG15(KEY)
RRSIG14（键）RRSIG15（键）
The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY 14.
其余区域数据具有与SOA记录相同的签名，即使用DNSKEY 14创建的RRSIG。
Authors' Addresses
作者地址
Olaf M. Kolkman NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands
Olaf M.Kolkman NLnet实验室Kruislaan 419阿姆斯特丹1098弗吉尼亚州荷兰
EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
R. (Miek) Gieben
R.（Miek）Gieben
EMail: miek@miek.nl
EMail: miek@miek.nl
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。