Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 8027 USC/ISI
BCP: 207 O. Gudmundsson
Category: Best Current Practice CloudFlare
ISSN: 2070-1721 S. Krishnaswamy
Parsons
November 2016
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 8027 USC/ISI
BCP: 207 O. Gudmundsson
Category: Best Current Practice CloudFlare
ISSN: 2070-1721 S. Krishnaswamy
Parsons
November 2016
DNSSEC Roadblock Avoidance
避免路障
Abstract
摘要
This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.
本文档描述了验证DNS解析程序、存根解析程序或应用程序在不兼容的基础结构中可能遇到的问题。它概述了潜在的检测和缓解技术。本文件的范围是创建一种共享方法，以检测和克服DNSSEC软件/系统可能面临的网络问题。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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 BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第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/rfc8027.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8027.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Notation ...................................................3
1.2. Background .................................................3
1.3. Implementation Experiences .................................4
1.3.1. Test Zone Implementation ............................4
2. Goals ...........................................................4
3. Detecting DNSSEC Non-compliance .................................5
3.1. Determining DNSSEC Support in Recursive Resolvers ..........5
3.1.1. Supports UDP Answers ................................6
3.1.2. Supports TCP Answers ................................6
3.1.3. Supports EDNS0 ......................................6
3.1.4. Supports the DO Bit .................................7
3.1.5. Supports the AD Bit DNSKEY Algorithms 5 and/or 8 ....7
3.1.6. Returns RRSIG for Signed Answer .....................7
3.1.7. Supports Querying for DNSKEY Records ................8
3.1.8. Supports Querying for DS Records ....................8
3.1.9. Supports Negative Answers with NSEC Records .........8
3.1.10. Supports Negative Answers with NSEC3 Records .......9
3.1.11. Supports Queries Where DNAME Records Lead
to an Answer .......................................9
3.1.12. Permissive DNSSEC .................................10
3.1.13. Supports Unknown RRtypes ..........................10
3.2. Direct Network Queries ....................................10
3.2.1. Support for Remote UDP over Port 53 ................10
3.2.2. Support for Remote UDP with Fragmentation ..........11
3.2.3. Support for Outbound TCP over Port 53 ..............11
3.3. Support for DNSKEY and DS Combinations ....................11
4. Aggregating the Results ........................................12
4.1. Resolver Capability Description ...........................12
5. Roadblock Avoidance ............................................13
5.1. Partial Resolver Usage ....................................16
5.1.1. Known Insecure Lookups .............................16
5.1.2. Partial NSEC/NSEC3 Support .........................16
6. Start-Up and Network Connectivity Issues .......................16
6.1. What to Do ................................................17
7. Quick Test .....................................................17
7.1. Test Negative Answers Algorithm 5 .........................17
7.2. Test Algorithm 8 ..........................................18
7.3. Test Algorithm 13 .........................................18
7.4. Fails When DNSSEC Does Not Validate .......................18
8. Security Considerations ........................................18
9. Normative References ...........................................18
Acknowledgments ...................................................19
Authors' Addresses ................................................19
1. Introduction ....................................................3
1.1. Notation ...................................................3
1.2. Background .................................................3
1.3. Implementation Experiences .................................4
1.3.1. Test Zone Implementation ............................4
2. Goals ...........................................................4
3. Detecting DNSSEC Non-compliance .................................5
3.1. Determining DNSSEC Support in Recursive Resolvers ..........5
3.1.1. Supports UDP Answers ................................6
3.1.2. Supports TCP Answers ................................6
3.1.3. Supports EDNS0 ......................................6
3.1.4. Supports the DO Bit .................................7
3.1.5. Supports the AD Bit DNSKEY Algorithms 5 and/or 8 ....7
3.1.6. Returns RRSIG for Signed Answer .....................7
3.1.7. Supports Querying for DNSKEY Records ................8
3.1.8. Supports Querying for DS Records ....................8
3.1.9. Supports Negative Answers with NSEC Records .........8
3.1.10. Supports Negative Answers with NSEC3 Records .......9
3.1.11. Supports Queries Where DNAME Records Lead
to an Answer .......................................9
3.1.12. Permissive DNSSEC .................................10
3.1.13. Supports Unknown RRtypes ..........................10
3.2. Direct Network Queries ....................................10
3.2.1. Support for Remote UDP over Port 53 ................10
3.2.2. Support for Remote UDP with Fragmentation ..........11
3.2.3. Support for Outbound TCP over Port 53 ..............11
3.3. Support for DNSKEY and DS Combinations ....................11
4. Aggregating the Results ........................................12
4.1. Resolver Capability Description ...........................12
5. Roadblock Avoidance ............................................13
5.1. Partial Resolver Usage ....................................16
5.1.1. Known Insecure Lookups .............................16
5.1.2. Partial NSEC/NSEC3 Support .........................16
6. Start-Up and Network Connectivity Issues .......................16
6.1. What to Do ................................................17
7. Quick Test .....................................................17
7.1. Test Negative Answers Algorithm 5 .........................17
7.2. Test Algorithm 8 ..........................................18
7.3. Test Algorithm 13 .........................................18
7.4. Fails When DNSSEC Does Not Validate .......................18
8. Security Considerations ........................................18
9. Normative References ...........................................18
Acknowledgments ...................................................19
Authors' Addresses ................................................19
This document describes problems observable during DNSSEC ([RFC4034] [RFC4035]) deployment that derive from non-compliant infrastructure. It poses potential detection and mitigation techniques.
本文档描述了DNSSEC（[RFC4034][RFC4035]）部署过程中发现的问题，这些问题源于不符合要求的基础架构。它提出了潜在的检测和缓解技术。
In this document, a "Host Validator" can either be a validating stub-resolver, such as a library that an application has linked in, or a validating resolver daemon running on the same machine. It may or may not be trying to use upstream caching resolvers during its own resolution process; both cases are covered by the tests defined in this document.
在本文档中，“主机验证器”可以是验证存根解析器（例如应用程序链接到的库），也可以是在同一台计算机上运行的验证解析器守护程序。它在自己的解析过程中可能尝试使用上游缓存解析程序，也可能不尝试使用上游缓存解析程序；本文件中定义的测试涵盖了这两种情况。
The sub-variant of this is a "Validating Forwarding Resolver", which is a resolver that is configured to use upstream Resolvers when possible. A Validating Forwarding Resolver also needs to perform the tests outlined in this document before using an upstream recursive resolver.
其子变量是“验证转发解析器”，这是一个配置为在可能时使用上游解析器的解析器。在使用上游递归解析器之前，验证转发解析器还需要执行本文档中概述的测试。
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]中所述进行解释。
Deployment of DNSSEC validation is hampered by network components that make it difficult or sometimes impossible for validating resolvers to effectively obtain the DNSSEC data they need. This can occur for many different reasons including, but not limited to, the following:
网络组件阻碍了DNSSEC验证的部署，这使得验证解析程序很难或有时不可能有效获取所需的DNSSEC数据。这可能是由于许多不同的原因造成的，包括但不限于以下原因：
o Recursive resolvers and DNS proxies [RFC5625] not being fully DNSSEC compliant
o 递归解析程序和DNS代理[RFC5625]不完全符合DNSSEC
o Resolvers not being DNSSEC aware
o 解析程序不支持DNSSEC
o "Middleboxes" actively blocking, modifying, and/or restricting outbound traffic to the DNS port (53) either UDP and/or TCP
o “中间盒”主动阻止、修改和/或限制到DNS端口（53）的出站流量（UDP和/或TCP）
o In-path network components not allowing UDP fragments
o 路径内网络组件不允许UDP片段
This document talks about ways that a Host Validator can detect the state of the network it is attached to, and ways to hopefully circumvent the problems associated with the network defects it discovers. The tests described in this document may be performed on any validating resolver to detect and prevent problems. While these
本文档讨论主机验证器可以检测其连接到的网络状态的方法，以及希望规避与它发现的网络缺陷相关的问题的方法。本文档中描述的测试可在任何验证解析器上执行，以检测和预防问题。而这些
recommendations are mainly aimed at Host Validators, it is prudent to perform these tests from regular validating resolvers, just to make sure things work.
建议主要针对主机验证器，谨慎的做法是从常规验证解析器执行这些测试，以确保一切正常。
There are situations where a host cannot talk directly to a Resolver; the tests below cannot address how to overcome that, and inconsistent results can be seen in such cases. This can happen, for instance, when there are DNS proxies/forwarders between the user and the actual resolvers.
在某些情况下，主机无法直接与解析程序对话；下面的测试无法解决如何克服这一问题，在这种情况下可以看到不一致的结果。例如，当用户和实际解析程序之间存在DNS代理/转发器时，可能会发生这种情况。
Multiple lessons learned from multiple implementations led to the development of this document, including (in alphabetical order) DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, and FCC_Grade.
从多个实施中吸取的多个经验教训导致了本文件的编制，包括（按字母顺序）DNSSEC工具的DNSSEC检查、DNSSEC_解析器_检查、DNSSEC触发器和FCC_等级。
Detecting lack of support for specified Domain Name System Key (DNSKEY) algorithms and Delegation Signer (DS) digest algorithms is outside the scope of this document, but the document provides information on how to do that. See the sample test tool: <https://github.com/ogud/DNSSEC_ALG_Check>.
检测不支持指定域名系统密钥（DNSKEY）算法和委托签名者（DS）摘要算法超出了本文档的范围，但本文档提供了有关如何做到这一点的信息。请参见示例测试工具：<https://github.com/ogud/DNSSEC_ALG_Check>.
This document does describe compliance tests for algorithms 5, 7, and 13 with DS digest algorithms 1 and 2.
本文档确实描述了算法5、7和13与DS摘要算法1和2的符合性测试。
In this document, the "test.example.com" domain is used to refer to DNS records that contain test records that have known DNSSEC properties associated with them. For example, the "badsign-a.test.example.com" domain is used below to refer to a DNS A record where the signatures published for it are invalid (i.e., they are "bad signatures" that should cause a validation failure).
在本文档中，“test.example.com”域用于引用包含测试记录的DNS记录，这些测试记录具有与其关联的已知DNSSEC属性。例如，下面使用“badsign-a.test.example.com”域来引用为其发布的签名无效的DNS a记录（即，它们是应导致验证失败的“错误签名”）。
At the time of this publication, the "test.dnssec-tools.org" domain implements all of these test records. Thus, it may be possible to replace "test.example.com" in this document with "test.dnssec-tools.org" when performing real-world tests.
在本出版物发布时，“test.dnssec tools.org”域实现了所有这些测试记录。因此，在执行实际测试时，可以将本文档中的“test.example.com”替换为“test.dnssec tools.org”。
This document is intended to show how a Host Validator can detect the capabilities of a recursive resolver and work around any problems that could potentially affect DNSSEC resolution. This enables the Host Validator to make use of the caching functionality of the recursive resolver, which is desirable in that it decreases network traffic and improves response times.
本文档旨在展示主机验证器如何检测递归解析器的功能，以及如何解决可能影响DNSSEC解析的任何问题。这使主机验证器能够利用递归解析器的缓存功能，这是可取的，因为它减少了网络流量并提高了响应时间。
A Host Validator has two choices: it can wait to determine that it has problems with a recursive resolver based on the results that it is getting from real-world queries issued to it or it can proactively test for problems (Section 3) to build a workaround list ahead of time (Section 5). There are pros and cons to both of these paths that are application specific, and this document does not attempt to provide guidance about whether proactive tests should or should not be used. Either way, DNSSEC roadblock avoidance techniques ought to be used when needed and if possible.
主机验证器有两种选择：它可以等待根据从向其发出的实际查询中获得的结果来确定它与递归解析器之间是否存在问题，或者它可以主动测试问题（第3节），以提前构建解决方案列表（第5节）。这两种方法都有其特定于应用程序的优点和缺点，本文档并不试图提供关于是否应使用主动测试的指导。无论采用哪种方式，在需要时，如果可能，应使用DNSSEC路障避免技术。
Note: Besides being useful for Host Validators, the same tests can be used for a recursive resolver to check if its upstream connections hinder DNSSEC validation.
注意：除了对主机验证器有用之外，递归解析器还可以使用相同的测试来检查其上游连接是否妨碍DNSSEC验证。
This section outlines tests that a validator should perform in order to test certain features of the surrounding network. A resolver should perform these tests when first starting but MAY also perform these tests when it has detected network changes (e.g., address changes, network reattachment, or etc.).
本节概述了验证器应执行的测试，以测试周围网络的某些功能。解析器应在首次启动时执行这些测试，但也可在检测到网络更改（例如，地址更改、网络重新连接等）时执行这些测试。
Note: When performing these tests against an address, we make the following assumption about that address: it is a unicast address or an anycast [RFC4786] cluster where all servers have identical configuration and connectivity.
注意：当对某个地址执行这些测试时，我们对该地址做出以下假设：它是单播地址或选播[RFC4786]群集，其中所有服务器都具有相同的配置和连接。
Note: When performing these tests, we also assume that the path is clear of "DNS-interfering" middleboxes, like firewalls, proxies, or forwarders. The presence of such infrastructure can easily make a recursive resolver appear to be functioning improperly. It is beyond the scope of the document as how to work around such interference, although the tests defined in this document may indicate when such misbehaving middleware is causing interference.
注意：在执行这些测试时，我们还假设路径中没有“DNS干扰”的中间盒，如防火墙、代理或转发器。这种基础设施的存在很容易使递归解析器看起来运行不正常。如何解决此类干扰超出了本文档的范围，尽管本文档中定义的测试可能表明此类行为不当的中间件何时会导致干扰。
Note: This document specifies two sets of tests to perform: a comprehensive one and a fast one. The fast one will detect most common problems; thus, if the fast one passes, then the comprehensive one MAY be considered passed as well.
注：本文件规定了要执行的两组测试：综合测试和快速测试。快速的将检测最常见的问题；因此，如果快速考试通过，那么综合考试也可以被视为通过。
Ideally, a Host Validator can make use of the caching present in recursive resolvers. This section discusses the tests that a recursive resolver MUST pass in order to be fully usable as a DNS cache.
理想情况下，主机验证器可以利用递归解析器中的缓存。本节讨论递归解析程序必须通过的测试，才能完全用作DNS缓存。
Unless stated otherwise:
除非另有说明，否则：
o all of the following tests SHOULD have the Recursion Desired (RD) flag set when sending out a query and queries SHOULD be sent over UDP.
o 当发送查询时，以下所有测试都应该设置递归期望（RD）标志，并且查询应该通过UDP发送。
o the tests MUST NOT have the DNSSEC OK (DO) bit set or utilize any of the other DNSSEC-related requirements, like Extension Mechanisms for DNS (EDNS0).
o 测试不得设置DNSSEC OK（DO）位或利用任何其他DNSSEC相关要求，如DNS扩展机制（EDNS0）。
The tests are designed to check for support of one feature at a time.
这些测试旨在一次检查一个功能的支持情况。
Purpose: This tests basic DNS-over-UDP functionality to a resolver.
目的：测试解析程序的基本DNS over UDP功能。
Test: A DNS request is sent to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com.
测试：将DNS请求发送到正在测试的解析程序，以获取已知现有域（如good-A.Test.example.com）的A记录。
SUCCESS: A DNS response was received that contains an A record in the answer section. (The data itself does not need to be checked.)
成功：收到的DNS响应包含应答部分中的A记录。（不需要检查数据本身。）
Note: An implementation MAY chose not to perform the rest of the tests if this test fails, as it is highly unlikely that the resolver under test will pass any of the remaining tests.
注意：如果此测试失败，实现可能会选择不执行其余的测试，因为被测试的冲突解决程序不太可能通过其余的任何测试。
Purpose: This tests basic TCP functionality to a resolver.
目的：测试解析程序的基本TCP功能。
Test: A DNS request is sent over TCP to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com.
测试：DNS请求通过TCP发送到正在测试的解析程序，以获取已知现有域（如good-A.Test.example.com）的A记录。
SUCCESS: A DNS response was received that contains an A record in the answer section. (The data itself does not need to be checked.)
成功：收到的DNS响应包含应答部分中的A记录。（不需要检查数据本身。）
Purpose: Test whether a resolver properly supports the EDNS0 extension option.
目的：测试冲突解决程序是否正确支持EDNS0扩展选项。
Prerequisite: Supports UDP or TCP.
前提条件：支持UDP或TCP。
Test: Send a request to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com, with an EDNS0 OPT record in the additional section.
测试：向正在测试的冲突解决程序发送一个请求，以获取已知现有域（如good-a.Test.example.com）的a记录，并在附加部分中包含一个EDNS0 OPT记录。
SUCCESS: A DNS response was received that contains an EDNS0 option with version number 0.
成功：收到包含版本号为0的EDNS0选项的DNS响应。
Purpose: This tests whether a resolver has minimal support of the DO bit.
目的：测试解析器是否对DO位有最低限度的支持。
Prerequisite: Supports EDNS0.
前提条件：支持EDNS0。
Test: Send a request to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com. Set the DO bit in the outgoing query.
测试：向测试中的冲突解决程序发送请求，以获取已知现有域（如good-a.Test.example.com）的a记录。在传出查询中设置DO位。
SUCCESS: A DNS response was received that contains the DO bit set.
成功：接收到包含DO位集的DNS响应。
Note: This only tests that the resolver set the DO bit in the response. Later tests will determine if the DO bit was actually made use of. Some resolvers successfully pass this test because they simply copy the unknown flags into the response. These resolvers will fail the later tests.
注意：这仅测试解析器是否在响应中设置了DO位。稍后的测试将确定是否实际使用了DO位。一些解析程序成功通过了此测试，因为它们只是将未知标志复制到响应中。这些解析器将无法通过后续测试。
Purpose: This tests whether the resolver is a validating resolver.
目的：测试冲突解决程序是否为验证冲突解决程序。
Prerequisite: Supports the DO bit.
前提条件：支持DO位。
Test: Send requests to the resolver under test for an A record for a known existing domain in a DNSSEC-signed zone that is verifiable to a configured trust anchor, such as good-a.test.example.com using the root's published DNSKEY or DS record as a trust anchor. Set the DO bit in the outgoing query. This test should be done twice: once for a zone that contains algorithm 5 (RSASHA1) and again for algorithm 8 (RSASHA256).
测试：向测试中的冲突解决程序发送请求，以获取DNSSEC签名区域中已知现有域的A记录，该区域可通过配置的信任锚点进行验证，例如good-A.Test.example.com，使用根发布的DNSKEY或DS记录作为信任锚点。在传出查询中设置DO位。此测试应进行两次：一次用于包含算法5（RSASHA1）的区域，另一次用于算法8（RSASHA256）。
SUCCESS: A DNS response was received that contains the Authentic Data (AD) bit set for algorithm 5 (RSASHA1).
成功：接收到包含为算法5（RSASHA1）设置的真实数据（AD）位的DNS响应。
BONUS: The AD bit is set for a resolver that supports algorithm 8 (RSASHA256).
额外好处：AD位是为支持算法8（RSASA256）的解析器设置的。
Purpose: This tests whether a resolver will properly return Resource Record Signature (RRSIG) records when the DO bit is set.
目的：测试设置DO位时，解析程序是否正确返回资源记录签名（RRSIG）记录。
Prerequisite: Supports the DO bit.
前提条件：支持DO位。
Test: Send a request to the resolver under test for an A record for a known existing domain in a DNSSEC-signed zone, such as good-a.test.example.com. Set the DO bit in the outgoing query.
测试：向测试中的冲突解决程序发送请求，以获取DNSSEC签名区域（如good-a.Test.example.com）中已知现有域的a记录。在传出查询中设置DO位。
SUCCESS: A DNS response was received that contains at least one RRSIG record.
成功：收到至少包含一条RRSIG记录的DNS响应。
Purpose: This tests whether a resolver can query for and receive a DNSKEY record from a signed zone.
目的：测试冲突解决程序是否可以查询并从签名区域接收DNSKEY记录。
Prerequisite: Supports the DO bit.
前提条件：支持DO位。
Test: Send a request to the resolver under test for a DNSKEY record that is known to exist in a signed zone, such as test.example.com/ DNSKEY. Set the DO bit in the outgoing query.
测试：向正在测试的解析程序发送一个请求，以获取已知存在于签名区域中的DNSKEY记录，例如Test.example.com/DNSKEY。在传出查询中设置DO位。
SUCCESS: A DNS response was received that contains a DNSKEY record in the answer section.
成功：收到的DNS响应在应答部分包含DNSKEY记录。
Note: Some DNSKEY Resource Record Sets (RRsets) are large and, if the network path has problems with large answers, this query may result in either a false positive or a false negative. In general, the DNSKEY queried for should be small enough to fit into a 1220-byte answer to avoid a false negative result when TCP is disabled. However, querying many zones will result in answers greater than 1220 bytes, so DNS over TCP MUST be available for DNSSEC use in general.
注意：某些DNSKEY资源记录集（RRSET）较大，如果网络路径存在较大答案的问题，此查询可能会导致误报或误报。通常，查询的DNSKEY应该足够小，以适合1220字节的答案，以避免在禁用TCP时出现假阴性结果。但是，查询多个区域将导致大于1220字节的答案，因此TCP上的DNS通常必须可用于DNSSEC。
Purpose: This tests whether a resolver can query for and receive a DS record from a signed zone.
目的：测试冲突解决程序是否可以查询并从签名区域接收DS记录。
Prerequisite: Supports the DO bit.
前提条件：支持DO位。
Test: Send a request to the resolver under test for a DS record that is known to exist in a signed zone, such as test.example.com/DS. Set the DO bit in the outgoing query.
测试：向正在测试的解析程序发送一个请求，请求已知存在于签名区域中的DS记录，例如Test.example.com/DS。在传出查询中设置DO位。
SUCCESS: A DNS response was received that contains a DS record in the answer section.
成功：收到的DNS响应在应答部分包含DS记录。
Purpose: This tests whether a resolver properly returns NextSECure (NSEC) records for a nonexisting domain in a DNSSEC-signed zone.
目的：测试解析程序是否正确返回DNSSEC签名区域中不存在的域的NextSECure（NSEC）记录。
Prerequisite: Supports the DO bit.
前提条件：支持DO位。
Test: Send a request to the resolver under test for an A record that is known to not exist in an NSEC-signed zone, such as nonexistent.test.example.com. Set the DO bit in the outgoing query.
测试：向正在测试的解析程序发送一个请求，以获取已知不存在于NSEC签名区域（如nonexistent.Test.example.com）中的a记录。在传出查询中设置DO位。
SUCCESS: A DNS response was received that contains an NSEC record.
成功：收到包含NSEC记录的DNS响应。
Note: The query issued in this test MUST be sent to an NSEC-signed zone. Getting back appropriate NSEC3 records does not indicate a failure, but a bad test.
注意：此测试中发出的查询必须发送到NSEC签名区域。返回适当的NSEC3记录并不表示失败，而是表示测试失败。
Purpose: This tests whether a resolver properly returns NSEC3 records ([RFC5155]) for a nonexisting domain in a DNSSEC-signed zone.
目的：测试解析程序是否正确返回DNSSEC签名区域中不存在的域的NSEC3记录（[RFC5155]）。
Prerequisite: Supports the DO bit.
前提条件：支持DO位。
Test: Send a request to the resolver under test for an A record that is known to be nonexistent in a zone signed using NSEC3, such as nonexistent.nsec3-ns.test.example.com. Set the DO bit in the outgoing query.
测试：向正在测试的冲突解决程序发送一个请求，以获取已知在使用NSEC3签名的区域中不存在的a记录，例如nonexistent.NSEC3-ns.Test.example.com。在传出查询中设置DO位。
SUCCESS: A DNS response was received that contains an NSEC3 record.
成功：接收到包含NSEC3记录的DNS响应。
Bonus: If the AD bit is set, this validator supports algorithm 7 (RSASHA1-NSEC3-SHA1).
额外好处：如果设置了AD位，则该验证器支持算法7（RSASHA1-NSEC3-SHA1）。
Note: The query issued in this test MUST be sent to an NSEC3-signed zone. Getting back appropriate NSEC records does not indicate a failure, but a bad test.
注意：此测试中发出的查询必须发送到NSEC3签名区域。取回适当的NSEC记录并不表示失败，而是一个糟糕的测试。
Purpose: This tests whether a resolver can query for an A record in a zone with a known DNAME referral for the record's parent.
目的：此测试冲突解决程序是否可以在区域中查询记录，该区域中记录的父项具有已知的DNAME引用。
Test: Send a request to the resolver under test for an A record that is known to exist in a signed zone within a DNAME-referral child zone, such as good-a.dname-good-ns.test.example.com.
测试：向测试中的冲突解决程序发送一个请求，以获取已知存在于DNAME引用子区域（如good-a.DNAME-good-ns.Test.example.com）内的签名区域中的a记录。
SUCCESS: A DNS response was received that contains a DNAME in the answer section. An RRSIG MUST also be received in the answer section that covers the DNAME record.
成功：收到的DNS响应在应答部分包含DNAME。还必须在涵盖DNAME记录的应答部分接收RRSIG。
Purpose: To see if a validating resolver is ignoring DNSSEC validation failures.
目的：查看验证解析程序是否忽略DNSSEC验证失败。
Prerequisite: Supports the AD bit.
前提条件：支持AD位。
Test: Ask for data from a broken DNSSEC delegation, such as badsign-a.test.example.com.
测试：从中断的DNSSEC委托中请求数据，例如badsign-a.Test.example.com。
SUCCESS: A reply was received with the Rcode set to SERVFAIL.
成功：接收到Rcode设置为SERVFAIL的回复。
Purpose: Some DNS Resolvers/gateways only support some Resource Record Types (RRtypes). This causes problems for applications that need recently defined types.
用途：某些DNS解析程序/网关仅支持某些资源记录类型（RRTYPE）。这会给需要最近定义类型的应用程序带来问题。
Prerequisite: Supports UDP or TCP.
前提条件：支持UDP或TCP。
Test: Send a request for a recently defined type or an unknown type in the 20000-22000 range, that resolves to a server that will return an answer for all types, such as alltypes.example.com (a server today that supports this is alltypes.res.dnssecready.org).
测试：发送对最近定义的类型或20000-22000范围内的未知类型的请求，该请求将解析为一个服务器，该服务器将返回所有类型的答案，例如alltypes.example.com（目前支持该请求的服务器是alltypes.res.dnssecready.org）。
SUCCESS: A DNS response was retrieved that contains the type requested in the answer section.
成功：检索到包含应答部分中请求的类型的DNS响应。
If needed, a Host Validator may need to make direct queries to authoritative servers or known Open Recursive Resolvers in order to collect data. To do that, a number of key network features MUST be functional.
如果需要，主机验证器可能需要直接查询权威服务器或已知的开放递归解析器，以便收集数据。要做到这一点，一些关键的网络功能必须是功能性的。
Purpose: This tests basic UDP functionality to outside the local network.
目的：测试本地网络外部的基本UDP功能。
Test: A DNS request is sent to a known distant authoritative server for a record known to be within that server's authoritative data. Example: send a query to the address of ns1.test.example.com for the good-a.test.example.com/A record.
测试：DNS请求被发送到已知的远程权威服务器，以获取已知位于该服务器权威数据内的记录。示例：向ns1.test.Example.com的地址发送一个查询，查询good-a.test.Example.com/a记录。
SUCCESS: A DNS response was received that contains an A record in the answer section.
成功：收到的DNS响应包含应答部分中的A记录。
Note: An implementation can use the local resolvers for determining the address of the name server that is authoritative for the given zone. The recursive bit MAY be set for this request, but it does not need to be.
注意：实现可以使用本地解析程序来确定对给定区域具有权威性的名称服务器的地址。可以为此请求设置递归位，但不需要设置。
Purpose: This tests if the local network can receive fragmented UDP answers.
目的：测试本地网络是否可以接收分段UDP应答。
Prerequisite: Local UDP traffic > 1500 bytes in size is possible.
先决条件：本地UDP流量可能大于1500字节。
Test: A DNS request is sent over UDP to a known distant DNS address asking for a record that has an answer larger than 2000 bytes. For example, send a query for the test.example.com/DNSKEY record with the DO bit set in the outgoing query.
测试：DNS请求通过UDP发送到已知的远程DNS地址，请求一个应答大于2000字节的记录。例如，使用传出查询中设置的DO位发送test.example.com/DNSKEY记录的查询。
SUCCESS: A DNS response was received that contains the large answer.
成功：收到包含大答案的DNS响应。
Note: A failure in getting large answers over UDP is not a serious problem if TCP is working.
注意：如果TCP正常工作，通过UDP获取大型答案的失败不是一个严重的问题。
Purpose: This tests basic TCP functionality to outside the local network.
目的：测试本地网络外部的基本TCP功能。
Test: A DNS request is sent over TCP to a known distant authoritative server for a record known to be within that server's authoritative data. Example: send a query to the address of ns1.test.example.com for the good-a.test.example.com/A record.
测试：DNS请求通过TCP发送到已知的远程权威服务器，以获取已知位于该服务器权威数据内的记录。示例：向ns1.test.Example.com的地址发送一个查询，查询good-a.test.Example.com/a记录。
SUCCESS: A DNS response was received that contains an A record in the answer section.
成功：收到的DNS响应包含应答部分中的A记录。
Note: An implementation can use the local resolvers for determining the address of the name server that is authoritative for the given zone. The recursive bit MAY be set for this request, but it does not need to be.
注意：实现可以使用本地解析程序来确定对给定区域具有权威性的名称服务器的地址。可以为此请求设置递归位，但不需要设置。
Purpose: This test can check what algorithm combinations are supported.
目的：此测试可以检查支持哪些算法组合。
Prerequisite: Supports the AD bit for Algorithms 5 and/or 8.
前提条件：支持算法5和/或8的AD位。
Test: A DNS request is sent over UDP to the resolver under test for a known combination of the DS algorithm number (N) and DNSKEY algorithm number (M) of the example form ds-N.alg-M-nsec.test.example.com. Examples:
测试：DNS请求通过UDP发送到正在测试的解析程序，以获取示例表单DS-N.alg-M-nsec.Test.example.com中DS算法编号（N）和DNSKEY算法编号（M）的已知组合。示例：
ds-2.alg-13-nsec.test.example.com TXT or ds-4.alg-13-nsec3.test.example.com TXT
ds-2.alg-13-nsec.test.example.com TXT或ds-4.alg-13-nsec3.test.example.com TXT
SUCCESS: A DNS response is received with the AD bit set and with a matching record type in the answer section.
成功：接收到一个DNS响应，其中设置了AD位，并且应答部分中有一个匹配的记录类型。
Note: For algorithms 6 and 7, NSEC is not defined; thus, a query for alg-M-nsec3 is required. Similarly, NSEC3 is not defined for algorithms 1, 3, and 5. Furthermore, algorithms 2, 4, 9, and 11 do not currently have definitions for signed zones.
注：对于算法6和7，未定义NSEC；因此，需要查询alg-M-nsec3。类似地，未为算法1、3和5定义NSEC3。此外，算法2、4、9和11目前没有符号区域的定义。
Some conclusions can be drawn from the results of the above tests in an "aggregated" form. This section defines some labels to assign to a resolver under test given the results of the tests run against them.
从上述测试结果中可以得出一些“聚合”形式的结论。本节定义了一些标签，以便在给定针对这些标签运行的测试结果的情况下分配给测试中的冲突解决程序。
This section will group and label certain common results.
本节将对某些常见结果进行分组和标记。
Resolvers are classified into the following broad behaviors:
分解器分为以下几种主要行为：
Validator: The resolver passes all DNSSEC tests and had the AD bit appropriately set.
验证器：解析器通过了所有DNSSEC测试，并正确设置了AD位。
DNSSEC-Aware: The resolver passes all DNSSEC tests, but it does not appropriately set the AD bit on answers, indicating it is not validating. A Host Validator will function fine using this resolver as a forwarder.
DNSSEC Aware：解析程序通过了所有DNSSEC测试，但未正确设置答案上的AD位，表示未进行验证。使用此解析器作为转发器，主机验证器将正常工作。
Non-DNSSEC-Capable: The resolver is not DNSSEC-aware and will make it hard for a Host Validator to operate behind it. It MAY be usable to query for data that is in known insecure sections of the DNS tree.
不支持DNSSEC：解析程序不支持DNSSEC，这将使主机验证程序很难在其后面运行。它可以用于查询DNS树的已知不安全部分中的数据。
Not a DNS Resolver: This is an improperly behaving resolver and should not be used at all.
不是DNS解析程序：这是一个行为不正确的解析程序，根本不应使用。
While it would be great if all resolvers fell cleanly into one of the broad categories above, that is not the case. For that reason, it is necessary to augment the classification with a more descriptive result. This is done by adding the word "Partial" in front of Validator/DNSSEC-aware classifications, followed by sub-descriptors of what is not working.
如果所有的解析器都能清晰地归为上面的一大类，那就太好了，但事实并非如此。因此，有必要用更具描述性的结果来扩充分类。这是通过在Validator/DNSSEC感知分类前面添加单词“Partial”来完成的，后面是不起作用的子描述符。
Unknown: Failed the unknown test
未知：未知测试失败
DNAME: Failed the DNAME test
DNAME:DNAME测试失败
NSEC3: Failed the NSEC3 test
NSEC3:未通过NSEC3测试
TCP: TCP not available
TCP:TCP不可用
SlowBig: UDP is size limited, but TCP fallback works
SlowBig:UDP的大小有限，但TCP回退可以工作
NoBig: TCP not available and UDP is size limited
NoBig:TCP不可用，UDP大小有限
Permissive: Passes data known to fail validation
允许：传递已知未通过验证的数据
The goal of this document is to tie the above tests and aggregations to avoidance practices; however, the document does not specify exactly how to do that.
本文件的目标是将上述测试和汇总与规避实践联系起来；然而，该文件并没有具体说明如何做到这一点。
Once we have determined what level of support is available in the network, we can determine what must be done in order to effectively act as a validating resolver. This section discusses some of the options available given the results from the previous sections.
一旦我们确定了网络中可用的支持级别，我们就可以确定必须做什么才能有效地充当验证解析器。本节讨论了根据前几节的结果提供的一些可用选项。
The general fallback approach can be described by the following sequence:
一般回退方法可按以下顺序描述：
If the resolver is labeled as "Validator" or "DNSSEC-aware":
如果冲突解决程序标记为“验证程序”或“DNSSEC感知”：
Send queries through this resolver and perform local validation on the results.
通过此解析器发送查询并对结果执行本地验证。
If validation fails, try the next resolver.
如果验证失败，请尝试下一个解析器。
Else, if the resolver is labeled "Not a DNS Resolver" or "Non-DNSSEC-capable":
否则，如果解析程序标记为“非DNS解析程序”或“不支持DNSSEC”：
Mark it as unusable and try the next resolver.
将其标记为不可用，然后尝试下一个解析器。
Else if no more resolvers are configured and if direct queries are supported:
否则，如果未配置更多解析程序并且支持直接查询：
1. Try iterating from the Root.
1. 尝试从根开始迭代。
2. If the answer is SECURE/BOGUS: Return the result of the iteration.
2. 如果答案是安全的/虚假的：返回迭代的结果。
3. If the answer is INSECURE: Re-query "Non-DNSSEC-capable" servers and return answers from them without the AD bit set to the client.
3. 如果答案不安全：重新查询“不支持DNSSEC”的服务器，并在不向客户端设置AD位的情况下从服务器返回答案。
This will increase the likelihood that split-view unsigned answers are found.
这将增加发现拆分视图未签名答案的可能性。
Else:
其他：
Return an error code and log a failure.
返回错误代码并记录失败。
While attempting resolution through a particular recursive name server with a particular transport method that worked, any transport-specific parameters MUST be remembered in order to avoid any unnecessary fallback attempts.
在尝试使用有效的特定传输方法通过特定递归名称服务器解析时，必须记住任何特定于传输的参数，以避免任何不必要的回退尝试。
Transport-specific parameters MUST also be remembered for each authoritative name server that is queried while performing an iterative mode lookup.
还必须记住在执行迭代模式查找时查询的每个权威名称服务器的特定于传输的参数。
Any transport settings that are remembered for a particular name server MUST be periodically refreshed; they should also be refreshed when an error is encountered as described below.
必须定期刷新为特定名称服务器记住的任何传输设置；当遇到如下所述的错误时，还应刷新它们。
For a stub resolver, problems with the name server can manifest themselves under the following types of error conditions:
对于存根解析器，名称服务器的问题可能会在以下类型的错误条件下表现出来：
o No Response, error response, or missing DNSSEC metadata
o 无响应、错误响应或缺少DNSSEC元数据
o Illegal Response: An illegal response is received, which prevents the validator from fetching all the necessary records required for constructing an authentication chain. This could result when referral loops are encountered, when any of the antecedent zone delegations are lame, when aliases are erroneously followed for certain RRtypes (such as Start of Authority (SOA), DNSKEYs, or DS records), or when resource records for certain types (e.g., DS) are returned from a zone that is not authoritative for such records.
o 非法响应：接收到非法响应，这会阻止验证程序获取构建身份验证链所需的所有必要记录。当遇到引用循环时，当任何先行区域委派都是lame时，当某些RRTYPE（如授权开始（SOA）、DNSKEYs或DS记录）的别名被错误地跟随时，或者当某些类型（如DS）的资源记录从对此类记录不具有授权的区域返回时，可能会出现这种情况。
o Bogus Response: A Bogus Response is received, when the cryptographic assertions in the authentication chain do not validate properly.
o 虚假响应：当身份验证链中的加密断言未正确验证时，会收到虚假响应。
For each of the above error conditions, a validator MAY adopt the following dynamic fallback technique, preferring a particular approach if it is known to work for a given name server or zone from previous attempts.
对于上述每种错误情况，验证器都可以采用以下动态回退技术，如果已知该方法适用于以前尝试的给定名称服务器或区域，则更倾向于使用特定方法。
o No response, error response, or missing DNSSEC metadata:
o 无响应、错误响应或缺少DNSSEC元数据：
* Retry with different EDNS0 sizes (4096, 1492, or None).
* 使用不同的EDNS0大小（4096、1492或无）重试。
* Retry with TCP only.
* 仅使用TCP重试。
* Perform an iterative query starting from the Root if the previous error was returned from a lookup that had recursion enabled.
* 如果上一个错误是从启用递归的查找返回的，则从根开始执行迭代查询。
* Retry using an alternative transport method, if this alternative method is known (configured) to be supported by the name server in question.
* 如果名称服务器已知（已配置）支持此替代方法，请使用替代传输方法重试。
o Illegal Response
o 非法响应
* Perform an iterative query starting from the Root if the previous error was returned from a lookup that had recursion enabled.
* 如果上一个错误是从启用递归的查找返回的，则从根开始执行迭代查询。
* Check if any of the antecedent zones up to the closest configured trust anchor are Insecure.
* 检查最近配置的信任锚点之前的任何先行区域是否不安全。
o Bogus Response
o 虚假反应
* Perform an iterative query starting from the Root if the previous error was returned from a lookup that had recursion enabled.
* 如果上一个错误是从启用递归的查找返回的，则从根开始执行迭代查询。
For each fallback technique, attempts to reach multiple potential name servers should be skewed such that the next name server is tried when the previous one returns an error or a timeout is reached.
对于每种回退技术，到达多个潜在名称服务器的尝试都应该是倾斜的，以便在前一个名称服务器返回错误或达到超时时尝试下一个名称服务器。
The validator SHOULD remember, in its zone-specific fallback cache, any broken behavior identified for a particular zone for a duration of that zone's SOA-negative TTL.
验证器应该记住，在其特定于区域的回退缓存中，在特定区域的SOA负TTL期间，为该区域标识的任何损坏行为。
The validator MAY place name servers that exhibit broken behavior into a blacklist and bypass these name servers for all zones that they are authoritative for. The validator MUST time out entries in this name server blacklist periodically, where this interval could be set to be the same as the DNSSEC BAD cache default TTL.
验证器可能会将表现出破坏行为的名称服务器放入黑名单，并绕过这些名称服务器以获得其授权的所有区域。验证程序必须定期超时此名称服务器黑名单中的条目，其中此间隔可以设置为与DNSSEC坏缓存默认TTL相同。
It may be possible to use Non-DNSSEC-Capable caching resolvers in careful ways if maximum optimization is desired. This section describes some of the advanced techniques that could be implemented to use a resolver in at least a minimal way. Most of the time, this would be unnecessary; the exception being the case where none of the resolvers are fully compliant and, thus, the choice would be to use them at least minimally or not at all (and no caching benefits would be available).
如果需要最大程度的优化，可以谨慎地使用不支持DNSSEC的缓存解析器。本节介绍了一些可以实现的高级技术，这些技术可以至少以最小的方式使用解析器。大多数时候，这是不必要的；例外情况是，没有一个解析器是完全兼容的，因此，可以选择至少最低限度地使用它们，或者根本不使用它们（并且不提供缓存好处）。
If a resolver is Non-DNSSEC-Capable but a section of the DNS tree has been determined to be Insecure [RFC4035], then queries to this section of the tree MAY be sent through the Non-DNSSEC-Capable caching resolver.
如果解析程序不支持DNSSEC，但DNS树的某一部分已被确定为不安全[RFC4035]，则可通过不支持DNSSEC的缓存解析程序发送对该部分树的查询。
Resolvers that understand DNSSEC generally, and understand NSEC but not NSEC3, are partially usable. These resolvers generally also lack support for unknown types, rendering them mostly useless and to be avoided.
通常理解DNSSEC、理解NSEC但不理解NSEC3的解析器部分可用。这些解析器通常也缺乏对未知类型的支持，这使得它们大部分是无用的，需要避免。
A number of scenarios will produce either short-term or long-term connectivity issues with respect to DNSSEC validation. Consider the following cases:
许多场景将产生与DNSSEC验证相关的短期或长期连接问题。考虑以下情况：
Time Synchronization: Time synchronization problems can occur when a device has been off for a period of time and the clock is no longer in close synchronization with "real time" or when a device always has the clock set to the same time during start-up. This will cause problems when the device needs to resolve its source of time synchronization, such as "ntp.example.com".
时间同步：当设备关闭一段时间且时钟不再与“实时”紧密同步时，或当设备在启动期间始终将时钟设置为相同时间时，可能会出现时间同步问题。当设备需要解决其时间同步源（如“ntp.example.com”）时，这将导致问题。
Changing Network Properties: A newly established network connection may change state shortly after an HTTP-based paywall authentication system has been used. This is especially common in hotel, airport, and coffee-shop networks where DNSSEC, validation,
更改网络属性：新建立的网络连接可能在使用基于HTTP的付费墙身份验证系统后不久更改状态。这在酒店、机场和咖啡馆网络中尤其常见，其中DNSSEC、验证、，
and even DNS are not functional until the user proceeds through a series of forced web pages used to enable their network. The tests in Section 3 will produce very different results before and after the network authorization has succeeded. APIs exist on many operating systems to detect initial network device status changes, such as right after DHCP has finished, but few (none?) exist to detect that authentication through a paywall has succeeded.
而且，直到用户通过一系列用于启用其网络的强制网页时，DNS才起作用。第3节中的测试将在网络授权成功之前和之后产生非常不同的结果。许多操作系统上都存在API来检测初始网络设备状态的变化，例如在DHCP完成之后，但很少（没有？）存在API来检测通过付费墙进行的身份验证是否成功。
There are only two choices when situations like this happen:
发生这种情况时，只有两种选择：
Continue to perform DNSSEC processing, which will likely result in all DNS requests failing. This is the most secure route, but causes the most operational grief for users.
继续执行DNSSEC处理，这可能会导致所有DNS请求失败。这是最安全的路线，但会给用户带来最大的操作痛苦。
Turn off DNSSEC support until the network proves to be usable. This allows the user to continue using the network, at the cost of security. It also allows for a denial-of-service attack if a man-in-the-middle can convince a device that DNSSEC is impossible.
关闭DNSSEC支持，直到网络证明可用。这允许用户以安全为代价继续使用网络。如果中间人能够使设备相信DNSSEC是不可能的，那么它还允许拒绝服务攻击。
If the Host Validator detects that DNSSEC resolution is not possible, it SHOULD log the event and/or SHOULD report an error to the user. In the case where there is no user, no reporting can be performed; thus, the device MAY have a policy of action, like continue or fail. Until middleboxes allow DNSSEC-protected information to traverse them consistently, software implementations may need to offer this choice to let users pick the security level they require. Note that continuing without DNSSEC protection in the absence of a notification or report could lead to situations where users assume a level of security that does not exist.
如果主机验证程序检测到DNSSEC解析不可能，则应记录事件和/或向用户报告错误。在没有用户的情况下，不能进行报告；因此，设备可能具有操作策略，如继续或失败。在中间盒允许DNSSEC保护的信息一致地遍历它们之前，软件实现可能需要提供这种选择，以允许用户选择所需的安全级别。请注意，如果在没有通知或报告的情况下继续没有DNSSEC保护，可能会导致用户假定不存在安全级别的情况。
The quick tests defined below make the assumption that the questions to be asked are of a real resolver; and the only real question is: "How complete is the DNSSEC support?". This quick test has been implemented in a few programs developed at IETF hackathons at IETF 93 and IETF 94. The programs use a common grading method. For each question that returns an expected answer, the resolver gets a point. If the AD bit is set as expected, the resolver gets a second point.
下面定义的快速测试假设要问的问题是一个真正的解析器；唯一真正的问题是：“DNSSEC支持的完整程度如何？”。该快速测试已在IETF hackathons在IETF 93和IETF 94开发的一些程序中实施。这些程序使用一种通用的分级方法。对于每个返回预期答案的问题，解析器都会得到一分。如果AD位按预期设置，解析器将获得第二个点。
Query: realy-doesnotexist.test.example.com. A
查询：realy-doesnotexist.test.example.com。A.
Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC-proof
Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC-proof
Query: alg-8-nsec3.test.example.com. SOA
查询：alg-8-nsec3.test.example.com。SOA
Answer: RCODE= 0, Answer: SOA record
Answer: RCODE= 0, Answer: SOA record
Query: alg-13-nsec.test.example.com. SOA
查询：alg-13-nsec.test.example.com。SOA
Answer: RCODE= 0, Answer: SOA record
Answer: RCODE= 0, Answer: SOA record
Query: dnssec-failed.test.example.com. SOA
查询：dnssec-failed.test.example.com。SOA
Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0
Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0
This document discusses problems that may occur while deploying the DNSSEC protocol. It describes what may be possible to help detect and mitigate these problems. Following the outlined suggestions will result in a more secure DNSSEC-operational environment than if DNSSEC was simply disabled.
本文档讨论部署DNSSEC协议时可能出现的问题。它描述了可能有助于检测和缓解这些问题的方法。与直接禁用DNSSEC相比，遵循概述的建议将产生更安全的DNSSEC操作环境。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，DOI 10.17487/RFC4786，2006年12月<http://www.rfc-editor.org/info/rfc4786>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 5155，DOI 10.17487/RFC5155，2008年3月<http://www.rfc-editor.org/info/rfc5155>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <http://www.rfc-editor.org/info/rfc5625>.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 5625，DOI 10.17487/RFC5625，2009年8月<http://www.rfc-editor.org/info/rfc5625>.
Acknowledgments
致谢
We thank the IESG and DNSOP working group members for their extensive comments and suggestions.
我们感谢IESG和DNSOP工作组成员的广泛意见和建议。
Authors' Addresses
作者地址
Wes Hardaker USC/ISI P.O. Box 382 Davis, CA 95617 United States of America
美国加利福尼亚州戴维斯市382号威斯哈达克USC/ISI邮政信箱，邮编：95617
Email: ietf@hardakers.net
Email: ietf@hardakers.net
Olafur Gudmundsson CloudFlare San Francisco, CA 94107 United States of America
Olafur Gudmundsson CloudFlare旧金山，CA 94107美利坚合众国
Email: olafur+ietf@cloudflare.com
Email: olafur+ietf@cloudflare.com
Suresh Krishnaswamy Parsons 7110 Samuel Morse Dr Columbia, MD 21046 United States of America
Suresh Krishnaswamy Parsons 7110 Samuel Morse哥伦比亚博士，马里兰州21046美利坚合众国
Email: suresh@tislabs.com
Email: suresh@tislabs.com