Internet Engineering Task Force (IETF) S. Dickinson
Request for Comments: 8310 Sinodun
Updates: 7858 D. Gillmor
Category: Standards Track ACLU
ISSN: 2070-1721 T. Reddy
McAfee
March 2018
Internet Engineering Task Force (IETF) S. Dickinson
Request for Comments: 8310 Sinodun
Updates: 7858 D. Gillmor
Category: Standards Track ACLU
ISSN: 2070-1721 T. Reddy
McAfee
March 2018
Usage Profiles for DNS over TLS and DNS over DTLS
通过TLS的DNS和通过DTL的DNS的使用配置文件
Abstract
摘要
This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.
本文档讨论基于一个或多个身份验证机制的使用概况，这些机制可用于传输层安全性（TLS）或数据报TLS（DTL）上的DNS。与仅使用明文DNS相比，这些配置文件可以增加DNS事务的隐私。本文档还指定了新的身份验证机制——它描述了DNS客户端可以使用身份验证域名对与DNS服务器的（D）TLS连接进行身份验证的几种方法。此外，它还为通过（D）TLS实现DNS的DNS客户端和服务器定义（D）TLS协议配置文件。本文件更新了RFC 7858。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8310.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8310.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Scope ...........................................................7
4. Discussion ......................................................8
5. Usage Profiles ..................................................8
5.1. DNS Resolution ............................................11
6. Authentication in DNS over (D)TLS ..............................11
6.1. DNS-over-(D)TLS Startup Configuration Problems ............11
6.2. Credential Verification ...................................12
6.3. Summary of Authentication Mechanisms ......................12
6.4. Combining Authentication Mechanisms .......................15
6.5. Authentication in Opportunistic Privacy ...................15
6.6. Authentication in Strict Privacy ..........................16
6.7. Implementation Guidance ...................................16
7. Sources of Authentication Domain Names .........................17
7.1. Full Direct Configuration .................................17
7.2. Direct Configuration of ADN Only ..........................17
7.3. Dynamic Discovery of ADN ..................................17
7.3.1. DHCP ...............................................18
8. Credential Verification Based on Authentication Domain Name ....18
8.1. Authentication Based on PKIX Certificate ..................18
8.2. DANE ......................................................19
8.2.1. Direct DNS Meta-Queries ............................20
8.2.2. TLS DNSSEC Chain Extension .........................20
9. (D)TLS Protocol Profile ........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
11.1. Countermeasures to DNS Traffic Analysis ..................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................24
Appendix A. Server Capability Probing and Caching by DNS Clients ..26
Acknowledgments ...................................................27
Authors' Addresses ................................................27
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Scope ...........................................................7
4. Discussion ......................................................8
5. Usage Profiles ..................................................8
5.1. DNS Resolution ............................................11
6. Authentication in DNS over (D)TLS ..............................11
6.1. DNS-over-(D)TLS Startup Configuration Problems ............11
6.2. Credential Verification ...................................12
6.3. Summary of Authentication Mechanisms ......................12
6.4. Combining Authentication Mechanisms .......................15
6.5. Authentication in Opportunistic Privacy ...................15
6.6. Authentication in Strict Privacy ..........................16
6.7. Implementation Guidance ...................................16
7. Sources of Authentication Domain Names .........................17
7.1. Full Direct Configuration .................................17
7.2. Direct Configuration of ADN Only ..........................17
7.3. Dynamic Discovery of ADN ..................................17
7.3.1. DHCP ...............................................18
8. Credential Verification Based on Authentication Domain Name ....18
8.1. Authentication Based on PKIX Certificate ..................18
8.2. DANE ......................................................19
8.2.1. Direct DNS Meta-Queries ............................20
8.2.2. TLS DNSSEC Chain Extension .........................20
9. (D)TLS Protocol Profile ........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
11.1. Countermeasures to DNS Traffic Analysis ..................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................24
Appendix A. Server Capability Probing and Caching by DNS Clients ..26
Acknowledgments ...................................................27
Authors' Addresses ................................................27
DNS privacy issues are discussed in [RFC7626]. The specific issues described in [RFC7626] that are most relevant to this document are
DNS隐私问题在[RFC7626]中讨论。[RFC7626]中描述的与本文件最相关的具体问题如下：
o Passive attacks that eavesdrop on cleartext DNS transactions on the wire (Section 2.4 of [RFC7626]) and
o 窃听在线明文DNS交易的被动攻击（RFC7626第2.4节）和
o Active attacks that redirect clients to rogue servers to monitor DNS traffic (Section 2.5.3 of [RFC7626]).
o 将客户端重定向到恶意服务器以监视DNS流量的主动攻击（RFC7626第2.5.3节）。
Mitigating these attacks increases the privacy of DNS transactions; however, many of the other issues raised in [RFC7626] still apply.
减轻这些攻击会增加DNS交易的隐私；然而，[RFC7626]中提出的许多其他问题仍然适用。
Two documents that provide ways to increase DNS privacy between DNS clients and DNS servers are
以下两个文档提供了增加DNS客户端和DNS服务器之间DNS隐私的方法：
o "Specification for DNS over Transport Layer Security (TLS)" [RFC7858], referred to here as simply "DNS over TLS".
o “传输层上的DNS安全规范（TLS）”[RFC7858]，此处简称为“TLS上的DNS”。
o "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094], referred to here as simply "DNS over DTLS". Note that [RFC8094] is an Experimental specification.
o “数据报传输层安全性（DTLS）上的DNS”[RFC8094]，此处简称为“DTLS上的DNS”。请注意，[RFC8094]是一个实验规范。
Both documents are limited in scope to communications between stub clients and recursive resolvers, and the same scope is applied to this document (see Sections 2 and 3). The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application was out of scope for the DNS PRIVate Exchange (dprive) Working Group charter at the time this document was published.
这两个文档的范围都局限于存根客户端和递归解析器之间的通信，并且相同的范围也适用于本文档（参见第2节和第3节）。此处的建议可能会在将来进行修改或扩展，以用于递归客户端和权威服务器，但在本文档发布时，此应用程序超出了DNS专用交换（dprive）工作组章程的范围。
This document specifies two usage profiles (Strict Privacy and Opportunistic Privacy) for DTLS [RFC6347] and TLS [RFC5246] that provide improved levels of mitigation for the attacks described above compared to using only cleartext DNS.
本文档为DTL[RFC6347]和TLS[RFC5246]指定了两个使用配置文件（严格隐私和机会主义隐私），与仅使用明文DNS相比，这两个配置文件为上述攻击提供了更好的缓解级别。
Section 5 presents a generalized discussion of usage profiles by separating the usage profile, which is based purely on the security properties it offers the user, from the specific mechanism or mechanisms that are used for DNS server authentication. The profiles described are
第5节通过将纯粹基于其提供给用户的安全属性的使用配置文件与用于DNS服务器身份验证的一个或多个特定机制分开，对使用配置文件进行了一般性讨论。所描述的配置文件如下所示
o A Strict Privacy profile, which requires an encrypted connection and successful authentication of the DNS server; this mitigates both passive eavesdropping and client redirection (at the expense of providing no DNS service if an encrypted, authenticated connection is not available).
o 严格的隐私配置文件，需要加密连接和DNS服务器的成功身份验证；这减轻了被动窃听和客户端重定向（如果加密、身份验证的连接不可用，则以不提供DNS服务为代价）。
o An Opportunistic Privacy profile, which will attempt, but does not require, encryption and successful authentication; it therefore provides limited or no mitigation for such attacks but maximizes the chance of DNS service.
o 机会主义隐私档案，将尝试但不要求加密和成功认证；因此，它为此类攻击提供了有限的缓解措施，或没有缓解措施，但最大限度地提高了DNS服务的机会。
The above usage profiles attempt authentication of the server using at least one authentication mechanism. Section 6.4 discusses how to combine authentication mechanisms to determine the overall authentication result. Depending on that overall authentication result (and whether encryption is available), the usage profile will determine if the connection should proceed, fall back, or fail.
以上使用配置文件尝试使用至少一种身份验证机制对服务器进行身份验证。第6.4节讨论了如何组合身份验证机制以确定总体身份验证结果。根据整个身份验证结果（以及加密是否可用），使用情况配置文件将确定连接是否应继续、后退或失败。
One authentication mechanism is already described in [RFC7858]. [RFC7858] specifies an authentication mechanism for DNS over TLS that is based on Subject Public Key Info (SPKI) in the context of a specific case of a Strict Privacy profile using that single authentication mechanism. Therefore, the "out-of-band key-pinned privacy profile" described in [RFC7858] would qualify as a "Strict Privacy profile" that used SPKI pinning for authentication.
[RFC7858]中已经描述了一种身份验证机制。[RFC7858]指定TLS上DNS的身份验证机制，该机制基于使用单一身份验证机制的严格隐私配置文件的特定情况下的主题公钥信息（SPKI）。因此，[RFC7858]中描述的“带外密钥锁定隐私配置文件”将符合使用SPKI锁定进行身份验证的“严格隐私配置文件”的条件。
This document extends the use of authentication based on SPKI pin sets, so that it is considered a general authentication mechanism that can be used with either DNS-over-(D)TLS usage profile. That is, the mechanism for SPKI pin sets as described in [RFC7858] MAY be used with DNS over (D)TLS.
本文档扩展了基于SPKI pin集的身份验证的使用，因此它被认为是一种通用身份验证机制，可与DNS over-（D）TLS使用配置文件一起使用。也就是说，[RFC7858]中所述的SPKI引脚集机制可与（D）TLS上的DNS一起使用。
This document also describes a number of additional authentication mechanisms, all of which specify how a DNS client should authenticate a DNS server based on an "authentication domain name". In particular, the following topics are described:
本文档还描述了一些附加的身份验证机制，所有这些机制都指定了DNS客户端应如何基于“身份验证域名”对DNS服务器进行身份验证。具体而言，描述了以下主题：
o How a DNS client can obtain the combination of an authentication domain name and IP address for a DNS server. See Section 7.
o DNS客户端如何获得DNS服务器的身份验证域名和IP地址的组合。见第7节。
o What acceptable credentials a DNS server can present to prove its identity for (D)TLS authentication based on a given authentication domain name. See Section 8.
o DNS服务器可以提供哪些可接受的凭据来证明其身份，以便基于给定的身份验证域名进行（D）TLS身份验证。见第8节。
o How a DNS client can verify that any given credential matches the authentication domain name obtained for a DNS server. See Section 8.
o DNS客户端如何验证任何给定凭据是否与为DNS服务器获得的身份验证域名匹配。见第8节。
This document defines a (D)TLS protocol profile for use with DNS; see Section 9. This profile defines the configuration options and protocol extensions required of both parties to (1) optimize connection establishment and session resumption for transporting DNS and (2) support all currently specified authentication mechanisms.
本文件定义了（D）用于DNS的TLS协议配置文件；见第9节。此配置文件定义了双方所需的配置选项和协议扩展，以（1）优化传输DNS的连接建立和会话恢复；（2）支持所有当前指定的身份验证机制。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Several terms are used specifically in the context of this document:
本文件中专门使用了几个术语：
o DNS client: A DNS stub resolver or forwarder. In the case of a forwarder, the term "DNS client" is used to discuss the side that sends queries.
o DNS客户端：DNS存根解析程序或转发器。对于转发器，术语“DNS客户端”用于讨论发送查询的一方。
o DNS server: A DNS recursive resolver or forwarder. In the case of a forwarder, the term "DNS server" is used to discuss the side that responds to queries. Note that, as used in this document, this term does not apply to authoritative servers.
o DNS服务器：DNS递归解析程序或转发器。对于转发器，术语“DNS服务器”用于讨论响应查询的一方。请注意，本文档中使用的术语不适用于权威服务器。
o Privacy-enabling DNS server: A DNS server that implements DNS over TLS [RFC7858] and may optionally implement DNS over DTLS [RFC8094]. The server should also offer at least one of the credentials described in Section 8 and implement the (D)TLS profile described in Section 9.
o 启用隐私的DNS服务器：通过TLS[RFC7858]实现DNS的DNS服务器，可以选择通过DTL[RFC8094]实现DNS。服务器还应提供第8节中描述的至少一个凭据，并实现第9节中描述的（D）TLS配置文件。
o (D)TLS: Used for brevity; refers to both Transport Layer Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. Specific terms will be used for any text that applies to either protocol alone.
o （D） TLS：用于简洁；指传输层安全性[RFC5246]和数据报传输层安全性[RFC6347]。具体条款将用于单独适用于任一协议的任何文本。
o DNS over (D)TLS: Used for brevity; refers to both DNS over TLS [RFC7858] and DNS over DTLS [RFC8094]. Specific terms will be used for any text that applies to either protocol alone.
o （D）TLS上的DNS：用于简洁；指TLS上的DNS[RFC7858]和DTLS上的DNS[RFC8094]。具体条款将用于单独适用于任一协议的任何文本。
o Authentication domain name: A domain name that can be used to authenticate a privacy-enabling DNS server. Sources of authentication domain names are discussed in Section 7.
o 验证域名：可用于验证启用隐私的DNS服务器的域名。第7节讨论了验证域名的来源。
o SPKI pin sets: [RFC7858] describes the use of cryptographic digests to "pin" public key information in a manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. An SPKI pin set is a collection of these pins that constrains a DNS server.
o SPKI pin集：[RFC7858]描述了使用加密摘要以类似于HTTP公钥锁定（HPKP）[RFC7469]的方式“锁定”公钥信息。SPKI引脚集是约束DNS服务器的这些引脚的集合。
o Authentication information: Information a DNS client may use as the basis of an authentication mechanism. In this context, this information can be either
o 身份验证信息：DNS客户端可以用作身份验证机制基础的信息。在这种情况下，此信息可以是
* an SPKI pin set or
* SPKI引脚集或
* an authentication domain name
* 验证域名
o Reference identifier: A reference identifier as described in [RFC6125], constructed by the DNS client when performing TLS authentication of a DNS server.
o 参考标识符：[RFC6125]中所述的参考标识符，由DNS客户端在对DNS服务器执行TLS身份验证时构造。
o Credential: Information available for a DNS server that proves its identity for authentication purposes. Credentials discussed here include
o 凭据：可用于DNS服务器的信息，用于证明其身份以进行身份验证。这里讨论的凭证包括
* a PKIX certificate
* PKIX证书
* a DNSSEC-validated chain to a TLSA record
* DNSSEC验证的TLSA记录链
but may also include SPKI pin sets.
但也可能包括SPKI管脚套件。
This document is limited to describing
本文件仅限于描述
o Usage profiles based on general authentication mechanisms.
o 基于通用身份验证机制的使用配置文件。
o The details of domain-name-based authentication of DNS servers by DNS clients (as defined in Section 2).
o DNS客户端对DNS服务器进行基于域名的身份验证的详细信息（定义见第2节）。
o The (D)TLS profiles needed to support authentication in DNS over (D)TLS.
o 支持通过（D）TLS在DNS中进行身份验证所需的（D）TLS配置文件。
As such, the following topics are out of scope for this document:
因此，以下主题超出了本文件的范围：
o Authentication of authoritative servers by recursive resolvers.
o 通过递归解析程序对权威服务器进行身份验证。
o Authentication of DNS clients by DNS servers.
o DNS服务器对DNS客户端的身份验证。
o The details of how to perform authentication based on SPKI pin sets. This is defined in [RFC7858].
o 有关如何基于SPKI pin集执行身份验证的详细信息。这在[RFC7858]中有定义。
o Any server identifier other than domain names, including IP addresses, organizational names, country of origin, etc.
o 域名以外的任何服务器标识符，包括IP地址、组织名称、原产国等。
One way to mitigate eavesdropping on cleartext DNS transactions by passive attackers is to encrypt the query (and response). Such encryption typically provides integrity protection as a side effect; this means that on-path attackers cannot simply inject bogus DNS responses. To also mitigate active attackers pretending to be the server, the client must authenticate the (D)TLS connection to the server.
减轻被动攻击者对明文DNS事务的窃听的一种方法是加密查询（和响应）。这种加密通常作为副作用提供完整性保护；这意味着路径上的攻击者不能简单地注入虚假的DNS响应。为了减轻假装是服务器的主动攻击者的攻击，客户端必须验证与服务器的（D）TLS连接。
This document discusses usage profiles, which provide differing levels of attack mitigation to DNS clients, based on the requirements for authentication and encryption, regardless of the context (for example, which network the client is connected to). A usage profile is a concept distinct from a usage policy or usage model; a usage policy or usage model might dictate which profile should be used in a particular context (enterprise vs. coffee shop), with a particular set of DNS servers or with reference to other external factors. A description of the variety of usage policies is out of scope for this document but may be the subject of future work.
本文档讨论了使用配置文件，它根据身份验证和加密的要求，为DNS客户端提供不同级别的攻击缓解，而不考虑上下文（例如，客户端连接到哪个网络）。使用概要文件是一个不同于使用策略或使用模型的概念；使用策略或使用模型可能规定在特定上下文（企业与咖啡馆）、特定DNS服务器集或参考其他外部因素中应使用哪个配置文件。对各种使用策略的描述超出了本文档的范围，但可能是未来工作的主题。
The term "privacy-enabling DNS server" is used throughout this document. This is a DNS server that
本文档中使用了术语“启用隐私的DNS服务器”。这是一个DNS服务器
o MUST implement DNS over TLS [RFC7858].
o 必须通过TLS实现DNS[RFC7858]。
o MAY implement DNS over DTLS [RFC8094].
o 可以通过DTL实现DNS[RFC8094]。
o SHOULD offer at least one of the credentials described in Section 8.
o 应至少提供第8节中所述的一种凭证。
o Implements the (D)TLS profile described in Section 9.
o 实现第9节中描述的（D）TLS配置文件。
A DNS client has a choice of usage profiles available to increase the privacy of DNS transactions. This choice is briefly discussed in both [RFC7858] and [RFC8094]. These usage profiles are
DNS客户端可以选择使用配置文件来增加DNS事务的隐私。[RFC7858]和[RFC8094]都简要讨论了这一选择。这些使用配置文件是
o Strict Privacy profile: The DNS client requires both an encrypted and authenticated connection to a privacy-enabling DNS server. A hard failure occurs if this is not available. This requires the client to securely obtain authentication information it can use to authenticate the server. This profile mitigates both passive and active attacks, thereby providing the client with the best available privacy for DNS. This profile is discussed in detail in Section 6.6.
o 严格的隐私配置文件：DNS客户端需要到启用隐私的DNS服务器的加密和身份验证连接。如果不可用，则会发生硬故障。这要求客户端安全地获取可用于对服务器进行身份验证的身份验证信息。此配置文件可减轻被动和主动攻击，从而为客户端提供DNS的最佳可用隐私。第6.6节详细讨论了该剖面。
o Opportunistic Privacy profile: The DNS client uses Opportunistic Security as described in [RFC7435].
o 机会主义隐私配置文件：DNS客户端使用[RFC7435]中所述的机会主义安全性。
* "... the use of cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available."
* “…使用明文作为基线通信安全策略，协商加密和身份验证，并在可用时应用于通信。”
As described in [RFC7435], it might result in
如[RFC7435]所述，它可能导致
* an encrypted and authenticated connection
* 经过加密和验证的连接
* an encrypted connection
* 加密连接
* a cleartext connection
* 明文连接
depending on the fallback logic of the client, the available authentication information, and the capabilities of the DNS server. In all these cases, the DNS client is willing to continue with a connection to the DNS server and perform resolution of queries. The use of Opportunistic Privacy is intended to support incremental deployment of increased privacy with a view to widespread adoption of the Strict Privacy profile. It should be employed when the DNS client might otherwise settle for cleartext; it provides the maximum protection available, depending on the combination of factors described above. If all the configured DNS servers are DNS privacy servers, then it can provide protection against passive attacks and might protect against active ones.
取决于客户端的回退逻辑、可用的身份验证信息和DNS服务器的功能。在所有这些情况下，DNS客户端愿意继续连接到DNS服务器并执行查询解析。机会主义隐私的使用旨在支持增加隐私的增量部署，以期广泛采用严格的隐私配置文件。当DNS客户端可能以其他方式接受明文时，应该使用它；根据上述因素的组合，它提供了最大的可用保护。如果所有配置的DNS服务器都是DNS隐私服务器，那么它可以针对被动攻击提供保护，也可以针对主动攻击提供保护。
Both profiles can include an initial meta-query (performed using Opportunistic Privacy) to obtain the IP address for the privacy-enabling DNS server to which the DNS client will subsequently connect. The rationale for permitting this for the Strict Privacy profile is that requiring such meta-queries to also be performed using the Strict Privacy profile would introduce significant deployment obstacles. However, it should be noted that in this scenario an active attack on the meta-query is possible. Such an attack could result in a Strict Privacy profile client connecting to a server it cannot authenticate (and therefore not obtaining DNS service) or an Opportunistic Privacy client connecting to a server controlled by the attacker. DNSSEC validation can detect the attack on the meta-query, which may result in the client not obtaining DNS service (for both usage profiles), depending on its DNSSEC validation policy. See Section 7.2 for more discussion.
这两个配置文件都可以包括初始元查询（使用机会主义隐私执行），以获取DNS客户端随后将连接到的启用隐私的DNS服务器的IP地址。对于严格隐私配置文件，允许这样做的理由是，要求也使用严格隐私配置文件执行此类元查询将引入重大部署障碍。然而，应该注意的是，在这种情况下，对元查询的主动攻击是可能的。此类攻击可能导致严格的隐私配置文件客户端连接到无法进行身份验证的服务器（因此无法获得DNS服务）或机会主义隐私客户端连接到由攻击者控制的服务器。DNSSEC验证可以检测对元查询的攻击，这可能导致客户端无法获得DNS服务（对于两种使用配置文件），具体取决于其DNSSEC验证策略。更多讨论见第7.2节。
To compare the two usage profiles, Table 1 below shows a successful Strict Privacy profile alongside the three possible outcomes of an Opportunistic Privacy profile. In the best-case scenario for the Opportunistic Privacy profile (an authenticated and encrypted
为了比较这两种使用模式，下表1显示了成功的严格隐私模式以及机会主义隐私模式的三种可能结果。在机会主义隐私模式的最佳情况下（经过身份验证和加密的
connection), it is equivalent to the Strict Privacy profile. In the worst-case scenario, it is equivalent to cleartext. Clients using the Opportunistic Privacy profile SHOULD try for the best case but MAY fall back to the intermediate case and, eventually, the worst-case scenario, in order to obtain a response. One reason to fall back without trying every available privacy-enabling DNS server is if latency is more important than attack mitigation; see Appendix A. The Opportunistic Privacy profile therefore provides varying protection, depending on what kind of connection is actually used, including no attack mitigation at all.
连接），它相当于严格的隐私配置文件。在最坏的情况下，它相当于明文。使用机会主义隐私配置文件的客户应该尝试最佳情况，但可能会退回到中间情况，最终是最坏情况，以便获得响应。如果延迟比攻击缓解更重要，那么在不尝试每一个可用的隐私保护DNS服务器的情况下后退的一个原因是；参见附录A。因此，机会主义隐私保护模式提供了不同的保护，具体取决于实际使用的连接类型，完全不包括攻击缓解。
Note that there is no requirement in Opportunistic Security to notify the user regarding what type of connection is actually used; the "detection" described below is only possible if such connection information is available. However, if it is available and the user is informed that an unencrypted connection was used to connect to a server, then the user should assume (detect) that the connection is subject to both active and passive attacks, since the DNS queries are sent in cleartext. This might be particularly useful if a new connection to a certain server is unencrypted when all previous connections were encrypted. Similarly, if the user is informed that an encrypted but unauthenticated connection was used, then the user can detect that the connection may be subject to active attacks. In other words, for the cases where no protection is provided against an attacker (N), it is possible to detect that an attack might be happening (D). This is discussed in Section 6.5.
注意，机会主义安全不要求通知用户实际使用的连接类型；只有在此类连接信息可用的情况下，才能进行下面描述的“检测”。但是，如果它可用，并且通知用户使用未加密的连接连接到服务器，则用户应假设（检测）该连接同时受到主动和被动攻击，因为DNS查询以明文形式发送。如果与某个服务器的新连接在之前的所有连接都已加密的情况下未加密，则这可能特别有用。类似地，如果通知用户使用了加密但未经验证的连接，则用户可以检测到该连接可能受到主动攻击。换句话说，对于没有针对攻击者提供保护的情况（N），可以检测到可能正在发生的攻击（D）。第6.5节对此进行了讨论。
+---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+
| Strict | A, E | P | P |
| Opportunistic | A, E | P | P |
| Opportunistic | E | P | N, D |
| Opportunistic | | N, D | N, D |
+---------------+------------+------------------+-----------------+
+---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+
| Strict | A, E | P | P |
| Opportunistic | A, E | P | P |
| Opportunistic | E | P | N, D |
| Opportunistic | | N, D | N, D |
+---------------+------------+------------------+-----------------+
P == Protection; N == No protection; D == Detection is possible;
A == Authenticated connection; E == Encrypted connection
P == Protection; N == No protection; D == Detection is possible;
A == Authenticated connection; E == Encrypted connection
Table 1: Attack Protection by Usage Profile and Type of Attacker
表1：按使用情况和攻击者类型划分的攻击防护
The Strict Privacy profile provides the best attack mitigation and therefore SHOULD always be implemented in DNS clients that implement the Opportunistic Privacy profile.
严格隐私配置文件提供了最佳的攻击缓解，因此应始终在实施机会主义隐私配置文件的DNS客户端中实施。
A DNS client that implements DNS over (D)TLS SHOULD NOT be configured by default to use only cleartext.
默认情况下，不应将通过（D）TLS实现DNS的DNS客户端配置为仅使用明文。
The choice between the two profiles depends on a number of factors, including which is more important to the particular client:
两个配置文件之间的选择取决于许多因素，包括对特定客户更重要的因素：
o DNS service, at the cost of no attack mitigation (Opportunistic Privacy) or
o DNS服务，但不以攻击缓解（机会主义隐私）或
o Best available attack mitigation, at the potential cost of no DNS service (Strict Privacy).
o 以无DNS服务（严格保密）的潜在成本，提供最佳可用的攻击缓解。
Additionally, the two profiles require varying levels of configuration (or a trusted relationship with a provider) and DNS server capabilities; therefore, DNS clients will need to carefully select which profile to use based on their communication needs.
此外，这两个配置文件需要不同级别的配置（或与提供商的信任关系）和DNS服务器功能；因此，DNS客户端需要根据其通信需求仔细选择要使用的配置文件。
A DNS server that implements DNS over (D)TLS SHOULD provide at least one credential (Section 2) so that those DNS clients that wish to use the Strict Privacy profile are able to do so.
通过（D）TLS实现DNS的DNS服务器应提供至少一个凭据（第2节），以便希望使用严格隐私配置文件的DNS客户端能够这样做。
A DNS client SHOULD select a particular usage profile when resolving a query. A DNS client MUST NOT fall back from Strict Privacy to Opportunistic Privacy during the resolution of a given query, as this could invalidate the protection offered against attackers. It is anticipated that DNS clients will use a particular usage profile for all queries to all configured servers until an operational issue or policy update dictates a change in the profile used.
解析查询时，DNS客户端应选择特定的使用配置文件。在解析给定查询期间，DNS客户端不得从严格隐私退回到机会主义隐私，因为这可能使针对攻击者提供的保护失效。预期DNS客户端将对所有配置的服务器的所有查询使用特定的使用配置文件，直到操作问题或策略更新指示更改所使用的配置文件。
This section describes authentication mechanisms and how they can be used in either Strict or Opportunistic Privacy for DNS over (D)TLS.
本节描述了身份验证机制，以及如何在DNS over（D）TLS的严格或机会主义隐私中使用这些机制。
Many (D)TLS clients use PKIX authentication [RFC6125] based on an authentication domain name for the server they are contacting. These clients typically first look up the server's network address in the DNS before making this connection. Such a DNS client therefore has a bootstrap problem, as it will typically only know the IP address of its DNS server.
许多（D）TLS客户机基于其联系的服务器的身份验证域名使用PKIX身份验证[RFC6125]。这些客户端通常首先在DNS中查找服务器的网络地址，然后再进行此连接。因此，这样的DNS客户端存在引导问题，因为它通常只知道其DNS服务器的IP地址。
In this case, before connecting to a DNS server, a DNS client needs to learn the authentication domain name it should associate with the IP address of a DNS server for authentication purposes. Sources of authentication domain names are discussed in Section 7.
在这种情况下，在连接到DNS服务器之前，DNS客户端需要了解它应该与DNS服务器的IP地址关联的身份验证域名，以便进行身份验证。第7节讨论了验证域名的来源。
One advantage of this domain-name-based approach is that it encourages the association of stable, human-recognizable identifiers with secure DNS service providers.
这种基于域名的方法的一个优点是，它鼓励将稳定的、人类可识别的标识符与安全的DNS服务提供商相关联。
Verification of SPKI pin sets is discussed in [RFC7858].
[RFC7858]中讨论了SPKI引脚集的验证。
In terms of domain-name-based verification, once an authentication domain name is known for a DNS server, a choice of authentication mechanisms can be used for credential verification. Section 8 discusses these mechanisms -- namely, PKIX certificate-based authentication and DNS-Based Authentication of Named Entities (DANE) -- in detail.
在基于域名的验证方面，一旦DNS服务器的验证域名已知，就可以选择用于凭证验证的验证机制。第8节详细讨论了这些机制，即基于PKIX证书的身份验证和基于DNS的命名实体身份验证（DANE）。
Note that the use of DANE adds requirements on the ability of the client to get validated DNSSEC results. This is discussed in more detail in Section 8.2.
请注意，DANE的使用增加了对客户获得经验证的DNSSEC结果的能力的要求。第8.2节对此进行了更详细的讨论。
This section provides an overview of the various authentication mechanisms. Table 2 below indicates how the DNS client obtains information to use for authentication for each option: either statically via direct configuration or dynamically. Of course, the Opportunistic Privacy profile does not require authentication, and so a client using that profile may choose to connect to a privacy-enabling DNS server on the basis of just an IP address.
本节概述了各种身份验证机制。下面的表2说明了DNS客户端如何获取用于每个选项的身份验证的信息：通过直接配置静态获取或动态获取。当然，机会主义隐私配置文件不需要身份验证，因此使用该配置文件的客户机可以仅基于IP地址选择连接到支持隐私的DNS服务器。
+---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description |
| | Config | Obtained | |
+---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pin set(s) and IP |
| | | | address obtained out of band |
| | | | [RFC7858] |
| | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see Section 7.1) |
| | | | |
| 3 | ADN | IP | ADN only: Opportunistic Privacy |
| | | | meta-queries to a NP DNS server |
| | | | for A/AAAA (see Section 7.2) |
| | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | Section 7.3.1) |
| | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic Privacy meta-queries |
| | | | to NP DNS server (see Section |
| | | | 8.2.1) |
| | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see |
| | | | Section 8.2.2) |
+---+------------+-------------+------------------------------------+
+---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description |
| | Config | Obtained | |
+---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pin set(s) and IP |
| | | | address obtained out of band |
| | | | [RFC7858] |
| | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see Section 7.1) |
| | | | |
| 3 | ADN | IP | ADN only: Opportunistic Privacy |
| | | | meta-queries to a NP DNS server |
| | | | for A/AAAA (see Section 7.2) |
| | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | Section 7.3.1) |
| | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic Privacy meta-queries |
| | | | to NP DNS server (see Section |
| | | | 8.2.1) |
| | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see |
| | | | Section 8.2.2) |
+---+------------+-------------+------------------------------------+
SPKI == SPKI pin set(s); IP == IP Address;
ADN == Authentication Domain Name; NP == Network-Provided;
PE == Privacy-Enabling; [ ] == Data may be obtained either
statically or dynamically
SPKI == SPKI pin set(s); IP == IP Address;
ADN == Authentication Domain Name; NP == Network-Provided;
PE == Privacy-Enabling; [ ] == Data may be obtained either
statically or dynamically
Table 2: Overview of Authentication Mechanisms
表2：认证机制概述
The following summary attempts to present some key attributes of each of the mechanisms (using the "Short name" from Table 2), indicating attractive attributes with a "+" and undesirable attributes with a "-".
下面的摘要试图展示每个机制的一些关键属性（使用表2中的“短名称”），用“+”表示有吸引力的属性，用“-”表示不需要的属性。
1. SPKI
1. 斯普基
+ Minimal leakage (note that the ADN is always leaked in the Server Name Indication (SNI) field in the ClientHello in TLS when communicating with a privacy-enabling DNS server)
+ 最小泄漏（请注意，当与启用隐私的DNS服务器通信时，ADN总是在TLS中ClientHello的服务器名称指示（SNI）字段中泄漏）
- Overhead of ongoing key management required
- 需要持续密钥管理的开销
2. ADN
2. ADN
+ Minimal leakage
+ 最小泄漏
+ One-off direct configuration only
+ 仅限一次性直接配置
3. ADN only
3. 仅限ADN
+ Minimal one-off direct configuration; only a human-recognizable domain name needed
+ 最小一次性直接配置；只需要一个人类可识别的域名
- A/AAAA meta-queries leaked to network-provided DNS server that may be subject to active attack (attack can be mitigated by DNSSEC validation)
- A/AAAA元查询泄漏到网络提供的DNS服务器，可能受到主动攻击（可通过DNSSEC验证减轻攻击）
4. DHCP
4. DHCP
+ No static config
+ 没有静态配置
- Requires a non-standard or future DHCP option in order to provide the ADN
- 需要非标准或将来的DHCP选项才能提供ADN
- Requires secure and trustworthy connection to DHCP server if used with a Strict Privacy profile
- 如果与严格的隐私配置文件一起使用，则需要安全可靠地连接到DHCP服务器
5. DANE
5. 丹麦人
The ADN and/or IP may be obtained statically or dynamically, and the relevant attributes of that method apply.
ADN和/或IP可以静态或动态获得，并且该方法的相关属性适用。
+ DANE options (e.g., matching on entire certificate)
+ DANE选项（例如，整个证书上的匹配）
- Requires a DNSSEC-validating stub implementation (the deployment of which is limited at the time of this writing)
- 需要DNSSEC验证存根实现（在撰写本文时，其部署受到限制）
- DNSSEC chain meta-queries leaked to network-provided DNS server that may be subject to active attack
- DNSSEC链元查询泄漏到网络提供的DNS服务器，可能受到主动攻击
6. TLS extension
6. TLS扩展
The ADN and/or IP may be obtained statically or dynamically, and the relevant attributes of that method apply.
ADN和/或IP可以静态或动态获得，并且该方法的相关属性适用。
+ Reduced latency compared with DANE
+ 与DANE相比，延迟减少
+ No network-provided DNS server required if ADN and IP statically configured
+ 如果ADN和IP静态配置，则不需要网络提供的DNS服务器
+ DANE options (e.g., matching on entire certificate)
+ DANE选项（例如，整个证书上的匹配）
- Requires a DNSSEC-validating stub implementation
- 需要DNSSEC验证存根实现
This document does not make explicit recommendations about how an authentication mechanism based on SPKI pin sets should be combined with a domain-based mechanism from an operator perspective. However, it can be envisaged that a DNS server operator may wish to make both an SPKI pin set and an authentication domain name available to allow clients to choose which mechanism to use. Therefore, the following text provides guidance on how clients ought to behave if they choose to configure both, as is possible in HPKP [RFC7469].
从运营商的角度来看，本文档没有明确建议如何将基于SPKI pin集的身份验证机制与基于域的机制相结合。然而，可以设想，DNS服务器运营商可能希望使SPKI pin集和认证域名都可用，以允许客户端选择要使用的机制。因此，以下文本提供了有关客户机在选择配置两者时应如何操作的指导，这在HPKP[RFC7469]中是可能的。
A DNS client that is configured with both an authentication domain name and an SPKI pin set for a DNS server SHOULD match on both a valid credential for the authentication domain name and a valid SPKI pin set (if both are available) when connecting to that DNS server. In this case, the client SHOULD treat individual SPKI pins as specified in Section 2.6 of [RFC7469] with regard to user-defined trust anchors. The overall authentication result SHOULD only be considered successful if both authentication mechanisms are successful.
在连接到DNS服务器时，配置了DNS服务器的身份验证域名和SPKI pin集的DNS客户端应在身份验证域名的有效凭据和有效SPKI pin集（如果两者都可用）上匹配。在这种情况下，客户应按照[RFC7469]第2.6节中关于用户定义信任锚的规定处理单个SPKI引脚。只有当两种身份验证机制都成功时，才应认为整个身份验证结果成功。
An Opportunistic Privacy Profile (based on Opportunistic Security [RFC7435]) that MAY be used for DNS over (D)TLS is described in [RFC7858] and is further specified in this document.
[RFC7858]中描述了可用于通过（D）TLS的DNS的机会主义隐私配置文件（基于机会主义安全[RFC7435]），并在本文档中进一步规定。
DNS clients that issue queries under an Opportunistic Privacy profile and that know authentication information for a given privacy-enabling DNS server SHOULD try to authenticate the server using the mechanisms described here. This is useful for detecting (but not preventing) active attacks, since the fact that authentication information is available indicates that the server in question is a privacy-enabling DNS server to which it should be possible to establish an authenticated and encrypted connection. In this case, whilst a client cannot know the reason for an authentication failure, from a security standpoint the client should consider an active attack in progress and proceed under that assumption. For example, a client that implements a nameserver selection algorithm that preferentially uses nameservers that successfully authenticated (see Section 5) might not continue to use the failing server if there were alternative servers available.
根据机会主义隐私配置文件发出查询并知道给定隐私启用DNS服务器的身份验证信息的DNS客户端应尝试使用此处描述的机制对服务器进行身份验证。这对于检测（但不是防止）主动攻击很有用，因为身份验证信息可用这一事实表明所讨论的服务器是一个支持隐私的DNS服务器，应该可以与之建立经过身份验证和加密的连接。在这种情况下，当客户端不能知道认证失败的原因时，从安全的角度来看，客户端应该考虑正在进行的主动攻击并在该假设下进行。例如，如果客户机实现了名称服务器选择算法，该算法优先使用已成功验证的名称服务器（请参见第5节），则如果存在可用的替代服务器，则该客户机可能不会继续使用故障服务器。
Attempting authentication is also useful for debugging or diagnostic purposes if there are means to report the result. This information can provide a basis for a DNS client to switch to (preferred) Strict Privacy where it is viable, e.g., where all the configured servers support DNS over (D)TLS and successfully authenticate.
如果有方法报告结果，尝试身份验证对于调试或诊断目的也很有用。此信息可为DNS客户端切换到（首选）严格隐私提供基础，前提是它是可行的，例如，所有配置的服务器都支持通过（D）TLS的DNS并成功进行身份验证。
To authenticate a privacy-enabling DNS server, a DNS client needs to know authentication information for each server it is willing to contact. This is necessary to protect against active attacks that attempt to redirect clients to rogue DNS servers.
要对启用隐私的DNS服务器进行身份验证，DNS客户端需要知道它愿意联系的每台服务器的身份验证信息。这对于防止试图将客户端重定向到恶意DNS服务器的主动攻击是必要的。
A DNS client requiring Strict Privacy MUST use either (1) one of the sources listed in Section 7, to obtain an authentication domain name for the server it contacts or (2) an SPKI pin set as described in [RFC7858].
需要严格保密的DNS客户端必须使用（1）第7节中列出的来源之一，以获取其联系的服务器的身份验证域名，或（2）如[RFC7858]中所述的SPKI pin设置。
A DNS client requiring Strict Privacy MUST only attempt to connect to DNS servers for which at least one piece of authentication information is known. The client MUST use the available verification mechanisms described in Section 8 to authenticate the server and MUST abort connections to a server when no verification mechanism succeeds.
要求严格保密的DNS客户端只能尝试连接到至少已知一条身份验证信息的DNS服务器。客户端必须使用第8节中描述的可用验证机制对服务器进行身份验证，并且在没有验证机制成功时必须中止与服务器的连接。
With Strict Privacy, the DNS client MUST NOT commence sending DNS queries until at least one of the privacy-enabling DNS servers becomes available.
在严格保密的情况下，DNS客户端必须在至少一个支持保密的DNS服务器可用之前才能开始发送DNS查询。
A privacy-enabling DNS server may be temporarily unavailable when configuring a network. For example, for clients on networks that require registration through web-based login (a.k.a. "captive portals"), such registration may rely on DNS interception and spoofing. Techniques such as those used by dnssec-trigger [dnssec-trigger] MAY be used during network configuration, with the intent to transition to the designated privacy-enabling DNS servers after captive-portal registration. If using a Strict Privacy profile, the system MUST alert by some means that the DNS is not private during such a bootstrap operation.
配置网络时，启用隐私的DNS服务器可能暂时不可用。例如，对于网络上需要通过基于web的登录（也称为“捕获门户”）进行注册的客户端，此类注册可能依赖DNS拦截和欺骗。诸如dnssec触发器[dnssec触发器]所使用的技术可在网络配置期间使用，目的是在捕获门户注册后过渡到指定的隐私启用DNS服务器。如果使用严格的隐私配置文件，系统必须通过某种方式发出警报，表明DNS在此类引导操作期间不是私有的。
Section 9 describes the (D)TLS profile for DNS over (D)TLS. Additional considerations relating to general implementation guidelines are discussed in both Section 11 and Appendix A.
第9节描述了通过（D）TLS的DNS的（D）TLS配置文件。第11节和附录A中讨论了与一般实施指南相关的其他注意事项。
DNS clients may be directly and securely provisioned with the authentication domain name of each privacy-enabling DNS server -- for example, using a client-specific configuration file or API.
DNS客户端可以直接安全地配置每个支持隐私的DNS服务器的身份验证域名——例如，使用特定于客户端的配置文件或API。
In this case, direct configuration for a DNS client would consist of both an IP address and an authentication domain name for each DNS server that were obtained via an out-of-band mechanism.
在这种情况下，DNS客户端的直接配置将包括通过带外机制获得的每个DNS服务器的IP地址和身份验证域名。
A DNS client may be configured directly and securely with only the authentication domain name of each of its privacy-enabling DNS servers -- for example, using a client-specific configuration file or API.
DNS客户端可以直接、安全地配置，只使用其每个支持隐私的DNS服务器的身份验证域名，例如，使用特定于客户端的配置文件或API。
A DNS client might learn of a default recursive DNS resolver from an untrusted source (such as DHCP's DNS Recursive Name Server option [RFC3646]). It can then use meta-queries performed using an Opportunistic Privacy profile to an untrusted recursive DNS resolver to establish the IP address of the intended privacy-enabling DNS resolver by doing a lookup of A/AAAA records. A DNSSEC-validating client SHOULD apply the same validation policy to the A/AAAA meta-queries as it does to other queries. A client that does not validate DNSSEC SHOULD apply the same policy (if any) to the A/AAAA meta-queries as it does to other queries. Private DNS resolution can now be done by the DNS client against the pre-configured privacy-enabling DNS resolver, using the IP address obtained from the untrusted DNS resolver.
DNS客户端可能从不受信任的源（例如DHCP的DNS递归名称服务器选项[RFC3646]）了解到默认递归DNS解析程序。然后，它可以使用使用机会主义隐私配置文件对不受信任的递归DNS解析程序执行的元查询，通过查找a/AAAA记录来建立预期的启用隐私的DNS解析程序的IP地址。DNSSEC验证客户端应将相同的验证策略应用于A/AAAA元查询，就像它应用于其他查询一样。未验证DNSSEC的客户端应将相同的策略（如果有）应用于A/AAAA元查询，就像它应用于其他查询一样。现在，DNS客户端可以使用从不受信任的DNS解析程序获得的IP地址，针对预配置的启用隐私的DNS解析程序执行私有DNS解析。
A DNS client so configured that successfully connects to a privacy-enabling DNS server MAY choose to locally cache the server host IP addresses in order to not have to repeat the meta-query.
配置为成功连接到启用隐私的DNS服务器的DNS客户端可以选择本地缓存服务器主机IP地址，以便不必重复元查询。
This section discusses the general case of a DNS client discovering both the authentication domain name and IP address dynamically. At the time of this writing, this is not possible by any standard means. However, since, for example, a future DHCP extension could (in principle) provide this mechanism, the required security properties of such mechanisms are outlined here.
本节讨论DNS客户端动态发现身份验证域名和IP地址的一般情况。在撰写本文时，任何标准方法都无法做到这一点。但是，由于（原则上）将来的DHCP扩展可以提供这种机制，因此这里概述了这种机制所需的安全属性。
When using a Strict Privacy profile, the dynamic discovery technique used as a source of authentication domain names MUST be considered secure and trustworthy. This requirement does not apply when using an Opportunistic Privacy profile, given the security expectation of that profile.
当使用严格的隐私配置文件时，用作验证域名来源的动态发现技术必须被视为安全可靠的。在使用机会主义隐私配置文件时，鉴于该配置文件的安全预期，此要求不适用。
In the typical case today, a DHCP server [RFC2131] [RFC3315] provides a list of IP addresses for DNS resolvers (see Section 3.8 of [RFC2132]) but does not provide an authentication domain name for the DNS resolver, thus preventing the use of most of the authentication methods described here (all of those that are based on a mechanism with ADN; see Table 2).
在今天的典型案例中，DHCP服务器[RFC2131][RFC3315]为DNS解析程序提供IP地址列表（参见[RFC2132]第3.8节），但不为DNS解析程序提供身份验证域名，因此阻止使用此处描述的大多数身份验证方法（所有这些都基于ADN机制；见表2）。
This document does not specify or request any DHCP extension to provide authentication domain names. However, if one is developed in future work, the issues outlined in Section 8 of [RFC7227] should be taken into account, as should the security considerations discussed in Section 23 of [RFC3315].
本文档未指定或请求任何DHCP扩展来提供验证域名。但是，如果在未来的工作中开发了一个，则应考虑[RFC7227]第8节中概述的问题，以及[RFC3315]第23节中讨论的安全考虑因素。
This document does not attempt to describe secured and trusted relationships to DHCP servers, as this is purely a DHCP issue (and still open, at the time of this writing). Whilst some implementation work is in progress to secure IPv6 connections for DHCP, IPv4 connections have received little or no implementation attention in this area.
本文档不试图描述与DHCP服务器之间的安全和可信关系，因为这纯粹是一个DHCP问题（在撰写本文时仍然是开放的）。虽然为保护DHCP的IPv6连接的安全正在进行一些实施工作，但IPv4连接在这方面很少或根本没有受到实施方面的关注。
When a DNS client configured with an authentication domain name connects to its configured DNS server over (D)TLS, the server may present it with a PKIX certificate. In order to ensure proper authentication, DNS clients MUST verify the entire certification path per [RFC5280]. The DNS client additionally uses validation techniques as described in [RFC6125] to compare the domain name to the certificate provided.
当配置了身份验证域名的DNS客户端通过（D）TLS连接到其配置的DNS服务器时，服务器可能会向其提供PKIX证书。为了确保正确的身份验证，DNS客户端必须按照[RFC5280]验证整个认证路径。DNS客户端还使用[RFC6125]中所述的验证技术将域名与提供的证书进行比较。
A DNS client constructs one reference identifier for the server based on the authentication domain name: a DNS-ID, which is simply the authentication domain name itself.
DNS客户端基于身份验证域名为服务器构造一个参考标识符：DNS-ID，它只是身份验证域名本身。
If the reference identifier is found (as described in Section 6 of [RFC6125]) in the PKIX certificate's subjectAltName extension, the DNS client should accept the certificate for the server.
如果在PKIX证书的subjectAltName扩展中找到引用标识符（如[RFC6125]第6节所述），DNS客户端应接受服务器的证书。
A compliant DNS client MUST only inspect the certificate's subjectAltName extension for the reference identifier. In particular, it MUST NOT inspect the Subject field itself.
符合要求的DNS客户端必须仅检查证书的subjectAltName扩展以查找引用标识符。特别是，它不能检查主题字段本身。
DANE [RFC6698] provides various mechanisms using DNSSEC to anchor trust for certificates and raw public keys. However, this requires the DNS client to have an authentication domain name (which must be obtained via a trusted source) for the DNS privacy server.
DANE[RFC6698]提供了各种机制，使用DNSSEC为证书和原始公钥锚定信任。但是，这要求DNS客户端具有DNS隐私服务器的身份验证域名（必须通过可信来源获得）。
This section assumes a solid understanding of both DANE [RFC6698] and DANE operations [RFC7671]. A few pertinent issues covered in these documents are outlined here as useful pointers, but familiarity with both of these documents in their entirety is expected.
本节假设对丹麦[RFC6698]和丹麦运营[RFC7671]都有扎实的了解。本文概述了这些文档中涉及的一些相关问题，作为有用的指针，但希望您对这两个文档的全部内容都熟悉。
Note that [RFC6698] says
注意，[RFC6698]表示
Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator.
自行验证DNSSEC签名的客户端必须使用标准DNSSEC验证程序。依赖其他实体执行DNSSEC签名验证的客户机必须在其自身和验证器之间使用安全机制。
Note that [RFC7671] covers the following topics:
请注意，[RFC7671]涵盖以下主题：
o Sections 4.1 ("Opportunistic Security and PKIX Usages") and 14 ("Security Considerations") of [RFC7671], which both discuss the use of schemes based on trust anchors and end entities (PKIX-TA(0) and PKIX-EE(1), respectively) for Opportunistic Security.
o [RFC7671]第4.1节（“机会主义安全和PKIX使用”）和第14节（“安全注意事项”）均讨论了基于信任锚和终端实体（分别为PKIX-TA（0）和PKIX-EE（1））的方案在机会主义安全中的使用。
o Section 5 ("Certificate-Usage-Specific DANE Updates and Guidelines") of [RFC7671] -- specifically, Section 5.1 of [RFC7671], which outlines the combination of certificate usage DANE-EE(3) and selector SPKI(1) with raw public keys [RFC7250]. Section 5.1 of [RFC7671] also discusses the security implications of this mode; for example, it discusses key lifetimes and specifies that validity period enforcement is based solely on the TLSA RRset properties for this case.
o [RFC7671]的第5节（“特定于证书使用的DANE更新和指南”）——具体而言，是[RFC7671]的第5.1节，概述了证书使用DANE-EE（3）和选择器SPKI（1）与原始公钥[RFC7250]的组合。[RFC7671]第5.1节还讨论了该模式的安全含义；例如，它讨论了密钥生存期，并指定有效期强制仅基于此情况下的TLSA RRset属性。
o Section 13 ("Operational Considerations") of [RFC7671], which discusses TLSA TTLs and signature validity periods.
o [RFC7671]第13节（“操作注意事项”），讨论TLSA TTL和签名有效期。
The specific DANE record for a DNS privacy server would take the form
DNS隐私服务器的特定DANE记录将采用以下形式
_853._tcp.[authentication-domain-name] for TLS
_853._TLS的tcp。[验证域名]
_853._udp.[authentication-domain-name] for DTLS
_853._udp。[验证域名]用于DTL
The DNS client MAY choose to perform the DNS meta-queries to retrieve the required DANE records itself. The DNS meta-queries for such DANE records MAY use the Opportunistic Privacy profile or be in the clear to avoid trust recursion. The records MUST be validated using DNSSEC as described in [RFC6698].
DNS客户端可以选择执行DNS元查询以检索所需的DANE记录本身。针对此类DANE记录的DNS元查询可能会使用机会主义隐私配置文件，也可能是公开的，以避免信任递归。必须使用[RFC6698]中所述的DNSSEC对记录进行验证。
The DNS client MAY offer the TLS extension described in [TLS-DNSSEC-Chain-Ext]. If the DNS server supports this extension, it can provide the full chain to the client in the handshake.
DNS客户端可以提供[TLS DNSSEC Chain Ext]中所述的TLS扩展。如果DNS服务器支持此扩展，它可以在握手中向客户端提供完整的链。
If the DNS client offers the TLS DNSSEC chain extension, it MUST be capable of validating the full DNSSEC authentication chain down to the leaf. If the supplied DNSSEC chain does not validate, the client MUST ignore the DNSSEC chain and validate only via other supplied credentials.
如果DNS客户端提供TLS DNSSEC链扩展，则它必须能够验证整个DNSSEC认证链直至叶。如果提供的DNSSEC链未验证，则客户端必须忽略DNSSEC链并仅通过其他提供的凭据进行验证。
This section defines the (D)TLS protocol profile of DNS over (D)TLS.
本节定义了通过（D）TLS的DNS的（D）TLS协议配置文件。
Clients and servers MUST adhere to the (D)TLS implementation recommendations and security considerations of [RFC7525], except with respect to the (D)TLS version.
客户机和服务器必须遵守[RFC7525]的（D）TLS实施建议和安全注意事项，但（D）TLS版本除外。
Since encryption of DNS using (D)TLS is a greenfield deployment, DNS clients and servers MUST implement only (D)TLS 1.2 or later. For example, implementing (D)TLS 1.3 [TLS-1.3] [DTLS-1.3] is also an option.
由于使用（D）TLS对DNS进行加密是一种全新的部署，DNS客户端和服务器必须仅实现（D）TLS 1.2或更高版本。例如，实施（D）TLS 1.3[TLS-1.3][DTLS-1.3]也是一种选择。
Implementations MUST NOT offer or provide TLS compression, since compression can leak significant amounts of information, especially to a network observer capable of forcing the user to do an arbitrary DNS lookup in the style of the Compression Ratio Info-leak Made Easy (CRIME) attacks [CRIME].
实现不得提供或提供TLS压缩，因为压缩可能会泄漏大量信息，尤其是对能够迫使用户以压缩比的方式进行任意DNS查找的网络观察者而言。信息泄漏容易（犯罪）攻击[犯罪]。
Implementations compliant with this profile MUST implement the following items:
符合此配置文件的实施必须实施以下各项：
o TLS session resumption without server-side state [RFC5077], which eliminates the need for the server to retain cryptographic state for longer than necessary. (This statement updates [RFC7858].)
o 没有服务器端状态的TLS会话恢复[RFC5077]，这消除了服务器保留加密状态超过必要时间的需要。（此声明更新了[RFC7858]。）
o Raw public keys [RFC7250], which reduce the size of the ServerHello and can be used by servers that cannot obtain certificates (e.g., DNS servers on private networks). A client MUST only indicate support for raw public keys if it has an SPKI pin set pre-configured (for interoperability reasons).
o 原始公钥[RFC7250]，用于减小ServerHello的大小，并可由无法获取证书的服务器（例如，专用网络上的DNS服务器）使用。如果客户机预先配置了SPKI pin集（出于互操作性原因），则必须仅指示支持原始公钥。
Implementations compliant with this profile SHOULD implement the following items:
符合此配置文件的实施应实施以下项目：
o TLS False Start [RFC7918], which reduces round trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query.
o TLS错误启动[RFC7918]，它通过允许TLS第二次消息传递（ChangeCipherSpec）也包含（加密的）DNS查询来减少往返。
o The Cached Information Extension [RFC7924], which avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake.
o 缓存的信息扩展[RFC7924]，如果客户端缓存了来自先前TLS握手的信息，则可以避免传输服务器的证书和证书链。
Guidance specific to TLS is provided in [RFC7858], and guidance specific to DTLS is provided in [RFC8094].
[RFC7858]中提供了特定于TLS的指南，而[RFC8094]中提供了特定于DTL的指南。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
Security considerations discussed in [RFC7525], [RFC8094], and [RFC7858] apply to this document.
[RFC7525]、[RFC8094]和[RFC7858]中讨论的安全注意事项适用于本文档。
DNS clients SHOULD implement (1) support for the mechanisms described in Section 8.2 and (2) offering a configuration option that limits authentication to using only those mechanisms (i.e., with no fallback to pure PKIX-based authentication) such that authenticating solely via the PKIX infrastructure can be avoided.
DNS客户端应实现（1）对第8.2节中描述的机制的支持，以及（2）提供一个配置选项，该选项将身份验证限制为仅使用这些机制（即，没有回退到纯基于PKIX的身份验证），从而避免仅通过PKIX基础设施进行身份验证。
This section makes suggestions for measures that can reduce the ability of attackers to infer information pertaining to encrypted client queries by other means (e.g., via an analysis of encrypted traffic size or via monitoring of the unencrypted traffic from a DNS recursive resolver to an authoritative server).
本节建议采取措施，降低攻击者通过其他方式（例如，通过分析加密流量大小或通过监测从DNS递归解析程序到权威服务器的未加密流量）推断加密客户端查询相关信息的能力。
DNS-over-(D)TLS clients and servers SHOULD implement the following relevant DNS extensions:
通过-（D）TLS的DNS客户端和服务器应实现以下相关DNS扩展：
o Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which allows encrypted queries and responses to hide their size, making analysis of encrypted traffic harder.
o DNS（EDNS（0））填充[RFC7830]的扩展机制，它允许加密查询和响应隐藏其大小，从而使加密流量的分析更加困难。
Guidance on padding policies for EDNS(0) is provided in [EDNS0-Pad-Policies].
[EDNS0 Pad策略]中提供了有关EDN（0）填充策略的指导。
DNS-over-(D)TLS clients SHOULD implement the following relevant DNS extensions:
通过-（D）TLS的DNS客户端应实现以下相关DNS扩展：
o Privacy election per [RFC7871] ("Client Subnet in DNS Queries"). If a DNS client does not include an edns-client-subnet EDNS0 option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may potentially leak client address information to the upstream authoritative DNS servers. A DNS client ought to be able to inform the DNS resolver that it does not want any address information leaked, and the DNS resolver should honor that request.
o 根据[RFC7871]（“DNS查询中的客户端子网”）进行隐私选择。如果DNS客户端在查询中不包括源前缀长度设置为0的edns客户端子网EDNS0选项，则DNS服务器可能会将客户端地址信息泄漏到上游权威DNS服务器。DNS客户端应该能够通知DNS解析程序它不希望任何地址信息泄漏，并且DNS解析程序应该遵守该请求。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<https://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7250]Wouters，P.，Ed.，Tschofenig，H.，Ed.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年6月<https://www.rfc-editor.org/info/rfc7250>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<https://www.rfc-editor.org/info/rfc7671>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>.
[RFC7830]Mayrhofer，A.，“EDNS（0）填充选项”，RFC 7830，DOI 10.17487/RFC7830，2016年5月<https://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS传输层安全规范（TLS）”，RFC 7858，DOI 10.17487/RFC7858，2016年5月<https://www.rfc-editor.org/info/rfc7858>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/info/rfc7918>.
[RFC7918]Langley，A.，Modadugu，N.，和B.Moeller，“传输层安全（TLS）错误启动”，RFC 7918，DOI 10.17487/RFC7918，2016年8月<https://www.rfc-editor.org/info/rfc7918>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.
[RFC7924]Santesson，S.和H.Tschofenig，“传输层安全（TLS）缓存信息扩展”，RFC 7924DOI 10.17487/RFC79242016年7月<https://www.rfc-editor.org/info/rfc7924>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8094]Reddy，T.，Wing，D.，和P.Patil，“数据报传输层安全（DTLS）上的DNS”，RFC 8094，DOI 10.17487/RFC8094，2017年2月<https://www.rfc-editor.org/info/rfc8094>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty Security Conference, 2012, <https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf>.
[犯罪]Rizzo，J.和T.Duong，“犯罪袭击”，Ekoparty安全会议，2012年<https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf>.
[dnssec-trigger] NLnetLabs, "Dnssec-Trigger", December 2017, <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[dnssec触发器]NLnetLabs，“dnssec触发器”，2017年12月<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-dtls13-26, March 2018.
[DTLS-1.3]Rescorla，E.，Tschofenig，H.和N.Modadugu，“数据报传输层安全（DTLS）协议版本1.3”，正在进行的工作，草案-ietf-tls-dtls13-26，2018年3月。
[EDNS0-Pad-Policies] Mayrhofer, A., "Padding Policy for EDNS(0)", Work in Progress, draft-ietf-dprive-padding-policy-04, February 2018.
[EDNS0 Pad政策]Mayrhofer，A.，“EDN（0）的填充政策”，正在进行的工作，草案-ietf-dprive-Padding-Policy-042018年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<https://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<https://www.rfc-editor.org/info/rfc2132>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<https://www.rfc-editor.org/info/rfc3315>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646]Droms，R.，Ed.“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，DOI 10.17487/RFC3646，2003年12月<https://www.rfc-editor.org/info/rfc3646>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<https://www.rfc-editor.org/info/rfc7227>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<https://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<https://www.rfc-editor.org/info/rfc7469>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7626]Bortzmeyer，S.，“DNS隐私注意事项”，RFC 7626，DOI 10.17487/RFC7626，2015年8月<https://www.rfc-editor.org/info/rfc7626>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/info/rfc7871>.
[RFC7871]Contavalli，C.，van der Gaast，W.，Lawrence，D.，和W.Kumari，“DNS查询中的客户端子网”，RFC 7871，DOI 10.17487/RFC7871，2016年5月<https://www.rfc-editor.org/info/rfc7871>.
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-27, March 2018.
[TLS-1.3]Rescorla，E.“传输层安全（TLS）协议版本1.3”，正在进行的工作，草案-ietf-TLS-tls13-27，2018年3月。
[TLS-DNSSEC-Chain-Ext] Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE Record and DNSSEC Authentication Chain Extension for TLS", Work in Progress, draft-ietf-tls-dnssec-chain-extension-06, January 2018.
[TLS DNSSEC链分机]Shore，M.，Barnes，R.，Huque，S.，和W.Toorop，“用于TLS的丹麦记录和DNSSEC认证链扩展”，正在进行的工作，草案-ietf-TLS-DNSSEC-Chain-Extension-062018年1月。
This section presents a non-normative discussion of how DNS clients might probe for, and cache capabilities of, privacy-enabling DNS servers.
本节介绍DNS客户端如何探测和缓存支持隐私的DNS服务器的功能的非规范性讨论。
Deployment of both DNS over TLS and DNS over DTLS will be gradual. Not all servers will support one or both of these protocols, and the well-known port might be blocked by some middleboxes. Clients will be expected to keep track of servers that support DNS over TLS and/or DNS over DTLS, as well as those that have been previously authenticated.
通过TLS部署DNS和通过DTL部署DNS将是渐进的。并非所有服务器都支持这两种协议中的一种或两种，并且众所周知的端口可能会被某些中间盒阻塞。客户机将需要跟踪支持通过TLS的DNS和/或通过DTL的DNS的服务器，以及之前已通过身份验证的服务器。
If no server capability information is available, then (unless otherwise specified by the configuration of the DNS client) DNS clients that implement both TLS and DTLS should try to authenticate using both protocols before failing or falling back to an unauthenticated or cleartext connection. DNS clients using an Opportunistic Privacy profile should try all available servers (possibly in parallel) in order to obtain an authenticated and encrypted connection before falling back. (RATIONALE: This approach can increase latency while discovering server capabilities but maximizes the chance of sending the query over an authenticated and encrypted connection.)
如果没有可用的服务器功能信息，则（除非DNS客户端的配置另有规定），实现TLS和DTL的DNS客户端应尝试使用这两种协议进行身份验证，然后再失败或返回到未经身份验证或明文连接。使用机会主义隐私配置文件的DNS客户端应该尝试所有可用的服务器（可能并行），以便在回退之前获得经过身份验证和加密的连接。（理由：这种方法可以在发现服务器功能时增加延迟，但可以最大限度地利用经过身份验证和加密的连接发送查询。）
Acknowledgments
致谢
Thanks to the authors of both [RFC8094] and [RFC7858] for laying the groundwork for this document and for reviewing the contents. The authors would also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian Huitema, and John Levine for review and discussion of the ideas presented here.
感谢[RFC8094]和[RFC7858]的作者为本文件奠定了基础，并对其内容进行了审查。作者还要感谢John Dickinson、Shumon Huque、Melinda Shore、Gowri Viswewaran、Ray Bellis、Stephane Bortzmeyer、Jinmei Tatuya、Paul Hoffman、Christian Huitema和John Levine对本文所述观点的回顾和讨论。
Authors' Addresses
作者地址
Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
Sara Dickinson Sinodun互联网技术中心牛津科技园牛津OX4 4GA英国
Email: sara@sinodun.com
URI: https://www.sinodun.com/
Email: sara@sinodun.com
URI: https://www.sinodun.com/
Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States of America
美国纽约州纽约市布罗德街125号18楼Daniel Kahn Gillmor ACLU 10004
Email: dkg@fifthhorseman.net
Email: dkg@fifthhorseman.net
Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India
印度卡纳塔克邦班加罗尔大使馆高尔夫链接商务园Tirumaleswar Reddy McAfee，Inc.560071
Email: TirumaleswarReddy_Konda@McAfee.com
Email: TirumaleswarReddy_Konda@McAfee.com