Network Working Group R. Arends
Request for Comments: 4035 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: 4035 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
Protocol Modifications 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 new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.
本文档是描述DNS安全扩展（DNSSEC）的文档系列的一部分。DNS安全扩展是新资源记录和协议修改的集合，这些记录和协议修改将数据源身份验证和数据完整性添加到DNS。本文件描述了DNSSEC协议的修改。本文件定义了签名区域的概念，以及使用DNSSEC服务和解析的要求。这些技术允许具有安全意识的解析器对DNS资源记录和权威DNS错误指示进行身份验证。
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 . . . . . . . . . . . . 4
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
3.1.4. Including DS RRs in a Response . . . . . . . . . 14
3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
3.1.6. The AD and CD Bits in an Authoritative Response. 16
3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Signature Verification Support . . . . . . . . . . . . . 19
4.3. Determining Security Status of Data . . . . . . . . . . 20
4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
5.1. Special Considerations for Islands of Security . . . . . 26
5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
5.3.3. Checking the Signature . . . . . . . . . . . . . 31
5.3.4. Authenticating a Wildcard Expanded RRset
Positive Response. . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . . 4
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
3.1.4. Including DS RRs in a Response . . . . . . . . . 14
3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
3.1.6. The AD and CD Bits in an Authoritative Response. 16
3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Signature Verification Support . . . . . . . . . . . . . 19
4.3. Determining Security Status of Data . . . . . . . . . . 20
4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
5.1. Special Considerations for Islands of Security . . . . . 26
5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
5.3.3. Checking the Signature . . . . . . . . . . . . . 31
5.3.4. Authenticating a Wildcard Expanded RRset
Positive Response. . . . . . . . . . . . . . . . 32
5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
The DNS Security Extensions (DNSSEC) are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document defines the DNSSEC protocol modifications. Section 2 of this document defines the concept of a signed zone and lists the requirements for zone signing. Section 3 describes the modifications to authoritative name server behavior necessary for handling signed zones. Section 4 describes the behavior of entities that include security-aware resolver functions. Finally, Section 5 defines how to use DNSSEC RRs to authenticate a response.
DNS安全扩展（DNSSEC）是新资源记录和协议修改的集合，这些记录和协议修改将数据源身份验证和数据完整性添加到DNS中。本文件定义了DNSSEC协议修改。本文件第2节定义了已签署区域的概念，并列出了区域签署的要求。第3节描述了处理签名区域所需的对权威名称服务器行为的修改。第4节描述了包含安全感知解析器函数的实体的行为。最后，第5节定义了如何使用DNSSEC RRs对响应进行身份验证。
This document is part of a family of documents defining DNSSEC that should be read together as a set.
本文档是定义DNSSEC的文档系列的一部分，这些文档应作为一个集合一起阅读。
[RFC4033] contains an introduction to DNSSEC and definitions 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]还包含由该文档集更新和淘汰的其他文档的列表。
[RFC4034] defines the DNSSEC resource records.
[RFC4034]定义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 protocol operations.
本文件定义了DNSSEC协议操作。
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 introduces the concept of signed zones. A signed zone includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) Delegation Signer (DS) records according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, respectively. A zone that does not include these records according to the rules in this section is an unsigned zone.
DNSSEC引入了有符号区域的概念。根据第2.1节、第2.2节、第2.3节和第2.4节分别规定的规则，签名区域包括DNS公钥（DNSKEY）、资源记录签名（RRSIG）、下一安全（NSEC）和（可选）委托签名者（DS）记录。根据本节中的规则，不包含这些记录的区域是未签名区域。
DNSSEC requires a change to the definition of the CNAME resource record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs to appear at the same owner name as does a CNAME RR.
DNSSEC要求更改CNAME资源记录（[RFC1035]）的定义。第2.5节更改了CNAME RR，以允许RRSIG和NSEC RRs以与CNAME RR相同的所有者名称出现。
DNSSEC specifies the placement of two new RR types, NSEC and DS, which can be placed at the parental side of a zone cut (that is, at a delegation point). This is an exception to the general prohibition against putting data in the parent zone at a zone cut. Section 2.6 describes this change.
DNSSEC指定两种新RR类型NSEC和DS的放置，它们可以放置在分区切割的父侧（即，在委派点）。这是一般禁止在分区切割时将数据放入父分区的例外情况。第2.6节描述了这一变化。
To sign a zone, the zone's administrator generates one or more public/private key pairs and uses the private key(s) to sign authoritative RRsets in the zone. For each private key used to create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR containing the corresponding public key. A zone key DNSKEY RR MUST have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 of [RFC4034]). Public keys associated with other DNS operations MAY be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT be used to verify RRSIGs.
要对区域进行签名，区域管理员将生成一个或多个公钥/私钥对，并使用私钥对区域中的权威RRSET进行签名。对于用于在区域中创建RRSIG RRs的每个私钥，该区域应包括包含相应公钥的区域DNSKEY RR。区域密钥DNSKEY RR必须设置标志RDATA字段的区域密钥位（见[RFC4034]第2.1.1节）。与其他DNS操作相关联的公钥可存储在DNSKEY RRs中，该RRs未标记为区域密钥，但不得用于验证RRSIG。
If the zone administrator intends a signed zone to be usable other than as an island of security, the zone apex MUST contain at least one DNSKEY RR to act as a secure entry point into the zone. This secure entry point could then be used as the target of a secure delegation via a corresponding DS RR in the parent zone (see [RFC4034]).
如果区域管理员打算将签名区域用作安全岛以外的其他用途，则区域顶点必须至少包含一个DNSKEY RR，以作为区域的安全入口点。然后，该安全入口点可以通过父区域中相应的DS RR用作安全委派的目标（请参见[RFC4034]）。
For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record that meets the following requirements:
对于签名区域中的每个权威RRset，必须至少有一条RRSIG记录满足以下要求：
o The RRSIG owner name is equal to the RRset owner name.
o RRSIG所有者名称等于RRset所有者名称。
o The RRSIG class is equal to the RRset class.
o RRSIG类等于RRset类。
o The RRSIG Type Covered field is equal to the RRset type.
o RRSIG类型覆盖字段等于RRset类型。
o The RRSIG Original TTL field is equal to the TTL of the RRset.
o RRSIG原始TTL字段等于RRset的TTL。
o The RRSIG RR's TTL is equal to the TTL of the RRset.
o RRSIG RR的TTL等于RRset的TTL。
o The RRSIG Labels field is equal to the number of labels in the RRset owner name, not counting the null root label and not counting the leftmost label if it is a wildcard.
o RRSIG标签字段等于RRset所有者名称中的标签数，不计算空根标签，如果是通配符，则不计算最左边的标签。
o The RRSIG Signer's Name field is equal to the name of the zone containing the RRset.
o RRSIG签名者的名称字段等于包含RRset的区域的名称。
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a zone key DNSKEY record at the zone apex.
o RRSIG算法、签名者姓名和密钥标记字段标识区域顶点处的区域密钥DNSKEY记录。
The process for constructing the RRSIG RR for a given RRset is described in [RFC4034]. An RRset MAY have multiple RRSIG RRs associated with it. Note that as RRSIG RRs are closely tied to the RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
[RFC4034]中描述了为给定RRset构造RRSIG RR的过程。一个RRset可能有多个与之关联的RRSIG RRs。请注意，与所有其他DNS不同，由于RRSIG RRs与包含其签名的RRSET密切相关，因此RRSIG RRs
RR types, do not form RRsets. In particular, the TTL values among RRSIG RRs with a common owner name do not follow the RRset rules described in [RFC2181].
RR类型，不构成RRSET。特别是，具有公共所有者名称的RRSIG RRs中的TTL值不遵循[RFC2181]中描述的RRset规则。
An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would add no value and would create an infinite loop in the signing process.
不能对RRSIG RR本身进行签名，因为对RRSIG RR进行签名不会增加任何值，并且会在签名过程中创建无限循环。
The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed.
出现在区域顶点名称处的NS RRset必须签名，但出现在委派点处的NS RRset（即父区域中将名称委派给子区域的名称服务器的NS RRset）不得签名。与委派关联的粘合地址集不得签名。
There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).
在区域顶点DNSKEY RRset中，每个RRset必须使用每个算法的至少一个DNSKEY具有RRSIG。apex DNSKEY RRset本身必须由位于委派父级（如果有）的DS RRset中出现的每个算法签名。
Each owner name in the zone that has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. The format of NSEC RRs and the process for constructing the NSEC RR for a given name is described in [RFC4034].
区域中具有权威数据或委派点NS RRset的每个所有者名称必须具有NSEC资源记录。[RFC4034]中描述了NSEC RR的格式以及为给定名称构建NSEC RR的过程。
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
任何NSEC RR的TTL值应与区域SOA RR中的最小TTL值字段相同。
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce the risk of response inconsistency in security oblivious recursive name servers.
NSEC记录（及其关联的RRSIG RRset）不得是任何特定所有者名称的唯一RRset。也就是说，签名过程不得为所有者名称节点创建NSEC或RRSIG RRs，这些节点在区域签名之前不是任何RRset的所有者名称。这样做的主要原因是希望同一区域的已签名和未签名版本之间的命名空间一致性，以及希望降低不关心安全性的递归名称服务器中响应不一致的风险。
The type bitmap of every NSEC resource record in a signed zone MUST indicate the presence of both the NSEC record itself and its corresponding RRSIG record.
签名区域中每个NSEC资源记录的类型位图必须指示NSEC记录本身及其相应RRSIG记录的存在。
The difference between the set of owner names that require RRSIG records and the set of owner names that require NSEC records is subtle and worth highlighting. RRSIG records are present at the owner names of all authoritative RRsets. NSEC records are present at the owner names of all names for which the signed zone is authoritative and also at the owner names of delegations from the
需要RRSIG记录的所有者名称集和需要NSEC记录的所有者名称集之间的差异是微妙的，值得强调。RRSIG记录存在于所有权威RRSET的所有者名称中。NSEC记录存在于签署区域具有权威性的所有名称的所有者名称处，以及来自
signed zone to its children. Neither NSEC nor RRSIG records are present (in the parent zone) at the owner names of glue address RRsets. Note, however, that this distinction is for the most part visible only during the zone signing process, as NSEC RRsets are authoritative data and are therefore signed. Thus, any owner name that has an NSEC RRset will have RRSIG RRs as well in the signed zone.
为其子项创建了签名区域。粘合地址RRSET的所有者名称中不存在NSEC或RRSIG记录（在父区域中）。但是，请注意，这种区别大部分仅在区域签名过程中可见，因为NSEC RRSET是权威数据，因此是经过签名的。因此，具有NSEC RRset的任何所有者名称在签名区域中也将具有RRSIG RRs。
The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and any RRsets 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和父区域具有权威数据的任何RRset相对应的位；与父级未授权的任何非NS RRset相对应的位必须清除。
The DS resource record establishes authentication chains between DNS zones. A DS RRset SHOULD be present at a delegation point when the child zone is signed. The DS RRset MAY contain multiple records, each referencing a public key in the child zone used to verify the RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS RRsets MUST NOT appear at a zone's apex.
DS资源记录在DNS区域之间建立身份验证链。签名子区域时，DS RRset应出现在委派点。DS RRset可能包含多个记录，每个记录引用子区域中用于验证该区域中RRSIG的公钥。区域中的所有DS RRSET必须签名，并且DS RRSET不得出现在区域的顶点。
A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key. DS RRs that fail to meet these conditions are not useful for validation, but because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur.
DS RR应指向子级的apex DNSKEY RRset中存在的DNSKEY RR，子级的apex DNSKEY RRset应由相应的私钥签名。无法满足这些条件的DS RR对验证无效，但由于DS RR及其对应的DNSKEY RR位于不同的区域，并且由于DNS只是松散一致的，因此可能会发生临时不匹配。
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset).
DS RRset的TTL应与授权NS RRset的TTL相匹配（即，来自包含DS RRset的同一区域的NS RRset）。
Construction of a DS RR requires knowledge of the corresponding DNSKEY RR in the child zone, which implies communication between the child and parent zones. This communication is an operational matter not covered by this document.
构建DS RR需要了解子区域中相应的DNSKEY RR，这意味着子区域和父区域之间的通信。此通信是本文件未涵盖的操作事项。
If a CNAME RRset is present at a name in a signed zone, appropriate RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that name for secure dynamic update purposes is also allowed ([RFC3007]). Other types MUST NOT be present at that name.
如果签名区域中的某个名称处存在CNAME RRset，则该名称处需要相应的RRSIG和NSEC RRset。出于安全动态更新目的，还允许在该名称处设置密钥RRset（[RFC3007]）。该名称处不得存在其他类型。
This is a modification to the original CNAME definition given in [RFC1034]. The original definition of the CNAME RR did not allow any other types to coexist with a CNAME record, but a signed zone
这是对[RFC1034]中给出的原始CNAME定义的修改。CNAME RR的原始定义不允许任何其他类型与CNAME记录共存，而是允许签名区域
requires NSEC and RRSIG RRs for every authoritative name. To resolve this conflict, this specification modifies the definition of the CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
每个权威名称都需要NSEC和RRSIG RRs。为了解决此冲突，本规范修改了CNAME资源记录的定义，以允许它与NSEC和RRSIG RRs共存。
DNSSEC introduced two new RR types that are unusual in that they can appear at the parental side of a zone cut. At the parental side of a zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at the owner name. A DS RR could also be present if the zone being delegated is signed and seeks to have a chain of authentication to the parent zone. This is an exception to the original DNS specification ([RFC1034]), which states that only NS RRsets could appear at the parental side of a zone cut.
DNSSEC引入了两种新的RR类型，这两种类型不同寻常，因为它们可以出现在分区切割的母侧。在分区切割的母端（即在委派点），所有者名称处需要NSEC RRs。如果要委派的区域已签名，并且试图拥有到父区域的身份验证链，则也可能存在DS RR。这是原始DNS规范（[RFC1034]）的一个例外，该规范规定只有NS RRSET可以出现在分区切割的父端。
This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut.
此规范更新了原始DNS规范，以允许在分区切割的父端使用NSEC和DS RR类型。当这些RRSET出现在分区切割的父侧时，它们对父对象具有权威性。
Appendix A shows a complete example of a small signed zone.
附录A显示了一个完整的小签名区域示例。
This section describes the behavior of entities that include security-aware name server functions. In many cases such functions will be part of a security-aware recursive name server, but a security-aware authoritative name server has some of the same requirements. Functions specific to security-aware recursive name servers are described in Section 3.2; functions specific to authoritative servers are described in Section 3.1.
本节描述包含安全感知名称服务器功能的实体的行为。在许多情况下，这些函数将是安全感知递归名称服务器的一部分，但安全感知权威名称服务器具有一些相同的要求。第3.2节描述了特定于安全感知递归名称服务器的功能；第3.1节描述了权威服务器的特定功能。
In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" are as used in [RFC1034].
在以下讨论中，[RFC1034]中使用了术语“SNAME”、“SCLASS”和“STYPE”。
A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets. As IPv6 packets can only be fragmented by the source host, a security aware name server SHOULD take steps to ensure that UDP datagrams it transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], and [RFC3226] for further discussion of packet size and fragmentation issues.
安全感知名称服务器必须支持EDNS0（[RFC2671]）消息大小扩展，必须支持至少1220个八位字节的消息大小，并且应该支持4000个八位字节的消息大小。由于IPv6数据包只能由源主机进行分段，因此具有安全意识的名称服务器应采取措施确保其通过IPv6传输的UDP数据报在必要时以最小IPv6 MTU进行分段，除非路径MTU已知。请参阅[RFC1122]、[RFC2460]和[RFC3226]了解关于数据包大小和碎片问题的进一步讨论。
A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below. Because the DS RR type has the peculiar property of only existing in the parent zone at delegation points, DS RRs always require some special processing, as described in Section 3.1.4.1.
接收不包含EDNS OPT伪RR或DO位为clear的DNS查询的安全感知名称服务器必须将RRSIG、DNSKEY和NSEC RRs视为任何其他RRset，并且不得执行下述任何附加处理。由于DS RR类型具有仅存在于委托点的父区域中的特殊属性，因此DS RR始终需要一些特殊处理，如第3.1.4.1节所述。
Security aware name servers that receive explicit queries for security RR types that match the content of more than one zone that it serves (for example, NSEC and RRSIG RRs above and below a delegation point where the server is authoritative for both zones) should behave self-consistently. As long as the response is always consistent for each query to the name server, the name server MAY return one of the following:
安全感知名称服务器接收与它所服务的多个区域的内容相匹配的安全RR类型的显式查询（例如，NSEC和RRSIG RRs位于服务器对两个区域都具有权威的委托点之上和之下），其行为应自洽。只要对名称服务器的每个查询的响应始终一致，名称服务器可能会返回以下其中一个：
o The above-delegation RRsets. o The below-delegation RRsets. o Both above and below-delegation RRsets. o Empty answer section (no records). o Some other response. o An error.
o 上述代表团是两套。o以下代表团成员。o高于和低于授权集。o空回答部分（无记录）。o其他一些回应。o一个错误。
DNSSEC allocates two new bits in the DNS message header: the CD (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit is controlled by resolvers; a security-aware name server MUST copy the CD bit from a query into the corresponding response. The AD bit is controlled by name servers; a security-aware name server MUST ignore the setting of the AD bit in queries. See Sections 3.1.6, 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
DNSSEC在DNS消息头中分配两个新位：CD（检查禁用）位和AD（真实数据）位。CD位由解析器控制；具有安全意识的名称服务器必须将CD位从查询复制到相应的响应中。AD位由名称服务器控制；具有安全意识的名称服务器必须忽略查询中的AD位设置。有关这些位行为的详细信息，请参见第3.1.6、3.2.2、3.2.3、4和4.9节。
A security aware name server that synthesizes CNAME RRs from DNAME RRs as described in [RFC2672] SHOULD NOT generate signatures for the synthesized CNAME RRs.
如[RFC2672]所述，从DNAME RRs合成CNAME RRs的安全感知名称服务器不应为合成的CNAME RRs生成签名。
Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name server for a signed zone MUST include additional RRSIG, NSEC, and DS RRs, according to the following rules:
根据以下规则，接收到设置了EDN（[RFC2671]）OPT pseudo RR DO位（[RFC3225]）的相关查询后，签名区域的安全感知权威名称服务器必须包括额外的RRSIG、NSEC和DS RRs：
o RRSIG RRs that can be used to authenticate a response MUST be included in the response according to the rules in Section 3.1.1.
o 根据第3.1.1节中的规则，可用于验证响应的RRSIG RRs必须包含在响应中。
o NSEC RRs that can be used to provide authenticated denial of existence MUST be included in the response automatically according to the rules in Section 3.1.3.
o 根据第3.1.3节中的规则，可用于提供认证拒绝存在的NSEC RRs必须自动包含在响应中。
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST be included in referrals automatically according to the rules in Section 3.1.4.
o 根据第3.1.4节的规则，证明不存在DS RRs的DS RRset或NSEC RR必须自动包括在转介中。
These rules only apply to responses where the semantics convey information about the presence or absence of resource records. That is, these rules are not intended to rule out responses such as RCODE 4 ("Not Implemented") or RCODE 5 ("Refused").
这些规则仅适用于语义传递有关是否存在资源记录的信息的响应。也就是说，这些规则并不打算排除响应，如RCODE 4（“未实现”）或RCODE 5（“拒绝”）。
DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 discusses zone transfer requirements.
DNSSEC不更改DNS区域传输协议。第3.1.5节讨论了区域转移要求。
When responding to a query that has the DO bit set, a security-aware authoritative name server SHOULD attempt to send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response. A name server SHOULD make every attempt to keep the RRset and its associated RRSIG(s) together in a response. Inclusion of RRSIG RRs in a response is subject to the following rules:
当响应设置了DO位的查询时，安全感知权威名称服务器应尝试发送RRSIG RRs，安全感知解析器可使用该RRSIG RRs对响应中的RRSET进行身份验证。名称服务器应尽一切努力将RRset及其关联的RRSIG保持在一个响应中。响应中包含RRSIG RRs应遵守以下规则：
o When placing a signed RRset in the Answer section, the name server MUST also place its RRSIG RRs in the Answer section. The RRSIG RRs have a higher priority for inclusion than any other RRsets that may have to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o 在应答部分中放置签名RRset时，名称服务器还必须在应答部分中放置其RRSIG RRs。RRSIG RRs的包含优先级高于可能必须包含的任何其他RRs集。如果空间不允许包含这些RRSIG RRs，则名称服务器必须设置TC位。
o When placing a signed RRset in the Authority section, the name server MUST also place its RRSIG RRs in the Authority section. The RRSIG RRs have a higher priority for inclusion than any other RRsets that may have to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o 当在授权部分中放置签名RRset时，名称服务器还必须在授权部分中放置其RRSIG RRs。RRSIG RRs的包含优先级高于可能必须包含的任何其他RRs集。如果空间不允许包含这些RRSIG RRs，则名称服务器必须设置TC位。
o When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section. If space does not permit inclusion of both the RRset and its associated RRSIG RRs, the name server MAY retain the RRset while dropping the RRSIG RRs. If this happens, the name server MUST NOT set the TC bit solely because these RRSIG RRs didn't fit.
o 在附加节中放置签名的RRset时，名称服务器还必须在附加节中放置其RRSIG RRs。如果空间不允许同时包含RRset及其关联的RRSIG RRs，则名称服务器可以在删除RRSIG RRs的同时保留RRset。如果发生这种情况，名称服务器不能仅因为这些RRSIG RRs不适合而设置TC位。
When responding to a query that has the DO bit set and that requests the SOA or NS RRs at the apex of a signed zone, a security-aware authoritative name server for that zone MAY return the zone apex DNSKEY RRset in the Additional section. In this situation, the DNSKEY RRset and associated RRSIG RRs have lower priority than does any other information that would be placed in the additional section. The name server SHOULD NOT include the DNSKEY RRset unless there is enough space in the response message for both the DNSKEY RRset and its associated RRSIG RR(s). If there is not enough space to include these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST NOT set the TC bit solely because these RRs didn't fit (see Section 3.1.1).
当响应设置了DO位并请求签名区域顶点处的SOA或NS RRs的查询时，该区域的安全感知权威名称服务器可能会在附加部分中返回区域顶点DNSKEY RRset。在这种情况下，DNSKEY RRset和相关RRSIG RRs的优先级低于其他任何将放在附加部分中的信息。名称服务器不应包括DNSKEY RRset，除非响应消息中有足够的空间容纳DNSKEY RRset及其关联的RRSIG RR。如果没有足够的空间包含这些DNSKEY和RRSIG RRs，则名称服务器必须忽略它们，并且不得仅因为这些RRs不适合而设置TC位（参见第3.1.1节）。
When responding to a query that has the DO bit set, a security-aware authoritative name server for a signed zone MUST include NSEC RRs in each of the following cases:
在响应设置了DO位的查询时，签名区域的安全感知权威名称服务器在以下情况下必须包括NSEC RRs：
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> but does not contain any RRsets that exactly match <SNAME, SCLASS, STYPE>.
无数据：区域包含完全匹配<SNAME，SCLASS>的RRSET，但不包含完全匹配<SNAME，SCLASS，STYPE>的任何RRSET。
Name Error: The zone does not contain any RRsets that match <SNAME, SCLASS> either exactly or via wildcard name expansion.
名称错误：区域不包含完全匹配或通过通配符名称扩展匹配<SNAME，SCLASS>的任何RRSET。
Wildcard Answer: The zone does not contain any RRsets that exactly match <SNAME, SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> via wildcard name expansion.
通配符回答：区域不包含任何与<SNAME，SCLASS>完全匹配的RRset，但包含通过通配符名称扩展与<SNAME，SCLASS，STYPE>匹配的RRset。
Wildcard No Data: The zone does not contain any RRsets that exactly match <SNAME, SCLASS> and does contain one or more RRsets that match <SNAME, SCLASS> via wildcard name expansion, but does not contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name expansion.
通配符无数据：区域不包含任何完全匹配<SNAME，SCLASS>的RRSET，并且包含一个或多个通过通配符名称扩展匹配<SNAME，SCLASS>的RRSET，但不包含通过通配符名称扩展匹配<SNAME，SCLASS，STYPE>的RRSET。
In each of these cases, the name server includes NSEC RRs in the response to prove that an exact match for <SNAME, SCLASS, STYPE> was not present in the zone and that the response that the name server is returning is correct given the data in the zone.
在上述每种情况下，名称服务器在响应中包括NSEC RRs，以证明<SNAME，SCLASS，STYPE>的精确匹配在区域中不存在，并且名称服务器返回的响应在给定区域中数据的情况下是正确的。
If the zone contains RRsets matching <SNAME, SCLASS> but contains no RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST include the NSEC RR for <SNAME, SCLASS> along with its associated RRSIG RR(s) in the Authority section of the response (see Section 3.1.1). If space does not permit inclusion of the NSEC RR or its associated RRSIG RR(s), the name server MUST set the TC bit (see Section 3.1.1).
如果区域包含与<SNAME，SCLASS>匹配的RRset，但不包含与<SNAME，SCLASS，STYPE>匹配的RRset，则名称服务器必须将<SNAME，SCLASS>的NSEC RR及其相关RRSIG RR包含在响应的权限部分中（参见第3.1.1节）。如果空间不允许包含NSEC RR或其相关RRSIG RR，则名称服务器必须设置TC位（见第3.1.1节）。
Since the search name exists, wildcard name expansion does not apply to this query, and a single signed NSEC RR suffices to prove that the requested RR type does not exist.
由于搜索名称存在，因此通配符名称扩展不适用于此查询，并且单签名NSEC RR足以证明请求的RR类型不存在。
If the zone does not contain any RRsets matching <SNAME, SCLASS> either exactly or via wildcard name expansion, then the name server MUST include the following NSEC RRs in the Authority section, along with their associated RRSIG RRs:
如果区域不包含完全匹配或通过通配符名称扩展匹配<SNAME，SCLASS>的任何RRs集，则名称服务器必须在权限部分中包括以下NSEC RRs及其关联的RRSIG RRs：
o An NSEC RR proving that there is no exact match for <SNAME, SCLASS>.
o 证明<SNAME，SCLASS>没有精确匹配的NSEC RR。
o An NSEC RR proving that the zone contains no RRsets that would match <SNAME, SCLASS> via wildcard name expansion.
o NSEC RR，证明区域不包含通过通配符名称扩展匹配<SNAME，SCLASS>的RRSET。
In some cases, a single NSEC RR may prove both of these points. If it does, the name server SHOULD only include the NSEC RR and its RRSIG RR(s) once in the Authority section.
在某些情况下，一个NSEC RR可以证明这两个点。如果是，名称服务器应该只在授权部分包含一次NSEC RR及其RRSIG RR。
If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
如果空间不允许包含这些NSEC和RRSIG RRs，则名称服务器必须设置TC位（见第3.1.1节）。
The owner names of these NSEC and RRSIG RRs are not subject to wildcard name expansion when these RRs are included in the Authority section of the response.
当这些RRs包含在响应的权限部分时，这些NSEC和RRSIG RRs的所有者名称不受通配符名称扩展的约束。
Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets).
请注意，这种形式的响应包括SNAME对应于区域内的空非终端名称（该名称不是任何RRset的所有者名称，而是一个或多个RRset的父名称）的情况。
If the zone does not contain any RRsets that exactly match <SNAME, SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> via wildcard name expansion, the name server MUST include the
如果区域不包含任何完全匹配<SNAME，SCLASS>的RRset，但包含通过通配符名称扩展匹配<SNAME，SCLASS，STYPE>的RRset，则名称服务器必须包含
wildcard-expanded answer and the corresponding wildcard-expanded RRSIG RRs in the Answer section and MUST include in the Authority section an NSEC RR and associated RRSIG RR(s) proving that the zone does not contain a closer match for <SNAME, SCLASS>. If space does not permit inclusion of the answer, NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
通配符扩展应答和应答部分中相应的通配符扩展RRSIG RRs，并且必须在授权部分中包含NSEC RR和相关RRSIG RR，以证明分区不包含与<SNAME，SCLASS>更接近的匹配项。如果空格不允许包含应答、NSEC和RRSIG RRs，则名称服务器必须设置TC位（见第3.1.1节）。
This case is a combination of the previous cases. The zone does not contain an exact match for <SNAME, SCLASS>, and although the zone does contain RRsets that match <SNAME, SCLASS> via wildcard expansion, none of those RRsets matches STYPE. The name server MUST include the following NSEC RRs in the Authority section, along with their associated RRSIG RRs:
本案例是之前案例的组合。该区域不包含与<SNAME，SCLASS>完全匹配的内容，尽管该区域确实包含通过通配符扩展与<SNAME，SCLASS>匹配的RRSET，但这些RRSET中没有一个与STYPE匹配。名称服务器必须在授权部分包括以下NSEC RRs及其相关RRSIG RRs：
o An NSEC RR proving that there are no RRsets matching STYPE at the wildcard owner name that matched <SNAME, SCLASS> via wildcard expansion.
o NSEC RR，证明在通过通配符扩展匹配<SNAME，SCLASS>的通配符所有者名称中没有与STYPE匹配的RRSET。
o An NSEC RR proving that there are no RRsets in the zone that would have been a closer match for <SNAME, SCLASS>.
o NSEC RR证明该区域中没有RRSET与<SNAME，SCLASS>更接近。
In some cases, a single NSEC RR may prove both of these points. If it does, the name server SHOULD only include the NSEC RR and its RRSIG RR(s) once in the Authority section.
在某些情况下，一个NSEC RR可以证明这两个点。如果是，名称服务器应该只在授权部分包含一次NSEC RR及其RRSIG RR。
The owner names of these NSEC and RRSIG RRs are not subject to wildcard name expansion when these RRs are included in the Authority section of the response.
当这些RRs包含在响应的权限部分时，这些NSEC和RRSIG RRs的所有者名称不受通配符名称扩展的约束。
If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
如果空间不允许包含这些NSEC和RRSIG RRs，则名称服务器必须设置TC位（见第3.1.1节）。
As explained above, there are several situations in which a security-aware authoritative name server has to locate an NSEC RR that proves that no RRsets matching a particular SNAME exist. Locating such an NSEC RR within an authoritative zone is relatively simple, at least in concept. The following discussion assumes that the name server is authoritative for the zone that would have held the non-existent RRsets matching SNAME. The algorithm below is written for clarity, not for efficiency.
如上所述，有几种情况下，具有安全意识的权威名称服务器必须定位NSEC RR，以证明不存在与特定SNAME匹配的RRSET。至少在概念上，将这样一个NSEC RR定位在一个权威区域内是相对简单的。下面的讨论假设名称服务器对可能包含不存在的与SNAME匹配的RRSET的区域具有权威性。下面的算法是为了清晰，而不是为了效率。
To find the NSEC that proves that no RRsets matching name N exist in the zone Z that would have held them, construct a sequence, S, consisting of the owner names of every RRset in Z, sorted into
要找到证明在区域Z中不存在与名称N匹配的RRset的NSEC（该区域本来可以容纳它们），请构造一个序列S，由Z中每个RRset的所有者名称组成，排序为
canonical order ([RFC4034]), with no duplicate names. Find the name M that would have immediately preceded N in S if any RRsets with owner name N had existed. M is the owner name of the NSEC RR that proves that no RRsets exist with owner name N.
规范顺序（[RFC4034]），没有重复的名称。如果存在所有者名称为N的RRSET，则查找在S中紧跟在N之前的名称M。M是NSEC RR的所有者名称，证明不存在所有者名称为N的RRSET。
The algorithm for finding the NSEC RR that proves that a given name is not covered by any applicable wildcard is similar but requires an extra step. More precisely, the algorithm for finding the NSEC proving that no RRsets exist with the applicable wildcard name is precisely the same as the algorithm for finding the NSEC RR that proves that RRsets with any other owner name do not exist. The part that's missing is a method of determining the name of the non-existent applicable wildcard. In practice, this is easy, because the authoritative name server has already checked for the presence of precisely this wildcard name as part of step (1)(c) of the normal lookup algorithm described in Section 4.3.2 of [RFC1034].
用于查找NSEC RR（证明给定名称不包含在任何适用通配符中）的算法类似，但需要额外的步骤。更准确地说，用于查找NSEC（证明不存在具有适用通配符名称的RRSET）的算法与用于查找NSEC RR（证明不存在具有任何其他所有者名称的RRSET）的算法完全相同。缺少的部分是确定不存在的适用通配符名称的方法。实际上，这很容易，因为作为[RFC1034]第4.3.2节所述正常查找算法步骤（1）（c）的一部分，权威名称服务器已经检查了是否存在该通配符名称。
When responding to a query that has the DO bit set, a security-aware authoritative name server returning a referral includes DNSSEC data along with the NS RRset.
当响应设置了DO位的查询时，返回引用的安全感知权威名称服务器包括DNSSEC数据和NS RRset。
If a DS RRset is present at the delegation point, the name server MUST return both the DS RRset and its associated RRSIG RR(s) in the Authority section along with the NS RRset.
如果DS RRset存在于委派点，则名称服务器必须在授权部分中连同NS RRset一起返回DS RRset及其关联的RRSIG RR。
If no DS RRset is present at the delegation point, the name server MUST return both the NSEC RR that proves that the DS RRset is not present and the NSEC RR's associated RRSIG RR(s) along with the NS RRset. The name server MUST place the NS RRset before the NSEC RRset and its associated RRSIG RR(s).
如果委派点不存在DS RRset，则名称服务器必须返回证明DS RRset不存在的NSEC RR和NSEC RR的关联RRSIG RR以及NS RRset。名称服务器必须将NS RRset置于NSEC RRset及其关联RRSIG RR之前。
Including these DS, NSEC, and RRSIG RRs increases the size of referral messages and may cause some or all glue RRs to be omitted. If space does not permit inclusion of the DS or NSEC RRset and associated RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
包括这些DS、NSEC和RRSIG RRs会增加转介消息的大小，并可能导致省略部分或全部粘合RRs。如果空间不允许包含DS或NSEC RRset和相关RRSIG RRs，则名称服务器必须设置TC位（见第3.1.1节）。
The DS resource record type is unusual in that it appears only on the parent zone's side of a zone cut. For example, the DS RRset for the delegation of "foo.example" is stored in the "example" zone rather than in the "foo.example" zone. This requires special processing rules for both name servers and resolvers, as the name server for the child zone is authoritative for the name at the zone cut by the normal DNS rules but the child zone does not contain the DS RRset.
DS资源记录类型不同寻常，因为它仅出现在分区切割的父分区一侧。例如，“foo.example”委托的DS RRset存储在“example”区域中，而不是“foo.example”区域中。这要求名称服务器和解析程序都有特殊的处理规则，因为子区域的名称服务器对被正常DNS规则切割的区域的名称具有权威性，但子区域不包含DS RRset。
A security-aware resolver sends queries to the parent zone when looking for a needed DS RR at a delegation point (see Section 4.2). However, special rules are necessary to avoid confusing security-oblivious resolvers which might become involved in processing such a query (for example, in a network configuration that forces a security-aware resolver to channel its queries through a security-oblivious recursive name server). The rest of this section describes how a security-aware name server processes DS queries in order to avoid this problem.
在委派点查找所需的DS RR时，具有安全意识的解析器会向父区域发送查询（请参见第4.2节）。但是，为了避免混淆可能涉及处理此类查询的安全无关解析程序（例如，在强制安全无关解析程序通过安全无关递归名称服务器传递其查询的网络配置中），需要使用特殊规则。本节的其余部分将介绍安全感知名称服务器如何处理DS查询以避免此问题。
The need for special processing by a security-aware name server only arises when all the following conditions are met:
只有在满足以下所有条件时，才需要由具有安全意识的名称服务器进行特殊处理：
o The name server has received a query for the DS RRset at a zone cut.
o 名称服务器已在区域切割处收到对DS RRset的查询。
o The name server is authoritative for the child zone.
o 名称服务器是子区域的权威服务器。
o The name server is not authoritative for the parent zone.
o 名称服务器不是父区域的权威服务器。
o The name server does not offer recursion.
o 名称服务器不提供递归。
In all other cases, the name server either has some way of obtaining the DS RRset or could not have been expected to have the DS RRset even by the pre-DNSSEC processing rules, so the name server can return either the DS RRset or an error response according to the normal processing rules.
在所有其他情况下，名称服务器可以通过某种方式获取DS RRset，或者即使按照DNSSEC之前的处理规则，名称服务器也不可能具有DS RRset，因此名称服务器可以根据正常处理规则返回DS RRset或错误响应。
If all the above conditions are met, however, the name server is authoritative for SNAME but cannot supply the requested RRset. In this case, the name server MUST return an authoritative "no data" response showing that the DS RRset does not exist in the child zone's apex. See Appendix B.8 for an example of such a response.
但是，如果满足上述所有条件，名称服务器对SNAME具有权威性，但无法提供请求的RRset。在这种情况下，名称服务器必须返回权威的“无数据”响应，表明DS RRset不存在于子区域的顶点中。有关此类响应的示例，请参见附录B.8。
DNSSEC does not change the DNS zone transfer process. A signed zone will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these records have no special meaning with respect to a zone transfer operation.
DNSSEC不会更改DNS区域传输过程。签名区域将包含RRSIG、DNSKEY、NSEC和DS资源记录，但这些记录对于区域传输操作没有特殊意义。
An authoritative name server is not required to verify that a zone is properly signed before sending or accepting a zone transfer. However, an authoritative name server MAY choose to reject the entire zone transfer if the zone fails to meet any of the signing requirements described in Section 2. The primary objective of a zone transfer is to ensure that all authoritative name servers have identical copies of the zone. An authoritative name server that
在发送或接受区域传输之前，不需要权威名称服务器来验证区域是否已正确签名。但是，如果区域未能满足第2节中描述的任何签名要求，则权威名称服务器可以选择拒绝整个区域传输。区域传输的主要目标是确保所有权威名称服务器具有相同的区域副本。一个权威的名称服务器
chooses to perform its own zone validation MUST NOT selectively reject some RRs and accept others.
选择执行自己的区域验证时，不得有选择地拒绝某些RRs并接受其他RRs。
DS RRsets appear only on the parental side of a zone cut and are authoritative data in the parent zone. As with any other authoritative RRset, the DS RRset MUST be included in zone transfers of the zone in which the RRset is authoritative data. In the case of the DS RRset, this is the parent zone.
DS RRSET仅出现在分区切割的父侧，是父分区中的权威数据。与任何其他权威RRset一样，DS RRset必须包含在RRset为权威数据的区域的区域传输中。对于DS RRset，这是父区域。
NSEC RRs appear in both the parent and child zones at a zone cut and are authoritative data in both the parent and child zones. The parental and child NSEC RRs at a zone cut are never identical to each other, as the NSEC RR in the child zone's apex will always indicate the presence of the child zone's SOA RR whereas the parental NSEC RR at the zone cut will never indicate the presence of an SOA RR. As with any other authoritative RRs, NSEC RRs MUST be included in zone transfers of the zone in which they are authoritative data. The parental NSEC RR at a zone cut MUST be included in zone transfers of the parent zone, and the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone.
NSEC RRs在分区切割时同时出现在父分区和子分区中，并且是父分区和子分区中的权威数据。分区切割处的父NSEC RR和子NSEC RR永远不会相同，因为子分区顶点中的NSEC RR始终表示存在子分区的SOA RR，而分区切割处的父NSEC RR永远不会表示存在SOA RR。与任何其他权威RRs一样，NSEC RRs必须包含在作为权威数据的区域的区域传输中。分区切割处的父NSEC RR必须包含在父分区的分区传输中，子分区顶点处的NSEC必须包含在子分区的分区传输中。
RRSIG RRs appear in both the parent and child zones at a zone cut and are authoritative in whichever zone contains the authoritative RRset for which the RRSIG RR provides the signature. That is, the RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be authoritative in the parent zone, and the RRSIG for any RRset in the child zone's apex will be authoritative in the child zone. Parental and child RRSIG RRs at a zone cut will never be identical to each other, as the Signer's Name field of an RRSIG RR in the child zone's apex will indicate a DNSKEY RR in the child zone's apex whereas the same field of a parental RRSIG RR at the zone cut will indicate a DNSKEY RR in the parent zone's apex. As with any other authoritative RRs, RRSIG RRs MUST be included in zone transfers of the zone in which they are authoritative data.
RRSIG RRs在分区切割时同时出现在父分区和子分区中，并且在包含RRSIG RR提供签名的权威RRset的任何分区中都具有权威性。也就是说，分区切割处DS RRset或父NSEC RR的RRSIG RR将在父分区中具有权威性，而子分区顶点中任何RRset的RRSIG将在子分区中具有权威性。分区切割处的父RRSIG RR和子RRSIG RR永远不会彼此相同，因为子分区顶点中RRSIG RR的签名者姓名字段将指示子分区顶点中的DNSKEY RR，而分区切割处的父RRSIG RR的相同字段将指示父分区顶点中的DNSKEY RR。与任何其他权威RRs一样，RRSIG RRs必须包含在作为权威数据的区域的区域传输中。
The CD and AD bits are designed for use in communication between security-aware resolvers and security-aware recursive name servers. These bits are for the most part not relevant to query processing by security-aware authoritative name servers.
CD和AD位设计用于安全感知解析器和安全感知递归名称服务器之间的通信。这些位在很大程度上与安全感知权威名称服务器的查询处理无关。
A security-aware name server does not perform signature validation for authoritative data during query processing, even when the CD bit is clear. A security-aware name server SHOULD clear the CD bit when composing an authoritative response.
具有安全意识的名称服务器在查询处理期间不会对权威数据执行签名验证，即使CD位已清除。具有安全意识的名称服务器在编写权威响应时应清除CD位。
A security-aware name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. A security-aware name server's local policy MAY consider data from an authoritative zone to be authentic without further validation. However, the name server MUST NOT do so unless the name server obtained the authoritative zone via secure means (such as a secure zone transfer mechanism) and MUST NOT do so unless this behavior has been configured explicitly.
具有安全意识的名称服务器不得在响应中设置AD位，除非名称服务器认为响应的应答和授权部分中的所有RRSET都是可信的。安全感知名称服务器的本地策略可以考虑来自权威区域的数据在没有进一步验证的情况下是可信的。但是，除非名称服务器通过安全手段（如安全区域传输机制）获得了权威区域，否则名称服务器不得这样做，并且除非已明确配置此行为，否则不得这样做。
A security-aware name server that supports recursion MUST follow the rules for the CD and AD bits given in Section 3.2 when generating a response that involves data obtained via recursion.
支持递归的安全感知名称服务器在生成涉及通过递归获得的数据的响应时，必须遵循第3.2节中给出的CD和AD位规则。
As explained in [RFC4033], a security-aware recursive name server is an entity that acts in both the security-aware name server and security-aware resolver roles. This section uses the terms "name server side" and "resolver side" to refer to the code within a security-aware recursive name server that implements the security-aware name server role and the code that implements the security-aware resolver role, respectively.
如[RFC4033]中所述，安全感知递归名称服务器是一个实体，它同时扮演安全感知名称服务器和安全感知解析器角色。本节使用术语“名称服务器端”和“解析程序端”分别指实现安全感知名称服务器角色的安全感知递归名称服务器中的代码和实现安全感知解析程序角色的代码。
The resolver side follows the usual rules for caching and negative caching that would apply to any security-aware resolver.
冲突解决程序端遵循适用于任何具有安全意识的冲突解决程序的缓存和负缓存的常规规则。
The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested.
安全感知递归名称服务器的解析器端在发送请求时必须设置DO位，而不管名称服务器端收到的发起请求中DO位的状态如何。如果未设置发起查询中的DO位，则名称服务器端必须从响应中删除任何正在验证的DNSSEC RR，但不得删除发起查询明确请求的任何DNSSEC RR类型。
The CD bit exists in order to allow a security-aware resolver to disable signature validation in a security-aware name server's processing of a particular query.
CD位的存在是为了允许安全感知解析程序在安全感知名称服务器处理特定查询时禁用签名验证。
The name server side MUST copy the setting of the CD bit from a query to the corresponding response.
名称服务器端必须将CD位的设置从查询复制到相应的响应。
The name server side of a security-aware recursive name server MUST pass the state of the CD bit to the resolver side along with the rest
具有安全意识的递归名称服务器的名称服务器端必须将CD位的状态与其余部分一起传递给解析器端
of an initiating query, so that the resolver side will know whether it is required to verify the response data it returns to the name server side. If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, and the recursive name server should not interfere.
，以便解析器端知道是否需要验证返回给名称服务器端的响应数据。如果设置了CD位，则表示原始解析程序愿意执行其本地策略要求的任何身份验证。因此，递归名称服务器的解析器端不需要对响应中的RRSET执行身份验证。设置CD位时，如果可能，递归名称服务器应将请求的数据返回到原始解析程序，即使递归名称服务器的本地身份验证策略将拒绝相关记录。也就是说，通过设置CD位，原始解析程序已指示它负责执行自己的身份验证，递归名称服务器不应进行干扰。
If the resolver side implements a BAD cache (see Section 4.7) and the name server side receives a query that matches an entry in the resolver side's BAD cache, the name server side's response depends on the state of the CD bit in the original query. If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure).
如果解析器端实现了一个坏缓存（参见第4.7节），并且名称服务器端接收到一个与解析器端坏缓存中的条目匹配的查询，则名称服务器端的响应取决于原始查询中CD位的状态。如果设置了CD位，名称服务器端应返回坏缓存中的数据；如果未设置CD位，名称服务器端必须返回RCODE 2（服务器故障）。
The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. Several of the possible reasons why signature validation might fail involve conditions that may not apply equally to the recursive name server and the client that invoked it. For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security that the recursive name server does not share. In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client.
上述规则的目的是向能够执行自己的签名验证检查的客户机提供原始数据，同时保护依赖于安全感知递归名称服务器的解析器端执行此类检查的客户机。签名验证可能失败的几个可能原因涉及的条件可能不适用于递归名称服务器和调用它的客户端。例如，递归名称服务器的时钟可能设置不正确，或者客户端可能知道递归名称服务器不共享的相关安全岛。在这种情况下，“保护”能够执行自己的签名验证的客户机，使其永远不会看到“坏”数据，对客户机没有帮助。
The name server side of a security-aware recursive name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. The name server side SHOULD set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic. The resolver side MUST follow the procedure described in Section 5 to determine whether the RRs in question are authentic. However, for backward compatibility, a recursive name server MAY set the AD bit when a response includes unsigned CNAME RRs if those CNAME
安全感知递归名称服务器的名称服务器端不得在响应中设置AD位，除非名称服务器认为响应的应答和授权部分中的所有RRSET都是可信的。当且仅当解析器端认为应答部分中的所有RRs和授权部分中的任何相关否定响应RRs都是可信的时，名称服务器端应设置AD位。分解器侧必须遵循第5节中描述的程序，以确定相关RRs是否真实。但是，为了向后兼容，递归名称服务器可以在响应包含未签名的CNAME RRs时设置AD位，如果这些CNAME RRs
RRs demonstrably could have been synthesized from an authentic DNAME RR that is also included in the response according to the synthesis rules described in [RFC2672].
根据[RFC2672]中所述的合成规则，RRs可以从响应中也包含的真实DNAME RR合成。
See Appendix B for example response packets.
有关响应包的示例，请参见附录B。
This section describes the behavior of entities that include security-aware resolver functions. In many cases such functions will be part of a security-aware recursive name server, but a stand-alone security-aware resolver has many of the same requirements. Functions specific to security-aware recursive name servers are described in Section 3.2.
本节描述包含安全感知解析器函数的实体的行为。在许多情况下，此类函数将是安全感知递归名称服务器的一部分，但独立的安全感知解析器具有许多相同的要求。第3.2节描述了特定于安全感知递归名称服务器的功能。
A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
在发送查询时，具有安全意识的冲突解决程序必须包含EDNS（[RFC2671]）OPT伪RR，并设置DO（[RFC3225]）位。
A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR to advertise the message size that it is willing to accept. A security-aware resolver's IP layer MUST handle fragmented UDP packets correctly regardless of whether any such fragmented packets were received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and [RFC3226] for discussion of these requirements.
安全感知解析程序必须支持至少1220个八位字节的消息大小，应支持4000个八位字节的消息大小，并且必须使用EDNS OPT伪RR中的“发件人的UDP有效负载大小”字段来公布其愿意接受的消息大小。具有安全意识的解析器的IP层必须正确处理分段UDP数据包，无论这些分段数据包是通过IPv4还是IPv6接收的。有关这些要求的讨论，请参见[RFC1122]、[RFC2460]和[RFC3226]。
A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response, except when:
具有安全意识的解析器必须支持第5节中描述的签名验证机制，并应将其应用于每个收到的响应，除非：
o the security-aware resolver is part of a security-aware recursive name server, and the response is the result of recursion on behalf of a query received with the CD bit set;
o 安全感知解析器是安全感知递归名称服务器的一部分，响应是代表使用CD位集接收的查询的递归结果；
o the response is the result of a query generated directly via some form of application interface that instructed the security-aware resolver not to perform validation for this query; or
o 响应是通过某种形式的应用程序接口直接生成的查询的结果，该应用程序接口指示安全感知解析器不对此查询执行验证；或
o validation for this query has been disabled by local policy.
o 本地策略已禁用此查询的验证。
A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names.
安全感知解析器对签名验证的支持必须包括对通配符所有者名称验证的支持。
Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries.
安全感知解析程序可在尝试执行验证时查询缺少的安全RRs；选择这样做的实现必须意识到，收到的答案可能不足以验证原始响应。例如，区域更新可能已更改（或删除）原始查询和后续查询之间的所需信息。
When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone.
当试图检索驻留在分区切割处父端的缺失NSEC RRs时，安全感知迭代模式解析器必须查询父分区（而不是子分区）的名称服务器。
When attempting to retrieve a missing DS, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. As explained in Section 3.1.4.1, security-aware name servers need to apply special processing rules to handle the DS RR, and in some situations the resolver may also need to apply special rules to locate the name servers for the parent zone if the resolver does not already have the parent's NS RRset. To locate the parent NS RRset, the resolver can start with the delegation name, strip off the leftmost label, and query for an NS RRset by that name. If no NS RRset is present at that name, the resolver then strips off the leftmost remaining label and retries the query for that name, repeating this process of walking up the tree until it either finds the NS RRset or runs out of labels.
当尝试检索缺少的DS时，具有安全意识的迭代模式解析器必须查询父区域而不是子区域的名称服务器。如第3.1.4.1节所述，具有安全意识的名称服务器需要应用特殊处理规则来处理DS RR，在某些情况下，如果解析程序尚未设置父区域的NS RRset，则解析程序可能还需要应用特殊规则来定位父区域的名称服务器。要定位父NS RRset，解析器可以从委派名称开始，去掉最左边的标签，然后按该名称查询NS RRset。如果该名称处不存在NS RRset，则解析程序会剥离最左边的剩余标签，并重试该名称的查询，重复向上遍历树的过程，直到找到NS RRset或用完标签。
A security-aware resolver MUST be able to determine whether it should expect a particular RRset to be signed. More precisely, a security-aware resolver must be able to distinguish between four cases:
具有安全意识的冲突解决程序必须能够确定是否应该对特定的RRset进行签名。更准确地说，具有安全意识的解析器必须能够区分四种情况：
Secure: An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed and is subject to signature validation, as described above.
安全：解析程序能够为其构建从受信任安全锚到RRset的签名DNSKEY和DS RRs链的RRset。在这种情况下，如上所述，RRset应该被签名并接受签名验证。
Insecure: An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature.
不安全：冲突解决程序知道它没有从任何可信起点到RRset的签名DNSKEY和DS RRs链的RRset。当目标RRset位于未签名区域或未签名区域的后代中时，可能会发生这种情况。在这种情况下，RRset可能会被签名，也可能不会被签名，但解析器将无法验证签名。
Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption.
伪造：一种RRset，解析程序认为它应该能够为其建立信任链，但由于签名由于某种原因无法验证，或者由于相关DNSSEC RRs指示应存在的数据缺失，它无法建立信任链。这种情况可能表示攻击，但也可能表示配置错误或某种形式的数据损坏。
Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.
不确定：由于解析程序无法获得必要的DNSSEC RRs，因此解析程序无法确定是否应对其进行签名的RRset。当安全感知解析器无法联系相关区域的安全感知名称服务器时，可能会发生这种情况。
A security-aware resolver MUST be capable of being configured with at least one trusted public key or DS RR and SHOULD be capable of being configured with multiple trusted public keys or DS RRs. Since a security-aware resolver will not be able to validate signatures without such a configured trust anchor, the resolver SHOULD have some reasonably robust mechanism for obtaining such keys when it boots; examples of such a mechanism would be some form of non-volatile storage (such as a disk drive) or some form of trusted local network configuration mechanism.
具有安全意识的冲突解决程序必须能够配置至少一个受信任的公钥或DS RR，并且应该能够配置多个受信任的公钥或DS RR。由于具有安全意识的冲突解决程序在没有这种配置的信任锚的情况下将无法验证签名，因此冲突解决程序应该具有一些合理的健壮机制，以便在启动时获得此类密钥；此类机制的示例包括某种形式的非易失性存储（如磁盘驱动器）或某种形式的可信本地网络配置机制。
Note that trust anchors also cover key material that is updated in a secure manner. This secure manner could be through physical media, a key exchange protocol, or some other out-of-band means.
请注意，信任锚还包括以安全方式更新的关键材料。这种安全方式可以通过物理介质、密钥交换协议或其他带外方式实现。
A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In most cases the appropriate cache index for the atomic entry will be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response form described in Section 3.1.3.2 the appropriate cache index will be the double <QNAME,QCLASS>.
具有安全意识的冲突解决程序应将每个响应缓存为包含整个答案的单个原子条目，包括命名的RRset和任何关联的DNSSEC RRs。当包含在其中的任何RRs过期时，解析程序应丢弃整个原子条目。在大多数情况下，原子项的适当缓存索引将是三元组<QNAME，QTYPE，QCLASS>，但在第3.1.3.2节中描述的响应表单等情况下，适当的缓存索引将是双元组<QNAME，QCLASS>。
The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update).
这些建议的原因是，在初始查询和缓存中的数据过期之间，权威数据可能已经更改（例如，通过动态更新）。
There are two situations for which this is relevant:
有两种情况与此相关：
1. By using the RRSIG record, it is possible to deduce that an answer was synthesized from a wildcard. A security-aware recursive name server could store this wildcard data and use it to generate positive responses to queries other than the name for which the original answer was first received.
1. 通过使用RRSIG记录，可以推断答案是由通配符合成的。具有安全意识的递归名称服务器可以存储此通配符数据，并使用它生成对查询的肯定响应，而不是第一次收到原始答案的名称。
2. NSEC RRs received to prove the non-existence of a name could be reused by a security-aware resolver to prove the non-existence of any name in the name range it spans.
2. 为证明某个名称不存在而收到的NSEC RRs可由具有安全意识的冲突解决程序重新使用，以证明其所跨越的名称范围内的任何名称都不存在。
In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace.
理论上，解析程序可以使用通配符或NSEC RRs（分别）生成肯定和否定响应，直到相关记录上的TTL或签名过期。然而，对于解析器来说，避免阻塞新的权威数据或自行合成新数据似乎是谨慎的。遵循此建议的解析器将具有更一致的命名空间视图。
A security-aware resolver MAY set a query's CD bit in order to indicate that the resolver takes responsibility for performing whatever authentication its local policy requires on the RRsets in the response. See Section 3.2 for the effect this bit has on the behavior of security-aware recursive name servers.
具有安全意识的冲突解决程序可以设置查询的CD位，以指示冲突解决程序负责对响应中的RRSET执行其本地策略要求的任何身份验证。有关此位对安全感知递归名称服务器行为的影响，请参见第3.2节。
A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message.
安全感知解析器在编写查询消息时必须清除AD位，以防止错误名称服务器盲目地将查询消息中不理解的头位复制到响应消息中。
A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel or the resolver was specifically configured to regard the message header bits without using a secure channel.
解析程序必须忽略响应中CD和AD位的含义，除非响应是通过使用安全通道获得的，或者解析程序专门配置为在不使用安全通道的情况下考虑消息头位。
While many validation errors will be transient, some are likely to be more persistent, such as those caused by administrative error (failure to re-sign a zone, clock skew, and so forth). Since requerying will not help in these cases, validating resolvers might generate a significant amount of unnecessary DNS traffic as a result of repeated queries for RRsets with persistent validation failures.
虽然许多验证错误是暂时的，但有些可能更持久，例如由管理错误（无法重新签名区域、时钟偏移等）引起的错误。由于在这些情况下，重新查询不会有帮助，因此验证解析程序可能会产生大量不必要的DNS流量，这是由于重复查询具有持续验证失败的RRSET造成的。
To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions.
为了防止这种不必要的DNS流量，安全感知解析程序可能会缓存带有无效签名的数据，但有一些限制。
Conceptually, caching such data is similar to negative caching ([RFC2308]), except that instead of caching a valid negative response, the resolver is caching the fact that a particular answer failed to validate. This document refers to a cache of data with invalid signatures as a "BAD cache".
从概念上讲，缓存此类数据类似于负面缓存（[RFC2308]），不同之处在于解析程序不是缓存有效的负面响应，而是缓存特定答案未能验证的事实。本文档将具有无效签名的数据缓存称为“坏缓存”。
Resolvers that implement a BAD cache MUST take steps to prevent the cache from being useful as a denial-of-service attack amplifier, particularly the following:
实现坏缓存的解析程序必须采取措施防止缓存用作拒绝服务攻击放大器，尤其是以下情况：
o Since RRsets that fail to validate do not have trustworthy TTLs, the implementation MUST assign a TTL. This TTL SHOULD be small, in order to mitigate the effect of caching the results of an attack.
o 由于无法验证的RRSET没有可靠的TTL，因此实现必须分配一个TTL。此TTL应较小，以减轻缓存攻击结果的影响。
o In order to prevent caching of a transient validation failure (which might be the result of an attack), resolvers SHOULD track queries that result in validation failures and SHOULD only answer from the BAD cache after the number of times that responses to queries for that particular <QNAME, QTYPE, QCLASS> have failed to validate exceeds a threshold value.
o 为了防止缓存暂时性验证失败（可能是攻击的结果），解析程序应跟踪导致验证失败的查询，并且只应在响应该特定<QNAME，QTYPE，QCLASS>验证失败，超过阈值。
Resolvers MUST NOT return RRsets from the BAD cache unless the resolver is not required to validate the signatures of the RRsets in question under the rules given in Section 4.2 of this document. See Section 3.2.2 for discussion of how the responses returned by a security-aware recursive name server interact with a BAD cache.
除非根据本文件第4.2节给出的规则，不要求冲突解决程序验证相关RRSET的签名，否则冲突解决程序不得从坏缓存返回RRSET。有关安全感知递归名称服务器返回的响应如何与坏缓存交互的讨论，请参见第3.2.2节。
A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs that could have been synthesized from the DNAME RR, as described in [RFC2672], at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so.
验证安全意识解析程序必须将有效的已签名DNAME RR的签名视为还包括可能已从DNAME RR合成的未签名CNAME RR，如[RFC2672]中所述，至少在一定程度上不会仅因为响应消息包含此类CNAME RR而拒绝响应消息。冲突解决程序可以将此类CNAME RRs保留在其缓存或其交回的答案中，但无需这样做。
A security-aware stub resolver MUST support the DNSSEC RR types, at least to the extent of not mishandling responses just because they contain DNSSEC RRs.
具有安全意识的存根解析器必须支持DNSSEC RR类型，至少在不会因为响应包含DNSSEC RR而错误处理响应的范围内。
A non-validating security-aware stub resolver MAY include the DNSSEC RRs returned by a security-aware recursive name server as part of the data that the stub resolver hands back to the application that invoked it, but is not required to do so. A non-validating stub resolver that seeks to do this will need to set the DO bit in order to receive DNSSEC RRs from the recursive name server.
非验证性安全感知存根解析器可能包括由安全感知递归名称服务器返回的DNSSEC RRs，作为存根解析器返回给调用它的应用程序的数据的一部分，但不需要这样做。寻求执行此操作的非验证存根解析器需要设置do位，以便从递归名称服务器接收DNSSEC RRs。
A validating security-aware stub resolver MUST set the DO bit, because otherwise it will not receive the DNSSEC RRs it needs to perform signature validation.
具有验证安全意识的存根解析器必须设置DO位，否则它将不会收到执行签名验证所需的DNSSEC RRs。
A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf.
非验证性安全感知存根解析程序在发送查询时不应设置CD位，除非应用层请求它。根据定义，非验证性存根解析程序依赖于安全感知递归名称服务器代表其执行验证。
A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy.
验证安全感知存根解析程序应设置CD位，因为否则，安全感知递归名称服务器将使用名称服务器的本地策略回答查询，这可能会阻止存根解析程序接收存根解析程序的本地策略可接受的数据。
A non-validating security-aware stub resolver MAY chose to examine the setting of the AD bit in response messages that it receives in order to determine whether the security-aware recursive name server that sent the response claims to have cryptographically verified the data in the Answer and Authority sections of the response message. Note, however, that the responses received by a security-aware stub resolver are heavily dependent on the local policy of the security-aware recursive name server. Therefore, there may be little practical value in checking the status of the AD bit, except perhaps as a debugging aid. In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel.
非验证性安全感知存根解析器可选择检查其接收的响应消息中的AD位的设置，以确定发送响应的安全感知递归名称服务器是否声称已对响应消息的应答和授权部分中的数据进行了加密验证。但是，请注意，安全感知存根解析器接收到的响应严重依赖于安全感知递归名称服务器的本地策略。因此，除了作为调试辅助外，检查AD位的状态可能没有什么实际价值。在任何情况下，安全感知存根解析器都不得依赖于据称代表其执行的签名验证，除非安全感知存根解析器通过安全通道从可信的安全感知递归名称服务器获得相关数据。
A validating security-aware stub resolver SHOULD NOT examine the setting of the AD bit in response messages, as, by definition, the stub resolver performs its own signature validation regardless of the setting of the AD bit.
具有验证安全意识的存根解析器不应检查响应消息中AD位的设置，因为根据定义，存根解析器执行自己的签名验证，而不管AD位的设置如何。
To use DNSSEC RRs for authentication, a security-aware resolver requires configured knowledge of at least one authenticated DNSKEY or DS RR. The process for obtaining and authenticating this initial trust anchor is achieved via some external mechanism. For example, a resolver could use some off-line authenticated exchange to obtain a zone's DNSKEY RR or to obtain a DS RR that identifies and authenticates a zone's DNSKEY RR. The remainder of this section assumes that the resolver has somehow obtained an initial set of trust anchors.
要使用DNSSEC RRs进行身份验证，具有安全意识的冲突解决程序需要至少一个已验证的DNSKEY或DS RR的配置知识。获取和验证该初始信任锚的过程是通过一些外部机制实现的。例如，冲突解决程序可以使用一些离线身份验证的交换来获取区域的DNSKEY RR或获取标识和身份验证区域的DNSKEY RR的DS RR。本节的其余部分假设解析器以某种方式获得了信任锚的初始集。
An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY RRset. To authenticate an apex DNSKEY RRset by using an initial key, the resolver MUST:
初始DNSKEY RR可用于验证区域的apex DNSKEY RRset。要使用初始密钥对apex DNSKEY RRset进行身份验证，解析程序必须：
1. verify that the initial DNSKEY RR appears in the apex DNSKEY RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA bit 7) set; and
1. 验证初始DNSKEY RR是否出现在apex DNSKEY RRset中，并且DNSKEY RR是否设置了区域密钥标志（DNSKEY RDATA位7）；和
2. verify that there is some RRSIG RR that covers the apex DNSKEY RRset, and that the combination of the RRSIG RR and the initial DNSKEY RR authenticates the DNSKEY RRset. The process for using an RRSIG RR to authenticate an RRset is described in Section 5.3.
2. 验证是否存在覆盖apex DNSKEY RRset的某些RRSIG RR，以及RRSIG RR和初始DNSKEY RR的组合是否验证了DNSKEY RRset。第5.3节描述了使用RRSIG RR认证RRset的过程。
Once the resolver has authenticated the apex DNSKEY RRset by using an initial DNSKEY RR, delegations from that zone can be authenticated by using DS RRs. This allows a resolver to start from an initial key and use DS RRsets to proceed recursively down the DNS tree, obtaining other apex DNSKEY RRsets. If the resolver were configured with a root DNSKEY RR, and if every delegation had a DS RR associated with it, then the resolver could obtain and validate any apex DNSKEY RRset. The process of using DS RRs to authenticate referrals is described in Section 5.2.
一旦解析器使用初始DNSKEY RR对apex DNSKEY RRset进行了身份验证，则可以使用DS RRs对来自该区域的委派进行身份验证。这允许解析器从初始密钥开始，并使用DS RRSET沿DNS树递归进行，从而获得其他apex DNSKEY RRSET。如果冲突解决程序配置了根DNSKEY RR，并且每个委派都有一个与其关联的DS RR，则冲突解决程序可以获取并验证任何apex DNSKEY RRset。第5.2节描述了使用DS RRs认证转介的过程。
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex DNSKEY RRset and RRSIG RRs from the zone to authenticate any other RRsets in the zone once the resolver has authenticated a zone's apex DNSKEY RRset. Section 5.4 shows how the resolver can use authenticated NSEC RRsets from the zone to prove that an RRset is not present in the zone.
第5.3节说明了一旦解析器验证了区域的apex DNSKEY RRset，解析器如何使用apex DNSKEY RRset中的DNSKEY RRs和区域中的RRSIG RRs来验证区域中的任何其他RRset。第5.4节说明了冲突解决程序如何使用来自区域的经过身份验证的NSEC RRset来证明区域中不存在RRset。
When a resolver indicates support for DNSSEC (by setting the DO bit), a security-aware name server should attempt to provide the necessary DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). However, a security-aware resolver may still receive a response that lacks the appropriate DNSSEC RRs, whether due to configuration issues such as an upstream security-oblivious recursive name server that
当解析器指示支持DNSSEC（通过设置DO位）时，安全感知名称服务器应尝试在响应中提供必要的DNSKEY、RRSIG、NSEC和DS RRSET（请参阅第3节）。但是，安全感知解析程序仍然可能接收到缺少适当DNSSEC RRs的响应，无论是由于配置问题，例如上游安全无关的递归名称服务器
accidentally interferes with DNSSEC RRs or due to a deliberate attack in which an adversary forges a response, strips DNSSEC RRs from a response, or modifies a query so that DNSSEC RRs appear not to be requested. The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists.
意外干扰DNSSEC RRs，或由于对手伪造响应、从响应中删除DNSSEC RRs或修改查询以使DNSSEC RRs看起来不被请求的故意攻击。响应中缺少DNSSEC数据本身不得视为不存在认证信息。
A resolver SHOULD expect authentication information from signed zones. A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset.
解析程序应该期望来自签名区域的身份验证信息。如果已为冲突解决程序配置了区域的公钥信息，或者如果已对区域的父级进行了签名，并且来自父级的委托包含DS RRset，则冲突解决程序应认为已对区域进行了签名。
Islands of security (see [RFC4033]) are signed zones for which it is not possible to construct an authentication chain to the zone from its parent. Validating signatures within an island of security requires that the validator have some other means of obtaining an initial authenticated zone key for the island. If a validator cannot obtain such a key, it SHOULD switch to operating as if the zones in the island of security are unsigned.
安全岛（请参见[RFC4033]）是已签名区域，无法为其构建从其父区域到该区域的身份验证链。在安全岛内验证签名需要验证器有一些其他方法来获取岛的初始认证区域密钥。如果验证器无法获得这样的密钥，它应该切换到安全岛中的区域未签名的状态。
All the normal processes for validating responses apply to islands of security. The only difference between normal validation and validation within an island of security is in how the validator obtains a trust anchor for the authentication chain.
验证响应的所有正常过程都适用于安全孤岛。正常验证和安全岛内验证之间的唯一区别在于验证器如何获得身份验证链的信任锚。
Once the apex DNSKEY RRset for a signed parent zone has been authenticated, DS RRsets can be used to authenticate the delegation to a signed child zone. A DS RR identifies a DNSKEY RR in the child zone's apex DNSKEY RRset and contains a cryptographic digest of the child zone's DNSKEY RR. Use of a strong cryptographic digest algorithm ensures that it is computationally infeasible for an adversary to generate a DNSKEY RR that matches the digest. Thus, authenticating the digest allows a resolver to authenticate the matching DNSKEY RR. The resolver can then use this child DNSKEY RR to authenticate the entire child apex DNSKEY RRset.
签名父区域的apex DNSKEY RRset经过身份验证后，可以使用DS RRset对签名子区域的委派进行身份验证。DS RR标识子区域的顶点DNSKEY RR集中的DNSKEY RR，并包含子区域的DNSKEY RR的加密摘要。使用强加密摘要算法可确保对手生成与摘要匹配的DNSKEY RR在计算上不可行。因此，验证摘要允许解析器验证匹配的DNSKEY RR。然后，解析程序可以使用此子DNSKEY RR对整个子DNSKEY RRset进行身份验证。
Given a DS RR for a delegation, the child zone's apex DNSKEY RRset can be authenticated if all of the following hold:
给定委派的DS RR，如果满足以下所有条件，则可以对子区域的apex DNSKEY RRset进行身份验证：
o The DS RR has been authenticated using some DNSKEY RR in the parent's apex DNSKEY RRset (see Section 5.3).
o 已使用母公司apex DNSKEY RRset中的某些DNSKEY RR对DS RR进行了验证（见第5.3节）。
o The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY RRset, and, when the DNSKEY RR's owner name and RDATA are hashed using the digest algorithm specified in the DS RR's Digest Type field, the resulting digest value matches the Digest field of the DS RR.
o DS RR中的算法和密钥标记与子区域顶点DNSKEY RRset中DNSKEY RR的算法字段和密钥标记相匹配，并且，当使用DS RR的摘要类型字段中指定的摘要算法对DNSKEY RR的所有者名称和RDATA进行散列时，生成的摘要值与DS RR的摘要字段相匹配。
o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the corresponding private key has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the child zone's apex DNSKEY RRset.
o 子区域中匹配的DNSKEY RR设置了区域标志位，相应的私钥对子区域的顶点DNSKEY RRset进行了签名，生成的RRSIG RR对子区域的顶点DNSKEY RRset进行身份验证。
If the referral from the parent zone did not contain a DS RRset, the response should have included a signed NSEC RRset proving that no DS RRset exists for the delegated name (see Section 3.1.4). A security-aware resolver MUST query the name servers for the parent zone for the DS RRset if the referral includes neither a DS RRset nor a NSEC RRset proving that the DS RRset does not exist (see Section 4).
如果来自父区域的转介不包含DS RRset，则响应应包含签名的NSEC RRset，证明委托名称不存在DS RRset（见第3.1.4节）。如果引用既不包括DS RRset，也不包括证明DS RRset不存在的NSEC RRset，则具有安全意识的解析程序必须查询DS RRset父区域的名称服务器（请参见第4节）。
If the validator authenticates an NSEC RRset that proves that no DS RRset is present for this zone, then there is no authentication path leading from the parent to the child. If the resolver has an initial DNSKEY or DS RR that belongs to the child zone or to any delegation below the child zone, this initial DNSKEY or DS RR MAY be used to re-establish an authentication path. If no such initial DNSKEY or DS RR exists, the validator cannot authenticate RRsets in or below the child zone.
如果验证器对NSEC RRset进行身份验证，证明此区域不存在DS RRset，则不存在从父级到子级的身份验证路径。如果冲突解决程序的初始DNSKEY或DS RR属于子区域或子区域下的任何委派，则此初始DNSKEY或DS RR可用于重新建立身份验证路径。如果不存在此类初始DNSKEY或DS RR，则验证程序无法验证子区域内或子区域下的RRSET。
If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.
如果验证器不支持经过身份验证的DS RRset中列出的任何算法，则解析程序没有受支持的从父级到子级的身份验证路径。如上所述，冲突解决程序应将此情况视为已验证的NSEC RRset证明不存在DS RRset的情况。
Note that, for a signed delegation, there are two NSEC RRs associated with the delegated name. One NSEC RR resides in the parent zone and can be used to prove whether a DS RRset exists for the delegated name. The second NSEC RR resides in the child zone and identifies which RRsets are present at the apex of the child zone. The parent NSEC RR and child NSEC RR can always be distinguished because the SOA bit will be set in the child NSEC RR and clear in the parent NSEC RR. A security-aware resolver MUST use the parent NSEC RR when attempting to prove that a DS RRset does not exist.
请注意，对于已签名的委派，有两个NSEC RRs与委派名称关联。一个NSEC RR驻留在父区域中，可用于证明委托名称是否存在DS RRset。第二个NSEC RR位于子区域中，并标识哪些RRSET位于子区域的顶点。父NSEC RR和子NSEC RR始终可以区分，因为SOA位将在子NSEC RR中设置，并在父NSEC RR中清除。当试图证明DS RRset不存在时，具有安全意识的冲突解决程序必须使用父NSEC RR。
If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned.
如果冲突解决程序不支持经过身份验证的DS RRset中列出的任何算法，则冲突解决程序将无法验证到子区域的身份验证路径。在这种情况下，解析程序应将子区域视为未签名。
A validator can use an RRSIG RR and its corresponding DNSKEY RR to attempt to authenticate RRsets. The validator first checks the RRSIG RR to verify that it covers the RRset, has a valid time interval, and identifies a valid DNSKEY RR. The validator then constructs the canonical form of the signed data by appending the RRSIG RDATA (excluding the Signature Field) with the canonical form of the covered RRset. Finally, the validator uses the public key and signature to authenticate the signed data. Sections 5.3.1, 5.3.2, and 5.3.3 describe each step in detail.
验证器可以使用RRSIG RR及其相应的DNSKEY RR来尝试验证RRSET。验证器首先检查RRSIG RR，以验证它是否覆盖RRset，是否具有有效的时间间隔，并标识有效的DNSKEY RR。然后，验证器通过将RRSIG RDATA（不包括签名字段）与覆盖的RRset的规范形式相加来构造签名数据的规范形式。最后，验证器使用公钥和签名对签名数据进行身份验证。第5.3.1、5.3.2和5.3.3节详细描述了每个步骤。
A security-aware resolver can use an RRSIG RR to authenticate an RRset if all of the following conditions hold:
如果满足以下所有条件，则具有安全意识的冲突解决程序可以使用RRSIG RR对RRset进行身份验证：
o The RRSIG RR and the RRset MUST have the same owner name and the same class.
o RRSIG RR和RRset必须具有相同的所有者名称和相同的类。
o The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset.
o RRSIG RR的签名者姓名字段必须是包含RRset的区域的名称。
o The RRSIG RR's Type Covered field MUST equal the RRset's type.
o RRSIG RR的类型覆盖字段必须等于RRset的类型。
o The number of labels in the RRset owner name MUST be greater than or equal to the value in the RRSIG RR's Labels field.
o RRset所有者名称中的标签数必须大于或等于RRSIG RR的标签字段中的值。
o The validator's notion of the current time MUST be less than or equal to the time listed in the RRSIG RR's Expiration field.
o 验证器的当前时间概念必须小于或等于RRSIG RR的到期字段中列出的时间。
o The validator's notion of the current time MUST be greater than or equal to the time listed in the RRSIG RR's Inception field.
o 验证器的当前时间概念必须大于或等于RRSIG RR的Inception字段中列出的时间。
o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST match the owner name, algorithm, and key tag for some DNSKEY RR in the zone's apex DNSKEY RRset.
o RRSIG RR的签名者姓名、算法和密钥标记字段必须与区域顶点DNSKEY RRset中某些DNSKEY RR的所有者姓名、算法和密钥标记匹配。
o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) set.
o 匹配的DNSKEY RR必须存在于区域的顶点DNSKEY RRset中，并且必须设置区域标志位（DNSKEY RDATA标志位7）。
It is possible for more than one DNSKEY RR to match the conditions above. In this case, the validator cannot predetermine which DNSKEY RR to use to authenticate the signature, and it MUST try each matching DNSKEY RR until either the signature is validated or the validator has run out of matching public keys to try.
多个DNSKEY RR可能与上述条件相匹配。在这种情况下，验证器无法预先确定使用哪个DNSKEY RR对签名进行身份验证，它必须尝试每个匹配的DNSKEY RR，直到签名得到验证或者验证器没有匹配的公钥可供尝试。
Note that this authentication process is only meaningful if the validator authenticates the DNSKEY RR before using it to validate signatures. The matching DNSKEY RR is considered to be authentic if:
请注意，只有当验证器在使用DNSKEY RR验证签名之前对其进行验证时，此验证过程才有意义。匹配的DNSKEY RR被认为是真实的，如果：
o the apex DNSKEY RRset containing the DNSKEY RR is considered authentic; or
o 包含DNSKEY RR的apex DNSKEY RRset被认为是真实的；或
o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, and the DNSKEY RR either matches an authenticated DS RR from the parent zone or matches a trust anchor.
o RRSIG RR覆盖的RRset是apex DNSKEY RRset本身，DNSKEY RR与来自父区域的经过身份验证的DS RR匹配，或者与信任锚匹配。
Once the RRSIG RR has met the validity requirements described in Section 5.3.1, the validator has to reconstruct the original signed data. The original signed data includes RRSIG RDATA (excluding the Signature field) and the canonical form of the RRset. Aside from being ordered, the canonical form of the RRset might also differ from the received RRset due to DNS name compression, decremented TTLs, or wildcard expansion. The validator should use the following to reconstruct the original signed data:
一旦RRSIG RR满足第5.3.1节所述的有效性要求，验证器必须重建原始签名数据。原始签名数据包括RRSIG RDATA（不包括签名字段）和RRset的规范形式。除了排序之外，由于DNS名称压缩、递减TTL或通配符扩展，RRset的规范形式也可能与收到的RRset不同。验证器应使用以下方法重建原始签名数据：
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
"|" denotes concatenation
“|”表示串联
RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signature field excluded and the Signer's Name in canonical form.
RRSIG_RDATA是RRSIG RDATA字段的有线格式，不包括签名字段，签名者的姓名为规范格式。
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
RR（i）=名称|类型|类别|源代码| RDATA长度| RDATA
name is calculated according to the function below
根据下面的函数计算名称
class is the RRset's class
类是RRset的类
type is the RRset type and all RRs in the class
type是RRset类型和类中的所有rr
OrigTTL is the value from the RRSIG Original TTL field
OrigTTL是来自RRSIG原始TTL字段的值
All names in the RDATA field are in canonical form
RDATA字段中的所有名称均为规范格式
The set of all RR(i) is sorted into canonical order.
所有RR（i）的集合按规范顺序排序。
To calculate the name: let rrsig_labels = the value of the RRSIG Labels field
要计算名称：让rrsig_labels=rrsig labels字段的值
let fqdn = RRset's fully qualified domain name in canonical form
让fqdn=RRset的标准格式的完全限定域名
let fqdn_labels = Label count of the fqdn above.
让fqdn_labels=上面fqdn的标签计数。
if rrsig_labels = fqdn_labels, name = fqdn
如果rrsig_标签=fqdn_标签，则名称=fqdn
if rrsig_labels < fqdn_labels, name = "*." | the rightmost rrsig_label labels of the fqdn
如果rrsig_标签<fqdn_标签，则name=“*”| fqdn最右边的rrsig_标签
if rrsig_labels > fqdn_labels the RRSIG RR did not pass the necessary validation checks and MUST NOT be used to authenticate this RRset.
如果rrsig_labels>fqdn_labels，则rrsig RR未通过必要的验证检查，且不得用于验证此RRset。
The canonical forms for names and RRsets are defined in [RFC4034].
[RFC4034]中定义了名称和RRSET的规范形式。
NSEC RRsets at a delegation boundary require special processing. There are two distinct NSEC RRsets associated with a signed delegated name. One NSEC RRset resides in the parent zone, and specifies which RRsets are present at the parent zone. The second NSEC RRset resides at the child zone and identifies which RRsets are present at the apex in the child zone. The parent NSEC RRset and child NSEC RRset can always be distinguished as only a child NSEC RR will indicate that an SOA RRset exists at the name. When reconstructing the original NSEC RRset for the delegation from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the child zone. When reconstructing the original NSEC RRset for the apex of the child zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone.
委托边界处的NSEC RRSET需要特殊处理。有两个不同的NSEC RRSET与签名的委托名称关联。一个NSEC RRset驻留在父区域中，并指定父区域中存在哪些RRset。第二个NSEC RRset位于子区域，并标识哪些RRset位于子区域的顶点。父NSEC RRset和子NSEC RRset始终可以区分，因为只有子NSEC RR将指示名称处存在SOA RRset。从父区域重建委托的原始NSEC RRs集时，NSEC RRs不得与子区域的NSEC RRs组合。重建子分区顶点的原始NSEC RRs集时，NSEC RRs不得与父分区的NSEC RRs组合。
Note that each of the two NSEC RRsets at a delegation point has a corresponding RRSIG RR with an owner name matching the delegated name, and each of these RRSIG RRs is authoritative data associated with the same zone that contains the corresponding NSEC RRset. If necessary, a resolver can tell these RRSIG RRs apart by checking the Signer's Name field.
请注意，在委派点的两个NSEC RRset中的每一个都有一个对应的RRSIG RR，其所有者名称与委派名称匹配，并且这些RRSIG RRs中的每一个都是与包含相应NSEC RRset的同一区域相关联的权威数据。如有必要，解析器可以通过检查签名者的姓名字段来区分这些RRSIG RRs。
Once the resolver has validated the RRSIG RR as described in Section 5.3.1 and reconstructed the original signed data as described in Section 5.3.2, the validator can attempt to use the cryptographic signature to authenticate the signed data, and thus (finally!) authenticate the RRset.
一旦解析器按照第5.3.1节所述验证了RRSIG RR，并按照第5.3.2节所述重建了原始签名数据，验证器就可以尝试使用加密签名验证签名数据，从而（最终！）验证RRset。
The Algorithm field in the RRSIG RR identifies the cryptographic algorithm used to generate the signature. The signature itself is contained in the Signature field of the RRSIG RDATA, and the public key used to verify the signature is contained in the Public Key field of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] provides a list of algorithm types and provides pointers to the documents that define each algorithm's use.
RRSIG RR中的算法字段标识用于生成签名的加密算法。签名本身包含在RRSIG RDATA的签名字段中，用于验证签名的公钥包含在匹配DNSKEY RR的公钥字段中（见第5.3.1节）。[RFC4034]提供算法类型列表，并提供指向定义每个算法使用的文档的指针。
Note that it is possible for more than one DNSKEY RR to match the conditions in Section 5.3.1. In this case, the validator can only determine which DNSKEY RR is correct by trying each matching public key until the validator either succeeds in validating the signature or runs out of keys to try.
注意，可能有多个DNSKEY RR符合第5.3.1节中的条件。在这种情况下，验证器只能通过尝试每个匹配的公钥来确定哪个DNSKEY RR是正确的，直到验证器成功验证签名或用完要尝试的密钥为止。
If the Labels field of the RRSIG RR is not equal to the number of labels in the RRset's fully qualified owner name, then the RRset is either invalid or the result of wildcard expansion. The resolver MUST verify that wildcard expansion was applied properly before considering the RRset to be authentic. Section 5.3.4 describes how to determine whether a wildcard was applied properly.
如果RRSIG RR的标签字段不等于RRset的完全限定所有者名称中的标签数，则RRset无效或是通配符扩展的结果。在将RRset视为真实之前，解析程序必须验证是否正确应用了通配符扩展。第5.3.4节描述了如何确定是否正确应用了通配符。
If other RRSIG RRs also cover this RRset, the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results.
如果其他RRSIG RRs也覆盖此RRset，则本地冲突解决程序安全策略将确定冲突解决程序是否还必须测试这些RRSIG RRs，以及如果这些RRSIG RRs导致不同的结果，如何解决冲突。
If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of:
如果冲突解决程序接受RRset为可信的，则验证程序必须将RRSIG RR的TTL和已验证RRset中的每个RR设置为不大于以下最小值的值：
o the RRset's TTL as received in the response;
o 响应中接收到的RRset的TTL；
o the RRSIG RR's TTL as received in the response;
o 响应中接收到的RRSIG RR的TTL；
o the value in the RRSIG RR's Original TTL field; and
o RRSIG RR的原始TTL字段中的值；和
o the difference of the RRSIG RR's Signature Expiration time and the current time.
o RRSIG RR的签名过期时间与当前时间之差。
If the number of labels in an RRset's owner name is greater than the Labels field of the covering RRSIG RR, then the RRset and its covering RRSIG RR were created as a result of wildcard expansion. Once the validator has verified the signature, as described in Section 5.3, it must take additional steps to verify the non-existence of an exact match or closer wildcard match for the query. Section 5.4 discusses these steps.
如果RRset所有者名称中的标签数量大于覆盖RRSIG RR的标签字段，则RRset及其覆盖RRSIG RR是通过通配符扩展创建的。验证程序验证完签名后（如第5.3节所述），必须采取其他步骤验证查询是否存在精确匹配或更接近的通配符匹配。第5.4节讨论了这些步骤。
Note that the response received by the resolver should include all NSEC RRs needed to authenticate the response (see Section 3.1.3).
请注意，解析程序收到的响应应包括验证响应所需的所有NSEC RRs（见第3.1.3节）。
A resolver can use authenticated NSEC RRs to prove that an RRset is not present in a signed zone. Security-aware name servers should automatically include any necessary NSEC RRs for signed zones in their responses to security-aware resolvers.
解析程序可以使用经过身份验证的NSEC RRs来证明RRset不存在于签名区域中。安全感知名称服务器应在其对安全感知解析程序的响应中自动包含签名区域的任何必要NSEC RRs。
Denial of existence is determined by the following rules:
拒绝存在由以下规则决定：
o If the requested RR name matches the owner name of an authenticated NSEC RR, then the NSEC RR's type bit map field lists all RR types present at that owner name, and a resolver can prove that the requested RR type does not exist by checking for the RR type in the bit map. If the number of labels in an authenticated NSEC RR's owner name equals the Labels field of the covering RRSIG RR, then the existence of the NSEC RR proves that wildcard expansion could not have been used to match the request.
o 如果请求的RR名称与经过身份验证的NSEC RR的所有者名称匹配，则NSEC RR的类型位图字段将列出该所有者名称处存在的所有RR类型，并且解析程序可以通过检查位图中的RR类型来证明请求的RR类型不存在。如果经过身份验证的NSEC RR的所有者名称中的标签数等于覆盖RRSIG RR的标签字段，则NSEC RR的存在证明无法使用通配符扩展来匹配请求。
o If the requested RR name would appear after an authenticated NSEC RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order defined in [RFC4034], then no RRsets with the requested name exist in the zone. However, it is possible that a wildcard could be used to match the requested RR owner name and type, so proving that the requested RRset does not exist also requires proving that no possible wildcard RRset exists that could have been used to generate a positive response.
o 如果根据[RFC4034]中定义的规范DNS名称顺序，请求的RR名称将出现在经过身份验证的NSEC RR的所有者名称之后和该NSEC RR的下一个域名字段中列出的名称之前，则该区域中不存在具有请求名称的RRSET。但是，通配符可能用于匹配请求的RR所有者名称和类型，因此证明请求的RRset不存在也需要证明不存在可能用于生成肯定响应的通配符RRset。
In addition, security-aware resolvers MUST authenticate the NSEC RRsets that comprise the non-existence proof as described in Section 5.3.
此外，具有安全意识的解析器必须对NSEC RRSET进行身份验证，这些RRSET包括第5.3节所述的不存在证明。
To prove the non-existence of an RRset, the resolver must be able to verify both that the queried RRset does not exist and that no relevant wildcard RRset exists. Proving this may require more than
要证明RRset不存在，冲突解决程序必须能够验证查询的RRset是否不存在以及是否不存在相关的通配符RRset。证明这一点可能需要超过
one NSEC RRset from the zone. If the complete set of necessary NSEC RRsets is not present in a response (perhaps due to message truncation), then a security-aware resolver MUST resend the query in order to attempt to obtain the full collection of NSEC RRs necessary to verify the non-existence of the requested RRset. As with all DNS operations, however, the resolver MUST bound the work it puts into answering any particular query.
区域中的一个NSEC RRset。如果响应中不存在所需的完整NSEC RRs集（可能是由于消息截断），则具有安全意识的解析程序必须重新发送查询，以便尝试获取验证所请求RRs集不存在所需的完整NSEC RRs集。但是，与所有DNS操作一样，解析程序必须将其用于回答任何特定查询的工作绑定起来。
Since a validated NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR.
由于经过验证的NSEC RR证明了其自身及其相应的RRSIG RR的存在，因此验证器必须忽略NSEC RR中NSEC和RRSIG位的设置。
If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD. If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. However, it MUST return the full response if and only if the original query had the CD bit set. Also see Section 4.7 on caching responses that do not validate.
无论出于何种原因，如果无法验证任何RRSIG，则应认为响应不好。如果验证是为了服务递归查询而进行的，则名称服务器必须将RCODE 2返回给原始客户端。但是，当且仅当原始查询设置了CD位时，它必须返回完整响应。另请参见第4.7节“缓存未验证的响应”。
Appendix C shows an example of the authentication process.
附录C显示了认证过程的示例。
[RFC4034] contains a review of the IANA considerations introduced by DNSSEC. The following are additional IANA considerations discussed in this document:
[RFC4034]包含对DNSSEC引入的IANA注意事项的审查。以下是本文件中讨论的其他IANA注意事项：
[RFC2535] reserved the CD and AD bits in the message header. The meaning of the AD bit was redefined in [RFC3655], and the meaning of both the CD and AD bit are restated in this document. No new bits in the DNS message header are defined in this document.
[RFC2535]在消息头中保留CD和AD位。[RFC3655]中重新定义了AD位的含义，本文件中重申了CD和AD位的含义。本文档中未定义DNS消息头中的新位。
[RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit and defined its use. The use is restated but not altered in this document.
[RFC2671]引入了EDN，[RFC3225]保留了DNSSEC OK位并定义了其用途。本文件重申了该用途，但未对其进行修改。
This document describes how the DNS security extensions use public key cryptography to sign and authenticate DNS resource record sets. Please see [RFC4033] for terminology and general security considerations related to DNSSEC; see [RFC4034] for considerations specific to the DNSSEC resource record types.
本文档描述DNS安全扩展如何使用公钥加密技术对DNS资源记录集进行签名和身份验证。有关DNSSEC的术语和一般安全注意事项，请参见[RFC4033]；有关DNSSEC资源记录类型的特定注意事项，请参见[RFC4034]。
An active attacker who can set the CD bit in a DNS query message or the AD bit in a DNS response message can use these bits to defeat the protection that DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. For this reason, use of these control bits by a security-aware recursive-mode resolver requires a secure channel. See Sections 3.2.2 and 4.9 for further discussion.
可以在DNS查询消息中设置CD位或在DNS响应消息中设置AD位的主动攻击者可以使用这些位来破坏DNSSEC试图向无安全意识递归模式解析程序提供的保护。因此，安全感知递归模式解析器使用这些控制位需要安全通道。进一步讨论见第3.2.2节和第4.9节。
The protocol described in this document attempts to extend the benefits of DNSSEC to security-oblivious stub resolvers. However, as recovery from validation failures is likely to be specific to particular applications, the facilities that DNSSEC provides for stub resolvers may prove inadequate. Operators of security-aware recursive name servers will have to pay close attention to the behavior of the applications that use their services when choosing a local validation policy; failure to do so could easily result in the recursive name server accidentally denying service to the clients it is intended to support.
本文档中描述的协议试图将DNSSEC的优点扩展到安全无关的存根解析器。然而，由于验证失败的恢复可能特定于特定应用，DNSSEC为存根解析器提供的设施可能不充分。在选择本地验证策略时，具有安全意识的递归名称服务器的操作员必须密切关注使用其服务的应用程序的行为；如果不这样做，很容易导致递归名称服务器意外地拒绝向其打算支持的客户端提供服务。
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月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 26721999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]Conrad，D.“指示DNSSEC的分解器支持”，RFC 3225，2001年12月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
[RFC3226]Gudmundsson，O.，“DNSSEC和IPv6 A6感知服务器/解析器消息大小要求”，RFC 3226，2001年12月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655]Wellington，B.和O.Gudmundsson，“DNS认证数据（AD）位的重新定义”，RFC 3655，2003年11月。
The following example shows a (small) complete signed zone.
以下示例显示了一个（小）完整的签名区域。
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) 3600 NS ns1.example. 3600 NS ns2.example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 3600 MX 1 xx.example. 3600 RRSIG MX 5 1 3600 20040509183619 ( 20040409183619 38519 example. HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM W6OISukd1EQt7a0kygkg+PEDxdI= ) 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 3600 DNSKEY 256 3 5 ( AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
实例SOA ns1.1中的3600示例。bugs.x.w.示例。（1081539377 3600 300 3600000 3600）3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519示例。关于x0K36RCJAXYTCNGQ6IQNPNV5+drqYAsC9h 7TSJAHCQBHE67SR6AH2XDUGCQWU/n0UVzrF VKGO9EBARZ0GWDKCUWLM6ENB52K74L5LW DA7S/Un/IBTDQ4DAY8NMLQ7DW7N4P8/RJV07J86HYQGME7+MIRAZ81B0NSI=）示例3600。3600 NS ns2.0示例。3600 RRSIG NS 5 1 3600 20040509183619（20040409183619 38519示例。gl13F00f2U0R+SwixxlHsmy+qStYy5k6zfd EuivWc+WD1FMBCYQL0TK7LHTX6UOX8AGNF4 ISFV8QF4Q+O9QLNQIZMPU3LineKT4FZ8 Ro5urfovomRTBQW3U0HW0HWugge4G3ZPSHV48 0HjMeRaZB/FRPGfJPajngcq6Kwg=）3600 MX1.xx示例。3600 RRSIG MX 5 1 3600 20040509183619（20040409183619 38519示例。HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 2QAKHVPFAU/DgLgS/IKENkYOGL95G4N+NzE Vynu8DCTOCK+ChPcGeVjguQ7a3Ao9Z/ZkUO 6GMMUW4B89RZ1PUXW4JZUXJ66PTWOUU/iM W6OISUKD1EQT7A0KYGKYGKGKYG+PEXDI=）3600 NSEC a.示例。NS SOA MX RRSIG NSEC DNSKEY 3600 RRSIG NSEC 5 1 3600 20040509183619（20040409183619 38519示例：O0K558JHYRC97ISHNISLM4KLMW48C7U7CBM FTFHKE5IVQNRVTB1STLMGPBDIC9HCRYOO0V Z9ME5XpZUEHBGNHD5SFZGFEGXR5NYQ4TW SDBGIBILQUV1IVY29VHXY7WGR62Z0DVM JFFJ5ARXF4NP/kEowGgBRzY/U=3600 DNSKE5（AQOY1BZVVPPQHG4J7EJOM9RI3ZMYEW2OZDBV rZy/LVI5CQEPXHZS4I8DANH4DX3TBHOL61E K8EFMCSGXXKCIJJJJJHYHL94C+NwILQdzsUlSFo vBZsyl/NX6yEbtw/XN9ZN9ZNCRBYVGJZ/UVPZI
ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== ) 3600 DNSKEY 257 3 5 ( AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 9465 example. ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 38519 example. eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 7z5OXogYVaFzHKillDt3HRxHIZM= ) a.example. 3600 IN NS ns1.a.example. 3600 IN NS ns2.a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 3600 NSEC ai.example. NS DS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 ai.example. 3600 IN A 192.0.2.9 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example.
ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==）3600 DNSKEY 257 3 5（AQOeX7+BATMVvPVHB2CCLNL1DMRWUSCRVHXL LNxWDZVQP4TzVKP1ZMEPFB8VxHHHW3Y/0QZ SYCJCZGJ1QK8VJE52IOhinkrowLWxGPMFZP RLMlGybr51bOV/1SE0ODACJ3DMYB4QB5QB5GKT/K9alk5/J8VFD4JWW8JWCWD+E1SZE01SZE01ZZZZZZZZZZZZZZZJJJJJJJJJJJJJJJJJ（200404091836199465示例：ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ XYNZ99JVQZJ33WFS0Q0JCP7VXKAELXK9NYJ XevO/7NABO88IWSMKSPSR6JWZYKWFRBI/L9 HJYMYM9FJQ7UWM4DCP/bIuV/DKQOAK9NYHFVCV1TP4VKDQQG7R5TTVM=）3600 RRSIG DNSKE5 3600 20040509183619（20040409183619 38519示例。eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri BkbpYSRxOxCfRkQS5Oa0Bzmof XCxUp9Qhap eFIku28Vqfr8Nt7cigZLxjK+U331WS/4LirJKKKK 7Z5OxogyVafzkilld3RxHIZM=）NS ns2.a.a.a.a.a.a.a.a.example.3600中的a.example.36003600 RRSIG DS 5 2 3600 20040509183619（20040409183619 38519示例。oXIKit/QtdG64J/CB+GI8DOVNWVQRTOADQ ORKAN15FP3IZ7SUB7GVTBMxCjl7XUGQVCOH KDHYCUZP8W9QJRUSWKKKKKZYUL64NHGHUD EML8L9WLWVSL7PR2VNZDUM9BLYBAPPHAAPMRKX/Fm+V6CCF6CCF2EGNlY08KDKZ+XHO==3600 NSEC ai.示例。NS RRSIG NSEC3600 NSEC 3600（20040409183619 38519示例。Colygqjlqlrqmbq3iap2sysk4o5aqpksoba u9fq5smapzmmhfq3aglflkrkxrxvgxtqskgg2 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I bbdjgdahe0f5roj87996vjupdm1fbh481g sdkOW6Zyqtz3Zos8N0BBkEx+2G4=）192.0.2.5版本中的ns1.a.example.3600版本中的ns2.a.example.3600版本中的192.0.2.6 ai.example.3600版本中的ns1.a.example.3600版本中的RRSIG a 5 2 3600 20040509183619（20040409183619 38519示例）。
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 5 2 3600 20040509183619 (
20040409183619 38519 example.
Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
AhS+JOVfDI/79QtyTI0SaDWcg8U= )
b.example. 3600 IN NS ns1.b.example.
3600 IN NS ns2.b.example.
3600 NSEC ns1.example. NS RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
ns1.example. 3600 IN A 192.0.2.1
3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 5 2 3600 20040509183619 (
20040409183619 38519 example.
Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
AhS+JOVfDI/79QtyTI0SaDWcg8U= )
b.example. 3600 IN NS ns1.b.example.
3600 IN NS ns2.b.example.
3600 NSEC ns1.example. NS RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
ns1.example. 3600 IN A 192.0.2.1
3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
v/iVXSYC0b7mPSU+EOlknFpVECs= ) 3600 NSEC ns2.example. A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) ns2.example. 3600 IN A 192.0.2.2 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 3600 NSEC *.w.example. A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) *.w.example. 3600 IN MX 1 ai.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= ) 3600 NSEC x.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= ) x.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 20040409183619 38519 example. Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
v/iVXSYC0b7mPSU+EOlknFpVECs=）3600 NSEC ns2.示例。RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例：I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/EILDJHN7JPV6LGPIH/8FibkFvDyWf1Jf1Q0JGyO7JGyO7FvBNWQaaEP3UKDDBQ ZialI8QR2XHKJQ8E8Bp0+6NSH4ETWSG8LW6ETWSG8LW6LW7NxGyX8D8H8H8H8H8H8H8H8H8H7H7H7H7H7H7H7H7H7H2。3600在192.0.2.2 3600 RRSIG A 5 2 3600 20040509183619中（20040409183619 38519示例。V7cQRw1TR+KNAL1Z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+WUDHRH2AP9ULJPQJFWMKOU YFPGpQPC8KZGDE3VT5SNFEAOE13MQQTU7SO 6MIMIJK13KJ/JYJJ4NGMDRIC/3cM3ipXFhNTKq RDHX80YYZIZIVISO=*）示例。A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例。N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE VYAISKQZGP3JYXZJPVTQUVESGT3CGEHVB 3QbeJ5Dfb2V9NGCHj/OvF/LBXFWHLWZNGH l+BQGAGACMSLU/NL3NDIY/JSQjAcdZNDl4bw YMX28ETGI9A0QMP08RMBW=*。示例。3600英寸MX 1 ai.example。3600 RRSIG MX 5 2 3600 20040509183619（20040409183619 38519示例。OMK8RAZLEPFZLW75DXD63JY2WSWESZDKG2 F9AMN1CYTCD10YISAXFADVXSZ7XUJKATPC tvOQ2ofO7AZJ+D01EEQTVBPQ4/6KCWhqe2X TJNKLNVHNC0U28AOSSG0+4INVKOHKNKW4KX18MMR34I8LC36SR5KBNI8VHI=）3600 NSEC x.w示例。MX RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例。r/mZnRC3I/VicregictesxDHTSDLTT8NG9 HSBlABOlzLxQtfgTnn8f+AOWJIAFEE5RVU 5VHQJNP5 xMxMjFYPS8 TVVFXSAXFAHPYQTX 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 S1inqUoIv6TjAAP7018OLA=）x.w示例。3600英寸MX 1.xx示例。3600 RRSIG MX 5 3 3600 20040509183619（20040409183619 38519示例。Il2WTZ+Bkv+OYTBX4LITNW5MJB4RCWHO8Y1 XZPHZMZZUTVYL7LAA63F6YSVBZJRI3KJAP H3U1YNDON1DRWQMI9RJE4FOOBCKDM7P3I KX70EPCOFGRZYQ+BVXCVGUAU4ALV3W/Y1
jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20040509183619 ( 20040409183619 38519 example. aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e IjgiM8PXkBQtxPq37wDKALkyn7Q= ) x.y.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 5 4 3600 20040509183619 ( 20040409183619 38519 example. k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb +gLcMZBnHJ326nb/TOOmrqNmQQE= ) 3600 NSEC xx.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) xx.example. 3600 IN A 192.0.2.10 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 3600 HINFO "KLH-10" "TOPS-20" 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 20040409183619 38519 example. GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ RgNvuwbioFSEuv2pNlkq0goYxNY= ) 3600 AAAA 2001:db8::f00:baaa 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
jNSlwZ2mSWKHfxFQxPtLj8s32+k=）3600NSEC x.y.w.示例。MX RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20040509183619（20040409183619 38519示例。aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8j0tzeunqbyh5qfn5n1fqh/pS46UA7A4E mcwbn9pua1pdpy6rveralzlcr1ictvbtai NJuBba/vba/VHm+pebTbKcAPIvL9tBOoh+to1h6e ijgim8kbqtpqtq7wdkaln7q=）x.y.w示例。3600英寸MX 1.xx示例。3600 RRSIG MX 5 4 3600 20040509183619（20040409183619 38519示例。K2BJHBWP5LH5QN4IS39UIPZJAWYMJA38HIA t7i9t7nbX/E0FPNVDSQZCK7UL+zrVA+3MDj q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq GtOB9prkK54QTl/QZTXFMQPW480YOVKNHVB+gLcMZBnHJ326nb/TOOMRQQQQQQQQE=）3600 NSEC.xx示例。MX RRSIG NSEC 3600 RRSIG NSEC 5 4 3600 20040509183619（20040409183619 38519示例。Ove6Wuzn2ZiiejCvkPwbcayxP6EF8Cr6CSP arvstzksqunwbezmKU7E34O5LMB6CWSSPG xw098kNUFnHcQf/LZY2ZQROMUBRNQHJTITITTX A0arunjCzpJoyQ5T0SLJM6QP6QP6QP6CjI1Ap5VR QOkLjDNOLCjN3JK=）示例。3600在192.0.2.10 3600 RRSIG A 5 2 3600 20040509183619中（20040409183619 38519示例：kBF4YxMGWF0D8r0cztL+2FwvovN1U/GYSpYP 7SoKoNQ4fZKyk+Wewglium+uE1zjVTPXoa 0Z6WG0OzP46RKL1EzMcDoaeuzzaJ2BMQ+Y VDXG9Ik1YZKYG9GPZVUSNZUNZUZUNZOMGZGZGZ4）3600 HINFO“20”顶部3600（2004040918361938519示例。GY2PLSXmMHkWHfLdggiox8+CHWPEMNJLKML0T+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+WWF83YCUEUU8YKLHLWLV8GQ15YKTH0ITQY8/wI+RGNVUW2PNLKQ0GOYXNY=）3600 AAA 2001:db8:：f00:BAA 3600 RRSIG AAAA 5 2 3600 200405619（20040409183619 38519示例。ZZJ0YODXCBLNNOIWDSUKO5WQIAK24DLKG9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
xS9cL2QgW7FChw16mzlkH6/vsfs= ) 3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W GghLahumFIpg4MO3LS/prgzVVWo= )
xS9cL2QgW7FChw16mzlkH6/vsfs=）3600 NSEC示例。HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例：ZFWULN6AVC8BMGL5GFJD3BWT530Duzkhnoy 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k mvHgEa/HZBDB4PIY79W+VHRGOxDZDQGGCZZ ASXRPSGOWWSOELGHPNMII8x7QTCNTR382W GghLahumFIpg4MO3LS/PRGZVWO=）
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA Flags indicate that each of these DNSKEY RRs is a zone key. One of these DNSKEY RRs also has the SEP flag set and has been used to sign the apex DNSKEY RRset; this is the key that should be hashed to generate a DS record to be inserted into the parent zone. The other DNSKEY is used to sign all the other RRsets in the zone.
apex DNSKEY集合包括两个DNSKEY RRs，DNSKEY RDATA标志表示每个DNSKEY RRs都是区域密钥。其中一个DNSKEY RRs还具有SEP标志集，并已用于对apex DNSKEY RRs集进行签名；这是应该散列的键，以生成要插入父区域的DS记录。另一个DNSKEY用于对区域中的所有其他RRSET进行签名。
The zone includes a wildcard entry, "*.w.example". Note that the name "*.w.example" is used in constructing NSEC chains, and that the RRSIG covering the "*.w.example" MX RRset has a label count of 2.
该区域包含一个通配符条目“*.w.example”。请注意，名称“*.w.example”用于构造NSEC链，并且覆盖“*.w.example”MX RRset的RRSIG的标签计数为2。
The zone also includes two delegations. The delegation to "b.example" includes an NS RRset, glue address records, and an NSEC RR; note that only the NSEC RRset is signed. The delegation to "a.example" provides a DS RR; note that only the NSEC and DS RRsets are signed.
该区还包括两个代表团。对“b.example”的委托包括NS RRset、glue地址记录和NSEC RR；请注意，只有NSEC RRset被签名。对“a.example”的委托提供了DS RR；请注意，只有NSEC和DS RRSET被签名。
The examples in this section show response messages using the signed zone example in Appendix A.
本节中的示例使用附录A中的签名区域示例显示响应消息。
A successful query to an authoritative server.
对权威服务器的成功查询。
;; Header: QR AA DO RCODE=0
;;
;; Question
x.w.example. IN MX
;; Header: QR AA DO RCODE=0
;;
;; Question
x.w.example. IN MX
;; Answer
x.w.example. 3600 IN MX 1 xx.example.
x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
20040409183619 38519 example.
Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
;; Answer
x.w.example. 3600 IN MX 1 xx.example.
x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
20040409183619 38519 example.
Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
;; 权威的例子。3600 NS ns1.0示例。实例3600 NS ns2.0示例。实例3600 RRSIG NS 5 1 3600 20040509183619（20040409183619 38519示例：gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+WD1FMBCYQL0TK7LHTX6UOX8AGNF 4ISFV8QF4Q+O9QLNQIZMPU3LineKT4FZ8 RO5URFOVOMRTBQW3U0HW0HWUGGE4G3ZPSHV48 0HjMeRaZB/FRPGfJPajngcq6Kwg=）
;; Additional xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4= ) xx.example. 3600 AAAA 2001:db8::f00:baaa xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ xS9cL2QgW7FChw16mzlkH6/vsfs= ) ns1.example. 3600 IN A 192.0.2.1 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK v/iVXSYC0b7mPSU+EOlknFpVECs= ) ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
;; 附加xx.1示例。在192.0.2.10.xx示例中为3600。3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519示例。KBF4YXMGW0D8R0CZTL+2FWOVN1U/GYSP7SOKONQ4FZKYK+WEWglium+uE1zjVTPXoa 0Z6WG0OZP46RKL1EZMGOAEUZZAJ2BMQ+Y VDXG9IK1YZKYGYG9GBTOGPPOAGBJYO9EPULS6OMGZHV4=×示例）。3600 AAAA 2001:db8:：f00:baaa xx.example。3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519示例。Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/xS9cL2QgW7FChw16mzlkH6/vsfs=）ns1.示例。在192.0.2.1 ns1.1示例中为3600。3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519示例。F1C9HVHICS10CZU09G5YIVFKJY5YRQQQVET 5GHP82PZHAOMZ3K22JNMK4C+IjUeFp/to06 IM5FvPhtFfIdJPyQ84BHTv8VRXT5AB1WNB++iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK/IVXSYC0B7MPU+EOlknFpVECs=）示例2。在192.0.2.2 ns2.0示例中为3600。3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519示例：V7cQRw1TR+KNAL1Z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+Wudhrh22AP9ULJPQQJFWMKOU yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6MIJK13KJ/JYJJJJ4NGMDRIC/3cM3ipXFhNTKq RDHs80YY4ObirZVBFLISO=）
An authoritative name error. The NSEC RRs prove that the name does not exist and that no covering wildcard exists.
权威名称错误。NSEC RRs证明该名称不存在，并且不存在覆盖通配符。
;; Header: QR AA DO RCODE=3
;;
;; Question
ml.example. IN A
;; Header: QR AA DO RCODE=3
;;
;; Question
ml.example. IN A
;; Answer
;; (empty)
;; Answer
;; (empty)
;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; 权威的例子。SOA ns1.1中的3600示例。bugs.x.w.示例。（1081539377 3600 300 3600000 3600）示例。3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519示例。关于X0K36RCJAXYTCNGQ6IQNPNV5+drqYAsC9h 7TSJAHCQBHE67SR6AH2XDUGCQWU/n0UVzrF VKGO9EBARZ0GWDKCUWLM6ENB52K74L5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I=）b示例。3600 NSEC ns1.0示例。NS RRSIG NSEC b.示例。3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例。GNUXHN844WFMUHPZGWKWKJCPY5TTEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSCNVBNKM6OWOPYSY97MVJ5VQEWS 0LM9TFOQJCPTQKMKYVKKYPRWUNCWCLSF1Z VHRXGWT7OUFXLDOCG6TFFm9XE=）示例。例如3600毫微秒。NS SOA MX RRSIG NSEC DNSKEY示例。3600 RRSIG NSEC 5 1 3600 20040509183619（20040409183619 38519示例：O0K558JHYRC97ISHNISLM4KLMW48C7U7CBM FTFHKE5IVQNRVTB1STLMGPBDIC9HCRYOO0V Z9ME5XpZUEHBGNHD5SFZGFEGXR5NYQ4TW SDBGIBILQUV1IVY29VHXY7WGR62DPRZ0VM jfFJ5arXf4nPxp/kEowGgBRzY=）
;; Additional
;; (empty)
;; Additional
;; (empty)
A "no data" response. The NSEC RR proves that the name exists and that the requested RR type does not.
“无数据”响应。NSEC RR证明名称存在，而请求的RR类型不存在。
;; Header: QR AA DO RCODE=0
;;
;; Question
ns1.example. IN MX
;; Header: QR AA DO RCODE=0
;;
;; Question
ns1.example. IN MX
;; Answer
;; (empty)
;; Answer
;; (empty)
;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
;; 权威的例子。SOA ns1.1中的3600示例。bugs.x.w.示例。（1081539377 3600 300 3600000 3600）示例。3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519示例。关于X0K36RCJAXYTCNGQ6IQNPNV5+drqYAsC9h 7TSJAHCQBHE67SR6AH2XDUGCQWU/n0UVzrF VKGO9EBARZ0GWDKCUWLM6ENB52K74L5LW DA7S/Un/IBTDQ4AY8NMNLQI7DW7N4PNS8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I=）1.示例1。3600 NSEC ns2.0示例。一个RRSIG NSEC ns1.0示例。3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例：I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/EILDJHHN7JPV6LGPIH/8FibKfVdyW7Jf1Q0JGyO7JGyO7FvBNWQAAEPJK3UKDDBQ ZialI8QR2XHKJQ8E8EQ8EBP8X0+6H4ETWSGgSgSgH7J8IzablyQLW6Y6Y6X8D8DQLW6DQLW8DQLW6DQLW8JJ
;; Additional
;; (empty)
;; Additional
;; (empty)
Referral to a signed zone. The DS RR contains the data which the resolver will need to validate the corresponding DNSKEY RR in the child zone's apex.
转介到已签名区域。DS RR包含解析程序验证子区域顶点中相应DNSKEY RR所需的数据。
;; Header: QR DO RCODE=0
;;
;; Header: QR DO RCODE=0
;;
;; Question mc.a.example. IN MX
;; 问题mc.a.举例。在MX中
;; Answer
;; (empty)
;; Answer
;; (empty)
;; Authority a.example. 3600 IN NS ns1.a.example. a.example. 3600 IN NS ns2.a.example. a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
;; 权威是一个例子。以NS ns1.a.中的3600为例。a、 例如。以NS ns2.a.中的3600为例。a、 例如。3600 DS 57855 1（B6DCD485719ADCA18E5F3D48A2331627FDD3 636B）a.示例。3600 RRSIG DS 5 2 3600 20040509183619（20040409183619 38519示例。oXIKit/QtdG64J/CB+GI8DOVNWVQRTOADQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH KDHYCUZP8W9QJRUSWKKKKKCzYUL64NHGHUD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/Fm+V6CCF2EGN8KDKKKZZZYKKKZ+XHO=）
;; Additional ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6
;; 附加ns1.a.示例。在192.0.2.5 ns2.A.示例中为3600。192.0.2.6版本中的3600
Referral to an unsigned zone. The NSEC RR proves that no DS RR for this delegation exists in the parent zone.
对未签名区域的引用。NSEC RR证明父区域中不存在此委派的DS RR。
;; Header: QR DO RCODE=0
;;
;; Question
mc.b.example. IN MX
;; Header: QR DO RCODE=0
;;
;; Question
mc.b.example. IN MX
;; Answer
;; (empty)
;; Answer
;; (empty)
;; Authority b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns2.b.example. b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
;; 权威b.举例说明。以NS ns1.b.中的3600为例。b、 例如。以NS ns2.b.中的3600为例。b、 例如。3600 NSEC ns1.0示例。NS RRSIG NSEC b.示例。3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例：GNUXHN844WFMUHPZGWKWKJCPY5TTEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBNKNKM6OWOPYSY97MVJ5VQEWS 0LM9TFOQJCPTQKMKYVKKYPRWUNCWCLSF1Z VHRXGWT7OUFXLDOCG6TFFm9XE=）
;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8
;; 附加ns1.b.示例。在192.0.2.7 ns2.b.示例中为3600。192.0.2.8版本中的3600
A successful query that was answered via wildcard expansion. The label count in the answer's RRSIG RR indicates that a wildcard RRset was expanded to produce this response, and the NSEC RR proves that no closer match exists in the zone.
通过通配符扩展回答的成功查询。答案的RRSIG RR中的标签计数表示扩展了通配符RRset以生成此响应，NSEC RR证明区域中不存在更接近的匹配。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN MX
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN MX
;; Answer a.z.w.example. 3600 IN MX 1 ai.example. a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= )
;; 回答a.z.w.的例子。3600英寸MX 1 ai.example。a、 z.w.举例说明。3600 RRSIG MX 5 2 3600 20040509183619（20040409183619 38519示例。OMK8RAZLEPFZLW75DXD63JY2WSWESZDKG2 F9AMN1CYTCD10YISAXFADVXSZ7XUJKATPC tvOQ2ofO7AZJ+D01EEQTVBPQ4/6KCWhqe2X TJNKLNVHNC0U28AOSSG0+4INVKOHKNKW4KX18MMR34I8LC36SR5xBNI8VHI=）
;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
;; 权威的例子。3600 NS ns1.0示例。实例3600 NS ns2.0示例。实例3600 RRSIG NS 5 1 3600 20040509183619（20040409183619 38519示例。gl13F00f2U0R+SwixxlHsmy+qStYy5k6zfd EuivWc+WD1FMBCYQL0TK7LHTX6UOX8AGNF4 ISFVE8QF4Q+O9QLNQIZMPU3LineKT4FZ8 RO5URFOVOMRTBQW3U0HW0HWUGGE4G3ZPSHV48 0HjMeRaZB/FRPGfJPajngcq6Kwg=）x.y.w示例。3600 NSEC xx.example。MX RRSIG NSEC x.y.w.示例。3600 RRSIG NSEC 5 4 3600 20040509183619（20040409183619 38519示例。Ove6Wuzn2ZiejCvkPwBcayxP6EF8Cr6CSP arvstzksqqunwBezzmKU7E34O5LMB6CWSSPgXW098KNUFNHCQF/LZY2ZQROMUBRNQHJTITITTX aArunjCzCzZJOYQ5T0SL6QP6QP6QP6QP6QP6QP6QP6CjI1AP5VR QOKQOKQQQQQQQQQQQJDCLNOALCNOLCNOLCPKAM
;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
;; 附加ai.example。在192.0.2.9 ai示例中为3600。3600 RRSIG A 5 2 3600 20040509183619(
20040409183619 38519 example. pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) ai.example. 3600 AAAA 2001:db8::f00:baa9 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= )
2004040918361938519示例。pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B在hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6ZRTPG9FKS0GVMYRVOTNYX2HVQ=）ai中的作用。3600 AAAA 2001:db8:：f00:baa9 ai.example。3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519示例：nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK KEWXG2 ADYLKAOBIOR5+VoQV3XgTcofTJNsh 1RNF6EAV2ZPZB3由I6YO2BWY8MNKR4A7CL9T cMmDwV/HWFFKSB8XSC8XSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o=）
A "no data" response for a name covered by a wildcard. The NSEC RRs prove that the matching wildcard name does not have any RRs of the requested type and that no closer match exists in the zone.
通配符包含的名称的“无数据”响应。NSEC RRs证明匹配的通配符名称没有任何请求类型的RRs，并且区域中不存在更接近的匹配。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN AAAA
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN AAAA
;; Answer
;; (empty)
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= )
ARVSTZKSQUNWBEZMKU7E34O5LMB6CWSSSPG xw098kNUFnHcQf/LZY2ZQROMUBRNQHJTITTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk=）*。w.示例。3600毫微秒x.w.示例。MX RRSIG NSEC*.w.示例。3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519示例。r/mZnRC3I/VicregictesxDhtsdtlt8NG9 HSBlABOlzLxQtfgTnn8f+AOWJiaFe1e5RVU 5CVHQJNP5XPxMJHFYPS8TVvFxSAxPyQTX 91gsmcV/1V9/BZAG55CEFP9CM4Z9Y9NT9X8S1INQ2UO6TKKKKP7018OLA=）
;; Additional
;; (empty)
;; Additional
;; (empty)
A "no data" response for a QTYPE=DS query that was mistakenly sent to a name server for the child zone.
QTYPE=DS查询的“无数据”响应被错误地发送到子区域的名称服务器。
;; Header: QR AA DO RCODE=0
;;
;; Question
example. IN DS
;; Header: QR AA DO RCODE=0
;;
;; Question
example. IN DS
;; Answer
;; (empty)
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= )
FTFHKE5IVQNRVTB1STLMPGBDIC9HCRYOO0V Z9ME5xPZUEHBVGNHD5SFZGFEGXR5NYYQ4TW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U=）
;; Additional
;; (empty)
;; Additional
;; (empty)
The examples in this section show how the response messages in Appendix B are authenticated.
本节中的示例显示了如何对附录B中的响应消息进行身份验证。
The query in Appendix B.1 returned an MX RRset for "x.w.example.com". The corresponding RRSIG indicates that the MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The resolver needs the corresponding DNSKEY RR in order to authenticate this answer. The discussion below describes how a resolver might obtain this DNSKEY RR.
附录B.1中的查询返回了“x.w.example.com”的MX RRset。相应的RRSIG表示MX RRset由具有算法5和密钥标签38519的“示例”DNSKEY签名。解析程序需要相应的DNSKEY RR来验证此答案。下面的讨论描述了解析器如何获得此DNSKEY RR。
The RRSIG indicates the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. The "x.w.example.com" MX RRset is placed in canonical form, and, assuming the current time falls between the signature inception and expiration dates, the signature is authenticated.
RRSIG表示MX RRset的原始TTL为3600，为了进行身份验证，将当前TTL替换为3600。RRSIG标签字段值3表示答案不是通配符扩展的结果。“x.w.example.com”MX RRset以规范形式放置，并且假设当前时间介于签名起始日期和到期日期之间，则签名经过身份验证。
This example shows the logical authentication process that starts from the a configured root DNSKEY (or DS RR) and moves down the tree to authenticate the desired "example" DNSKEY RR. Note that the logical order is presented for clarity. An implementation may choose to construct the authentication as referrals are received or to construct the authentication chain only after all RRsets have been obtained, or in any other combination it sees fit. The example here demonstrates only the logical process and does not dictate any implementation rules.
此示例显示了逻辑身份验证过程，该过程从配置的根DNSKEY（或DS RR）开始，并向下移动树以验证所需的“示例”DNSKEY RR。请注意，为清晰起见，给出了逻辑顺序。实现可以选择在接收到引用时构造认证，或者仅在获得所有rrset之后构造认证链，或者选择它认为合适的任何其他组合。这里的示例只演示了逻辑过程，没有规定任何实现规则。
We assume the resolver starts with a configured DNSKEY RR for the root zone (or a configured DS RR for the root zone). The resolver checks whether this configured DNSKEY RR is present in the root DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY RRset, and whether the signature lifetime is valid. If all these
我们假设解析器从根区域配置的DNSKEY RR（或根区域配置的DS RR）开始。冲突解决程序检查此配置的DNSKEY RR是否存在于根DNSKEY RRset中（或DS RR是否与根DNSKEY RRset中的某些DNSKEY匹配），此DNSKEY RR是否已对根DNSKEY RRset签名，以及签名生存期是否有效。如果所有这些
conditions are met, all keys in the DNSKEY RRset are considered authenticated. The resolver then uses one (or more) of the root DNSKEY RRs to authenticate the "example" DS RRset. Note that the resolver may have to query the root zone to obtain the root DNSKEY RRset or "example" DS RRset.
如果满足条件，则DNSKEY RRset中的所有密钥都将被视为经过身份验证。然后，解析器使用一个（或多个）根DNSKEY RRs对“示例”DS RRset进行身份验证。请注意，解析程序可能必须查询根区域才能获得根DNSKEY RRset或“示例”DS RRset。
Once the DS RRset has been authenticated using the root DNSKEY, the resolver checks the "example" DNSKEY RRset for some "example" DNSKEY RR that matches one of the authenticated "example" DS RRs. If such a matching "example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "example" DNSKEY RRset and the signature lifetime is valid. If these conditions are met, all keys in the "example" DNSKEY RRset are considered authenticated.
使用根DNSKEY对DS RRset进行身份验证后，冲突解决程序将检查“示例”DNSKEY RRset中是否存在与已验证的“示例”DS RRs之一匹配的“示例”DNSKEY RR。如果找到这样一个匹配的“示例”DNSKEY，解析程序将检查此DNSKEY RR是否对“示例”DNSKEY RRset进行了签名，并且签名生存期是否有效。如果满足这些条件，“示例”DNSKEY RRset中的所有密钥都被视为已验证。
Finally, the resolver checks that some DNSKEY RR in the "example" DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY is used to authenticate the RRSIG included in the response. If multiple "example" DNSKEY RRs match this algorithm and key tag, then each DNSKEY RR is tried, and the answer is authenticated if any of the matching DNSKEY RRs validate the signature as described above.
最后，解析器检查“示例”DNSKEY RRset中的某些DNSKEY RR是否使用算法5，并且密钥标记是否为38519。此DNSKEY用于验证响应中包含的RRSIG。如果多个“示例”DNSKEY RRs与此算法和密钥标记匹配，则尝试每个DNSKEY RRs，并且如果任何匹配的DNSKEY RRs如上所述验证签名，则验证答案。
The query in Appendix B.2 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs. The NSEC RRs are authenticated in a manner identical to that of the MX RRset discussed above.
附录B.2中的查询返回了NSEC RRs，证明所请求的数据不存在且不适用通配符。通过验证两个NSEC RRs来验证否定回复。NSEC RRs以与上述MX RRset相同的方式进行身份验证。
The query in Appendix B.3 returned an NSEC RR that proves that the requested name exists, but the requested RR type does not exist. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
附录B.3中的查询返回一个NSEC RR，证明请求的名称存在，但请求的RR类型不存在。通过验证NSEC RR来验证否定回复。NSEC RR以与上述MX RRset相同的方式进行身份验证。
The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical to that of the MX RRset discussed above. This DS RR is used to authenticate the "a.example" DNSKEY RRset.
附录B.4中的查询返回了对签名“a.example.”区域的引用。DS RR以与上述MX RRset相同的方式进行身份验证。此DS RR用于验证“a.example”DNSKEY RRset。
Once the "a.example" DS RRset has been authenticated using the "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset for some "a.example" DNSKEY RR that matches the DS RR. If such a matching "a.example" DNSKEY is found, the resolver checks whether
使用“示例”DNSKEY对“a.example”DS RRset进行身份验证后，解析器将检查“a.example”DNSKEY RRset中是否存在与DS RR匹配的“a.example”DNSKEY RR。如果找到匹配的“a.example”DNSKEY，解析器将检查
this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether the signature lifetime is valid. If all these conditions are met, all keys in the "a.example" DNSKEY RRset are considered authenticated.
此DNSKEY RR已对“a.example”DNSKEY RRset进行签名，以及签名生存期是否有效。如果满足所有这些条件，“a.example”DNSKEY RRset中的所有密钥都被视为经过身份验证。
The query in Appendix B.5 returned a referral to an unsigned "b.example." zone. The NSEC proves that no authentication leads from "example" to "b.example", and the NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
附录B.5中的查询返回了对未签名“B.example.”区域的引用。NSEC证明没有从“示例”到“b.example”的认证，NSEC RR的认证方式与上述MX RRset的认证方式相同。
The query in Appendix B.6 returned an answer that was produced as a result of wildcard expansion. The answer section contains a wildcard RRset expanded as it would be in a traditional DNS response, and the corresponding RRSIG indicates that the expanded wildcard MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG indicates that the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 2 indicates that the answer is the result of wildcard expansion, as the "a.z.w.example" name contains 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset is placed in canonical form, and, assuming that the current time falls between the signature inception and expiration dates, the signature is authenticated.
附录B.6中的查询返回的答案是由于通配符扩展而产生的。应答部分包含一个在传统DNS响应中扩展的通配符RRset，相应的RRSIG表示扩展的通配符MX RRset由“示例”DNSKEY使用算法5和密钥标记38519签名。RRSIG表示MX RRset的原始TTL为3600，为了进行身份验证，将当前TTL替换为3600。RRSIG标签字段值2表示答案是通配符扩展的结果，因为“a.z.w.example”名称包含4个标签。名称“a.z.w.w.example”替换为“*.w.example”，MX RRset以规范形式放置，并且假设当前时间介于签名起始日期和到期日期之间，则签名经过身份验证。
The NSEC proves that no closer match (exact or closer wildcard) could have been used to answer this query, and the NSEC RR must also be authenticated before the answer is considered valid.
NSEC证明没有更接近的匹配（精确或更接近的通配符）可用于回答此查询，并且NSEC RR也必须经过身份验证，才能认为答案有效。
The query in Appendix B.7 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs.
附录B.7中的查询返回了NSEC RRs，证明所请求的数据不存在且不适用通配符。通过验证两个NSEC RRs来验证否定回复。
The query in Appendix B.8 returned NSEC RRs that shows the requested was answered by a child server ("example" server). The NSEC RR indicates the presence of an SOA RR, showing that the answer is from the child . Queries for the "example" DS RRset should be sent to the parent servers ("root" servers).
附录B.8中的查询返回了NSEC RRs，显示请求已由子服务器（“示例”服务器）响应。NSEC RR表示存在SOA RR，表明答案来自子级。对“示例”DS RRset的查询应发送到父服务器（“根”服务器）。
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编辑功能的资金目前由互联网协会提供。