Internet Engineering Task Force (IETF) S. Weiler, Ed.
Request for Comments: 6840 SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka, Ed.
Category: Standards Track Verisign, Inc.
ISSN: 2070-1721 February 2013
Internet Engineering Task Force (IETF) S. Weiler, Ed.
Request for Comments: 6840 SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka, Ed.
Category: Standards Track Verisign, Inc.
ISSN: 2070-1721 February 2013
Clarifications and Implementation Notes for DNS Security (DNSSEC)
DNS安全性（DNSSEC）的澄清和实施说明
Abstract
摘要
This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.
本文档是对DNS安全（DNSSEC）文档集的技术澄清的集合。它旨在作为实施者的资源，以及在编写本文时存在的DNSSEC勘误表的集合。
This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.
本文件更新了DNSSEC核心文件（RFC 4033、RFC 4034和RFC 4035）以及NSEC3规范（RFC 5155）。它还将NSEC3和SHA-2（RFC 4509和RFC 5702）定义为DNSSEC规范的核心部分。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6840.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6840.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction and Terminology ....................................4
1.1. Structure of This Document .................................4
1.2. Terminology ................................................4
2. Important Additions to DNSSEC ...................................4
2.1. NSEC3 Support ..............................................4
2.2. SHA-2 Support ..............................................5
3. Scaling Concerns ................................................5
3.1. Implement a BAD Cache ......................................5
4. Security Concerns ...............................................5
4.1. Clarifications on Nonexistence Proofs ......................5
4.2. Validating Responses to an ANY Query .......................6
4.3. Check for CNAME ............................................6
4.4. Insecure Delegation Proofs .................................7
5. Interoperability Concerns .......................................7
5.1. Errors in Canonical Form Type Code List ....................7
5.2. Unknown DS Message Digest Algorithms .......................7
5.3. Private Algorithms .........................................8
5.4. Caution about Local Policy and Multiple RRSIGs .............9
5.5. Key Tag Calculation ........................................9
5.6. Setting the DO Bit on Replies ..............................9
5.7. Setting the AD Bit on Queries .............................10
5.8. Setting the AD Bit on Replies .............................10
5.9. Always Set the CD Bit on Queries ..........................10
5.10. Nested Trust Anchors .....................................11
5.11. Mandatory Algorithm Rules ................................11
5.12. Ignore Extra Signatures from Unknown Keys ................12
6. Minor Corrections and Clarifications ...........................12
6.1. Finding Zone Cuts .........................................12
6.2. Clarifications on DNSKEY Usage ............................12
6.3. Errors in Examples ........................................13
6.4. Errors in RFC 5155 ........................................13
7. Security Considerations ........................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Appendix A. Acknowledgments .......................................16
Appendix B. Discussion of Setting the CD Bit ......................16
Appendix C. Discussion of Trust Anchor Preference Options .........19
C.1. Closest Encloser ..........................................19
C.2. Accept Any Success ........................................20
C.3. Preference Based on Source ................................20
1. Introduction and Terminology ....................................4
1.1. Structure of This Document .................................4
1.2. Terminology ................................................4
2. Important Additions to DNSSEC ...................................4
2.1. NSEC3 Support ..............................................4
2.2. SHA-2 Support ..............................................5
3. Scaling Concerns ................................................5
3.1. Implement a BAD Cache ......................................5
4. Security Concerns ...............................................5
4.1. Clarifications on Nonexistence Proofs ......................5
4.2. Validating Responses to an ANY Query .......................6
4.3. Check for CNAME ............................................6
4.4. Insecure Delegation Proofs .................................7
5. Interoperability Concerns .......................................7
5.1. Errors in Canonical Form Type Code List ....................7
5.2. Unknown DS Message Digest Algorithms .......................7
5.3. Private Algorithms .........................................8
5.4. Caution about Local Policy and Multiple RRSIGs .............9
5.5. Key Tag Calculation ........................................9
5.6. Setting the DO Bit on Replies ..............................9
5.7. Setting the AD Bit on Queries .............................10
5.8. Setting the AD Bit on Replies .............................10
5.9. Always Set the CD Bit on Queries ..........................10
5.10. Nested Trust Anchors .....................................11
5.11. Mandatory Algorithm Rules ................................11
5.12. Ignore Extra Signatures from Unknown Keys ................12
6. Minor Corrections and Clarifications ...........................12
6.1. Finding Zone Cuts .........................................12
6.2. Clarifications on DNSKEY Usage ............................12
6.3. Errors in Examples ........................................13
6.4. Errors in RFC 5155 ........................................13
7. Security Considerations ........................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Appendix A. Acknowledgments .......................................16
Appendix B. Discussion of Setting the CD Bit ......................16
Appendix C. Discussion of Trust Anchor Preference Options .........19
C.1. Closest Encloser ..........................................19
C.2. Accept Any Success ........................................20
C.3. Preference Based on Source ................................20
This document lists some additions, clarifications, and corrections to the core DNSSEC specification, as originally described in [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. (See Section 2 for more recent additions to that core document set.)
本文件列出了对核心DNSSEC规范的一些补充、澄清和更正，如[RFC4033]、[RFC4034]和[RFC4035]中所述，随后由[RFC5155]修订。（有关该核心文档集最近添加的内容，请参见第2节。）
It is intended to serve as a resource for implementors and as a repository of items existing at the time of writing that need to be addressed when advancing the DNSSEC documents along the Standards Track.
它旨在作为实施者的资源，并作为编写本报告时存在的项目的存储库，在沿着标准轨道推进DNSSEC文档时需要解决这些问题。
The clarifications and changes to DNSSEC are sorted according to their importance, starting with ones which could, if ignored, lead to security problems and progressing down to clarifications that are expected to have little operational impact.
DNSSEC的澄清和变更根据其重要性进行分类，首先是那些如果忽略可能导致安全问题的澄清和变更，然后是那些预计不会对运营产生什么影响的澄清。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This section lists some documents that are now considered core DNSSEC protocol documents in addition to those originally specified in Section 10 of [RFC4033].
本节列出了除[RFC4033]第10节中最初规定的文件外，现在被视为核心DNSSEC协议文件的一些文件。
[RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM records for hashed denial of existence. Validator implementations are strongly encouraged to include support for NSEC3 because a number of highly visible zones use it. Validators that do not support validation of responses using NSEC3 will be hampered in validating large portions of the DNS space.
[RFC5155]描述了NSEC3和NSEC3PARAM记录在哈希拒绝存在时的使用和行为。强烈建议验证程序实现包括对NSEC3的支持，因为许多高度可见的区域都使用它。不支持使用NSEC3验证响应的验证器将在验证大部分DNS空间时受到阻碍。
[RFC5155] is now considered part of the DNS Security Document Family as described by Section 10 of [RFC4033].
[RFC5155]现在被视为DNS安全文档系列的一部分，如[RFC4033]第10节所述。
Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3- SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512) signal that a zone might be using NSEC3, rather than NSEC. The zone may be using either, and validators supporting these algorithms MUST support both NSEC3 and NSEC responses.
请注意，[RFC5155]（DSA-NSEC3-SHA1和RSASHA1-NSEC3-SHA1）和[RFC5702]（RSASA256和RSASHA512）中定义的算法标识符表示区域可能正在使用NSEC3，而不是NSEC。区域可能使用其中一种，支持这些算法的验证器必须同时支持NSEC3和NSEC响应。
[RFC4509] describes the use of SHA-256 as a digest algorithm in Delegation Signer (DS) RRs. [RFC5702] describes the use of the RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. Validator implementations are strongly encouraged to include support for these algorithms for DS, DNSKEY, and RRSIG records.
[RFC4509]描述了在委托签名者（DS）RRs中使用SHA-256作为摘要算法。[RFC5702]介绍了RSASA256和RSASHA512算法在DNSKEY和RRSIG RRs中的使用。强烈建议验证程序实现包括对DS、DNSKEY和RRSIG记录的这些算法的支持。
Both [RFC4509] and [RFC5702] are now considered part of the DNS Security Document Family as described by Section 10 of [RFC4033].
[RFC4509]和[RFC5702]现在都被视为DNS安全文档系列的一部分，如[RFC4033]第10节所述。
Section 4.7 of [RFC4035] permits security-aware resolvers to implement a BAD cache. That guidance has changed: security-aware resolvers SHOULD implement a BAD cache as described in [RFC4035].
[RFC4035]第4.7节允许安全感知解析器实现坏缓存。该指南已经改变：安全感知解析器应该实现[RFC4035]中描述的坏缓存。
This change in guidance is based on operational experience with DNSSEC administrative errors leading to significant increases in DNS traffic, with an accompanying realization that such events are more likely and more damaging than originally supposed. An example of one such event is documented in "Rolling Over DNSSEC Keys" [Huston].
该指南的变化基于DNSSEC管理错误导致DNS流量显著增加的运行经验，同时认识到此类事件的可能性和破坏性比最初设想的更大。“滚动DNSSEC密钥”[Huston]中记录了一个此类事件的示例。
This section provides clarifications that, if overlooked, could lead to security issues.
本节提供了一些澄清，如果忽略这些澄清，可能会导致安全问题。
Section 5.4 of [RFC4035] under-specifies the algorithm for checking nonexistence proofs. In particular, the algorithm as presented would allow a validator to interpret an NSEC or NSEC3 RR from an ancestor zone as proving the nonexistence of an RR in a child zone.
下[RFC4035]第5.4节规定了检查不存在证明的算法。特别是，所提出的算法将允许验证器将来自祖先区域的NSEC或NSEC3 RR解释为证明子区域中不存在RR。
An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
“祖先委派”NSEC RR（或NSEC3 RR）是指具有以下特征的委派：
o the NS bit set,
o NS位设置，
o the Start of Authority (SOA) bit clear, and
o 权威的开始（SOA）有点清晰，并且
o a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR.
o 短于NSEC RR的所有者名称或NSEC3 RR的原始所有者名称的签名者字段。
Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that (original) owner name other than DS RRs, and all RRs below that owner name regardless of type.
祖先授权NSEC或NSEC3 RRs不得用于假设该区域切割下方不存在任何RRs，包括除DS RRs以外的该（原始）所有者名称处的所有RRs，以及该所有者名称下方的所有RRs，无论其类型如何。
Similarly, the algorithm would also allow an NSEC RR at the same owner name as a DNAME RR, or an NSEC3 RR at the same original owner name as a DNAME, to prove the nonexistence of names beneath that DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's (original) owner name.
类似地，该算法还允许与DNAME RR具有相同所有者名称的NSEC RR，或与DNAME具有相同原始所有者名称的NSEC3 RR，以证明该DNAME下不存在名称。设置了DNAME位的NSEC或NSEC3 RR不得用于假定该NSEC/NSEC3 RR（原始）所有者名称的任何子域不存在。
[RFC4035] does not address how to validate responses when QTYPE=*. As described in Section 6.2.2 of [RFC1034], a proper response to QTYPE=* may include a subset of the RRsets at a given name. That is, it is not necessary to include all RRsets at the QNAME in the response.
[RFC4035]未说明当QTYPE=*时如何验证响应。如[RFC1034]第6.2.2节所述，对QTYPE=*的正确响应可能包括给定名称处的RRSET子集。也就是说，没有必要在响应中包含QNAME处的所有RRSET。
When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS MUST be validated. If any of those RRsets fail validation, the answer is considered Bogus. If there are no RRsets matching QNAME and QCLASS, that fact MUST be validated according to the rules in Section 5.4 of [RFC4035] (as clarified in this document). To be clear, a validator must not expect to receive all records at the QNAME in response to QTYPE=*.
验证对QTYPE=*的响应时，必须验证所有接收到的与QNAME和QCLASS匹配的rrset。如果这些RRSET中的任何一个未通过验证，则认为答案是假的。如果没有与QNAME和QCLASS匹配的RRSET，则必须根据[RFC4035]第5.4节中的规则验证该事实（如本文件所述）。需要明确的是，验证器不能期望在QNAME处接收所有记录以响应QTYPE=*。
Section 5 of [RFC4035] says nothing explicit about validating responses based on (or that should be based on) CNAMEs. When validating a NOERROR/NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the bit for the query type.
[RFC4035]的第5节没有明确说明如何验证基于（或应该基于）CNAMEs的响应。验证NOERROR/NODATA响应时，验证程序必须检查匹配的NSEC或NSEC3 RR类型位图中的CNAME位以及查询类型的位。
Without this check, an attacker could successfully transform a positive CNAME response into a NOERROR/NODATA response by (for example) simply stripping the CNAME RRset from the response. A naive validator would then note that the QTYPE was not present in the matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was set; thus, the response should have been a positive CNAME response.
如果不进行此检查，攻击者可以通过（例如）简单地从响应中剥离CNAME RRset，成功地将肯定的CNAME响应转换为NOERROR/NODATA响应。然后，天真的验证器会注意到QTYPE不存在于匹配的NSEC/NSEC3 RR中，但没有注意到设置了CNAME位；因此，回应应该是积极的CNAME回应。
Section 5.2 of [RFC4035] specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also MUST check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or alternately make sure that the delegation is covered by an NSEC3 RR with the Opt-Out flag set.
[RFC4035]第5.2节规定，验证程序在证明委托不安全时，需要检查NSEC（或NSEC3）类型位图中是否缺少DS和SOA位。验证器还必须检查匹配的NSEC（或NSEC3）RR中是否存在NS位（证明确实存在委派），或者交替地确保委派由设置了退出标志的NSEC3 RR覆盖。
Without this check, an attacker could reuse an NSEC or NSEC3 RR matching a non-delegation name to spoof an unsigned delegation at that name. This would claim that an existing signed RRset (or set of signed RRsets) is below an unsigned delegation, thus not signed and vulnerable to further attack.
如果不进行此检查，攻击者可以重用与非委派名称匹配的NSEC或NSEC3 RR来欺骗该名称处的未签名委派。这将声称现有的已签名RRset（或一组已签名RRset）低于未签名的委派，因此未签名且易受进一步攻击。
When canonicalizing DNS names (for both ordering and signing), DNS names in the RDATA section of NSEC resource records are not converted to lowercase. DNS names in the RDATA section of RRSIG resource records are converted to lowercase.
规范化DNS名称（用于排序和签名）时，NSEC资源记录的RDATA部分中的DNS名称不会转换为小写。RRSIG资源记录的RDATA部分中的DNS名称转换为小写。
The guidance in the above paragraph differs from what has been published before but is consistent with current common practice. Item 3 of Section 6.2 of [RFC4034] says that names in both of these RR types should be converted to lowercase. The earlier [RFC3755] says that they should not. Current practice follows neither document fully.
上述段落中的指南与之前发布的指南不同，但与当前的常规做法一致。[RFC4034]第6.2节第3项规定，这两种RR类型的名称都应转换为小写。早些时候的[RFC3755]说他们不应该这样做。目前的做法没有完全遵循这两份文件。
Section 6.2 of [RFC4034] also erroneously lists HINFO as a record that needs conversion to lowercase, and twice at that. Since HINFO records contain no domain names, they are not subject to case conversion.
[RFC4034]的第6.2节也错误地将HINFO列为需要转换为小写的记录，并且两次都是这样。由于HINFO记录不包含域名，因此不需要进行大小写转换。
Section 5.2 of [RFC4035] includes rules for how to handle delegations to zones that are signed with entirely unsupported public key algorithms, as indicated by the key algorithms shown in those zones' DS RRsets. It does not explicitly address how to handle DS records that use unsupported message digest algorithms. In brief, DS records using unknown or unsupported message digest algorithms MUST be treated the same way as DS records referring to DNSKEY RRs of unknown or unsupported public key algorithms.
[RFC4035]第5.2节包括如何处理对使用完全不受支持的公钥算法签名的区域的委托的规则，如这些区域的DS RRSET中显示的密钥算法所示。它没有明确说明如何处理使用不受支持的消息摘要算法的DS记录。简言之，使用未知或不支持的消息摘要算法的DS记录必须以与引用未知或不支持的公钥算法的DNSKEY RRs的DS记录相同的方式处理。
The existing text says:
现有案文说：
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的情况。
In other words, when determining the security status of a zone, a validator disregards any authenticated DS records that specify unknown or unsupported DNSKEY algorithms. If none are left, the zone is treated as if it were unsigned.
换句话说，在确定区域的安全状态时，验证器会忽略指定未知或不受支持的DNSKEY算法的任何经过身份验证的DS记录。如果没有留下任何标记，则区域将被视为未签名。
This document modifies the above text to additionally disregard authenticated DS records using unknown or unsupported message digest algorithms.
本文档修改了上述文本，使用未知或不受支持的消息摘要算法来另外忽略经过身份验证的DS记录。
As discussed above, Section 5.2 of [RFC4035] requires that validators make decisions about the security status of zones based on the public key algorithms shown in the DS records for those zones. In the case of private algorithms, as described in Appendix A.1.1 of [RFC4034], the eight-bit algorithm field in the DS RR is not conclusive about what algorithm(s) is actually in use.
如上所述，[RFC4035]第5.2节要求验证器根据这些区域的DS记录中显示的公钥算法，对区域的安全状态做出决定。对于专用算法，如[RFC4034]附录A.1.1所述，DS RR中的八位算法字段不能确定实际使用的算法。
If no private algorithms appear in the DS RRset, or if any supported algorithm appears in the DS RRset, no special processing is needed. Furthermore, if the validator implementation does not support any private algorithms, or only supports private algorithms using an algorithm number not present in the DS RRset, no special processing is needed.
如果DS RRset中没有出现私有算法，或者DS RRset中出现任何受支持的算法，则无需进行特殊处理。此外，如果验证器实现不支持任何私有算法，或者仅支持使用DS RRset中不存在的算法编号的私有算法，则不需要特殊处理。
In the remaining cases, the security status of the zone depends on whether or not the resolver supports any of the private algorithms in use (provided that these DS records use supported message digest algorithms, as discussed in Section 5.2 of this document). In these cases, the resolver MUST retrieve the corresponding DNSKEY for each private algorithm DS record and examine the public key field to determine the algorithm in use. The security-aware resolver MUST ensure that the hash of the DNSKEY RR's owner name and RDATA matches the digest in the DS RR as described in Section 5.2 of [RFC4035], authenticating the DNSKEY. If all of the retrieved and authenticated DNSKEY RRs use unknown or unsupported private algorithms, then the zone is treated as if it were unsigned.
在其余情况下，区域的安全状态取决于解析器是否支持任何正在使用的私有算法（前提是这些DS记录使用支持的消息摘要算法，如本文档第5.2节所述）。在这些情况下，解析器必须为每个私有算法DS记录检索相应的DNSKEY，并检查公钥字段以确定正在使用的算法。具有安全意识的解析器必须确保DNSKEY RR的所有者名称和RDATA的哈希与[RFC4035]第5.2节所述DS RR中的摘要相匹配，以验证DNSKEY。如果所有检索和验证的DNSKEY RRs都使用未知或不受支持的私有算法，则区域将被视为未签名。
Note that if none of the private algorithm DS RRs can be securely matched to DNSKEY RRs and no other DS establishes that the zone is secure, the referral should be considered Bogus data as discussed in [RFC4035].
请注意，如果没有一个专用算法DS RRs可以安全地与DNSKEY RRs匹配，并且没有其他DS确定该区域是安全的，则该引用应被视为虚假数据，如[RFC4035]中所述。
This clarification facilitates the broader use of private algorithms, as suggested by [RFC4955].
正如[RFC4955]所建议的，这种澄清有助于更广泛地使用私有算法。
When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035] suggests that "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覆盖给定的RRset时，[RFC4035]第5.3.3节建议“本地冲突解决程序安全策略确定冲突解决程序是否也必须测试这些RRSIG RRs，以及如果这些RRSIG RRs导致不同的结果，如何解决冲突”。
This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation.
本文档规定，冲突解决程序应接受任何有效的RRSIG，并仅在所有RRSIG未通过验证时确定RRset为伪RRSIG。
If a resolver adopts a more restrictive policy, there's a danger that properly signed data might unnecessarily fail validation due to cache timing issues. Furthermore, certain zone management techniques, like the Double Signature Zone Signing Key Rollover method described in Section 4.2.1.2 of [RFC6781], will not work reliably. Such a resolver is also vulnerable to malicious insertion of gibberish signatures.
如果冲突解决程序采用更严格的策略，则存在一种危险，即正确签名的数据可能由于缓存计时问题而不必要地无法通过验证。此外，某些区域管理技术，如[RFC6781]第4.2.1.2节中描述的双重签名区域签名密钥翻转方法，将无法可靠工作。这样的解析器也容易受到恶意插入胡言乱语签名的攻击。
Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field calculation for algorithm 1. It correctly says that the Key Tag is the most significant 16 of the least significant 24 bits of the public key modulus. However, [RFC4034] then goes on to incorrectly say that this is fourth-to-last and third-to-last octets of the public key modulus. It is, in fact, the third-to-last and second-to-last octets.
[RFC4034]的附录B.1错误地定义了算法1的密钥标签字段计算。它正确地表示密钥标签是公钥模的最低有效24位中的最高有效16位。然而，[RFC4034]接着错误地说这是公钥模的第四到最后和第三到最后的八位字节。事实上，它是倒数第三和倒数第二个八位组。
As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the query MUST be copied in the response. However, in order to interoperate with implementations that ignore this rule on sending, resolvers MUST ignore the DO bit in responses.
如[RFC3225]第3节所述，必须在响应中复制查询的DNSSEC OK（DO）位。但是，为了与在发送时忽略此规则的实现进行互操作，解析程序必须忽略响应中的DO位。
The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries.
查询中真实数据（AD）位的语义以前未定义。[RFC4035]第4.6节指示解析器在编写查询时始终清除AD位。
This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit.
本文档将查询中的AD位设置定义为一个信号，表示请求者理解并对响应中的AD位的值感兴趣。这允许请求者指示其理解AD位，而无需通过DO位请求DNSSEC数据。
Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit.
[RFC4035]第3.2.3节描述了验证解析器应在何种条件下设置或清除响应中的AD位。为了与既不理解也不忽略AD位的传统存根解析程序和中间盒进行互操作，验证解析程序只应在响应同时满足[RFC4035]第3.2.3节中列出的条件且请求包含set DO位或set AD位时设置AD位。
When processing a request with the Checking Disabled (CD) bit set, a resolver SHOULD attempt to return all response data, even data that has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a resolver processing a request with the CD bit set to set the CD bit on its upstream queries.
当处理设置了检查禁用（CD）位的请求时，解析程序应尝试返回所有响应数据，即使是未通过DNSSEC验证的数据。[RFC4035]第3.2.2节要求解析器处理设置了CD位的请求，以在其上游查询中设置CD位。
This document further specifies that validating resolvers SHOULD set the CD bit on every upstream query. This is regardless of whether the CD bit was set on the incoming query or whether it has a trust anchor at or above the QNAME.
本文档进一步规定验证解析器应在每个上游查询上设置CD位。这与是否在传入查询上设置了CD位或是否在QNAME上或之上有信任锚点无关。
[RFC4035] is ambiguous about what to do when a cached response was obtained with the CD bit unset, a case that only arises when the resolver chooses not to set the CD bit on all upstream queries, as specified above. In the typical case, no new query is required, nor does the cache need to track the state of the CD bit used to make a given query. The problem arises when the cached response is a server failure (RCODE 2), which may indicate that the requested data failed DNSSEC validation at an upstream validating resolver. ([RFC2308] permits caching of server failures for up to five minutes.) In these cases, a new query with the CD bit set is required.
[RFC4035]对于在未设置CD位的情况下获得缓存响应时应该做什么不明确，这种情况仅在解析程序选择不对所有上游查询设置CD位时出现，如上所述。在典型情况下，不需要新查询，缓存也不需要跟踪用于进行给定查询的CD位的状态。当缓存的响应是服务器故障（RCODE 2）时，会出现问题，这可能表示请求的数据未通过上游验证解析程序的DNSSEC验证。（[RFC2308]允许将服务器故障缓存最多五分钟。）在这些情况下，需要使用CD位设置的新查询。
Appendix B discusses more of the logic behind the recommendation presented in this section.
附录B讨论了本节建议背后的更多逻辑。
A DNSSEC validator may be configured such that, for a given response, more than one trust anchor could be used to validate the chain of trust to the response zone. For example, imagine a validator configured with trust anchors for "example." and "zone.example." When the validator is asked to validate a response to "www.sub.zone.example.", either trust anchor could apply.
DNSSEC验证器可以配置为，对于给定的响应，可以使用多个信任锚来验证到响应区域的信任链。例如，假设一个验证器配置了信任锚，例如“example.”和“zone.example.”。当要求验证器验证对“www.sub.zone.example.”的响应时，任何一个信任锚都可以应用。
When presented with this situation, DNSSEC validators have a choice of which trust anchor(s) to use. Which to use is a matter of implementation choice. Appendix C discusses several possible algorithms.
当出现这种情况时，DNSSEC验证器可以选择使用哪个信任锚。使用哪一个是实现选择的问题。附录C讨论了几种可能的算法。
It is possible and advisable to expose the choice of policy as a configuration option. As a default, it is suggested that validators implement the "Accept Any Success" policy described in Appendix C.2 while exposing other policies as configuration options.
将策略选择作为配置选项公开是可能的，也是可取的。默认情况下，建议验证器实现附录C.2中描述的“接受任何成功”策略，同时将其他策略作为配置选项公开。
The "Accept Any Success" policy is to try all applicable trust anchors until one gives a validation result of Secure, in which case the final validation result is Secure. If and only if all applicable trust anchors give a result of Insecure, the final validation result is Insecure. If one or more trust anchors lead to a Bogus result and there is no Secure result, then the final validation result is Bogus.
“接受任何成功”策略是尝试所有适用的信任锚，直到其中一个给出安全的验证结果，在这种情况下，最终的验证结果是安全的。如果且仅当所有适用的信任锚给出不安全的结果，则最终验证结果是不安全的。如果一个或多个信任锚导致虚假结果，并且没有安全结果，则最终验证结果是虚假的。
The last paragraph of Section 2.2 of [RFC4035] includes rules describing which algorithms must be used to sign a zone. Since these rules have been confusing, they are restated using different language here:
[RFC4035]第2.2节的最后一段包括描述必须使用哪些算法对区域进行签名的规则。由于这些规则令人困惑，因此在此处使用不同的语言对其进行重述：
The DS RRset and DNSKEY RRset are used to signal which algorithms are used to sign a zone. The presence of an algorithm in either a zone's DS or DNSKEY RRset signals that that algorithm is used to sign the entire zone.
DS RRset和DNSKEY RRset用于指示用于为区域签名的算法。区域DS或DNSKEY RRset中的算法表示该算法用于对整个区域进行签名。
A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset. It is possible to add algorithms at the DNSKEY that aren't in the DS record, but not vice versa. If more than one key of the same algorithm is in the DNSKEY RRset, it is sufficient to sign each RRset with any subset of these DNSKEYs. It is acceptable to sign some RRsets with one subset of keys (or key) and other RRsets with a different subset, so long as at least
签名区域必须包含区域DS RRset中存在的每个算法的DNSKEY以及该区域的预期信任锚。还必须使用DNSKEY RRset中存在的每个算法（但不是每个密钥）对区域进行签名。可以在DNSKEY添加不在DS记录中的算法，但反之亦然。如果DNSKEY RRset中有多个相同算法的密钥，则用这些DNSKEY的任何子集对每个RRset进行签名就足够了。可以使用一个子集密钥（或密钥）对某些RRSET进行签名，并使用不同的子集对其他RRSET进行签名，只要至少
one DNSKEY of each algorithm is used to sign each RRset. Likewise, if there are DS records for multiple keys of the same algorithm, any subset of those may appear in the DNSKEY RRset.
每个算法的一个DNSKEY用于对每个RRset进行签名。同样，如果同一算法的多个密钥存在DS记录，则这些密钥的任何子集都可能出现在DNSKEY RRset中。
This requirement applies to servers, not validators. Validators SHOULD accept any single valid path. They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work. A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting.
此要求适用于服务器，而不是验证器。验证器应该接受任何单一的有效路径。他们不应坚持DS RRset中的所有算法都有效，也不应坚持DNSKEY RRset中的所有算法都有效。验证器可能有一个配置选项来执行签名完整性测试，以支持故障排除。
Validating resolvers MUST disregard RRSIGs in a zone that do not (currently) have a corresponding DNSKEY in the zone. Similarly, a validating resolver MUST disregard RRSIGs with algorithm types that don't exist in the DNSKEY RRset.
验证解析程序必须忽略区域中（当前）没有相应DNSKEY的RRSIG。类似地，验证解析器必须忽略具有DNSKEY RRset中不存在的算法类型的RRSIG。
Good key rollover and algorithm rollover practices, as discussed in RFC 6781 and its successor documents and as suggested by the rules in the previous section, may require that such RRSIGs be present in a zone.
RFC 6781及其后续文件中讨论的以及上一节规则中建议的良好密钥翻转和算法翻转实践可能要求区域中存在此类RRSIG。
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers for a parent zone but does not state how to find those servers. Specific instructions can be found in Section 4.2 of [RFC4035].
[RFC4035]的附录C.8讨论了向父区域的服务器发送DS查询，但未说明如何查找这些服务器。具体说明见[RFC4035]第4.2节。
It is possible to use different DNSKEYs to sign different subsets of a zone, constrained only by the rules in Section 5.11. It is even possible to use a different DNSKEY for each RRset in a zone, subject only to practical limits on the size of the DNSKEY RRset and the above rules. However, be aware that there is no way to tell resolvers what a particular DNSKEY is supposed to be used for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate any RRset in the zone. For example, if a weaker or less trusted DNSKEY is being used to authenticate NSEC RRsets or all dynamically updated records, that same DNSKEY can also be used to sign any other RRsets from the zone.
可以使用不同的DNSKEY对分区的不同子集进行签名，仅受第5.11节规则的约束。甚至可以为区域中的每个RRset使用不同的DNSKEY，但仅限于DNSKEY RRset大小的实际限制和上述规则。但是，请注意，无法告诉解析程序特定DNSKEY应该用于什么——区域的签名DNSKEY RRset中的任何DNSKEY都可以用于验证区域中的任何RRset。例如，如果使用较弱或不太可信的DNSKEY对NSEC RRSET或所有动态更新的记录进行身份验证，则该DNSKEY也可用于对区域中的任何其他RRSET进行签名。
Furthermore, note that the SEP bit setting has no effect on how a DNSKEY may be used -- the validation process is specifically prohibited from using that bit by Section 2.1.2 of [RFC4034]. It is
此外，请注意，SEP位设置对DNSKEY的使用方式没有影响，[RFC4034]第2.1.2节明确禁止验证过程使用该位。它是
possible to use a DNSKEY without the SEP bit set as the sole secure entry point to the zone, yet use a DNSKEY with the SEP bit set to sign all RRsets in the zone (other than the DNSKEY RRset). It is also possible to use a single DNSKEY, with or without the SEP bit set, to sign the entire zone, including the DNSKEY RRset itself.
可以使用未设置SEP位的DNSKEY作为区域的唯一安全入口点，但使用设置SEP位的DNSKEY对区域中的所有RRset（DNSKEY RRset除外）进行签名。也可以使用单个DNSKEY（带或不带SEP位集）对整个区域（包括DNSKEY RRset本身）进行签名。
The text in Appendix C.1 of [RFC4035] refers to the examples in Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This is painfully obvious in the second paragraph where it states that the RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. This is true for "x.w.example" but not for "x.w.example.com", which of course has a label count of 4 (antithetically, a label count of 3 would imply the answer was the result of a wildcard expansion).
[RFC4035]附录C.1中的文本将附录B.1中的示例称为“x.w.example.com”，而B.1使用“x.w.example”。这在第二段中非常明显，其中指出RRSIG标签字段值3表示答案不是通配符扩展的结果。这对于“x.w.example”是正确的，但对于“x.w.example.com”则不是这样，它的标签计数当然为4（相反，标签计数为3意味着答案是通配符扩展的结果）。
The first paragraph of Appendix C.6 of [RFC4035] also has a minor error: the reference to "a.z.w.w.example" should instead be "a.z.w.example", as in the previous line.
[RFC4035]附录C.6的第一段也有一个小错误：参考“a.z.w.w.example”应改为“a.z.w.example”，如前一行所示。
An NSEC3 record that matches an Empty Non-Terminal effectively has no type associated with it. This NSEC3 record has an empty type bit map. Section 3.2.1 of [RFC5155] contains the statement:
与空非终端有效匹配的NSEC3记录没有与其关联的类型。此NSEC3记录具有空类型位图。[RFC5155]第3.2.1节包含以下声明：
Blocks with no types present MUST NOT be included.
不包括不存在类型的块。
However, the same section contains a regular expression:
但是，同一节包含一个正则表达式：
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
The plus sign in the regular expression indicates that there is one or more of the preceding element. This means that there must be at least one window block. If this window block has no types, it contradicts with the first statement. Therefore, the correct text in Section 3.2.1 of [RFC5155] should be:
正则表达式中的加号表示前面有一个或多个元素。这意味着必须至少有一个窗口块。如果此窗口块没有类型，则与第一条语句冲突。因此，[RFC5155]第3.2.1节中的正确文本应为：
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
This document adds SHA-2 and NSEC3 support to the core DNSSEC protocol. Security considerations for those features are discussed in the documents defining them. Additionally, this document addresses some ambiguities and omissions in the core DNSSEC documents that, if not recognized and addressed in implementations, could lead
本文档将SHA-2和NSEC3支持添加到核心DNSSEC协议中。在定义这些功能的文档中讨论了这些功能的安全注意事项。此外，本文件解决了DNSSEC核心文件中的一些模糊和遗漏，如果在实施过程中未得到识别和解决，可能导致
to security failures. In particular, the validation algorithm clarifications in Section 4 are critical for preserving the security properties DNSSEC offers. Furthermore, failure to address some of the interoperability concerns in Section 5 could limit the ability to later change or expand DNSSEC, including adding new algorithms.
安全性故障。特别是，第4节中的验证算法说明对于保护DNSSEC提供的安全属性至关重要。此外，未能解决第5节中的一些互操作性问题可能会限制以后更改或扩展DNSSEC的能力，包括添加新算法。
The recommendation in Section 5.9 to always set the CD bit has security implications. By setting the CD bit, a resolver will not benefit from more stringent validation rules or a more complete set of trust anchors at an upstream validator.
第5.9节中关于始终设置CD位的建议具有安全含义。通过设置CD位，解析程序将不会受益于更严格的验证规则或上游验证器上更完整的信任锚。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[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月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]Conrad，D.“指示DNSSEC的分解器支持”，RFC 3225，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 the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509]Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，2006年5月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，2009年10月。
[Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston, "Rolling Over DNSSEC Keys", Internet Protocol Journal, Vol. 13, No.1, pp. 2-16, March 2010.
[Huston]Michaelson，G.，Wallstrom，P.，Arends，R.，和G.Huston，“滚动DNSSEC密钥”，互联网协议杂志，第13卷，第1期，第2-16页，2010年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月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755]Weiler，S.“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年5月。
[RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, July 2007.
[RFC4955]Blacka，D.，“DNS安全（DNSSEC）实验”，RFC 49552007年7月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 50111907年9月。
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007.
[RFC5074]Weiler，S.，“DNSSEC后备验证（DLV）”，RFC 5074，2007年11月。
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, December 2012.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，2012年12月。
The editors would like the thank Rob Austein for his previous work as an editor of this document.
编辑们要感谢Rob Austein，感谢他之前作为本文件编辑所做的工作。
The editors are extremely grateful to those who, in addition to finding errors and omissions in the DNSSEC document set, have provided text suitable for inclusion in this document.
编辑们非常感谢那些除了在DNSSEC文件集中发现错误和遗漏之外，还提供了适合纳入本文件的文本的人。
The lack of specificity about handling private algorithms, as described in Section 5.3, and the lack of specificity in handling ANY queries, as described in Section 4.2, were discovered by David Blacka.
David Black发现，如第5.3节所述，在处理私有算法方面缺乏特异性，以及如第4.2节所述，在处理任何查询方面缺乏特异性。
The error in algorithm 1 key tag calculation, as described in Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake contributed text for Section 5.5.
Abhijit Hayatnagarkar发现第5.5节所述的算法1密钥标签计算错误。唐纳德·伊斯特莱克为第5.5节提供了文本。
The bug relating to delegation NSEC RR's in Section 4.1 was found by Roy Badami. Roy Arends found the related problem with DNAME.
Roy Badami发现了第4.1节中与NSEC RR授权相关的错误。罗伊·阿伦兹发现了DNAME的相关问题。
The errors in the [RFC4035] examples were found by Roy Arends, who also contributed text for Section 6.3 of this document.
[RFC4035]示例中的错误由Roy Arends发现，他也为本文件第6.3节提供了文本。
Text on the mandatory algorithm rules was derived from suggestions by Matthijs Mekking and Ed Lewis.
强制性算法规则的文本来源于Matthijs Mekking和Ed Lewis的建议。
The CD bit logic was analyzed in depth by David Blacka, Olafur Gudmundsson, Mike St. Johns, and Andrew Sullivan.
David Black、Olafur Gudmundsson、Mike St.Johns和Andrew Sullivan对CD位逻辑进行了深入分析。
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer, Warren Kumari and Scott Rose for their contributions to this document.
编辑们要感谢阿尔弗雷德·霍恩斯、埃德·刘易斯、丹尼·梅耶、奥拉弗尔·古德蒙德森、苏珊娜·伍尔夫、里卡德·贝尔格林、迈克·圣约翰、马克·安德鲁斯、沃特·维恩加德斯、马提斯·梅金、安德鲁·沙利文、杰里米·里德、保罗·霍夫曼、莫汉·帕塔萨拉西、弗洛里安·魏默、沃伦·库马里和斯科特·罗斯对本文件的贡献。
[RFC4035] may be read as relying on the implicit assumption that there is at most one validating system between the stub resolver and the authoritative server for a given zone. It is entirely possible, however, for more than one validator to exist between a stub resolver and an authoritative server. If these different validators have disjoint trust anchors configured, then it is possible that each would be able to validate some portion of the DNS tree, but neither
[RFC4035]可以理解为依赖于一个隐含的假设，即对于给定区域，存根解析器和权威服务器之间最多有一个验证系统。但是，存根解析器和权威服务器之间完全可能存在多个验证器。如果这些不同的验证器配置了不相交的信任锚，那么每个验证器都可能能够验证DNS树的某些部分，但两者都不能
is able to validate all of it. Accordingly, it might be argued that it is desirable not to set the CD bit on upstream queries, because that allows for maximal validation.
能够验证所有这些。因此，可能有人认为，最好不要在上游查询上设置CD位，因为这允许最大限度的验证。
In Section 5.9 of this document, it is recommended to set the CD bit on an upstream query even when the incoming query arrives with CD=0. This is for two reasons: it encourages a more predictable validation experience as only one validator is always doing the validation, and it ensures that all DNSSEC data that exists may be available from the local cache should a query with CD=1 arrive.
在本文档第5.9节中，建议在上游查询上设置CD位，即使传入查询到达时CD=0。这有两个原因：它鼓励更可预测的验证体验，因为只有一个验证器始终在进行验证，并确保存在的所有DNSSEC数据在CD=1的查询到达时可以从本地缓存中获得。
As a matter of policy, it is possible to set the CD bit differently than suggested in Section 5.9. A different choice will, of course, not always yield the benefits listed above. It is beyond the scope of this document to outline all of the considerations and counter considerations for all possible policies. Nevertheless, it is possible to describe three approaches and their underlying philosophy of operation. These are laid out in the tables below.
根据政策，可以将CD位设置为与第5.9节中建议的不同。当然，不同的选择并不总是能带来上面列出的好处。概述所有可能政策的所有考虑因素和反考虑因素超出了本文件的范围。然而，可以描述三种方法及其基本的操作哲学。下表列出了这些内容。
The table that describes each model has five columns. The first column indicates the value of the CD bit that the resolver receives (for instance, on the name server side in an iterative resolver, or as local policy or from the API in the case of a stub). The second column indicates whether the query needs to be forwarded for resolution (F) or can be satisfied from a local cache (C). The third column is a line number, so that it can be referred to later in the table. The fourth column indicates any relevant conditions at the resolver, for example, whether the resolver has a covering trust anchor, and so on. If there are no parameters here, the column is empty. The fifth and final column indicates what action the resolver takes.
描述每个模型的表有五列。第一列指示解析程序接收的CD位的值（例如，在迭代解析程序中的名称服务器端，或者作为本地策略，或者在存根的情况下从API接收）。第二列指示查询是需要转发以进行解析（F），还是可以从本地缓存（C）中得到满足。第三列是行号，以便稍后在表中引用。第四列指示冲突解决程序的任何相关条件，例如，冲突解决程序是否具有覆盖信任锚点，等等。如果此处没有参数，则该列为空。第五列（也是最后一列）指示冲突解决程序执行的操作。
The tables differentiate between "cached data" and "cached RCODE=2". This is a shorthand; the point is that one has to treat RCODE=2 (server failure) as special, because it might indicate a validation failure somewhere upstream. The distinction is really between "cached RCODE=2" and "cached everything else".
这些表区分“缓存数据”和“缓存RCODE=2”。这是速记；关键是必须将RCODE=2（服务器故障）视为特殊的，因为它可能表示上游某个地方的验证失败。区别在于“cached RCODE=2”和“cached everythis”。
The tables are probably easiest to think of in terms of describing what happens when a stub resolver sends a query to an intermediate resolver, but they are perfectly general and can be applied to any validating resolver.
在描述存根解析器向中间解析器发送查询时发生的情况方面，这些表可能是最容易想到的，但它们非常通用，可以应用于任何验证解析器。
Model 1: "always set"
模型1：“始终设置”
This model is so named because the validating resolver sets the CD bit on queries it makes regardless of whether it has a covering trust anchor for the query. The general philosophy represented by this
此模型之所以如此命名，是因为验证解析器在其进行的查询上设置CD位，而不管其是否具有查询的覆盖信任锚。这所代表的一般哲学
table is that only one resolver should be responsible for validation irrespective of the possibility that an upstream resolver may be present with trust anchors that cover different or additional QNAMEs. It is the model recommended in Section 5.9 of this document.
表中显示，无论上游冲突解决程序是否可能存在覆盖不同或额外QName的信任锚，只有一个冲突解决程序负责验证。它是本文件第5.9节中推荐的模型。
CD F/C line conditions action
====================================================================
1 F A1 Set CD=1 on upstream query
0 F A2 Set CD=1 on upstream query
1 C A3 Return the cache contents
(data or RCODE=2)
0 C A4 no covering TA Return cache contents
(data or RCODE=2)
0 C A5 covering TA Validate cached result and
return it
CD F/C line conditions action
====================================================================
1 F A1 Set CD=1 on upstream query
0 F A2 Set CD=1 on upstream query
1 C A3 Return the cache contents
(data or RCODE=2)
0 C A4 no covering TA Return cache contents
(data or RCODE=2)
0 C A5 covering TA Validate cached result and
return it
Model 2: "never set when receiving CD=0"
型号2：“接收CD=0时从不设置”
This model is so named because it sets CD=0 on upstream queries for all received CD=0 queries, even if it has a covering trust anchor. The general philosophy represented by this table is that more than one resolver may take responsibility for validating a QNAME and that a validation failure for a QNAME by any resolver in the chain is a validation failure for the query. Using this model is NOT RECOMMENDED.
此模型之所以如此命名，是因为它为所有接收到的CD=0查询的上游查询设置了CD=0，即使它有一个覆盖信任锚。此表表示的一般原理是，多个解析程序可能负责验证QNAME，并且链中任何解析程序对QNAME的验证失败都是查询的验证失败。不建议使用此模型。
CD F/C line conditions action
====================================================================
1 F N1 Set CD=1 on upstream query
0 F N2 Set CD=0 on upstream query
1 C N3 cached data Return cached data
1 C N4 cached RCODE=2 Treat as line N1
0 C N5 no covering TA Return cache contents
(data or RCODE=2)
0 C N6 covering TA & Treat as line N2
cached data was
generated with CD=1
0 C N7 covering TA & Validate and return
cached data was
generated with CD=0
CD F/C line conditions action
====================================================================
1 F N1 Set CD=1 on upstream query
0 F N2 Set CD=0 on upstream query
1 C N3 cached data Return cached data
1 C N4 cached RCODE=2 Treat as line N1
0 C N5 no covering TA Return cache contents
(data or RCODE=2)
0 C N6 covering TA & Treat as line N2
cached data was
generated with CD=1
0 C N7 covering TA & Validate and return
cached data was
generated with CD=0
Model 3: "sometimes set"
模式3：“有时设置”
This model is so named because it sets the CD bit on upstream queries triggered by received CD=0 queries, based on whether the validator has a trust anchor configured that covers the query. If there is no covering trust anchor, the resolver clears the CD bit in the upstream
此模型之所以如此命名，是因为它根据验证器是否配置了覆盖查询的信任锚来设置由接收的CD=0查询触发的上游查询的CD位。如果没有覆盖信任锚，解析器将清除上游中的CD位
query. If there is a covering trust anchor, the resolver sets CD=1 and performs validation itself. The general philosophy represented by this table is that a resolver should try and validate QNAMEs for which it has trust anchors and should not preclude validation by other resolvers for QNAMEs for which it does not have covering trust anchors. Using this model is NOT RECOMMENDED.
查询如果存在覆盖信任锚，解析程序将设置CD=1并自行执行验证。此表表示的一般原理是，冲突解决程序应尝试验证其具有信任锚定的QName，并且不应排除其他冲突解决程序对其不具有覆盖信任锚定的QName的验证。不建议使用此模型。
CD F/C line conditions action
====================================================================
1 F S1 Set CD=1 on upstream query
0 F S2 covering TA Set CD=1 on upstream query
0 F S3 no covering TA Set CD=0 on upstream query
1 C S4 cached data Return cached data
1 C S5 cached RCODE=2 Treat as line S1
0 C S6 cached data was Return cache contents
generated with
CD=0
0 C S7 cached data was Validate & return cache
generated with contents
CD=1 &
covering TA
0 C S8 cached RCODE=2 Return cache contents
0 C S9 cached data Treat as line S3
was generated
with CD=1 &
no covering
TA
CD F/C line conditions action
====================================================================
1 F S1 Set CD=1 on upstream query
0 F S2 covering TA Set CD=1 on upstream query
0 F S3 no covering TA Set CD=0 on upstream query
1 C S4 cached data Return cached data
1 C S5 cached RCODE=2 Treat as line S1
0 C S6 cached data was Return cache contents
generated with
CD=0
0 C S7 cached data was Validate & return cache
generated with contents
CD=1 &
covering TA
0 C S8 cached RCODE=2 Return cache contents
0 C S9 cached data Treat as line S3
was generated
with CD=1 &
no covering
TA
This section presents several different policies for validating resolvers to use when they have a choice of trust anchors available for validating a given answer.
本节介绍了几个不同的策略，用于验证解析程序，当它们可以选择用于验证给定答案的信任锚时，可以使用这些策略。
One policy is to choose the trust anchor closest to the QNAME of the response. For example, consider a validator configured with trust anchors for "example." and "zone.example." When asked to validate a response for "www.sub.zone.example.", a validator using the "Closest Encloser" policy would choose the "zone.example." trust anchor.
一个策略是选择最接近响应QNAME的信任锚。例如，考虑为“示例”和“区域”示例配置信任锚的验证器，当被要求验证“www. .Zult.Simult.”的响应时，使用“最接近的外壳”策略的验证器将选择“区域。示例”信任锚点。
This policy has the advantage of allowing the operator to trivially override a parent zone's trust anchor with one that the operator can validate in a stronger way, perhaps because the resolver operator is
此策略的优点是允许操作员用操作员可以以更强有力的方式验证的信任锚来覆盖父区域的信任锚，这可能是因为解析器运算符是
affiliated with the zone in question. This policy also minimizes the number of public key operations needed, which is of benefit in resource-constrained environments.
隶属于相关区域。此策略还将所需的公钥操作数量降至最低，这在资源受限的环境中非常有益。
This policy has the disadvantage of giving the user some unexpected and unnecessary validation failures when sub-zone trust anchors are neglected. As a concrete example, consider a validator that configured a trust anchor for "zone.example." in 2009 and one for "example." in 2011. In 2012, "zone.example." rolls its Key Signing Key (KSK) and updates its DS records, but the validator operator doesn't update its trust anchor. With the "Closest Encloser" policy, the validator gets validation failures.
当忽略子区域信任锚时，该策略的缺点是给用户带来一些意外和不必要的验证失败。作为一个具体的例子，考虑一个在2009中为“区域.Simult..”配置信任锚点的验证器，在2011中为“示例”配置一个信任锚。2012年，“zone.example.”滚动其密钥签名密钥（KSK）并更新其DS记录，但验证程序操作员不更新其信任锚。使用“最近的封闭器”策略，验证程序将获得验证失败。
Another policy is to try all applicable trust anchors until one gives a validation result of Secure, in which case the final validation result is Secure. If and only if all applicable trust anchors give a result of Insecure, the final validation result is Insecure. If one or more trust anchors lead to a Bogus result and there is no Secure result, then the final validation result is Bogus.
另一个策略是尝试所有适用的信任锚，直到其中一个给出安全的验证结果，在这种情况下，最终的验证结果是安全的。如果且仅当所有适用的信任锚给出不安全的结果，则最终验证结果是不安全的。如果一个或多个信任锚导致虚假结果，并且没有安全结果，则最终验证结果是虚假的。
This has the advantage of causing the fewest validation failures, which may deliver a better user experience. If one trust anchor is out of date (as in our above example), the user may still be able to get a Secure validation result (and see DNS responses).
这样做的优点是导致最少的验证失败，从而可以提供更好的用户体验。如果一个信任锚过期（如上面的示例中所示），用户可能仍然能够获得安全验证结果（请参阅DNS响应）。
This policy has the disadvantage of making the validator subject to the compromise of the weakest of these trust anchors, while making it relatively painless to keep old trust anchors configured in perpetuity.
此策略的缺点是使验证器受到这些信任锚中最弱的信任锚的影响，同时使永久配置旧的信任锚相对轻松。
When the trust anchors have come from different sources (e.g., automated updates ([RFC5011]), one or more DNSSEC Lookaside Validation (DLV) registries ([RFC5074]), and manual configuration), a validator may wish to choose between them based on the perceived reliability of those sources. The order of precedence might be exposed as a configuration option.
当信任锚来自不同来源（例如，自动更新（[RFC5011]）、一个或多个DNSSEC后备验证（DLV）注册表（[RFC5074]）和手动配置）时，验证器可能希望根据这些来源的感知可靠性在它们之间进行选择。优先顺序可以作为配置选项公开。
For example, a validator might choose to prefer trust anchors found in a DLV registry over those manually configured on the theory that the manually configured ones will not be as aggressively maintained.
例如，验证器可能会选择在DLV注册表中找到的信任锚，而不是手动配置的信任锚，理论上，手动配置的信任锚不会得到如此积极的维护。
Conversely, a validator might choose to prefer manually configured trust anchors over those obtained from a DLV registry on the theory that the manually configured ones have been more carefully authenticated.
相反，验证器可能会选择手动配置的信任锚，而不是从DLV注册表获得的信任锚，因为理论上手动配置的信任锚已经过了更仔细的身份验证。
Or the validator might do something more complex: prefer a sub-set of manually configured trust anchors (based on a configuration option), then trust anchors that have been updated using the mechanism in [RFC5011], then trust anchors from one DLV registry, then trust anchors from a different DLV registry, then the rest of the manually configured trust anchors.
或者验证器可能会执行更复杂的操作：首选手动配置的信任锚点子集（基于配置选项），然后是使用[RFC5011]中的机制更新的信任锚点，然后是来自一个DLV注册表的信任锚点，然后是来自不同DLV注册表的信任锚点，然后是其余手动配置的信任锚。
Authors' Addresses
作者地址
Samuel Weiler (editor) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US
塞缪尔·韦勒（编辑）斯巴达公司，美国马里兰州哥伦比亚塞缪尔·莫尔斯大道7110号，邮编：21046
EMail: weiler@tislabs.com
EMail: weiler@tislabs.com
David Blacka (editor) Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 US
David Blacka（编辑）Verisign，Inc.美国弗吉尼亚州雷斯顿市布鲁蒙特大道12061号，邮编：20190
EMail: davidb@verisign.com
EMail: davidb@verisign.com