Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 8624 Red Hat
Obsoletes: 6944 O. Sury
Category: Standards Track Internet Systems Consortium
ISSN: 2070-1721 June 2019
Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 8624 Red Hat
Obsoletes: 6944 O. Sury
Category: Standards Track Internet Systems Consortium
ISSN: 2070-1721 June 2019
Algorithm Implementation Requirements and Usage Guidance for DNSSEC
DNSSEC的算法实现要求和使用指南
Abstract
摘要
The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.
DNSSEC协议利用各种加密算法来提供DNS数据的身份验证和不存在的证明。为了确保DNS解析程序和DNS权威服务器之间的互操作性，有必要指定一组算法实现要求和使用指南，以确保所有实现至少支持一种算法。本文件定义了DNSSEC的当前算法实施要求和使用指南。本文件淘汰了RFC 6944。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8624.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8624.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5
3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 5
3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 7
3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5
3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 5
3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 7
3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
The DNSSEC signing algorithms are defined by various RFCs, including [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], and [RFC8080]. DNSSEC is used to provide authentication of data. To ensure interoperability, a set of "mandatory-to-implement" DNSKEY algorithms are defined. This document obsoletes [RFC6944].
DNSSEC签名算法由各种RFC定义，包括[RFC4034]、[RFC5155]、[RFC5702]、[RFC5933]、[RFC6605]和[RFC8080]。DNSSEC用于提供数据的身份验证。为确保互操作性，定义了一组“强制实施”DNSKEY算法。本文件废除了[RFC6944]。
The field of cryptography evolves continuously. New, stronger algorithms appear, and existing algorithms are found to be less secure than originally thought. Attacks previously thought to be computationally infeasible become more accessible as the available computational resources increase. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise.
密码学领域不断发展。新的、更强大的算法出现了，而现有的算法被发现不如最初认为的安全。随着可用计算资源的增加，以前认为在计算上不可行的攻击变得更容易访问。因此，需要不时更新算法实现要求和使用指南，以反映新的现实。算法的选择必须是保守的，以最小化算法妥协的风险。
The mandatory-to-implement algorithm of tomorrow should already be available in most implementations of DNSSEC by the time it is made mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that algorithms in use today will become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or even be completely broken before this document is updated.
明天的强制实现算法在强制实施时，应该已经在DNSSEC的大多数实现中可用。本文件试图确定并介绍这些算法，以供未来强制实施状态。目前使用的算法不能保证将来会成为强制性的。已发布的算法会不断受到加密攻击，在更新本文档之前可能会变得太弱甚至完全崩溃。
This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that they cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in this document MAY be implemented. For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded from a MUST or a RECOMMENDED to a MAY.
本文件仅就强制实施算法或算法太弱以至于无法推荐的算法提供建议。[DNSKEY-IANA]和[DS-IANA]注册表中列出的本文件中未提及的任何算法均可实施。为了澄清和一致性，仅当算法从必须或推荐降级为可能时，才会在本文件中指定为可能。
Although this document's primary purpose is to update algorithm recommendations to keep DNSSEC authentication secure over time, it also aims to do so in such a way that DNSSEC implementations remain interoperable. DNSSEC interoperability is addressed by an incremental introduction or deprecation of algorithms.
尽管本文档的主要目的是更新算法建议，以保持DNSSEC认证的安全性，但它也旨在这样做，即DNSSEC实现保持互操作性。DNSSEC互操作性通过增量引入或弃用算法来解决。
[RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this document have chosen to use the terms RECOMMENDED and NOT
[RFC2119]认为该术语应等同于推荐，而不应等同于不推荐。本文件的作者选择使用推荐的术语，而不是
RECOMMENDED, as this more clearly expresses the intent to implementers.
推荐，因为这更清楚地表达了实施者的意图。
It is expected that deprecation of an algorithm will be performed gradually in a series of updates to this document. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a RECOMMENDED instead of a MUST.
预计在本文档的一系列更新中，将逐步对算法进行弃用。这为各种实现在保持互操作性的同时更新其实现的算法提供了时间。除非有强烈的安全原因，否则算法将从“必须”降级为“不推荐”或“可能”，而不是“不得”。类似地，一个未被提及为必须实现的算法预计将以推荐而不是必须的方式引入。
Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This will allow for deprecated algorithms to become less and less common over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT so that recursive resolvers can remove support for validating it.
由于使用未知DNSKEY算法的效果是区域被视为不安全，因此建议权威名称服务器和DNSSEC签名者不要使用降级为不推荐或更低级别的算法来创建新的DNSKEY。这将使不推荐的算法随着时间的推移变得越来越不常见。一旦算法达到足够低的部署级别，就可以将其标记为不得，以便递归解析器可以删除对验证它的支持。
Recursive nameservers are encouraged to retain support for all algorithms not marked as MUST NOT.
鼓励递归名称服务器保留对所有未标记为不得的算法的支持。
The recommendations of this document mostly target DNSSEC implementers, as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth transition to more secure algorithms. This perspective may differ from that of a user who wishes to deploy and configure DNSSEC with only the safest algorithm. On the other hand, the comments and recommendations in this document are also expected to be useful for such users.
本文档的建议主要针对DNSSEC实施者，因为实施需要满足高安全性预期以及不同供应商和不同版本之间的高互操作性。互操作性要求平滑过渡到更安全的算法。此观点可能与希望仅使用最安全算法部署和配置DNSSEC的用户不同。另一方面，本文件中的评论和建议也将对此类用户有用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA].
下表列出了DNSKEY算法[DNSKEY-IANA]的实施建议。
+--------+--------------------+-----------------+-------------------+
| Number | Mnemonics | DNSSEC Signing | DNSSEC Validation |
+--------+--------------------+-----------------+-------------------+
| 1 | RSAMD5 | MUST NOT | MUST NOT |
| 3 | DSA | MUST NOT | MUST NOT |
| 5 | RSASHA1 | NOT RECOMMENDED | MUST |
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |
| 8 | RSASHA256 | MUST | MUST |
| 10 | RSASHA512 | NOT RECOMMENDED | MUST |
| 12 | ECC-GOST | MUST NOT | MAY |
| 13 | ECDSAP256SHA256 | MUST | MUST |
| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED |
| 16 | ED448 | MAY | RECOMMENDED |
+--------+--------------------+-----------------+-------------------+
+--------+--------------------+-----------------+-------------------+
| Number | Mnemonics | DNSSEC Signing | DNSSEC Validation |
+--------+--------------------+-----------------+-------------------+
| 1 | RSAMD5 | MUST NOT | MUST NOT |
| 3 | DSA | MUST NOT | MUST NOT |
| 5 | RSASHA1 | NOT RECOMMENDED | MUST |
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |
| 8 | RSASHA256 | MUST | MUST |
| 10 | RSASHA512 | NOT RECOMMENDED | MUST |
| 12 | ECC-GOST | MUST NOT | MAY |
| 13 | ECDSAP256SHA256 | MUST | MUST |
| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED |
| 16 | ED448 | MAY | RECOMMENDED |
+--------+--------------------+-----------------+-------------------+
RSAMD5 is not widely deployed, and there is an industry-wide trend to deprecate MD5 usage.
RSAMD5没有得到广泛的部署，而且整个行业都有反对MD5使用的趋势。
RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although the zones deploying it are recommended to switch to ECDSAP256SHA256 as there is an industry-wide trend to move to elliptic curve cryptography. RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with or without NSEC3.
RSASHA1和RSASHA1-NSEC3-SHA1被广泛部署，尽管建议部署它的区域切换到ECDSAP256SHA256，因为整个行业都有转向椭圆曲线加密的趋势。RSASHA1不支持NSEC3。RSASHA1-NSEC3-SHA1可以与NSEC3一起使用，也可以不与NSEC3一起使用。
DSA and DSA-NSEC3-SHA1 are not widely deployed and are vulnerable to private key compromise when generating signatures using a weak or compromised random number generator.
DSA和DSA-NSEC3-SHA1未广泛部署，在使用弱随机数生成器或受损随机数生成器生成签名时，容易受到私钥泄露的影响。
RSASHA256 is widely used and considered strong. It has been the default algorithm for a number of years and is now slowly being replaced with ECDSAP256SHA256 due to its shorter key and signature size, resulting in smaller DNS packets.
RSASA256被广泛使用并被认为是强大的。多年来，它一直是默认算法，现在正慢慢被ECDSAP256SHA256取代，因为它的密钥和签名长度较短，导致DNS数据包较小。
RSASHA512 is NOT RECOMMENDED for DNSSEC signing because it has not seen wide deployment, but there are some deployments; hence, DNSSEC validation MUST implement RSASHA512 to ensure interoperability. There is no significant difference in cryptographic strength between RSASHA512 and RSASHA256; therefore, use of RSASHA512 is discouraged
不建议将RSASHA512用于DNSSEC签名，因为它尚未看到广泛部署，但存在一些部署；因此，DNSSEC验证必须实现RSASHA512以确保互操作性。RSASHA512和RSASHA256的加密强度没有显著差异；因此，不鼓励使用RSASHA512
as it will only make deprecation of older algorithms harder. People who wish to use a cryptographically stronger algorithm should switch to elliptic curve cryptography algorithms.
因为这只会使旧算法的弃用更加困难。希望使用加密能力更强的算法的人应该改用椭圆曲线加密算法。
ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 in [RFC7091]. GOST R 34.10-2012 hasn't been standardized for use in DNSSEC.
ECC-GOST（GOST R 34.10-2001）已在[RFC7091]中被GOST R 34.10-2012取代。GOST R 34.10-2012尚未标准化用于DNSSEC。
ECDSAP256SHA256 provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256 has been widely deployed; therefore, it is now at MUST level for both validation and signing. It is RECOMMENDED to use the deterministic digital signature generation procedure of the Elliptic Curve Digital Signature Algorithm (ECDSA), specified in [RFC6979], when implementing ECDSAP256SHA256 (and ECDSAP384SHA384).
ECDSAP256SHA256提供了比RSASA256或RSASHA512更短的签名长度和更高的加密强度。ECDSAP256SHA256已广泛部署；因此，它现在是验证和签名的必选级别。在实现ECDSAP256SHA256（和ECDSAP384SHA384）时，建议使用[RFC6979]中规定的椭圆曲线数字签名算法（ECDSA）的确定性数字签名生成过程。
ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256 but offers a modest security advantage over ECDSAP256SHA256 (192 bits of strength versus 128 bits). For most DNSSEC applications, ECDSAP256SHA256 should be satisfactory and robust for the foreseeable future and is therefore recommended for signing. While it is unlikely for a DNSSEC use case requiring 192-bit security strength to arise, ECDSA384SHA384 is provided for such applications, and it MAY be used for signing in these cases.
ECDSAP384SHA384与ECDSAP256SHA256具有相同的属性，但与ECDSAP256SHA256相比具有适度的安全优势（强度为192位，强度为128位）。对于大多数DNSSEC应用程序，ECDSAP256SHA256在可预见的未来应该是令人满意和健壮的，因此建议签署。虽然不太可能出现需要192位安全强度的DNSSEC用例，但ECDSA384SHA384可用于此类应用程序，在这些情况下可用于签名。
ED25519 and ED448 use the Edwards-curve Digital Security Algorithm (EdDSA). There are three main advantages of EdDSA: it does not require the use of a unique random number for each signature, there are no padding or truncation issues as with ECDSA, and it is more resilient to side-channel attacks. Furthermore, EdDSA cryptography is less prone to implementation errors ([RFC8032], [RFC8080]). It is expected that ED25519 will become the future RECOMMENDED default algorithm once there's enough support for this algorithm in the deployed DNSSEC validators.
ED25519和ED448使用爱德华兹曲线数字安全算法（EdDSA）。EdDSA有三个主要优点：它不需要为每个签名使用唯一的随机数，与ECDSA一样不存在填充或截断问题，并且对侧通道攻击更具弹性。此外，EdDSA加密不太容易出现实现错误（[RFC8032]，[RFC8080]）。一旦部署的DNSSEC验证器中对此算法有足够的支持，预计ED25519将成为未来推荐的默认算法。
Due to the industry-wide trend towards elliptic curve cryptography, ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade to ECDSAP256SHA256.
由于业界普遍倾向于椭圆曲线加密，建议新的DNSSEC部署使用ECDSAP256SHA256 DNSKEY算法，基于RSA的算法的用户应升级到ECDSAP256SHA256。
The following table lists the recommendations for Delegation Signer Digest Algorithms [DS-IANA]. These recommendations also apply to the Child Delegation Signer (CDS) RRTYPE as specified in [RFC7344].
下表列出了对委派签名者摘要算法[DS-IANA]的建议。这些建议也适用于[RFC7344]中规定的子委托签署人（CDS）RRTYPE。
+--------+-----------------+-------------------+-------------------+
| Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation |
+--------+-----------------+-------------------+-------------------+
| 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] |
| 1 | SHA-1 | MUST NOT | MUST |
| 2 | SHA-256 | MUST | MUST |
| 3 | GOST R 34.11-94 | MUST NOT | MAY |
| 4 | SHA-384 | MAY | RECOMMENDED |
+--------+-----------------+-------------------+-------------------+
+--------+-----------------+-------------------+-------------------+
| Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation |
+--------+-----------------+-------------------+-------------------+
| 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] |
| 1 | SHA-1 | MUST NOT | MUST |
| 2 | SHA-256 | MUST | MUST |
| 3 | GOST R 34.11-94 | MUST NOT | MAY |
| 4 | SHA-384 | MAY | RECOMMENDED |
+--------+-----------------+-------------------+-------------------+
[*] - This is a special type of CDS record signaling removal of DS at the parent in [RFC8078].
[*]-这是一种特殊类型的CDS记录，用于在[RFC8078]中的父级删除DS。
NULL is a special case; see [RFC8078].
空是一种特殊情况；见[RFC8078]。
SHA-1 is still widely used for Delegation Signer (DS) records, so validators MUST implement validation, but it MUST NOT be used to generate new DS and CDS records (see "Operational Considerations" for caveats when upgrading from the SHA-1 to SHA-256 DS algorithm.)
SHA-1仍然广泛用于委托签名者（DS）记录，因此验证器必须实现验证，但不能用于生成新的DS和CDS记录（从SHA-1升级到SHA-256 DS算法时，请参阅“操作注意事项”）
SHA-256 is widely used and considered strong.
SHA-256被广泛使用，并被认为是强效的。
GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in [RFC6986]. GOST R 34.11-2012 has not been standardized for use in DNSSEC.
GOST R 34.11-94已在[RFC6986]中被GOST R 34.11-2012取代。GOST R 34.11-2012尚未标准化用于DNSSEC。
SHA-384 shares the same properties as SHA-256 but offers a modest security advantage over SHA-256 (384 bits of strength versus 256 bits). For most applications of DNSSEC, SHA-256 should be satisfactory and robust for the foreseeable future and is therefore recommended for DS and CDS records. While it is unlikely for a DNSSEC use case requiring 384-bit security strength to arise, SHA-384 is provided for such applications, and it MAY be used for generating DS and CDS records in these cases.
SHA-384与SHA-256具有相同的特性，但与SHA-256相比具有适度的安全优势（强度为384位，强度为256位）。对于DNSSEC的大多数应用，SHA-256在可预见的未来应该是令人满意的和健壮的，因此建议用于DS和CD记录。虽然不太可能出现需要384位安全强度的DNSSEC用例，但为此类应用提供了SHA-384，在这些情况下，它可用于生成DS和CDS记录。
An operational recommendation for new and existing deployments: SHA-256 is the RECOMMENDED DS and CDS algorithm.
对新部署和现有部署的操作建议：SHA-256是推荐的DS和CDS算法。
The security of cryptographic systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
密码系统的安全性取决于所选密码算法的强度以及与这些算法一起使用的密钥的强度。安全性还取决于系统使用的协议工程，以确保没有非加密方式绕过整个系统的安全性。
This document concerns itself with the selection of cryptographic algorithms for use in DNSSEC, specifically with the selection of "mandatory-to-implement" algorithms. The algorithms identified in this document as MUST or RECOMMENDED to implement are not known to be broken (in the cryptographic sense) at the current time, and cryptographic research so far leads us to believe that they are likely to remain secure into the foreseeable future. However, this isn't necessarily forever, and it is expected that new revisions of this document will be issued from time to time to reflect the current best practices in this area.
本文件涉及DNSSEC中使用的加密算法的选择，特别是“强制实施”算法的选择。本文件中确定的必须或建议实施的算法目前还未被破坏（在密码意义上），迄今为止的密码研究使我们相信，它们在可预见的未来很可能保持安全。然而，这并不一定是永远的，预计本文件的新修订版将不时发布，以反映该领域的当前最佳实践。
Retiring an algorithm too soon would result in a zone (signed with a retired algorithm) being downgraded to the equivalent of an unsigned zone. Therefore, algorithm deprecation must be done very slowly and only after careful consideration and measurement of its use.
过早停用算法将导致区域（使用失效算法签名）降级为与未签名区域等效的区域。因此，算法弃用必须非常缓慢地进行，并且只有在仔细考虑和衡量其使用之后才能进行。
DNSKEY algorithm rollover in a live zone is a complex process. See [RFC6781] and [RFC7583] for guidelines on how to perform algorithm rollovers.
DNSKEY算法在活动区域中的翻滚是一个复杂的过程。请参阅[RFC6781]和[RFC7583]以了解有关如何执行算法翻转的指南。
DS algorithm rollover in a live zone is also a complex process. Upgrading an algorithm at the same time as rolling a new Key Signing Key (KSK) will lead to DNSSEC validation failures. Administrators MUST complete the process of the DS algorithm upgrade before starting a rollover process for a new KSK.
DS算法在活动区域中的翻滚也是一个复杂的过程。在滚动新密钥签名密钥（KSK）的同时升级算法将导致DNSSEC验证失败。管理员必须在启动新KSK的滚动过程之前完成DS算法升级过程。
This document has no IANA actions.
本文档没有IANA操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<https://www.rfc-editor.org/info/rfc4034>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 5155，DOI 10.17487/RFC5155，2008年3月<https://www.rfc-editor.org/info/rfc5155>.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, <https://www.rfc-editor.org/info/rfc5702>.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，DOI 10.17487/RFC5702，2009年10月<https://www.rfc-editor.org/info/rfc5702>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <https://www.rfc-editor.org/info/rfc6605>.
[RFC6605]Hoffman，P.和W.Wijngaards，“DNSSEC的椭圆曲线数字签名算法（DSA）”，RFC 6605，DOI 10.17487/RFC6605，2012年4月<https://www.rfc-editor.org/info/rfc6605>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979]Pornin，T，“数字签名算法（DSA）和椭圆曲线数字签名算法（ECDSA）的确定性使用”，RFC 6979，DOI 10.17487/RFC6979，2013年8月<https://www.rfc-editor.org/info/rfc6979>.
[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013, <https://www.rfc-editor.org/info/rfc6986>.
[RFC6986]Dolmatov，V.，Ed.和A.Degtyarev，“GOST R 34.11-2012：哈希函数”，RFC 6986，DOI 10.17487/RFC6986，2013年8月<https://www.rfc-editor.org/info/rfc6986>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-editor.org/info/rfc7344>.
[RFC7344]Kumari，W.，Gudmundsson，O.，和G.Barwood，“自动化DNSSEC委托信托维护”，RFC 7344，DOI 10.17487/RFC73442014年9月<https://www.rfc-editor.org/info/rfc7344>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032]Josefsson，S.和I.Liusvaara，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<https://www.rfc-editor.org/info/rfc8032>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, <https://www.rfc-editor.org/info/rfc8078>.
[RFC8078]Gudmundsson，O.和P.Wouters，“通过CD/CDNSKEY管理来自母公司的DS记录”，RFC 8078，DOI 10.17487/RFC8078，2017年3月<https://www.rfc-editor.org/info/rfc8078>.
[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017, <https://www.rfc-editor.org/info/rfc8080>.
[RFC8080]Sury，O.和R.Edmonds，“DNSSEC的爱德华兹曲线数字安全算法（EdDSA）”，RFC 8080，DOI 10.17487/RFC8080，2017年2月<https://www.rfc-editor.org/info/rfc8080>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 2010, <https://www.rfc-editor.org/info/rfc5933>.
[RFC5933]Dolmatov，V.，Ed.，Chuprina，A.，和I.Ustinov，“在DNSSEC的DNSKEY和RRSIG资源记录中使用GOST签名算法”，RFC 5933，DOI 10.17487/RFC5933，2010年7月<https://www.rfc-editor.org/info/rfc5933>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，DOI 10.17487/RFC6781，2012年12月<https://www.rfc-editor.org/info/rfc6781>.
[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status", RFC 6944, DOI 10.17487/RFC6944, April 2013, <https://www.rfc-editor.org/info/rfc6944>.
[RFC6944]Rose，S.“适用性声明：DNS安全（DNSSEC）DNSKEY算法实施状态”，RFC 6944，DOI 10.17487/RFC69442013年4月<https://www.rfc-editor.org/info/rfc6944>.
[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10.17487/RFC7091, December 2013, <https://www.rfc-editor.org/info/rfc7091>.
[RFC7091]Dolmatov，V.，Ed.和A.Degtyarev，“GOST R 34.10-2012：数字签名算法”，RFC 7091，DOI 10.17487/RFC7091，2013年12月<https://www.rfc-editor.org/info/rfc7091>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015, <https://www.rfc-editor.org/info/rfc7583>.
[RFC7583]Morris，S.，Ihren，J.，Dickinson，J.，和W.Mekking，“DNSSEC关键滚动时间考虑”，RFC 7583，DOI 10.17487/RFC7583，2015年10月<https://www.rfc-editor.org/info/rfc7583>.
[DNSKEY-IANA] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", <http://www.iana.org/assignments/dns-sec-alg-numbers>.
[DNSKEY-IANA]IANA，“域名系统安全（DNSSEC）算法编号”<http://www.iana.org/assignments/dns-sec-alg-numbers>.
[DS-IANA] IANA, "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms", <http://www.iana.org/assignments/ds-rr-types>.
[DS-IANA]IANA，“委托签署人（DS）资源记录（RR）类型摘要算法”<http://www.iana.org/assignments/ds-rr-types>.
Acknowledgements
致谢
This document borrows text from RFC 4307 by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT) and RFC 8247 by Yoav Nir, Tero Kivinen, Paul Wouters, and Daniel Migault. Much of the original text has been copied verbatim.
本文件引用了麻省理工学院（MIT）杰弗里·席勒（Jeffrey I.Schiller）的RFC 4307和Yoav Nir、Tero Kivinen、Paul Wouters和Daniel Migault的RFC 8247。原文大部分是逐字复制的。
We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur Gudmundsson, Paul Hoffman, Evan Hunt, and Peter Yee for their feedback.
我们要感谢迈克尔·西纳特拉、罗兰·范里斯维克·戴伊、奥拉弗尔·古德蒙德森、保罗·霍夫曼、埃文·亨特和彼得·叶的反馈。
Kudos to Roy Arends for bringing the DS rollover issue to light.
感谢罗伊·阿伦兹将DS滚动问题公诸于世。
Authors' Addresses
作者地址
Paul Wouters Red Hat Canada
加拿大保罗·沃特斯红帽酒店
Email: pwouters@redhat.com
Email: pwouters@redhat.com
Ondrej Sury Internet Systems Consortium Czech Republic
Ondrej Sury互联网系统联合会捷克共和国
Email: ondrej@isc.org
Email: ondrej@isc.org