Network Working Group R. Arends
Request for Comments: 4034 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Network Working Group R. Arends
Request for Comments: 4034 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Resource Records for the DNS Security Extensions
DNS安全扩展的资源记录
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.
本文档是描述DNS安全扩展（DNSSEC）的文档系列的一部分。DNS安全扩展是为DNS提供源身份验证的资源记录和协议修改的集合。本文档定义了公钥（DNSKEY）、委托签名人（DS）、资源记录数字签名（RRSIG）和认证拒绝存在（NSEC）资源记录。详细描述了每个资源记录的用途和格式，并给出了每个资源记录的示例。
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
本文件废除了RFC 2535，并纳入了RFC 2535所有更新的变更。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . 3
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
2.1.4. The Public Key Field . . . . . . . . . . . . . 5
2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
3.1.1. The Type Covered Field . . . . . . . . . . . . 7
3.1.2. The Algorithm Number Field . . . . . . . . . . 8
3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
3.1.5. Signature Expiration and Inception Fields. . . 9
3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
3.1.7. The Signer's Name Field. . . . . . . . . . . . 9
3.1.8. The Signature Field. . . . . . . . . . . . . . 9
3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
4.1.1. The Next Domain Name Field . . . . . . . . . . 13
4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
5.2. Processing of DS RRs When Validating Responses . . . . 17
5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
6. Canonical Form and Order of Resource Records . . . . . . . . 18
6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . 3
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
2.1.4. The Public Key Field . . . . . . . . . . . . . 5
2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
3.1.1. The Type Covered Field . . . . . . . . . . . . 7
3.1.2. The Algorithm Number Field . . . . . . . . . . 8
3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
3.1.5. Signature Expiration and Inception Fields. . . 9
3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
3.1.7. The Signer's Name Field. . . . . . . . . . . . 9
3.1.8. The Signature Field. . . . . . . . . . . . . . 9
3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
4.1.1. The Next Domain Name Field . . . . . . . . . . 13
4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
5.2. Processing of DS RRs When Validating Responses . . . . 17
5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
6. Canonical Form and Order of Resource Records . . . . . . . . 18
6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . 23
A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . 23
A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
The DNS Security Extensions (DNSSEC) introduce four new DNS resource record types: DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This document defines the purpose of each resource record (RR), the RR's RDATA format, and its presentation format (ASCII representation).
DNS安全扩展（DNSSEC）引入了四种新的DNS资源记录类型：DNS公钥（DNSKEY）、资源记录签名（RRSIG）、下一个安全（NSEC）和委派签名者（DS）。本文档定义了每个资源记录（RR）的用途、RR的RDATA格式及其表示格式（ASCII表示）。
This document is part of a family of documents defining DNSSEC, which should be read together as a set.
本文档是定义DNSSEC的文档系列的一部分，应作为一个集合一起阅读。
[RFC4033] contains an introduction to DNSSEC and definition of common terms; the reader is assumed to be familiar with this document. [RFC4033] also contains a list of other documents updated by and obsoleted by this document set.
[RFC4033]包含DNSSEC的介绍和常用术语的定义；假定读者熟悉本文件。[RFC4033]还包含由该文档集更新和淘汰的其他文档的列表。
[RFC4035] defines the DNSSEC protocol operations.
[RFC4035]定义DNSSEC协议操作。
The reader is also assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, particularly [RFC2181] and [RFC2308].
读者还假定熟悉[RFC1034]、[RFC1035]中描述的基本DNS概念，以及更新这些概念的后续文档，特别是[RFC2181]和[RFC2308]。
This document defines the DNSSEC resource records. All numeric DNS type codes given in this document are decimal integers.
本文件定义了DNSSEC资源记录。本文档中给出的所有数字DNS类型代码都是十进制整数。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). The public keys are stored in DNSKEY resource records and are used in the DNSSEC authentication process described in [RFC4035]: A zone signs its authoritative RRsets by using a private key and stores the corresponding public key in a DNSKEY RR. A resolver can then use the public key to validate signatures covering the RRsets in the zone, and thus to authenticate them.
DNSSEC使用公钥加密技术对DNS资源记录集（RRSET）进行签名和身份验证。公钥存储在DNSKEY资源记录中，并在[RFC4035]中描述的DNSSEC身份验证过程中使用：区域使用私钥对其权威RRSET进行签名，并将相应的公钥存储在DNSKEY RR中。然后，解析程序可以使用公钥验证区域中覆盖RRSET的签名，从而对其进行身份验证。
The DNSKEY RR is not intended as a record for storing arbitrary public keys and MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure.
DNSKEY RR并非用于存储任意公钥的记录，也不得用于存储与DNS基础设施没有直接关系的证书或公钥。
The Type value for the DNSKEY RR type is 48.
DNSKEY RR类型的类型值为48。
The DNSKEY RR is class independent.
DNSKEY RR是独立于类的。
The DNSKEY RR has no special TTL requirements.
DNSKEY RR没有特殊的TTL要求。
The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key Field.
DNSKEY RR的RDATA由2个八位字节标志字段、1个八位字节协议字段、1个八位字节算法字段和公钥字段组成。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name MUST be the name of a zone. If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and MUST NOT be used to verify RRSIGs that cover RRsets.
标志字段的第7位是区域键标志。如果位7的值为1，则DNSKEY记录保存DNS区域密钥，并且DNSKEY RR的所有者名称必须是区域的名称。如果位7的值为0，则DNSKEY记录保存其他类型的DNS公钥，并且不得用于验证覆盖RRSET的RRSIG。
Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only
标志字段的第15位是安全入口点标志，如[RFC3757]所述。如果位15的值为1，则DNSKEY记录保存一个用作安全入口点的密钥。这面旗只是
intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit. This also means that a DNSKEY RR with the SEP bit set would also need the Zone Key flag set in order to be able to generate signatures legally. A DNSKEY RR with the SEP set and the Zone Key flag not set MUST NOT be used to verify RRSIGs that cover RRsets.
旨在就本DNSKEY记录的预期用途向区域签名或调试软件提供提示；在签名验证过程中，验证器不得基于此位的设置以任何方式改变其行为。这也意味着，设置SEP位的DNSKEY RR还需要设置区域密钥标志，以便能够合法生成签名。设置SEP且未设置区域密钥标志的DNSKEY RR不得用于验证覆盖RRSIG的RRSIG。
Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR and MUST be ignored upon receipt.
保留位0-6和8-14：在创建DNSKEY RR时，这些位的值必须为0，并且在接收时必须忽略。
The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3.
协议字段的值必须为3，如果发现DNSKEY RR不是3，则必须在签名验证期间将其视为无效。
The Algorithm field identifies the public key's cryptographic algorithm and determines the format of the Public Key field. A list of DNSSEC algorithm types can be found in Appendix A.1
算法字段标识公钥的加密算法，并确定公钥字段的格式。DNSSEC算法类型列表见附录A.1
The Public Key Field holds the public key material. The format depends on the algorithm of the key being stored and is described in separate documents.
公钥字段保存公钥材料。格式取决于所存储密钥的算法，并在单独的文档中描述。
Although the Protocol Field always has value 3, it is retained for backward compatibility with early versions of the KEY record.
尽管Protocol字段的值始终为3，但为了与密钥记录的早期版本向后兼容而保留它。
The presentation format of the RDATA portion is as follows:
RDATA部分的表示格式如下所示：
The Flag field MUST be represented as an unsigned decimal integer. Given the currently defined flags, the possible values are: 0, 256, and 257.
标志字段必须表示为无符号十进制整数。给定当前定义的标志，可能的值为：0、256和257。
The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3.
协议字段必须表示为值为3的无符号十进制整数。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in Appendix A.1.
算法字段必须表示为无符号十进制整数或附录A.1中规定的算法助记符。
The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548].
公钥字段必须表示为公钥的Base64编码。Base64文本中允许空白。有关Base64编码的定义，请参阅[RFC3548]。
The following DNSKEY RR stores a DNS zone key for example.com.
以下DNSKEY RR存储了一个DNS区域密钥，例如.com。
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== )
example.com。DNSKEY 256 3 5中的86400（AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WQTKF7H6RFORQQQEEOGMMHFPFTF6Z MV1LYBUGIA7ZA6ZEZOZTYVHJL 742iU/TPPSEDHM2SNKLIFUPPN1U ANV4W==）
The first four text fields specify the owner name, TTL, Class, and RR type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in the Flags field has value 1. Value 3 is the fixed Protocol value. Value 5 indicates the public key algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1 and indicates that the format of the RSA/SHA1 public key field is defined in [RFC3110]. The remaining text is a Base64 encoding of the public key.
前四个文本字段指定所有者名称、TTL、类和RR类型（DNSKEY）。值256表示标志字段中的区域密钥位（位7）的值为1。值3是固定的协议值。值5表示公钥算法。附录A.1将算法类型5标识为RSA/SHA1，并指出[RFC3110]中定义了RSA/SHA1公钥字段的格式。剩下的文本是公钥的Base64编码。
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). Digital signatures are stored in RRSIG resource records and are used in the DNSSEC authentication process described in [RFC4035]. A validator can use these RRSIG RRs to authenticate RRsets from the zone. The RRSIG RR MUST only be used to carry verification material (digital signatures) used to secure DNS operations.
DNSSEC使用公钥加密技术对DNS资源记录集（RRSET）进行签名和身份验证。数字签名存储在RRSIG资源记录中，并用于[RFC4035]中描述的DNSSEC认证过程。验证器可以使用这些RRSIG RRs来验证区域中的RRSET。RRSIG RR只能用于携带用于保护DNS操作的验证材料（数字签名）。
An RRSIG record contains the signature for an RRset with a particular name, class, and type. The RRSIG RR specifies a validity interval for the signature and uses the Algorithm, the Signer's Name, and the Key Tag to identify the DNSKEY RR containing the public key that a validator can use to verify the signature.
RRSIG记录包含具有特定名称、类和类型的RRset的签名。RRSIG RR指定签名的有效期间隔，并使用算法、签名者姓名和密钥标记来标识包含验证器可用于验证签名的公钥的DNSKEY RR。
Because every authoritative RRset in a zone must be protected by a digital signature, RRSIG RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. A RRSIG and NSEC (see Section 4) MUST exist for the same name as a CNAME resource record in a signed zone.
由于区域中的每个权威RRset都必须受到数字签名的保护，因此对于包含CNAME RR的名称，必须存在RRSIG RRs。这是对传统DNS规范[RFC1034]的更改，该规范规定，如果名称存在CNAME，则该名称是唯一允许的类型。RRSIG和NSEC（参见第4节）必须与签名区域中的CNAME资源记录同名。
The Type value for the RRSIG RR type is 46.
RRSIG RR类型的类型值为46。
The RRSIG RR is class independent.
RRSIG RR是类独立的。
An RRSIG RR MUST have the same class as the RRset it covers.
RRSIG RR必须具有与其覆盖的RRset相同的类。
The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers. This is an exception to the [RFC2181] rules for TTL values of individual RRs within a RRset: individual RRSIG RRs with the same owner name will have different TTL values if the RRsets they cover have different TTL values.
RRSIG RR的TTL值必须与其覆盖的RRset的TTL值匹配。这是[RFC2181]规则对RRset中单个RRs的TTL值的例外情况：如果其覆盖的RRset具有不同的TTL值，则具有相同所有者名称的单个RRSIG RRs将具有不同的TTL值。
The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL field, a 4 octet Signature Expiration field, a 4 octet Signature Inception field, a 2 octet Key tag, the Signer's Name field, and the Signature field.
RRSIG RR的RDATA由2个八位类型覆盖字段、1个八位算法字段、1个八位标签字段、4个八位原始TTL字段、4个八位签名过期字段、4个八位签名起始字段、2个八位密钥标签、签名者姓名字段和签名字段组成。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type Covered field identifies the type of the RRset that is covered by this RRSIG record.
类型覆盖字段标识此RRSIG记录覆盖的RRset的类型。
The Algorithm Number field identifies the cryptographic algorithm used to create the signature. A list of DNSSEC algorithm types can be found in Appendix A.1
Algorithm Number字段标识用于创建签名的加密算法。DNSSEC算法类型列表见附录A.1
The Labels field specifies the number of labels in the original RRSIG RR owner name. The significance of this field is that a validator uses it to determine whether the answer was synthesized from a wildcard. If so, it can be used to determine what owner name was used in generating the signature.
标签字段指定原始RRSIG RR所有者名称中的标签数量。该字段的意义在于验证器使用它来确定答案是否由通配符合成。如果是这样，它可以用来确定生成签名时使用的所有者名称。
To validate a signature, the validator needs the original owner name that was used to create the signature. If the original owner name contains a wildcard label ("*"), the owner name may have been expanded by the server during the response process, in which case the validator will have to reconstruct the original owner name in order to validate the signature. [RFC4035] describes how to use the Labels field to reconstruct the original owner name.
要验证签名，验证器需要用于创建签名的原始所有者名称。如果原始所有者名称包含通配符标签（“*”），则服务器可能在响应过程中扩展了所有者名称，在这种情况下，验证程序必须重新构造原始所有者名称以验证签名。[RFC4035]描述了如何使用标签字段重建原始所有者名称。
The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present). The value of the Labels field MUST be less than or equal to the number of labels in the RRSIG owner name. For example, "www.example.com." has a Labels field value of 3, and "*.example.com." has a Labels field value of 2. Root (".") has a Labels field value of 0.
Labels字段的值不能计算终止所有者名称的空（根）标签或通配符标签（如果存在）。标签字段的值必须小于或等于RRSIG所有者名称中的标签数。例如，“www.example.com.”的标签字段值为3，“*.example.com.”的标签字段值为2。根（“.”）的标签字段值为0。
Although the wildcard label is not included in the count stored in the Labels field of the RRSIG RR, the wildcard label is part of the RRset's owner name when the signature is generated or verified.
尽管通配符标签不包括在存储在RRSIG RR标签字段中的计数中，但在生成或验证签名时，通配符标签是RRset所有者名称的一部分。
The Original TTL field specifies the TTL of the covered RRset as it appears in the authoritative zone.
原始TTL字段指定在权威区域中显示的覆盖RRset的TTL。
The Original TTL field is necessary because a caching resolver decrements the TTL value of a cached RRset. In order to validate a signature, a validator requires the original TTL. [RFC4035] describes how to use the Original TTL field value to reconstruct the original TTL.
原始TTL字段是必需的，因为缓存解析程序会递减缓存RRset的TTL值。为了验证签名，验证器需要原始TTL。[RFC4035]描述如何使用原始TTL字段值重建原始TTL。
The Signature Expiration and Inception fields specify a validity period for the signature. The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date.
签名到期和起始字段指定签名的有效期。RRSIG记录不得在起始日期之前用于身份验证，也不得在到期日期之后用于身份验证。
The Signature Expiration and Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The longest interval that can be expressed by this format without wrapping is approximately 136 years. An RRSIG RR can have an Expiration field value that is numerically smaller than the Inception field value if the expiration field value is near the 32-bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]. As a direct consequence, the values contained in these fields cannot refer to dates more than 68 years in either the past or the future.
签名过期和起始字段值以32位无符号秒数的形式指定日期和时间，该秒数自1970年1月1日00:00:00 UTC起经过，忽略闰秒，以网络字节顺序排列。这种格式无需包装即可表示的最长间隔约为136年。如果过期字段值接近32位环绕点，或者如果签名是长寿命的，则RRSIG RR的过期字段值可以在数字上小于初始字段值。因此，涉及这些字段的所有比较必须使用[RFC1982]中定义的“序列号算术”。因此，这些字段中包含的值不能指过去或未来超过68年的日期。
The Key Tag field contains the key tag value of the DNSKEY RR that validates this signature, in network byte order. Appendix B explains how to calculate Key Tag values.
密钥标记字段包含验证此签名的DNSKEY RR的密钥标记值（按网络字节顺序）。附录B说明了如何计算关键标签值。
The Signer's Name field value identifies the owner name of the DNSKEY RR that a validator is supposed to use to validate this signature. The Signer's Name field MUST contain the name of the zone of the covered RRset. A sender MUST NOT use DNS name compression on the Signer's Name field when transmitting a RRSIG RR.
签名者名称字段值标识验证程序用于验证此签名的DNSKEY RR的所有者名称。签名者名称字段必须包含覆盖RRset的区域名称。在传输RRSIG RR时，发送方不得在签名者的名称字段上使用DNS名称压缩。
The Signature field contains the cryptographic signature that covers the RRSIG RDATA (excluding the Signature field) and the RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered field. The format of this field depends on the algorithm in use, and these formats are described in separate companion documents.
签名字段包含覆盖RRSIG RDATA（不包括签名字段）和由RRSIG所有者名称、RRSIG类和RRSIG类型覆盖字段指定的RRset的加密签名。此字段的格式取决于使用的算法，这些格式在单独的配套文档中描述。
A signature covers the RRSIG RDATA (excluding the Signature Field) and covers the data RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered fields. The RRset is in canonical form (see Section 6), and the set RR(1),...RR(n) is signed as follows:
签名覆盖RRSIG RDATA（不包括签名字段），并覆盖由RRSIG所有者名称、RRSIG类和RRSIG类型覆盖字段指定的数据RRset。RRset是标准格式（见第6节），集合RR（1），…RR（n）的签名如下：
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
"|" denotes concatenation;
“|”表示串联；
RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the Signature field excluded;
RRSIG_RDATA是RRSIG RDATA字段的有线格式，签名者姓名字段为规范格式，签名字段除外；
RR(i) = owner | type | class | TTL | RDATA length | RDATA
RR（i）=所有者|类型|类别| TTL | RDATA长度| RDATA
"owner" is the fully qualified owner name of the RRset in canonical form (for RRs with wildcard owner names, the wildcard label is included in the owner name);
“所有者”是规范形式的RRset的完全限定所有者名称（对于具有通配符所有者名称的RRs，通配符标签包含在所有者名称中）；
Each RR MUST have the same owner name as the RRSIG RR;
每个RR必须具有与RRSIG RR相同的所有者名称；
Each RR MUST have the same class as the RRSIG RR;
每个RR必须具有与RRSIG RR相同的类；
Each RR in the RRset MUST have the RR type listed in the RRSIG RR's Type Covered field;
RRset中的每个RR必须在RRSIG RR的类型覆盖字段中列出RR类型；
Each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field;
RRset中的每个RR必须在RRSIG原始TTL字段中列出TTL；
Any DNS names in the RDATA field of each RR MUST be in canonical form; and
每个RR的RDATA字段中的任何DNS名称必须为规范格式；和
The RRset MUST be sorted in canonical order.
RRset必须按规范顺序排序。
See Sections 6.2 and 6.3 for details on canonical form and ordering of RRsets.
有关RRSET的规范形式和排序的详细信息，请参见第6.2节和第6.3节。
The presentation format of the RDATA portion is as follows:
RDATA部分的表示格式如下所示：
The Type Covered field is represented as an RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597], Section 5, MUST be used.
类型覆盖字段表示为RR类型助记符。当助记符未知时，必须使用[RFC3597]第5节中所述的类型表示。
The Algorithm field value MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic, as specified in Appendix A.1.
如附录A.1所述，算法字段值必须表示为无符号十进制整数或算法助记符。
The Labels field value MUST be represented as an unsigned decimal integer.
标签字段值必须表示为无符号十进制整数。
The Original TTL field value MUST be represented as an unsigned decimal integer.
原始TTL字段值必须表示为无符号十进制整数。
The Signature Expiration Time and Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where:
签名过期时间和起始时间字段值必须表示为无符号十进制整数，表示自1970年1月1日00:00:00 UTC起的秒数，或表示为YYYYMMDDHHmmSS格式（UTC），其中：
YYYY is the year (0001-9999, but see Section 3.1.5);
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and
SS is the second (00-59).
YYYY is the year (0001-9999, but see Section 3.1.5);
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and
SS is the second (00-59).
Note that it is always possible to distinguish between these two formats because the YYYYMMDDHHmmSS format will always be exactly 14 digits, while the decimal representation of a 32-bit unsigned integer can never be longer than 10 digits.
请注意，始终可以区分这两种格式，因为YYYYMMDDHHmmSS格式始终正好是14位数字，而32位无符号整数的十进制表示永远不能超过10位。
The Key Tag field MUST be represented as an unsigned decimal integer.
键标记字段必须表示为无符号十进制整数。
The Signer's Name field value MUST be represented as a domain name.
签名者的名称字段值必须表示为域名。
The Signature field is represented as a Base64 encoding of the signature. Whitespace is allowed within the Base64 text. See Section 2.2.
签名字段表示为签名的Base64编码。Base64文本中允许空白。见第2.2节。
The following RRSIG RR stores the signature for the A RRset of host.example.com:
以下RRSIG RR存储了host.example.com的RRA集的签名：
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
host.example.com。RRSIG A 5 3 86400 20030322173103中的86400（20030220173103 2642 example.com.oJB1W6WNGv+ldvq3wdg0mqg5iehjrip8wtr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o b9wfuh3dtxuafi/M0zmO/zz8w0rznl8o3t gnazpwqkkrn20xv6nwfwfxmjf8nn+6pbzedqfqfsssp3o=）
The first four fields specify the owner name, TTL, Class, and RR type (RRSIG). The "A" represents the Type Covered field. The value 5 identifies the algorithm used (RSA/SHA1) to create the signature. The value 3 is the number of Labels in the original owner name. The value 86400 in the RRSIG RDATA is the Original TTL for the covered A RRset. 20030322173103 and 20030220173103 are the expiration and
前四个字段指定所有者名称、TTL、类和RR类型（RRSIG）。“A”表示覆盖字段的类型。值5标识用于创建签名的算法（RSA/SHA1）。值3是原始所有者名称中的标签数。RRSIG RDATA中的值86400是覆盖RRA集的原始TTL。20030322173103和20030220173103是到期日和
inception dates, respectively. 2642 is the Key Tag, and example.com. is the Signer's Name. The remaining text is a Base64 encoding of the signature.
分别是起始日期。2642是密钥标记，example.com。是签名者的名字。剩下的文本是签名的Base64编码。
Note that combination of RRSIG RR owner name, class, and Type Covered indicates that this RRSIG covers the "host.example.com" A RRset. The Label value of 3 indicates that no wildcard expansion was used. The Algorithm, Signer's Name, and Key Tag indicate that this signature can be authenticated using an example.com zone DNSKEY RR whose algorithm is 5 and whose key tag is 2642.
请注意，RRSIG RR owner name、class和Type Covered的组合表示该RRSIG覆盖了RRset中的“host.example.com”。标签值3表示未使用通配符扩展。算法、签名者姓名和密钥标记表明，可以使用example.com zone DNSKEY RR对该签名进行身份验证，该区域的算法为5，密钥标记为2642。
The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name [RFC3845]. The complete set of NSEC RRs in a zone indicates which authoritative RRsets exist in a zone and also form a chain of authoritative owner names in the zone. This information is used to provide authenticated denial of existence for DNS data, as described in [RFC4035].
NSEC资源记录列出了两个独立的内容：包含权威数据或授权点NS RRset的下一个所有者名称（按照区域的规范顺序），以及NSEC RR所有者名称[RFC3845]中存在的RR类型集。区域中NSEC RRs的完整集合表示区域中存在哪些权威RRs集合，并在区域中形成一个权威所有者名称链。如[RFC4035]所述，此信息用于提供DNS数据的身份验证拒绝存在。
Because every authoritative name in a zone must be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone.
由于区域中的每个权威名称都必须是NSEC链的一部分，因此包含CNAME RR的名称必须存在NSEC RRs。这是对传统DNS规范[RFC1034]的更改，该规范规定，如果名称存在CNAME，则该名称是唯一允许的类型。RRSIG（参见第3节）和NSEC必须与签名区域中的CNAME资源记录具有相同的名称。
See [RFC4035] for discussion of how a zone signer determines precisely which NSEC RRs it has to include in a zone.
请参阅[RFC4035]，了解区域签名者如何准确确定其必须在区域中包含的NSEC RRs。
The type value for the NSEC RR is 47.
NSEC RR的类型值为47。
The NSEC RR is class independent.
NSEC RR与类别无关。
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).
NSEC RR应具有与SOA最小TTL字段相同的TTL值。这符合负缓存（[RFC2308]）的精神。
The RDATA of the NSEC RR is as shown below:
NSEC RR的RDATA如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Next Domain field contains the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset; see Section 6.1 for an explanation of canonical ordering. The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR). This indicates that the owner name of the NSEC RR is the last name in the canonical ordering of the zone.
“下一个域”字段包含具有权威数据或包含委托点集的下一个所有者名称（按区域的规范顺序）；有关规范排序的解释，请参见第6.1节。区域中最后一条NSEC记录中的下一个域名字段的值是区域顶点的名称（区域的SOA RR的所有者名称）。这表明NSEC RR的所有者名称是区域规范顺序中的姓氏。
A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR.
在传输NSEC RR时，发送方不得在下一个域名字段上使用DNS名称压缩。
Owner names of RRsets for which the given zone is not authoritative (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name.
除非在同一所有者名称下至少存在一个权威RRset，否则不得在下一个域名中列出给定区域不具有权威性的RRset的所有者名称（如胶水记录）。
The Type Bit Maps field identifies the RRset types that exist at the NSEC RR's owner name.
类型位图字段标识NSEC RR所有者名称中存在的RRset类型。
The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the window block's bitmap, and up to 32 octets (256 bits) of bitmap.
RR类型空间被分割为256个窗口块，每个窗口块表示16位RR类型空间的低位8位。每个具有至少一个活动RR类型的块都使用单个八位字节窗口编号（从0到255）、单个八位字节位图长度（从1到32）进行编码，该长度指示用于窗口块位图的八位字节数，以及最多32个八位字节（256位）的位图。
Blocks are present in the NSEC RR RDATA in increasing numerical order.
块以递增的数字顺序出现在NSEC RR RDATA中。
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
where "|" denotes concatenation.
其中“|”表示串联。
Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, and bit 2 to RR type 258. If a bit is set, it indicates that an RRset of that type is present for the NSEC RR's owner name. If a bit is clear, it indicates that no RRset of that type is present for the NSEC RR's owner name.
每个位图以网络位顺序对窗口块内RR类型的低位8位进行编码。第一位是位0。对于窗口块0，位1对应于RR类型1（A），位2对应于RR类型2（NS），依此类推。对于窗口块1，位1对应于RR类型257，位2对应于RR类型258。如果设置了位，则表示NSEC RR的所有者名称存在该类型的RRset。如果某个位是清除的，则表示NSEC RR的所有者名称不存在该类型的RRset。
Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read.
表示伪类型的位必须是清晰的，因为它们不会出现在区域数据中。如果遇到，在读取时必须忽略它们。
Blocks with no types present MUST NOT be included. Trailing zero octets in the bitmap MUST be omitted. The length of each block's bitmap is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the NSEC RR's owner name. Trailing zero octets not specified MUST be interpreted as zero octets.
不包括不存在类型的块。位图中尾随的零八位字节必须省略。每个块位图的长度由NSEC RR所有者名称中RR类型集合中该块内具有最大数值的类型代码确定。未指定的尾随零八位字节必须解释为零八位字节。
The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and the RR types for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear.
NSEC RR在委派点的位图需要特别注意。必须设置与授权NS RRset和父区域具有权威数据的RR类型相对应的位；与父级未授权的任何非NS RRset相对应的位必须清除。
A zone MUST NOT include an NSEC RR for any domain name that only holds glue records.
一个区域不得包含任何仅保存glue记录的域名的NSEC RR。
If a wildcard owner name appears in a zone, the wildcard label ("*") is treated as a literal symbol and is treated the same as any other owner name for the purposes of generating NSEC RRs. Wildcard owner names appear in the Next Domain Name field without any wildcard expansion. [RFC4035] describes the impact of wildcards on authenticated denial of existence.
如果区域中出现通配符所有者名称，则通配符标签（“*”）将被视为文字符号，并被视为与生成NSEC RRs的任何其他所有者名称相同。通配符所有者名称显示在下一个域名字段中，没有任何通配符扩展。[RFC4035]描述了通配符对经过身份验证的拒绝存在的影响。
The presentation format of the RDATA portion is as follows:
RDATA部分的表示格式如下所示：
The Next Domain Name field is represented as a domain name.
下一个域名字段表示为域名。
The Type Bit Maps field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation described in [RFC3597], Section 5, MUST be used.
类型位图字段表示为RR类型助记符序列。当助记符未知时，必须使用[RFC3597]第5节中描述的类型表示。
The following NSEC RR identifies the RRsets associated with alfa.example.com. and identifies the next authoritative name after alfa.example.com.
以下NSEC RR确定了与alfa.example.com相关的RRSET。并标识alfa.example.com之后的下一个权威名称。
alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )
alfa.example.com。NSEC host.example.com上的86400。（MX RRSIG NSEC类型1234）
The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets associated with the name alfa.example.com.
前四个文本字段指定名称、TTL、类和RR类型（NSEC）。条目host.example.com。是alfa.example.com之后的下一个权威名称。按照规范的顺序。A、MX、RRSIG、NSEC和TYPE1234助记符表示存在与名称alfa.example.com关联的A、MX、RRSIG、NSEC和TYPE1234 rrset。
The RDATA section of the NSEC RR above would be encoded as:
上述NSEC RR的RDATA部分将编码为：
0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20
0x04“h”o“s”t“0x07”e“x”a“m”p“l”e“0x03”c“o”m“0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20
Assuming that the validator can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or to prove that there is no AAAA record associated with alfa.example.com. Authenticated denial of existence is discussed in [RFC4035].
假设验证器可以验证此NSEC记录，它可以用来证明beta.example.com不存在，或者证明没有与alfa.example.com相关的AAAA记录。[RFC4035]中讨论了经验证的拒绝存在。
The DS Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. A DS RR refers to a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR. Note that while the digest should be sufficient to identify the public key, storing the key tag and key algorithm helps make the identification process more efficient. By authenticating the DS record, a resolver can authenticate the DNSKEY RR to which the DS record points. The key authentication process is described in [RFC4035].
DS资源记录引用DNSKEY RR，并用于DNS DNSKEY身份验证过程。DS RR通过存储密钥标记、算法编号和DNSKEY RR摘要来引用DNSKEY RR。注意，虽然摘要应该足以识别公钥，但存储密钥标签和密钥算法有助于提高识别过程的效率。通过验证DS记录，解析器可以验证DS记录指向的DNSKEY RR。[RFC4035]中描述了密钥认证过程。
The DS RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone. For example, the DS RR for "example.com" is stored in the "com" zone (the parent zone) rather than in the
DS RR及其对应的DNSKEY RR具有相同的所有者名称，但它们存储在不同的位置。DS RR仅显示在委派的上部（父）侧，并且是父区域中的权威数据。例如，“example.com”的DS RR存储在“com”区域（父区域）中，而不是存储在
"example.com" zone (the child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (the child zone). This simplifies DNS zone management and zone signing but introduces special response processing requirements for the DS RR; these are described in [RFC4035].
“example.com”区域（子区域）。相应的DNSKEY RR存储在“example.com”区域（子区域）中。这简化了DNS区域管理和区域签名，但为DS RR引入了特殊的响应处理要求；这些在[RFC4035]中进行了描述。
The type number for the DS record is 43.
DS记录的类型号为43。
The DS resource record is class independent.
DS资源记录与类无关。
The DS RR has no special TTL requirements.
DS RR没有特殊的TTL要求。
The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet Algorithm field, a 1 octet Digest Type field, and a Digest field.
DS RR的RDATA由2个八位键标记字段、1个八位算法字段、1个八位摘要类型字段和摘要字段组成。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.
Key Tag（关键标记）字段以网络字节顺序列出DS记录引用的DNSKEY RR的关键标记。
The Key Tag used by the DS RR is identical to the Key Tag used by RRSIG RRs. Appendix B describes how to compute a Key Tag.
DS RR使用的密钥标签与RRSIG RRs使用的密钥标签相同。附录B描述了如何计算密钥标签。
The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.
算法字段列出DS记录引用的DNSKEY RR的算法编号。
The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm number types.
DS RR使用的算法编号与RRSIG和DNSKEY RRs使用的算法编号相同。附录A.1列出了算法编号类型。
The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY RR. The Digest Type field identifies the algorithm used to construct the digest. Appendix A.2 lists the possible digest algorithm types.
DS RR通过包含DNSKEY RR的摘要来引用该DNSKEY RR。摘要类型字段标识用于构造摘要的算法。附录A.2列出了可能的摘要算法类型。
The DS record refers to a DNSKEY RR by including a digest of that DNSKEY RR.
DS记录通过包含DNSKEY RR的摘要来引用该DNSKEY RR。
The digest is calculated by concatenating the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then applying the digest algorithm.
摘要的计算方法是将DNSKEY RR的完全限定所有者名称的规范形式与DNSKEY RDATA连接起来，然后应用摘要算法。
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
"|" denotes concatenation
“|”表示串联
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
DNSKEY RDATA=标志|协议|算法|公钥。
The size of the digest may vary depending on the digest algorithm and DNSKEY RR size. As of the time of this writing, the only defined digest algorithm is SHA-1, which produces a 20 octet digest.
摘要的大小可能因摘要算法和DNSKEY RR大小而异。在撰写本文时，唯一定义的摘要算法是SHA-1，它生成20个八位组的摘要。
The DS RR links the authentication chain across zone boundaries, so the DS RR requires extra care in processing. The DNSKEY RR referred to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be used in the validation process.
DS RR跨区域边界链接身份验证链，因此DS RR在处理过程中需要格外小心。DS RR中提到的DNSKEY RR必须是DNSSEC区域密钥。DNSKEY RR标志必须设置标志位7。如果DNSKEY标志不表示DNSSEC区域密钥，则在验证过程中不得使用DS RR（及其引用的DNSKEY RR）。
The presentation format of the RDATA portion is as follows:
RDATA部分的表示格式如下所示：
The Key Tag field MUST be represented as an unsigned decimal integer.
键标记字段必须表示为无符号十进制整数。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1.
算法字段必须表示为无符号十进制整数或附录A.1中规定的算法助记符。
The Digest Type field MUST be represented as an unsigned decimal integer.
摘要类型字段必须表示为无符号十进制整数。
The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text.
摘要必须表示为不区分大小写的十六进制数字序列。十六进制文本中允许空白。
The following example shows a DNSKEY RR and its corresponding DS RR.
以下示例显示DNSKEY RR及其对应的DS RR。
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485
dskey.example.com。86400 IN DNSKEY 256 3 5（AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/2pHm822aJ5iI9BMzNXxeYCmZ drd99wywywyqusdjmmmaphxdvx egXd/M5+X7OrzKBaMbCVdFLU uh6dhwjbjevv5f2wjm9xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw=）；钥匙id=60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 )
dskey.example.com。DS 60485 5 1中的86400（2BB183AF5F22588179A53B0A 98631FAD1A292118）
The first four text fields specify the name, TTL, Class, and RR type (DS). Value 60485 is the key tag for the corresponding "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm used by this "dskey.example.com." DNSKEY RR. The value 1 is the algorithm used to construct the digest, and the rest of the RDATA text is the digest in hexadecimal.
前四个文本字段指定名称、TTL、类和RR类型（DS）。值60485是对应的“dskey.example.com.”DNSKEY RR的密钥标记，值5表示此“dskey.example.com.”DNSKEY RR使用的算法。值1是用于构造摘要的算法，其余RDATA文本是十六进制的摘要。
This section defines a canonical form for resource records, a canonical ordering of DNS names, and a canonical ordering of resource records within an RRset. A canonical name order is required to construct the NSEC name chain. A canonical RR form and ordering within an RRset are required in order to construct and verify RRSIG RRs.
本节定义资源记录的规范形式、DNS名称的规范顺序以及RRset内资源记录的规范顺序。构造NSEC名称链需要规范的名称顺序。为了构造和验证RRSIG RRs，需要规范的RR形式和RRset内的排序。
For the purposes of DNS security, owner names are ordered by treating individual labels as unsigned left-justified octet strings. The absence of a octet sorts before a zero value octet, and uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters.
出于DNS安全的目的，通过将单个标签视为未签名的左对齐八位字节字符串来排列所有者名称。没有八位字节的情况在零值八位字节之前排序，大写US-ASCII字母被视为小写US-ASCII字母。
To compute the canonical ordering of a set of DNS names, start by sorting the names according to their most significant (rightmost) labels. For names in which the most significant label is identical, continue sorting according to their next most significant label, and so forth.
要计算一组DNS名称的规范顺序，请首先根据名称的最重要（最右边）标签对名称进行排序。对于最重要标签相同的名称，继续根据其下一个最重要标签进行排序，依此类推。
For example, the following names are sorted in canonical DNS name order. The most significant label is "example". At this level, "example" sorts first, followed by names ending in "a.example", then by names ending "z.example". The names within each level are sorted in the same way.
例如，以下名称按规范DNS名称顺序排序。最重要的标签是“示例”。在这个级别，“example”首先排序，然后是以“a.example”结尾的名称，然后是以“z.example”结尾的名称。每个级别内的名称以相同的方式排序。
example a.example yljkjljk.a.example Z.a.example zABC.a.EXAMPLE z.example \001.z.example *.z.example \200.z.example
示例a.example yljkjljk.a.example Z.a.example zABC.a.example Z.example\001.Z.example*.Z.example\200.Z.example
For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where:
出于DNS安全的目的，RR的标准形式是RR的有线格式，其中：
1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified;
1. RR中的每个域名都是完全扩展（没有DNS名称压缩）和完全限定的；
2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters;
2. RR所有者名称中的所有大写US-ASCII字母均替换为相应的小写US-ASCII字母；
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters;
3. 如果RR的类型为NS、MD、MF、CNAME、SOA、MB、MG、MR、PTR、HINFO、MINFO、MX、HINFO、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KX、SRV、DNAME、A6、RRSIG或NSEC，则RDATA中包含的DNS名称中的所有大写US-ASCII字母将替换为相应的小写US-ASCII字母；
4. if the owner name of the RR is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution); and
4. 如果RR的所有者名称为通配符名称，则所有者名称为其原始未展开形式，包括“*”标签（无通配符替换）；和
5. the RR's TTL is set to its original value as it appears in the originating authoritative zone or the Original TTL field of the covering RRSIG RR.
5. RR的TTL设置为其原始值，因为它出现在原始授权区域或覆盖RRSIG RR的原始TTL字段中。
For the purposes of DNS security, RRs with the same owner name, class, and type are sorted by treating the RDATA portion of the canonical form of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet.
出于DNS安全性的目的，通过将每个RR规范形式的RDATA部分视为左对齐的无符号八位字节序列，对具有相同所有者名称、类和类型的RR进行排序，在该序列中，没有八位字节的情况在零八位字节之前排序。
[RFC2181] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset.
[RFC2181]指定不允许RRset包含重复记录（具有相同所有者名称、类、类型和RDATA的多个RRs）。因此，如果一个实现在将RRset放入规范形式时检测到重复的RRs，它必须将其视为协议错误。如果实现选择本着健壮性原则处理此协议错误（在其接受的方面是自由的），则必须删除除一个之外的所有重复RR，以便计算RRset的标准形式。
This document introduces no new IANA considerations, as all of the protocol parameters used in this document have already been assigned by previous specifications. However, since the evolution of DNSSEC has been long and somewhat convoluted, this section attempts to describe the current state of the IANA registries and other protocol parameters that are (or once were) related to DNSSEC.
本文档没有引入新的IANA注意事项，因为本文档中使用的所有协议参数都已由以前的规范指定。然而，由于DNSSEC的发展已经很长，而且有些复杂，本节试图描述IANA注册中心的当前状态以及与DNSSEC相关（或曾经相关）的其他协议参数。
Please refer to [RFC4035] for additional IANA considerations.
有关IANA的其他注意事项，请参考[RFC4035]。
DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol described in [RFC2931] and to the transaction KEY Resource Record described in [RFC2930].
DNS资源记录类型：[RFC2535]分别为SIG、KEY和NXT RRs分配了类型24、25和30。[RFC3658]已将DNS资源记录类型43分配给DS。[RFC3755]分别将类型46、47和48分配给RRSIG、NSEC和DNSKEY RRs。[RFC3755]还将类型30（NXT）标记为[RFC2931]中描述的“SIG（0）”交易安全协议和[RFC2930]中描述的交易密钥资源记录中类型24（SIG）和25（密钥）的过时和限制使用。
DNS Security Algorithm Numbers: [RFC2535] created an IANA registry for DNSSEC Resource Record Algorithm field numbers and assigned values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] altered this registry to include flags for each entry regarding its use with the DNS security extensions. Each algorithm entry could refer to an algorithm that can be used for zone signing, transaction security (see [RFC2931]), or both. Values 6-251 are available for assignment by IETF standards action ([RFC3755]). See Appendix A for a full listing of the DNS Security Algorithm Numbers entries at the time of this writing and their status for use in DNSSEC.
DNS安全算法编号：[RFC2535]为DNSSEC资源记录算法字段编号和赋值1-4和252-255创建了IANA注册表。[RFC3110]赋值5。[RFC3755]更改了此注册表，为每个条目包含有关其与DNS安全扩展一起使用的标志。每个算法条目都可以引用一个算法，该算法可用于区域签名、事务安全性（请参见[RFC2931]），或同时用于两者。IETF标准行动（[RFC3755]）可分配值6-251。有关撰写本文时DNS安全算法编号条目的完整列表及其在DNSSEC中使用的状态，请参见附录A。
[RFC3658] created an IANA registry for DNSSEC DS Digest Types and assigned value 0 to reserved and value 1 to SHA-1.
[RFC3658]为DNSSEC DS摘要类型创建了IANA注册表，并将值0分配给reserved，将值1分配给SHA-1。
KEY Protocol Values: [RFC2535] created an IANA Registry for KEY Protocol Values, but [RFC3445] reassigned all values other than 3 to reserved and closed this IANA registry. The registry remains closed, and all KEY and DNSKEY records are required to have a Protocol Octet value of 3.
密钥协议值：[RFC2535]为密钥协议值创建了IANA注册表，但[RFC3445]将3以外的所有值重新分配给保留并关闭了此IANA注册表。注册表保持关闭状态，所有密钥和DNSKEY记录的协议八位字节值必须为3。
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, this registry only contains assignments for bit 7 (the ZONE bit) and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). As stated in [RFC3755], bits 0-6 and 8-14 are available for assignment by IETF Standards Action.
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, this registry only contains assignments for bit 7 (the ZONE bit) and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). As stated in [RFC3755], bits 0-6 and 8-14 are available for assignment by IETF Standards Action.translate error, please retry
This document describes the format of four DNS resource records used by the DNS security extensions and presents an algorithm for calculating a key tag for a public key. Other than the items described below, the resource records themselves introduce no security considerations. Please see [RFC4033] and [RFC4035] for additional security considerations related to the use of these records.
本文档描述了DNS安全扩展使用的四个DNS资源记录的格式，并介绍了一种用于计算公钥的密钥标记的算法。除了下面描述的项目之外，资源记录本身没有引入任何安全考虑。请参阅[RFC4033]和[RFC4035]，了解与使用这些记录相关的其他安全注意事项。
The DS record points to a DNSKEY RR by using a cryptographic digest, the key algorithm type, and a key tag. The DS record is intended to identify an existing DNSKEY RR, but it is theoretically possible for an attacker to generate a DNSKEY that matches all the DS fields. The probability of constructing a matching DNSKEY depends on the type of digest algorithm in use. The only currently defined digest algorithm is SHA-1, and the working group believes that constructing a public key that would match the algorithm, key tag, and SHA-1 digest given in a DS record would be a sufficiently difficult problem that such an attack is not a serious threat at this time.
DS记录通过使用加密摘要、密钥算法类型和密钥标记指向DNSKEY RR。DS记录旨在识别现有的DNSKEY RR，但从理论上讲，攻击者有可能生成与所有DS字段匹配的DNSKEY。构造匹配DNSKEY的概率取决于使用的摘要算法的类型。目前唯一定义的摘要算法是SHA-1，工作组认为，构造一个与DS记录中给出的算法、密钥标签和SHA-1摘要相匹配的公钥将是一个非常困难的问题，这样的攻击目前不会构成严重威胁。
The key tag is used to help select DNSKEY resource records efficiently, but it does not uniquely identify a single DNSKEY resource record. It is possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm type, and the same key tag. An implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances. Please see Appendix B for further details.
密钥标记用于帮助有效地选择DNSKEY资源记录，但它不能唯一标识单个DNSKEY资源记录。两个不同的DNSKEY RRs可能具有相同的所有者名称、相同的算法类型和相同的密钥标记。在某些情况下，仅使用key标记选择DNSKEY RR的实现可能会选择错误的公钥。更多详情请参见附录B。
The table of algorithms in Appendix A and the key tag calculation algorithms in Appendix B include the RSA/MD5 algorithm for completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as explained in [RFC3110].
附录A中的算法表和附录B中的密钥标签计算算法包括完整性的RSA/MD5算法，但不推荐使用RSA/MD5算法，如[RFC3110]中所述。
This document was created from the input and ideas of the members of the DNS Extensions Working Group and working group mailing list. The editors would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, [RFC4033] includes a list of some of the participants who were kind enough to comment on these documents.
本文档是根据DNS扩展工作组和工作组邮件列表成员的输入和想法创建的。编辑们感谢在修订这些安全扩展规范期间收到的评论和建议。虽然不可能明确列出在DNSSEC开发的十年中做出贡献的所有人，[RFC4033]包括一些对这些文件发表评论的参与者的名单。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536]Eastlake 3rd，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 25361999年3月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]Eastlake 3rd，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658]Gudmundsson，O.“委托签署人（DS）资源记录（RR）”，RFC3658，2003年12月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755]Weiler，S.“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年5月。
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
[RFC3757]Kolkman，O.，Schlyter，J.，和E.Lewis，“域名系统密钥（DNSKEY）资源记录（RR）安全入口点（SEP）标志”，RFC 3757，2004年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999.
[RFC2537]Eastlake 3rd，D.，“域名系统（DNS）中的RSA/MD5密钥和SIG”，RFC 2537，1999年3月。
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2539]Eastlake 3rd，D.，“域名系统（DNS）中Diffie-Hellman密钥的存储”，RFC 25391999年3月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake 3rd，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004.
[RFC3845]Schlyter，J.，“DNS安全（DNSSEC）下一代安全（NSEC）RDATA格式”，RFC 38452004年8月。
The DNS security extensions are designed to be independent of the underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS resource records all use a DNSSEC Algorithm Number to identify the cryptographic algorithm in use by the resource record. The DS resource record also specifies a Digest Algorithm Number to identify the digest algorithm used to construct the DS record. The currently defined Algorithm and Digest Types are listed below. Additional Algorithm or Digest Types could be added as advances in cryptography warrant them.
DNS安全扩展设计为独立于底层加密算法。DNSKEY、RRSIG和DS资源记录都使用DNSSEC算法编号来标识资源记录正在使用的加密算法。DS资源记录还指定摘要算法编号，以标识用于构造DS记录的摘要算法。下面列出了当前定义的算法和摘要类型。随着密码学的进步，可以添加额外的算法或摘要类型。
A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms.
支持DNSSEC的解析程序或名称服务器必须实现所有必需的算法。
The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the security algorithm being used. These values are stored in the "Algorithm number" field in the resource record RDATA.
DNSKEY、RRSIG和DS RRs使用8位数字标识正在使用的安全算法。这些值存储在资源记录RDATA的“算法编号”字段中。
Some algorithms are usable only for zone signing (DNSSEC), some only for transaction security mechanisms (SIG(0) and TSIG), and some for both. Those usable for zone signing may appear in DNSKEY, RRSIG, and DS RRs. Those usable for transaction security would be present in SIG(0) and KEY RRs, as described in [RFC2931].
有些算法仅适用于区域签名（DNSSEC），有些算法仅适用于事务安全机制（SIG（0）和TSIG），有些算法同时适用于这两种机制。可用于区域签名的可能出现在DNSKEY、RRSIG和DS RRs中。如[RFC2931]所述，SIG（0）和密钥RRs中存在可用于事务安全性的信息。
Zone
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved
Zone
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved
6 - 251 Available for assignment by IETF Standards Action.
6-251可供IETF标准行动分配。
Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encoded domain name, which MUST NOT be compressed. The domain name indicates the private algorithm to use, and the remainder of the public key area is determined by that algorithm. Entities should only use domain names they control to designate their private algorithms.
算法编号253保留供私人使用，永远不会分配给特定算法。DNSKEY RR中的公钥区域和RRSIG RR中的签名区域以有线编码域名开始，不得压缩。域名表示要使用的私有算法，公钥区域的其余部分由该算法确定。实体应仅使用其控制的域名来指定其私有算法。
Algorithm number 254 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with an unsigned length byte followed by a BER encoded Object Identifier (ISO OID) of that length. The OID indicates the private algorithm in use, and the remainder of the area is whatever is required by that algorithm. Entities should only use OIDs they control to designate their private algorithms.
算法编号254保留供私人使用，永远不会分配给特定算法。DNSKEY RR中的公钥区域和RRSIG RR中的签名区域以无符号长度字节开头，后跟该长度的BER编码对象标识符（ISO OID）。OID表示正在使用的私有算法，该区域的剩余部分是该算法所需的部分。实体应仅使用其控制的OID来指定其私有算法。
A "Digest Type" field in the DS resource record types identifies the cryptographic digest algorithm used by the resource record. The following table lists the currently defined digest algorithm types.
DS资源记录类型中的“摘要类型”字段标识资源记录使用的加密摘要算法。下表列出了当前定义的摘要算法类型。
VALUE Algorithm STATUS 0 Reserved - 1 SHA-1 MANDATORY 2-255 Unassigned -
值算法状态0保留-1 SHA-1强制2-255未分配-
The Key Tag field in the RRSIG and DS resource record types provides a mechanism for selecting a public key efficiently. In most cases, a combination of owner name, algorithm, and key tag can efficiently identify a DNSKEY record. Both the RRSIG and DS resource records have corresponding DNSKEY records. The Key Tag field in the RRSIG and DS records can be used to help select the corresponding DNSKEY RR efficiently when more than one candidate DNSKEY RR is available.
RRSIG和DS资源记录类型中的密钥标记字段提供了有效选择公钥的机制。在大多数情况下，所有者名称、算法和密钥标记的组合可以有效地识别DNSKEY记录。RRSIG和DS资源记录都有相应的DNSKEY记录。当多个候选DNSKEY RR可用时，RRSIG和DS记录中的Key Tag字段可用于帮助有效选择相应的DNSKEY RR。
However, it is essential to note that the key tag is not a unique identifier. It is theoretically possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm, and the same key tag. The key tag is used to limit the possible candidate keys, but it does not uniquely identify a DNSKEY record. Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR.
但是，必须注意，密钥标记不是唯一标识符。理论上，两个不同的DNSKEY RRs可能具有相同的所有者名称、相同的算法和相同的密钥标记。密钥标记用于限制可能的候选密钥，但它不能唯一标识DNSKEY记录。实现不得假定密钥标记唯一标识DNSKEY RR。
The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bits.
除算法1外，所有DNSKEY算法类型的密钥标签均相同（关于算法1的密钥标签定义，请参见附录B.1）。密钥标记算法是将DNSKEY RDATA的有线格式分为2个八位组的总和。首先，RDATA（有线格式）被视为一系列2个八位组。然后将这些组相加，忽略任何进位。
A reference implementation of the key tag algorithm is as an ANSI C function is given below, with the RDATA portion of the DNSKEY RR is used as input. It is not necessary to use the following reference code verbatim, but the numerical value of the Key Tag MUST be identical to what the reference implementation would generate for the same input.
密钥标记算法的参考实现如下所示，ANSI C函数使用DNSKEY RR的RDATA部分作为输入。不必逐字使用下面的参考代码，但Key标记的数值必须与参考实现为相同输入生成的值相同。
Please note that the algorithm for calculating the Key Tag is almost but not completely identical to the familiar ones-complement checksum used in many other Internet protocols. Key Tags MUST be calculated using the algorithm described here rather than the ones complement checksum.
请注意，用于计算密钥标记的算法与许多其他Internet协议中使用的常见的补码校验和算法几乎相同，但并不完全相同。密钥标记必须使用此处描述的算法计算，而不是使用补码校验和的算法。
The following ANSI C reference implementation calculates the value of a Key Tag. This reference implementation applies to all algorithm types except algorithm 1 (see Appendix B.1). The input is the wire format of the RDATA portion of the DNSKEY RR. The code is written for clarity, not efficiency.
下面的ANSI C参考实现计算键标记的值。本参考实施适用于除算法1以外的所有算法类型（见附录B.1）。输入是DNSKEY RR的RDATA部分的导线格式。编写代码是为了清晰，而不是为了效率。
/*
* Assumes that int is at least 16 bits.
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
/*
* Assumes that int is at least 16 bits.
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
The key tag for algorithm 1 (RSA/MD5) is defined differently from the key tag for all other algorithms, for historical reasons. For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus).
由于历史原因，算法1（RSA/MD5）的密钥标记定义与所有其他算法的密钥标记不同。对于具有算法1的DNSKEY RR，密钥标签被定义为公钥模中最低有效24位中的最高有效16位（换句话说，公钥模的第四到最后和第三到最后八位字节）。
Please note that Algorithm 1 is NOT RECOMMENDED.
请注意，不建议使用算法1。
Authors' Addresses
作者地址
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
Roy Arends远程信息处理研究所Brouwerijstraat 1 7523 XC Enschede NL
EMail: roy.arends@telin.nl
EMail: roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Rob Austein互联网系统联合会950 Charter Street Redwood City，加利福尼亚州94063
EMail: sra@isc.org
EMail: sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Matt Larson VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: mlarson@verisign.com
EMail: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
Dan Massey科罗拉多州立大学计算机科学系科罗拉多州科林斯堡80523-1873
EMail: massey@cs.colostate.edu
EMail: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
斯科特·罗斯国家标准与技术研究所美国马里兰州盖瑟斯堡100号局道20899-8920
EMail: scott.rose@nist.gov
EMail: scott.rose@nist.gov
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。