Internet Engineering Task Force (IETF) P. Ebersman
Request for Comments: 7646 Comcast
Category: Informational W. Kumari
ISSN: 2070-1721 Google
C. Griffiths
Nominet
J. Livingood
Comcast
R. Weber
Nominum
September 2015
Internet Engineering Task Force (IETF) P. Ebersman
Request for Comments: 7646 Comcast
Category: Informational W. Kumari
ISSN: 2070-1721 Google
C. Griffiths
Nominet
J. Livingood
Comcast
R. Weber
Nominum
September 2015
Definition and Use of DNSSEC Negative Trust Anchors
DNSSEC负面信任锚的定义和使用
Abstract
摘要
DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.
DNS安全扩展（DNSSEC）现在正在广泛部署。但是，域签名工具和过程还不如与DNSSEC无关的域管理工具和过程成熟可靠。本文档定义了负信任锚（NTA），可通过在指定域禁用DNSSEC验证来缓解DNSSEC验证失败。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7646.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7646.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 and Motivation .....................................3
1.1. Definition of a Negative Trust Anchor ......................3
1.2. Motivations for Negative Trust Anchors .....................4
1.2.1. Mitigating Domain Validation Failures ...............4
1.2.2. Improving End-User Experience .......................4
1.2.3. Avoiding Switching to a Non-validating Resolver .....5
2. Use of a Negative Trust Anchor ..................................5
2.1. Applicability of Negative Trust Anchors ....................6
3. Managing Negative Trust Anchors .................................7
3.1. Alerting Users to Negative Trust Anchor Use ................7
4. Removal of a Negative Trust Anchor ..............................7
5. Comparison to Other DNS Misconfigurations .......................8
6. Intentionally Broken Domains ....................................8
7. Discovering Broken Domains ......................................9
8. Security Considerations ........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Configuration Examples ...............................13
A.1. NLnet Labs Unbound ........................................13
A.2. Internet System Consortium (ISC) BIND .....................14
A.3. Nominum Vantio ............................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................15
1. Introduction and Motivation .....................................3
1.1. Definition of a Negative Trust Anchor ......................3
1.2. Motivations for Negative Trust Anchors .....................4
1.2.1. Mitigating Domain Validation Failures ...............4
1.2.2. Improving End-User Experience .......................4
1.2.3. Avoiding Switching to a Non-validating Resolver .....5
2. Use of a Negative Trust Anchor ..................................5
2.1. Applicability of Negative Trust Anchors ....................6
3. Managing Negative Trust Anchors .................................7
3.1. Alerting Users to Negative Trust Anchor Use ................7
4. Removal of a Negative Trust Anchor ..............................7
5. Comparison to Other DNS Misconfigurations .......................8
6. Intentionally Broken Domains ....................................8
7. Discovering Broken Domains ......................................9
8. Security Considerations ........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Configuration Examples ...............................13
A.1. NLnet Labs Unbound ........................................13
A.2. Internet System Consortium (ISC) BIND .....................14
A.3. Nominum Vantio ............................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................15
DNSSEC has now entered widespread deployment. However, the DNSSEC signing tools and processes are less mature and reliable than those for non-DNSSEC-related administration. As a result, operators of DNS recursive resolvers, such as Internet Service Providers (ISPs), occasionally observe domains incorrectly managing DNSSEC-related resource records. This mismanagement triggers DNSSEC validation failures and then causes large numbers of end users to be unable to reach a domain. Many end users tend to interpret this as a failure of their ISP or resolver operator, and they may switch to a non-validating resolver or contact their ISP to complain, rather than seeing this as a failure on the part of the domain they wanted to reach. Without the techniques in this document, this pressure may cause the resolver operator to disable (or simply not deploy) DNSSEC validation.
DNSSEC现已进入广泛部署阶段。然而，与非DNSSEC相关管理相比，DNSSEC签署工具和流程不够成熟和可靠。因此，DNS递归解析程序的操作员（如Internet服务提供商（ISP））偶尔会发现域不正确地管理DNSSEC相关的资源记录。这种管理不善会触发DNSSEC验证失败，然后导致大量最终用户无法访问域。许多最终用户倾向于将此解释为其ISP或冲突解决程序运营商的故障，他们可能会切换到非验证冲突解决程序或联系其ISP投诉，而不是将此视为他们希望访问的域的故障。如果没有本文档中的技术，此压力可能会导致解析器操作员禁用（或干脆不部署）DNSSEC验证。
This document defines Negative Trust Anchors (NTAs), which can be used during the transition to ubiquitous DNSSEC deployment. NTAs are configured locally on a validating DNS recursive resolver to shield end users from DNSSEC-related authoritative name server operational errors. NTAs are intended to be temporary and only implemented by the organization requiring an NTA (and not distributed by any organizations outside of the administrative boundary). Finally, NTAs pertain only to DNSSEC and not to Public Key Infrastructures (PKIs) such as X.509.
本文档定义了负信任锚（NTA），可在过渡到无处不在的DNSSEC部署期间使用。NTA在验证DNS递归解析器上进行本地配置，以保护最终用户不受DNSSEC相关权威名称服务器操作错误的影响。NTA是临时性的，仅由需要NTA的组织实施（不由行政边界以外的任何组织分发）。最后，NTA仅适用于DNSSEC，而不适用于公钥基础设施（PKI），如X.509。
Use of an NTA to temporarily disable DNSSEC validation for a specific misconfigured domain name immediately restores access for end users. This allows the domain's administrators to fix their misconfiguration while also allowing the organization using the NTA to keep DNSSEC validation enabled and still reach the misconfigured domain.
使用NTA临时禁用特定错误配置域名的DNSSEC验证会立即恢复最终用户的访问。这允许域的管理员修复其错误配置，同时也允许使用NTA的组织保持启用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]中的说明进行解释。
Trust anchors are defined in [RFC5914]. A trust anchor is used by a validating caching resolver as a starting point for building the authentication chain for a signed DNS response. By way of analogy, NTAs stop validation of the authentication chain. Instead, the validator treats any upstream responses as if the zone is unsigned and does not set the Authentic Data (AD) bit in responses it sends to clients. Note that this is a behavior and not a separate resource record. This NTA can potentially be implemented at any level within
信任锚在[RFC5914]中定义。验证缓存解析程序使用信任锚点作为构建签名DNS响应的身份验证链的起点。通过类比，NTA停止验证链的验证。相反，验证程序将任何上游响应视为区域未签名，并且在发送给客户端的响应中未设置真实数据（AD）位。请注意，这是一种行为，而不是单独的资源记录。该NTA可能在公司内的任何级别实施
the chain of trust and would stop validation from that point in the chain down. Validation starts again if there is a positive trust anchor further down in the chain. For example, if there is an NTA at example.com and a positive trust anchor at foo.bar.example.com, then validation resumes for foo.bar.example.com and anything below it.
信任链将停止验证，从该点开始。如果链中有一个正向信任锚，验证将再次开始。例如，如果example.com上有一个NTA，foo.bar.example.com上有一个正向信任锚，那么foo.bar.example.com和它下面的任何东西都会恢复验证。
A domain name can fail validation for two general reasons: a legitimate security failure (e.g., due to an attack or compromise of some sort) or as a result of misconfiguration on the part of a zone administrator. As domains transition to DNSSEC, the most common reason for a validation failure has been misconfiguration. Thus, domain administrators should be sure to read [RFC6781] in full. They should pay special attention to Section 4.2 of [RFC6781], which pertains to key rollovers, as these appear to be the cause of many recent validation failures.
域名验证失败的一般原因有两个：合法的安全失败（例如，由于某种攻击或泄露）或区域管理员的错误配置。随着域转换到DNSSEC，验证失败的最常见原因是配置错误。因此，域管理员应该确保完整阅读[RFC6781]。他们应特别注意[RFC6781]第4.2节，该节涉及关键翻车，因为这些似乎是最近许多验证失败的原因。
It is also possible that some DNSSEC validation failures could arise due to differences in how different software developers interpret DNSSEC standards and/or how those developers choose to implement support for DNSSEC. For example, it is conceivable that a domain may be DNSSEC-signed properly, and one vendor's DNS recursive resolvers will validate the domain but other vendors' software may fail to validate the domain.
由于不同的软件开发人员对DNSSEC标准的解释方式和/或这些开发人员选择如何实施对DNSSEC的支持，也可能会出现一些DNSSEC验证失败。例如，可以想象，一个域可能是正确的DNSSEC签名，一个供应商的DNS递归解析器将验证该域，但其他供应商的软件可能无法验证该域。
End users generally do not know of, understand, or care about the resolution process that causes connections to happen. This is by design: the point of the DNS is to insulate users from having to remember IP addresses through a friendlier way of naming systems. It follows from this that end users do not, and should not, be expected to know about DNSSEC, validation, or anything of the sort. As a result, end users may misinterpret the failure to reach a domain due to DNSSEC-related misconfiguration. They may (incorrectly) assume that their ISP is purposely blocking access to the domain or that it is a performance failure on the part of their ISP (especially of the ISP's DNS servers). They may contact their ISP to complain, which will incur cost for their ISP. In addition, they may use online tools and sites to complain about this problem, such as via a blog, web forum, or social media site, which may lead to dissatisfaction on the part of other end users or general criticism of an ISP or operator of a DNS recursive resolver.
最终用户通常不知道、不理解或不关心导致连接发生的解决过程。这是出于设计：DNS的目的是通过一种更友好的命名系统，让用户不必记住IP地址。因此，最终用户不应该也不应该知道DNSSEC、验证或任何类似的信息。因此，最终用户可能会误解由于DNSSEC相关的错误配置导致无法访问域。他们可能（错误地）认为他们的ISP故意阻止对域的访问，或者认为这是他们的ISP（特别是ISP的DNS服务器）的性能故障。他们可能会联系他们的ISP投诉，这将为他们的ISP带来成本。此外，他们可能会使用在线工具和网站来投诉此问题，例如通过博客、网络论坛或社交媒体网站，这可能会导致其他最终用户的不满或对ISP或DNS递归解析器运营商的普遍批评。
As end users publicize these failures, others may recommend they switch from security-aware DNS resolvers to resolvers not performing DNSSEC validation. This is a shame since the ISP or other DNS recursive resolver operator is actually doing exactly what they are supposed to do in failing to resolve a domain name; this is the expected result when a domain can no longer be validated, and it protects end users from a potential security threat. Use of an NTA would allow the ISP to specifically remedy the failure to reach that domain, without compromising security for other sites. This would result in a satisfied end user, with minimal impact to the ISP, while maintaining the security of DNSSEC for correctly maintained domains.
当最终用户公布这些故障时，其他人可能会建议他们从具有安全意识的DNS解析程序切换到不执行DNSSEC验证的解析程序。这是一个耻辱，因为ISP或其他DNS递归解析器运营商实际上正在做他们应该做的事情，无法解析域名；当一个域不再能够被验证时，这是预期的结果，它可以保护最终用户免受潜在的安全威胁。使用NTA将允许ISP在不损害其他站点安全的情况下，特别补救未能到达该域的情况。这将使最终用户感到满意，对ISP的影响最小，同时为正确维护的域维护DNSSEC的安全性。
The following text from [RFC4033] is worth noting: "In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set." A responsibility (one of many) of a caching server operator is to protect the integrity of the cache.
[RFC4033]中的以下文本值得注意：“但是，归根结底，验证DNS密钥和数据是本地策略的问题，这可能会扩展甚至覆盖此文档集中定义的协议扩展。”缓存服务器操作员的职责（众多职责之一）是保护缓存的完整性。
As noted in Section 1.2.2, some people may consider switching to an alternative, non-validating resolver themselves, or may recommend that others do so. But if a domain fails DNSSEC validation and is inaccessible, this could very well be due to a security-related issue. In order to be as safe and secure as possible, end users should not change to DNS servers that do not perform DNSSEC validation as a workaround, and people should not recommend that others do so either. Domains that fail DNSSEC for legitimate reasons (versus misconfiguration) may be in control of hackers, or there could be other significant security issues with the domain.
正如在1.2.2节中所提到的，一些人可能会考虑切换到另一个非验证性的解析器本身，或者建议其他人这样做。但如果某个域未通过DNSSEC验证且无法访问，则很可能是由于安全相关的问题。为了尽可能的安全，最终用户不应更改为不执行DNSSEC验证的DNS服务器作为解决方法，人们也不应建议其他人这样做。由于合法原因（相对于错误配置）导致DNSSEC失败的域可能由黑客控制，或者域可能存在其他重大安全问题。
Thus, switching to a non-validating resolver to restore access to a domain that fails DNSSEC validation is not a recommended practice, is bad advice to others, and is potentially harmful to end-user security.
因此，切换到非验证解析程序以恢复对未通过DNSSEC验证的域的访问不是建议的做法，对其他人来说是错误的建议，并且可能对最终用户安全有害。
Technical personnel trained in the operation of DNS servers must confirm that a DNSSEC validation failure is due to misconfiguration, as a similar breakage could have occurred if an attacker gained access to a domain's authoritative servers and modified those records or had the domain pointed to their own rogue authoritative servers. They should also confirm that the domain is not intentionally broken, such as for testing purposes as noted in Section 6. Finally, they should make a reasonable attempt to contact the domain owner of the misconfigured zone, preferably prior to implementing the NTA.
在DNS服务器操作方面受过培训的技术人员必须确认DNSSEC验证失败是由于配置错误造成的，因为如果攻击者访问域的权威服务器并修改这些记录，或者将域指向其自己的恶意权威服务器，则可能会发生类似的破坏。他们还应确认该领域不是故意破坏的，如第6节所述的测试目的。最后，他们应该合理地尝试联系配置错误区域的域所有者，最好是在实施NTA之前。
Involving trained technical personnel is costly, but operational experience suggests that this is a very rare event, usually on the order of once per quarter (or even less).
涉及训练有素的技术人员成本高昂，但运营经验表明，这是一种非常罕见的事件，通常为每季度一次（甚至更少）。
It is important for the resolver operator to confirm that the domain is still under the ownership/control of the legitimate owner of the domain in order to ensure that disabling validation for a specific domain does not direct users to an address under an attacker's control. Contacting the domain owner and telling them the DNSSEC records that the resolver operator is seeing allows the resolver operator to determine if the issue is a DNSSEC misconfiguration or an attack.
解析程序操作员必须确认域仍在域合法所有者的所有权/控制下，以确保禁用特定域的验证不会将用户指向攻击者控制下的地址。与域所有者联系并告诉他们解析程序操作员看到的DNSSEC记录允许解析程序操作员确定问题是DNSSEC配置错误还是攻击。
In the case of a validation failure due to misconfiguration of a Top-Level Domain (TLD) or popular domain name (such as a top 100 website), content or services in the affected TLD or domain could be inaccessible for a large number of users. In such cases, it may be appropriate to use an NTA as soon as the misconfiguration is confirmed. An example of a list of "top N" websites is the Alexa "Top 500 Sites on the Web" [Alexa] or a list of the of the most-accessed names in the resolver's cache.
如果由于顶级域（TLD）或流行域名（如排名前100的网站）的错误配置而导致验证失败，大量用户可能无法访问受影响的TLD或域中的内容或服务。在这种情况下，一旦确认错误配置，就可以使用NTA。“top N”网站列表的一个示例是Alexa“Web上的500个网站”[Alexa]或解析程序缓存中访问次数最多的名称列表。
Once a domain has been confirmed to fail DNSSEC validation due to a DNSSEC-related misconfiguration, an ISP or other DNS recursive resolver operator may elect to use an NTA for that domain or sub-domain. This instructs their DNS recursive resolver to temporarily NOT perform DNSSEC validation at or in the misconfigured domain. This immediately restores access to the domain for end users while the domain's administrator corrects the misconfiguration(s). It does not and should not involve turning off validation more broadly.
一旦确认某个域由于DNSSEC相关的错误配置而未通过DNSSEC验证，ISP或其他DNS递归解析器运营商可选择对该域或子域使用NTA。这将指示他们的DNS递归解析程序暂时不在配置错误的域中执行DNSSEC验证。这将立即恢复最终用户对域的访问，同时域管理员更正错误配置。它没有也不应该涉及更广泛地关闭验证。
An NTA MUST only be used for a limited duration. Implementors SHOULD allow the operator using the NTA to set an end time and date associated with any NTA. Optimally, this time and date is set in a DNS recursive resolver's configuration, though in the short term, this may also be achieved via other systems or supporting processes. Use of an NTA MUST NOT be automatic.
NTA只能在有限的时间内使用。实施者应允许使用NTA的操作员设置与任何NTA相关的结束时间和日期。最佳情况下，此时间和日期是在DNS递归解析器的配置中设置的，尽管在短期内，这也可以通过其他系统或支持进程实现。不得自动使用NTA。
Finally, an NTA SHOULD be used only in a specific domain or sub-domain and MUST NOT affect validation of other names up the authentication chain. For example, an NTA for zone1.example.com would affect only names at or below zone1.example.com, and validation would still be performed on example.com, .com, and the root ("."). This NTA also SHOULD NOT affect names in another branch of the tree (such as example.net). In another example, an NTA for example.com would affect only names within example.com, and validation would
最后，NTA应仅在特定域或子域中使用，且不得影响认证链上其他名称的验证。例如，zone1.example.com的NTA将只影响zone1.example.com或以下的名称，并且仍将对example.com、.com和根（“.”）执行验证。此NTA也不应影响树的另一个分支（例如.net）中的名称。在另一个示例中，例如example.com的NTA只会影响example.com中的名称，而验证将
still be performed on .com and the root ("."). In this scenario, if there is a (probably manually configured) trust anchor for zone1.example.com, validation would be performed for zone1.example.com and subdomains of zone1.example.com.
仍然可以在.com和根目录（“.”）上执行。在此场景中，如果zone1.example.com有一个（可能是手动配置的）信任锚，则将对zone1.example.com和zone1.example.com的子域执行验证。
While NTAs have proven useful during the early stages of DNSSEC adoption, domain owners are ultimately responsible for managing and ensuring that their DNS records are configured correctly.
虽然NTA在DNSSEC采用的早期阶段已被证明是有用的，但域所有者最终负责管理并确保其DNS记录配置正确。
Most current implementations of DNS validating resolvers currently follow [RFC4033] on configuring a trust anchor using either a public key as in a DNSKEY resource record (RR) or a hash of a public key as in a DS RR.
当前大多数DNS验证解析器的实现都遵循[RFC4033]，即使用DNSKEY资源记录（RR）中的公钥或DS RR中的公钥哈希来配置信任锚。
Different DNS validators may have different configuration names for an NTA. For examples, see Appendix A.
对于NTA，不同的DNS验证程序可能具有不同的配置名称。有关示例，请参见附录A。
An NTA placed at a node where there is a configured positive trust anchor MUST take precedence over that trust anchor, effectively disabling it. Implementations MAY issue a warning or informational message when this occurs, so that operators are not surprised when this happens.
放置在存在已配置的正信任锚点的节点上的NTA必须优先于该信任锚点，从而有效地禁用它。当发生这种情况时，实现可能会发出警告或信息性消息，以便操作员在发生这种情况时不会感到惊讶。
End users of a DNS recursive resolver or other people may wonder why a domain that fails DNSSEC validation resolves with a supposedly validating resolver. Therefore, implementors should consider transparently disclosing NTAs that are currently in place or were in place in the past, such as on a website [Disclosure-Example].
DNS递归解析程序的最终用户或其他人可能想知道，为什么DNSSEC验证失败的域会使用假定的验证解析程序进行解析。因此，实现者应该考虑透明地公开过去在当前或已经到位的NTAS，例如在网站上[公开示例]。
This is particularly important since there is currently no special DNS query response code that could indicate to end users or applications that an NTA is in place. Such disclosures should optimally include both the data and time that the NTA was put in place and when it was removed.
这一点尤其重要，因为目前没有特殊的DNS查询响应代码可以向最终用户或应用程序表明NTA已到位。此类披露最好包括NTA实施的数据和时间，以及NTA被删除的时间。
As explored in Section 8, using an NTA once the zone correctly validates can have security considerations. It is therefore RECOMMENDED that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the NTA is in place, until such validation is again successful. NTAs MUST expire automatically when their configured lifetime ends. The lifetime SHOULD NOT exceed a week. There is limited experience with
如第8节所述，在区域正确验证后使用NTA可以考虑安全问题。因此，建议NTA实施者在NTA实施期间定期尝试验证相关域，直到验证再次成功。NTA必须在其配置的生存期结束时自动过期。寿命不应超过一周。这方面的经验有限
what this value should be, but at least one large vendor has documented customer feedback suggesting that a week is reasonable based on expectations of how long failures take to fix or to be forgotten. Operational experience may further refine these expectations.
这个值应该是多少，但至少有一家大型供应商记录了客户反馈，根据修复或忘记故障所需时间的预期，一周是合理的。运营经验可能会进一步完善这些预期。
Before removing the NTA, all authoritative resolvers listed in the zone should be checked (due to anycast and load balancers, it may not be possible to check all instances).
在删除NTA之前，应检查区域中列出的所有权威解析程序（由于anycast和负载平衡器，可能无法检查所有实例）。
Once all testing succeeds, an NTA should be removed as soon as is reasonably possible. One possible method to automatically determine when the NTA can be removed is to send a periodic query for type Start of Authority (SOA) at the NTA node; if it gets a response that it can validate (whether the response was an actual SOA answer or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is presumed no longer to be necessary and is removed. Implementations SHOULD, by default, perform this operation. Note that under some circumstances, this is undesirable behavior (for example, if www.example.com has a bad signature, but example.com/SOA is fine), so implementations may wish to allow the operator to override this spot-check/behavior.
一旦所有测试成功，NTA应尽快移除。自动确定何时可以删除NTA的一种可能方法是在NTA节点发送一个定期查询，以获取类型Start of AUTHORY（SOA）；如果它得到了一个可以验证的响应（无论该响应是实际的SOA响应还是具有适当NSEC/NSEC3记录的NOERROR/NODATA），NTA将被认为不再需要，并被删除。默认情况下，实现应该执行此操作。请注意，在某些情况下，这是不可取的行为（例如，如果www.example.com的签名不正确，但example.com/SOA没有问题），因此实现可能希望允许操作员覆盖此抽查/行为。
When removing the NTA, the implementation SHOULD remove all cached entries at and below the NTA node.
删除NTA时，实现应删除NTA节点上和下的所有缓存项。
Domain administrators are ultimately responsible for managing and ensuring their DNS records are configured correctly. ISPs or other DNS recursive resolver operators cannot and should not correct misconfigured A, CNAME, MX, or other resource records of domains for which they are not authoritative. Expecting non-authoritative entities to protect domain administrators from any misconfiguration of resource records is therefore unrealistic and unreasonable and, in the long term, is harmful to the delegated design of the DNS and could lead to extensive operational instability and/or variation.
域管理员最终负责管理并确保正确配置其DNS记录。ISP或其他DNS递归解析程序操作员不能也不应该纠正其非权威域的错误配置的A、CNAME、MX或其他资源记录。因此，期望非权威实体保护域管理员不受任何资源记录错误配置的影响是不现实和不合理的，从长远来看，这对DNS的授权设计有害，并可能导致广泛的操作不稳定和/或变化。
With DNSSEC breakage, it is often possible to tell that there is a misconfiguration by looking at the data and not needing to guess what it should have been.
对于DNSSEC破损，通常可以通过查看数据而不需要猜测数据应该是什么来判断是否存在错误配置。
Some domains, such as dnssec-failed.org, have been intentionally broken for testing purposes [Website-Visitors] [Netalyzr]. For example, dnssec-failed.org is a DNSSEC-signed domain that is broken. If an end user is querying a validating DNS recursive resolver, then
出于测试目的[网站访问者][Netalyzr]故意破坏了某些域，如dnssec-failed.org。例如，dnssec-failed.org是一个已断开的dnssec签名域。如果最终用户正在查询验证DNS递归解析器，则
this or other similarly intentionally broken domains should fail to resolve and should result in a "Server Failure" error (RCODE 2, also known as 'SERVFAIL'). If such a domain resolved successfully, then it is a sign that the DNS recursive resolver is not fully validating.
此域或其他类似故意破坏的域应无法解决，并应导致“服务器故障”错误（RCODE 2，也称为“SERVFAIL”）。如果成功解析此类域，则表明DNS递归解析程序未完全验证。
Organizations that utilize NTAs should not add an NTA for any intentionally broken domain. Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DNSSEC.
使用NTA的组织不应为任何故意破坏的域添加NTA。要求操作员尝试联系已破坏DNSSEC的区域的管理员，以防止此类添加。
Organizations operating an intentionally broken domain may wish to consider adding a TXT record for the domain to the effect of "This domain is purposely DNSSEC broken for testing purposes".
运行有意破坏的域的组织可能希望考虑为该域添加“TXT记录”，以“该域有意为测试目的而破坏DNSSEC”。
Discovering that a domain is DNSSEC broken as a result of an operator error instead of an attack is not trivial, and the examples here should be vetted by an experienced professional before making the decision to implement an NTA.
发现域因操作员错误而不是攻击而被DNSSEC破坏并非易事，在决定实施NTA之前，这里的示例应由经验丰富的专业人员进行审查。
One of the key things to look for when looking at a DNSSEC broken domain is consistency and history. Therefore, it is good if you have the ability to look at the server's DNS traffic over a long period of time or have a database that stores DNS names and associated answers (this is often referred to as a "passive DNS database"). Another invaluable tool is DNSViz (http://dnsviz.net), which also stores DNSSEC-related data historically. The drawback here is that you need for it to have tested the domain before the incident occurs.
在查看DNSSEC断开的域时，需要查找的关键内容之一是一致性和历史记录。因此，如果您能够长时间查看服务器的DNS流量，或者拥有一个存储DNS名称和相关答案的数据库（这通常被称为“被动DNS数据库”），这是很好的。另一个宝贵的工具是DNSViz(http://dnsviz.net)，它还存储历史上与DNSSEC相关的数据。这里的缺点是，您需要在事件发生之前对域进行测试。
The first and easiest thing to check is if the failure of the domain is consistent across different software implementations. If not, you want to inform the vendor where it fails so that the vendor can look more deeply into the issue.
第一件也是最容易检查的事情是，域的故障是否在不同的软件实现中是一致的。如果没有，您希望通知供应商它失败的地方，以便供应商可以更深入地调查问题。
The next thing is to figure out what the actual failure mode is. At the time of this writing, several tools that do this are available, including:
下一步是找出实际的故障模式是什么。在撰写本文时，有几种工具可用于此目的，包括：
o DNSViz (http://dnsviz.net)
o DNSViz(http://dnsviz.net)
o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com)
o Verisign DNSSEC调试器(http://dnssec-debugger.verisignlabs.com)
o Zonemaster (http://www.zonemaster.fr, https://github.com/dotse/ zonemaster)
o 区域管理员(http://www.zonemaster.fr, https://github.com/dotse/ 区域管理员）
Most of these tools are open source and can be installed locally. However, using the tools over the Internet has the advantage of providing visibility from a different point. This is an incomplete list, and it is expected that additional tools will be developed over time to aid in troubleshooting DNSSEC issues.
这些工具大多是开源的，可以在本地安装。然而，在互联网上使用这些工具的优点是可以从不同的角度提供可见性。这是一个不完整的列表，预计随着时间的推移，将开发更多的工具来帮助解决DNSSEC问题。
Once you figure out what the error is, you need to check if it shows consistently around the world and from all authoritative servers. Use DNS Tools (dig) or DNS looking glasses to verify this. An error that is consistently the same is more likely to be caused by an operator rather than by an attack. Also, if the output from the authoritative server is consistently different from the resolvers' output, this hints to an attack rather then an error, unless EDNS0 client subnet [CLIENT-SUBNET] is applied to the domain.
一旦你弄清楚错误是什么，你需要检查它是否在世界各地和所有权威服务器上一致地显示。使用DNS工具（dig）或DNS窥镜来验证这一点。一致相同的错误更有可能由操作员而不是攻击引起。此外，如果权威服务器的输出始终不同于解析程序的输出，则这将提示攻击而不是错误，除非EDNS0客户端子网[client-subnet]应用于域。
A last check is to look at the actual DNS data. Is the result of the query still the same or has it changed? While a lot of DNSSEC errors occur on events that change DNSSEC data, the actual record someone wants to go to often stays the same. If the data is the same, this is an indication (not a guarantee) that the error is operator caused. Keep in mind that with DNS being used to globally balance traffic, the data associated to a name might be different in different parts of the Internet.
最后一项检查是查看实际的DNS数据。查询的结果是否仍然相同或已更改？虽然许多DNSSEC错误发生在更改DNSSEC数据的事件上，但人们想要访问的实际记录通常保持不变。如果数据相同，则表明（不保证）错误是由操作员引起的。请记住，由于DNS用于全局平衡流量，与名称关联的数据在Internet的不同部分可能不同。
Here are some examples of common DNSSEC failures that have been seen as operator signing errors on the Internet:
以下是一些常见的DNSSEC故障示例，这些故障被视为Internet上的操作员签名错误：
o RRSIG timing issue. Each signature has an inception time and expiry time between which it is valid. Letting this time expire without creating a new signature is one of the most common DNSSEC errors. To a lesser extent, this also occurs if signatures were made active before the inception time. For all of these errors, your primary check is to check on the data. Signature expiration is also about the only error we see on actual data (like www.example.com). All other errors are more or less related to dealing with the chain of trust established by DS records in the parent zone and DNSKEYs in the child zones. These mostly occur during key rollovers but are not limited to that.
o RRSIG定时问题。每个签名都有一个起始时间和到期时间，在此期间签名有效。让此时间过期而不创建新签名是最常见的DNSSEC错误之一。在较小程度上，如果在初始时间之前激活了签名，也会发生这种情况。对于所有这些错误，您的主要检查是检查数据。签名过期也是我们在实际数据（如www.example.com）上看到的唯一错误。所有其他错误或多或少都与处理由父区域中的DS记录和子区域中的DNSKEY建立的信任链有关。这些主要发生在关键翻车期间，但不限于此。
o DNSKEYs in a child zone don't match the DS record in the parent zone. There is a big variation of this that can happen at any point in the key lifecycle. DNSViz is the best tool to show problems in the chain. If you debug it yourself, use dig +multiline so that you can see the key id of a DNSKEY. Common variations of this can be:
o 子区域中的DNSKEY与父区域中的DS记录不匹配。在关键生命周期的任何时候都可能发生这种情况的巨大变化。DNSViz是显示链中问题的最佳工具。如果您自己调试，请使用dig+multiline，以便可以看到DNSKEY的密钥id。这方面的常见变化可能是：
* DS pointing to a non-existent key in the child zone. Questions for consideration here include the following. Has there ever been a key (and, if so, was it used)? Has there been a recent change in the DNSKEY RRSet (indicating a key rollover)? Has the actual data in the zone changed? Is the zone DNSSEC signed at all and has it been in the past?
* DS指向子区域中不存在的密钥。这里要考虑的问题包括以下几点。有没有钥匙（如果有，是否使用过）？DNSKEY RRSet最近是否发生了变化（表示密钥翻转）？区域中的实际数据是否已更改？区域DNSSEC是否已经签署，过去是否签署过？
* DS pointing to an existent key, but no signatures are made with the key. The checks above should be done, with the addition of checking if another key in the DNSKEY RRSet is now used to sign the records.
* DS指向现有密钥，但没有使用该密钥进行签名。应进行上述检查，并检查DNSKEY RRSet中的另一个密钥现在是否用于签署记录。
* Data in DS or DNSKEY doesn't match the other. This is more common in initial setup when there was a copy-and-paste error. Again, checking history on data is the best you can do there.
* DS或DNSKEY中的数据与另一个不匹配。当出现复制粘贴错误时，这在初始设置中更为常见。同样，检查数据的历史记录是最好的方法。
All of the above is just a starting point for consideration when deciding whether or not to deploy a trust anchor. It is not possible to provide a simple checklist to run through to determine whether a domain is broken because of an attack or an operator error.
在决定是否部署信任锚时，以上所有内容只是一个考虑的起点。不可能提供一个简单的检查表来运行，以确定域是否因攻击或操作员错误而中断。
End-to-end DNSSEC validation will be disabled during the time that an NTA is used. In addition, the NTA may be in place after the time when the DNS misconfiguration that caused validation to break has been fixed. Thus, there may be a gap between when a domain has been re-secured and when an NTA is removed. In addition, an NTA may be put in place by DNS recursive resolver operators without the knowledge of the authoritative domain administrator for a given domain name. However, attempts SHOULD be made to contact and inform the domain administrator prior to putting the NTA in place.
在使用NTA期间，将禁用端到端DNSSEC验证。此外，NTA可能在导致验证中断的DNS错误配置被修复后到位。因此，域被重新保护和NTA被移除之间可能存在间隙。此外，DNS递归解析器操作员可以在给定域名的权威域管理员不知道的情况下放置NTA。但是，在实施NTA之前，应尝试联系并通知域管理员。
One side effect of implementing an NTA is that it may break client applications that assume that a domain is signed and expect an AD bit in the response. It is expected that many applications that require DNSSEC for a domain will perform their own validation, so this should not be a major issue.
实现NTA的一个副作用是，它可能会破坏假定域已签名并期望响应中有AD位的客户端应用程序。预计许多域需要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>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, <http://www.rfc-editor.org/info/rfc5914>.
[RFC5914]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚格式”，RFC 5914，DOI 10.17487/RFC59142010年6月<http://www.rfc-editor.org/info/rfc5914>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，DOI 10.17487/RFC6781，2012年12月<http://www.rfc-editor.org/info/rfc6781>.
[Alexa] Alexa, "The top 500 sites on the web", <http://www.alexa.com/topsites>.
[Alexa]Alexa，“网络500强网站”<http://www.alexa.com/topsites>.
[CLIENT-SUBNET] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", Work in Progress, draft-ietf-dnsop-edns-client-subnet-03, August 2015.
[CLIENT-SUBNET]Contavalli，C.，van der Gaast，W.，Lawrence，D.，和W.Kumari，“DNS查询中的客户端子网”，正在进行的工作，草稿-ietf-dnsop-edns-CLIENT-SUBNET-032015年8月。
[Disclosure-Example] Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", February 2013, <http://dns.comcast.net/index.php/entry/ faa-gov-failing-dnssec-validation-fixed>.
[披露示例]Comcast，“faa.gov未通过DNSSEC验证（已修复）”，2013年2月<http://dns.comcast.net/index.php/entry/ faa gov未通过dnssec验证已修复>。
[Netalyzr] Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, "Implications of Netalyzr's DNS Measurements", Securing and Trusting Internet Names (SATIN), April 2011, <http://conferences.npl.co.uk/satin/presentations/ satin2011slides-Weaver.pdf>.
[Netalyzr]Weaver，N.，Kreibich，C.，Nechaev，B.，和V.Paxson，“Netalyzr DNS测量的影响”，保护和信任互联网名称（SANDIN），2011年4月<http://conferences.npl.co.uk/satin/presentations/ satin2011slides Weaver.pdf>。
[Unbound-Config] Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 2010, <http://unbound.net/documentation/ howto_turnoff_dnssec.html>.
[Unbound Config]Wijngaards，W.，“Unbound:如何关闭DNSSEC”，2010年6月<http://unbound.net/documentation/ 如何关闭dnssec.html>。
[Website-Visitors] Mens, J., "Is my Web site being used via a DNSSEC-validator?", July 2012, <http://jpmens.net/2012/07/30/ is-my-web-site-being-used-via-dnssec-validator/>.
[网站访问者]Mens，J.，“我的网站是否通过DNSSEC验证程序使用？”，2012年7月<http://jpmens.net/2012/07/30/ 是否通过dnssec validator/>使用我的网站。
The section contains example configurations to achieve NTA functionality for the zone foo.example.com.
本节包含实现zone foo.example.com NTA功能的示例配置。
Note: These are simply examples -- name server operators are expected to test and understand the implications of these operations. Note also that some of available implementations may not implement all recommended functionality in this document. In that case, it is advisable to request the developer or vendor of the implementation to support the missing feature rather than start using the incomplete implementation.
注意：这些只是示例——名称服务器操作员需要测试并理解这些操作的含义。还请注意，一些可用的实现可能无法实现本文档中推荐的所有功能。在这种情况下，建议请求实现的开发人员或供应商支持缺少的特性，而不是开始使用不完整的实现。
Unbound [Unbound-Config] lets us simply disable validation checking for a specific zone by adding configuration statements to unbound.conf:
Unbound[Unbound Config]允许我们通过向Unbound.conf添加配置语句来简单地禁用特定区域的验证检查：
server: domain-insecure: "foo.example.com"
服务器：域不安全：“foo.example.com”
Using the 'unbound-control' command, one can add and remove NTAs without restarting the name server.
使用“unbound control”命令，可以添加和删除NTA，而无需重新启动名称服务器。
Using the "unbound-control" command: list_insecure list domain-insecure zones insecure_add zone add domain-insecure zone insecure_remove zone remove domain-insecure zone
使用“unbound control”命令：list\u unsecure list domain unsecure zones unsecure\u add zone add domain unsecure zone unsecure\u remove zone remove domain unsecure zone
Items added with the "unbound-control" command are added to the running server and are lost when the server is restarted. Items from unbound.conf stay after restart.
使用“unbound control”命令添加的项目将添加到正在运行的服务器，并且在服务器重新启动时丢失。unbound.conf中的项目在重新启动后保留。
For additional information, see [Unbound-Config].
有关更多信息，请参阅[未绑定配置]。
Use the "rndc" command:
使用“rndc”命令：
nta -dump List all negative trust anchors. nta [-lifetime duration] [-force] domain [view] Set a negative trust anchor, disabling DNSSEC validation for the given domain. Using -lifetime specifies the duration of the NTA, up to one week. The default is one hour. Using -force prevents the NTA from expiring before its full lifetime, even if the domain can validate sooner. nta -remove domain [view] Remove a negative trust anchor, re-enabling validation for the given domain.
nta-转储列出所有负面信任锚。nta[-lifetime duration][-force]域[view]设置负信任锚定，禁用给定域的DNSSEC验证。Using-lifetime指定NTA的持续时间，最长为一周。默认值为一小时。使用-force可以防止NTA在其整个生命周期之前过期，即使域可以更快地进行验证。nta-删除域[view]删除负面信任锚，重新启用给定域的验证。
**
**
*negative-trust-anchors*
*消极信任锚*
_Format_: name
_格式：名称
_Command Channel_: view.update name=world negative-trust-anchors=(foo.example.com)
_命令通道：view.updatename=世界负信任锚=（foo.example.com）
_Command Channel_: resolver.update name=res1 negative-trust-anchors=(foo.example.com)
_命令通道：resolver.updatename=res1负信任锚=（foo.example.com）
*Description*: Disables DNSSEC validation for a domain, even if the domain is under an existing security root.
*Description*：禁用域的DNSSEC验证，即使该域位于现有安全根目录下。
Acknowledgements
致谢
Several people made contributions to this document and/or played an important role in the development and evolution of it. In some cases, this included performing a detailed review and then providing feedback and constructive criticism for future revisions, or engaging in a healthy debate over the subject of the document. All of this was helpful, and therefore, the following individuals merit acknowledgement: Joe Abley, John Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom, Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes Hardaker, Paul Hoffman, Christer Holmberg, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc Lampo, Ted Lemon, Scott Rose, A. Schulze, Wendy Seltzer, Antoin Verschuren, Paul Vixie, Patrik Wallstrom, Nick Weaver, W.C.A. Wijngaards, and Suzanne Woolf.
一些人对此文件做出了贡献和/或在其发展和演变过程中发挥了重要作用。在某些情况下，这包括进行详细审查，然后为将来的修订提供反馈和建设性批评，或者就文件主题进行健康的辩论。所有这些都是有帮助的，因此，以下个人值得承认：乔·艾布利、约翰·巴尼茨、汤姆·克雷顿、马可·戴维斯、布赖恩·迪克森、帕特里克·福斯特罗姆、托尼·芬奇、克里斯·甘斯特、奥拉富尔·古德蒙松、彼得·哈戈皮安、韦斯·哈达克、保罗·霍夫曼、克里斯特·霍姆伯格、谢恩·克尔、默里·库奇拉维、里克·兰姆、马克·兰波、特德·莱蒙，斯科特·罗斯、A.舒尔茨、温迪·萨尔茨、安托因·维舒伦、保罗·维克西、帕特里克·沃尔斯特罗姆、尼克·韦弗、W.C.A.维恩加德斯和苏珊娜·伍尔夫。
Edward Lewis, Evan Hunt, Andrew Sullivan, and Tatuya Jinmei provided especially large amounts of text and/or detailed review.
Edward Lewis、Evan Hunt、Andrew Sullivan和Tatuya Jinmei提供了大量文本和/或详细评论。
Authors' Addresses
作者地址
Paul Ebersman Comcast One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 United States
美国宾夕法尼亚州费城肯尼迪大道1701号保罗·埃伯斯曼康卡斯特一号康卡斯特中心，邮编：19103
Email: ebersman-ietf@dragon.net
Email: ebersman-ietf@dragon.net
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043
Email: warren@kumari.net
URI: http://www.google.com
Email: warren@kumari.net
URI: http://www.google.com
Chris Griffiths Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ United Kingdom
Chris Griffiths Nominet Minerva House Edmund Halley Road牛津科技园牛津OX4 4DQ英国
Email: cgriffiths@gmail.com
URI: http://www.nominet.org.uk/
Email: cgriffiths@gmail.com
URI: http://www.nominet.org.uk/
Jason Livingood Comcast One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 United States
美国宾夕法尼亚州费城肯尼迪大道1701号詹森·利文戈德康卡斯特一号康卡斯特中心，邮编：19103
Email: jason_livingood@cable.comcast.com
URI: http://www.comcast.com
Email: jason_livingood@cable.comcast.com
URI: http://www.comcast.com
Ralf Weber Nominum
拉尔夫·韦伯·诺米姆
Email: Ralf.Weber@nominum.com
URI: http://www.nominum.com
Email: Ralf.Weber@nominum.com
URI: http://www.nominum.com