Internet Engineering Task Force (IETF) Z. Hu
Request for Comments: 7858 L. Zhu
Category: Standards Track J. Heidemann
ISSN: 2070-1721 USC/ISI
A. Mankin
Independent
D. Wessels
Verisign Labs
P. Hoffman
ICANN
May 2016
Internet Engineering Task Force (IETF) Z. Hu
Request for Comments: 7858 L. Zhu
Category: Standards Track J. Heidemann
ISSN: 2070-1721 USC/ISI
A. Mankin
Independent
D. Wessels
Verisign Labs
P. Hoffman
ICANN
May 2016
Specification for DNS over Transport Layer Security (TLS)
传输层安全性（TLS）上的DNS规范
Abstract
摘要
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.
本文档介绍如何使用传输层安全性（TLS）为DNS提供隐私。TLS提供的加密消除了网络中DNS查询的窃听和路径篡改机会，如RFC 7626中所述。此外，本文档指定了DNS over TLS的两种使用配置文件，并提供了性能注意事项方面的建议，以最大限度地减少在DNS中使用TCP和TLS的开销。
This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.
根据DPRIVE工作组的章程，本文档重点关注如何将存根保护到递归通信。它不会阻止协议的未来应用递归到权威流量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7858.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7858.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close, and Reestablishment . . . . . . 6
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Out-of-Band Key-Pinned Privacy Profile . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Out-of-Band Key-Pinned Privacy Profile Example . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close, and Reestablishment . . . . . . 6
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Out-of-Band Key-Pinned Privacy Profile . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Out-of-Band Key-Pinned Privacy Profile Example . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Today, nearly all DNS queries [RFC1034] [RFC1035] are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker that has access to the network channel, reducing the privacy of the querier. Recent news reports have elevated these concerns, and recent IETF work has specified privacy considerations for DNS [RFC7626].
如今，几乎所有DNS查询[RFC1034][RFC1035]都是未加密发送的，这使得它们容易受到访问网络通道的攻击者的窃听，从而降低了查询者的隐私。最近的新闻报道加剧了这些担忧，最近的IETF工作规定了DNS的隐私注意事项[RFC7626]。
Prior work has addressed some aspects of DNS security, but until recently, there has been little work on privacy between a DNS client and server. DNS Security Extensions (DNSSEC) [RFC4033] provide _response integrity_ by defining mechanisms to cryptographically sign zones, allowing end users (or their first-hop resolver) to verify replies are correct. By intention, DNSSEC does not protect request and response privacy. Traditionally, either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private; however, these perceptions are evolving due to recent events [RFC7258].
以前的工作已经解决了DNS安全性的一些方面，但直到最近，在DNS客户端和服务器之间的隐私方面的工作还很少。DNS安全扩展（DNSSEC）[RFC4033]通过定义加密签名区域的机制来提供响应完整性，允许最终用户（或其第一跳解析程序）验证响应是否正确。DNSSEC无意保护请求和响应隐私。传统上，隐私不被视为DNS流量的要求，或者假设网络流量是充分私有的；然而，由于最近的事件，这些看法正在演变[RFC7258]。
Other work that has offered the potential to encrypt between DNS clients and servers includes DNSCurve [DNSCurve], DNSCrypt [DNSCRYPT-WEBSITE], Confidential DNS [CONFIDENTIAL-DNS], and IPSECA [IPSECA]. In addition to the present specification, the DPRIVE Working Group has also adopted a proposal for DNS over Datagram Transport Layer Security (DTLS) [DNSoD].
其他有可能在DNS客户端和服务器之间进行加密的工作包括DNSCurve[DNSCurve]、DNSCrypt[DNSCrypt-WEBSITE]、机密DNS[Confidential-DNS]和IPSECA[IPSECA]。除本规范外，DPRIVE工作组还通过了数据报传输层安全（DTLS）[DNSoD]上的DNS提案。
This document describes using DNS over TLS on a well-known port and also offers advice on performance considerations to minimize overheads from using TCP and TLS with DNS.
本文档描述了在一个著名的端口上通过TLS使用DNS，并提供了有关性能注意事项的建议，以最大限度地减少通过DNS使用TCP和TLS产生的开销。
Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel. Deployment will be gradual. Not all servers will support DNS over TLS and the well-known port might be blocked by some firewalls. Clients will be expected to keep track of servers that support TLS and those that don't. Clients and servers will adhere to the TLS implementation recommendations and security considerations of [BCP195].
通过TLS启动DNS非常简单。通过在已知端口上建立连接，客户端和服务器期望并同意协商TLS会话以保护通道。部署将是渐进的。并非所有服务器都支持TLS上的DNS，并且已知端口可能会被某些防火墙阻止。客户机需要跟踪支持TLS和不支持TLS的服务器。客户机和服务器将遵守[BCP195]的TLS实施建议和安全注意事项。
The protocol described here works for queries and responses between stub clients and recursive servers. It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter.
这里描述的协议适用于存根客户端和递归服务器之间的查询和响应。它可以在递归客户端和权威服务器之间平等地工作，但根据DNS专用交换（DPRIVE）工作组当前的章程，该协议的应用超出了其范围。
This document describes two profiles in Section 4 that provide different levels of assurance of privacy: an opportunistic privacy profile and an out-of-band key-pinned privacy profile. It is expected that a future document based on [TLS-DTLS-PROFILES] will further describe additional privacy profiles for DNS over both TLS and DTLS.
本文档描述了第4节中提供不同级别隐私保证的两个配置文件：机会主义隐私配置文件和带外密钥锁定隐私配置文件。预计未来基于[TLS-DTLS-PROFILES]的文档将进一步描述TLS和DTLS上DNS的其他隐私配置文件。
An earlier draft version of this document described a technique for upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, essentially, "STARTTLS for DNS". To simplify the protocol, this document now only uses a well-known port to specify TLS use, omitting the upgrade approach. The upgrade approach no longer appears in this document, which now focuses exclusively on the use of a well-known port for DNS over TLS.
本文档的早期草稿描述了一种将DNS over TCP连接升级到DNS over TLS会话的技术，该会话本质上是“STARTTLS for DNS”。为了简化协议，本文档现在只使用一个众所周知的端口来指定TLS的使用，省略了升级方法。升级方法不再出现在本文档中，它现在只关注通过TLS使用DNS的知名端口。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
By default, a DNS server that supports DNS over TLS MUST listen for and accept TCP connections on port 853, unless it has mutual agreement with its clients to use a port other than 853 for DNS over TLS. In order to use a port other than 853, both clients and servers would need a configuration option in their software.
默认情况下，支持TLS上的DNS的DNS服务器必须侦听并接受端口853上的TCP连接，除非它与其客户端达成协议，将853以外的端口用于TLS上的DNS。为了使用853以外的端口，客户端和服务器都需要在其软件中配置选项。
By default, a DNS client desiring privacy from DNS over TLS from a particular server MUST establish a TCP connection to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over TLS. Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range. This recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks. The first data exchange on this TCP connection MUST be the client and server initiating a TLS handshake using the procedure described in [RFC5246].
默认情况下，希望通过TLS从特定服务器获得DNS隐私的DNS客户端必须与服务器上的端口853建立TCP连接，除非其与服务器达成协议，使用端口853以外的端口通过TLS进行DNS。这样的另一个端口不得为端口53，但可以来自“先到先服务”端口范围。针对通过TLS的DNS使用端口53的建议是为了避免选择使用或不使用TLS时的复杂性，并降低降级攻击的风险。此TCP连接上的第一次数据交换必须是使用[RFC5246]中描述的过程启动TLS握手的客户端和服务器。
DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port used for DNS over TLS (including, for example, after a failed TLS handshake). There are significant security issues in mixing protected and unprotected data,
DNS客户端和服务器不得使用端口853传输明文DNS消息。DNS客户端不得发送，DNS服务器不得响应用于TLS上DNS的任何端口上的明文DNS消息（包括，例如，在TLS握手失败后）。混合使用受保护和未受保护的数据时存在严重的安全问题，
and for this reason, TCP connections on a port designated by a given server for DNS over TLS are reserved purely for encrypted communications.
出于这个原因，指定服务器为DNS over TLS指定的端口上的TCP连接仅保留用于加密通信。
DNS clients SHOULD remember server IP addresses that don't support DNS over TLS, including timeouts, connection refusals, and TLS handshake failures, and not request DNS over TLS from them for a reasonable period (such as one hour per server). DNS clients following an out-of-band key-pinned privacy profile (Section 4.2) MAY be more aggressive about retrying DNS-over-TLS connection failures.
DNS客户端应该记住不支持通过TLS的DNS的服务器IP地址，包括超时、连接拒绝和TLS握手失败，并且在合理的时间段内（例如每台服务器一小时）不通过TLS请求DNS。遵循带外密钥锁定隐私配置文件（第4.2节）的DNS客户端在通过TLS连接失败重试DNS时可能更具攻击性。
Once the DNS client succeeds in connecting via TCP on the well-known port for DNS over TLS, it proceeds with the TLS handshake [RFC5246], following the best practices specified in [BCP195].
一旦DNS客户端成功地通过TCP在众所周知的TLS上的DNS端口上进行连接，它将按照[BCP195]中规定的最佳实践进行TLS握手[RFC5246]。
The client will then authenticate the server, if required. This document does not propose new ideas for authentication. Depending on the privacy profile in use (Section 4), the DNS client may choose not to require authentication of the server, or it may make use of a trusted Subject Public Key Info (SPKI) Fingerprint pin set.
如果需要，客户端将对服务器进行身份验证。本文件并未对认证提出新的想法。根据使用中的隐私配置文件（第4节），DNS客户端可以选择不要求对服务器进行身份验证，或者可以使用受信任的主体公钥信息（SPKI）指纹pin集。
After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping.
TLS协商完成后，连接将被加密，现在可以防止窃听。
All messages (requests and responses) in the established TLS session MUST use the two-octet length field described in Section 4.2.2 of [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call) to make it more likely that all the data will be transmitted in a single TCP segment ([RFC7766], Section 8).
建立的TLS会话中的所有消息（请求和响应）必须使用[RFC1035]第4.2.2节中描述的双八位组长度字段。出于效率考虑，DNS客户端和服务器应同时将两个八位字节长度字段和该长度字段描述的消息传递给TCP层（例如，在单个“写入”系统调用中），以使所有数据更有可能在单个TCP段中传输（[RFC7766]，第8节）。
In order to minimize latency, clients SHOULD pipeline multiple queries over a TLS session. When a DNS client sends multiple queries to a server, it should not wait for an outstanding reply before sending the next query ([RFC7766], Section 6.2.1.1).
为了最大限度地减少延迟，客户机应该在TLS会话上通过管道传输多个查询。当DNS客户端向服务器发送多个查询时，它不应在发送下一个查询之前等待未完成的答复（[RFC7766]，第6.2.1.1节）。
Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TLS connection using the Message ID. If the response contains a Question Section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability ([RFC7766], Section 7).
由于管道响应可能会无序到达，因此客户端必须使用消息ID匹配同一TLS连接上未完成查询的响应。如果响应包含问题部分，则客户端必须匹配QNAME、QCClass和QTYPE字段。客户端未能正确匹配对未完成查询的响应可能会对互操作性造成严重后果（[RFC7766]，第7节）。
For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()", current implementations are known to open and close TCP connections for each DNS query. To avoid excess TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver. Alternatively, they may prefer to use UDP to a DNS-over-TLS-enabled caching resolver on the same machine that then uses a system-wide TCP connection to the recursive resolver.
对于使用库函数（如“getaddrinfo（）”和“gethostbyname（）”）的DNS客户端，已知当前实现为每个DNS查询打开和关闭TCP连接。为了避免TCP连接过多（每个连接都有一个查询），客户端应该重用到递归解析器的单个TCP连接。或者，他们可能更喜欢在同一台机器上使用UDP连接到DNS over TLS启用的缓存解析器，然后使用系统范围的TCP连接到递归解析器。
In order to amortize TCP and TLS connection setup costs, clients and servers SHOULD NOT immediately close a connection after each response. Instead, clients and servers SHOULD reuse existing connections for subsequent queries as long as they have sufficient resources. In some cases, this means that clients and servers may need to keep idle connections open for some amount of time.
为了分摊TCP和TLS连接设置成本，客户端和服务器不应在每次响应后立即关闭连接。相反，只要客户机和服务器有足够的资源，它们就应该为后续查询重用现有连接。在某些情况下，这意味着客户端和服务器可能需要将空闲连接保持打开一段时间。
Proper management of established and idle connections is important to the healthy operation of a DNS server. An implementor of DNS over TLS SHOULD follow best practices for DNS over TCP, as described in [RFC7766]. Failure to do so may lead to resource exhaustion and denial of service.
正确管理已建立和空闲的连接对于DNS服务器的健康运行非常重要。TLS上DNS的实现者应遵循TCP上DNS的最佳实践，如[RFC7766]中所述。否则可能会导致资源耗尽和拒绝服务。
Whereas client and server implementations from the era of [RFC1035] are known to have poor TCP connection management, this document stipulates that successful negotiation of TLS indicates the willingness of both parties to keep idle DNS connections open, independent of timeouts or other recommendations for DNS over TCP without TLS. In other words, software implementing this protocol is assumed to support idle, persistent connections and be prepared to manage multiple, potentially long-lived TCP connections.
鉴于[RFC1035]时代的客户机和服务器实现的TCP连接管理较差，本文件规定，TLS的成功协商表明双方愿意保持空闲DNS连接打开，不受超时或其他建议的影响，通过TCP进行DNS而不使用TLS。换句话说，实现此协议的软件被假定为支持空闲的、持久的连接，并准备好管理多个可能长期存在的TCP连接。
This document does not make specific recommendations for timeout values on idle connections. Clients and servers should reuse and/or close connections depending on the level of available resources. Timeouts may be longer during periods of low activity and shorter during periods of high activity. Current work in this area may also assist DNS-over-TLS clients and servers in selecting useful timeout values [RFC7828] [TDNS].
本文档不针对空闲连接的超时值提出具体建议。客户端和服务器应根据可用资源的级别重用和/或关闭连接。低活动期间的超时时间可能较长，高活动期间的超时时间可能较短。目前在这方面的工作还可以帮助通过TLS客户端和服务器的DNS选择有用的超时值[RFC7828][TDN]。
Clients and servers that keep idle connections open MUST be robust to termination of idle connection by either party. As with current DNS over TCP, DNS servers MAY close the connection at any time (perhaps due to resource constraints). As with current DNS over TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries.
保持空闲连接打开的客户机和服务器必须对任何一方终止空闲连接具有鲁棒性。与当前通过TCP的DNS一样，DNS服务器可能随时关闭连接（可能是由于资源限制）。与当前TCP上的DNS一样，客户端必须处理突然关闭，并准备好重新建立连接和/或重试查询。
When reestablishing a DNS-over-TCP connection that was terminated, as discussed in [RFC7766], TCP Fast Open [RFC7413] is of benefit. Underlining the requirement for sending only encrypted DNS data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open, the client and server MUST immediately initiate or resume a TLS handshake (cleartext DNS MUST NOT be exchanged). DNS servers SHOULD enable fast TLS session resumption [RFC5077], and this SHOULD be used when reestablishing connections.
如[RFC7766]中所述，在通过TCP重新建立已终止的DNS连接时，TCP Fast Open[RFC7413]会带来好处。强调了仅通过TLS端口在DNS上发送加密DNS数据的要求（第3.2节），当使用TCP Fast Open时，客户端和服务器必须立即启动或恢复TLS握手（不得交换明文DNS）。DNS服务器应启用快速TLS会话恢复[RFC5077]，这应在重新建立连接时使用。
When closing a connection, DNS servers SHOULD use the TLS close-notify request to shift TCP TIME-WAIT state to the clients. Additional requirements and guidance for optimizing DNS over TCP are provided by [RFC7766].
关闭连接时，DNS服务器应使用TLS close notify请求将TCP时间等待状态转移到客户端。[RFC7766]提供了通过TCP优化DNS的其他要求和指南。
This protocol provides flexibility to accommodate several different use cases. This document defines two usage profiles: (1) opportunistic privacy and (2) out-of-band key-pinned authentication that can be used to obtain stronger privacy guarantees if the client has a trusted relationship with a DNS server supporting TLS. Additional methods of authentication will be defined in a forthcoming document [TLS-DTLS-PROFILES].
该协议提供了灵活性，以适应多个不同的用例。本文档定义了两种使用配置文件：（1）机会主义隐私和（2）带外密钥锁定身份验证，如果客户端与支持TLS的DNS服务器具有信任关系，则可使用该身份验证来获得更强大的隐私保证。其他认证方法将在即将发布的文件[TLS-DTLS-PROFILES]中定义。
For opportunistic privacy, analogous to SMTP opportunistic security [RFC7435], one does not require privacy, but one desires privacy when possible.
对于机会主义隐私，类似于SMTP机会主义安全[RFC7435]，不需要隐私，但在可能的情况下需要隐私。
With opportunistic privacy, a client might learn of a TLS-enabled recursive DNS resolver from an untrusted source. One possible example flow would be if the client used the DHCP DNS server option [RFC3646] to discover the IP address of a TLS-enabled recursive and then attempted DNS over TLS on port 853. With such a discovered DNS server, the client might or might not validate the resolver. These choices maximize availability and performance, but they leave the client vulnerable to on-path attacks that remove privacy.
利用机会主义隐私，客户机可能会从不受信任的来源了解到启用TLS的递归DNS解析器。一个可能的示例流是，客户端使用DHCP DNS服务器选项[RFC3646]查找启用TLS的递归的IP地址，然后尝试通过端口853上的TLS进行DNS。有了这样一个发现的DNS服务器，客户端可能会也可能不会验证解析程序。这些选择可以最大限度地提高可用性和性能，但会使客户端容易受到路径攻击，从而删除隐私。
Opportunistic privacy can be used by any current client, but it only provides privacy when there are no on-path active attackers.
机会主义隐私可以被任何当前客户端使用，但它仅在没有路径上活动攻击者时提供隐私。
The out-of-band key-pinned privacy profile can be used in environments where an established trust relationship already exists between DNS clients and servers (e.g., stub-to-recursive in enterprise networks, actively maintained contractual service
带外密钥锁定隐私配置文件可用于DNS客户端和服务器之间已建立信任关系的环境（例如，企业网络中的存根到递归、主动维护的合同服务）
relationships, or a client using a public DNS resolver). The result of this profile is that the client has strong guarantees about the privacy of its DNS data by connecting only to servers it can authenticate. Operators of a DNS-over-TLS service in this profile are expected to provide pins that are specific to the service being pinned (i.e., public keys belonging directly to the end entity or to a service-specific private certificate authority (CA)) and not to a public key(s) of a generic public CA.
关系，或使用公共DNS解析程序的客户端）。此配置文件的结果是，客户端通过仅连接到其可以进行身份验证的服务器，对其DNS数据的隐私有很强的保证。此配置文件中DNS over TLS服务的运营商应提供特定于被固定服务的PIN（即，直接属于终端实体或特定于服务的专用证书颁发机构（CA））的公钥，而不是通用公共CA的公钥。
In this profile, clients authenticate servers by matching a set of SPKI Fingerprints in an analogous manner to that described in [RFC7469]. With this out-of-band key-pinned privacy profile, client administrators SHOULD deploy a backup pin along with the primary pin, for the reasons explained in [RFC7469]. A backup pin is especially helpful in the event of a key rollover, so that a server operator does not have to coordinate key transitions with all its clients simultaneously. After a change of keys on the server, an updated pin set SHOULD be distributed to all clients in some secure way in preparation for future key rollover. The mechanism for an out-of-band pin set update is out of scope for this document.
在此配置文件中，客户机通过以与[RFC7469]中所述类似的方式匹配一组SPKI指纹来验证服务器。根据[RFC7469]中解释的原因，使用此带外密钥锁定隐私配置文件，客户端管理员应将备份pin与主pin一起部署。备份pin在密钥翻转时特别有用，这样服务器操作员就不必同时与所有客户端协调密钥转换。在服务器上更改密钥后，应以某种安全的方式将更新的pin集分发给所有客户端，以便为将来的密钥翻转做好准备。带外pin集更新机制不在本文档的范围内。
Such a client will only use DNS servers for which an SPKI Fingerprint pin set has been provided. The possession of a trusted pre-deployed pin set allows the client to detect and prevent person-in-the-middle and downgrade attacks.
此类客户端将仅使用已提供SPKI指纹pin码集的DNS服务器。拥有一个可信的预部署pin集允许客户端检测并防止中间人攻击和降级攻击。
However, a configured DNS server may be temporarily unavailable when configuring a network. For example, for clients on networks that require authentication through web-based login, such authentication 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 DNS provider after authentication. The user MUST be alerted whenever possible that the DNS is not private during such bootstrap.
但是，配置网络时，配置的DNS服务器可能暂时不可用。例如，对于网络上需要通过基于web的登录进行身份验证的客户端，此类身份验证可能依赖于DNS拦截和欺骗。诸如DNSSEC触发器[DNSSEC-trigger]所使用的技术可在网络配置期间使用，目的是在认证后转换到指定的DNS提供商。在这种引导过程中，必须尽可能提醒用户DNS不是私有的。
Upon successful TLS connection and handshake, the client computes the SPKI Fingerprints for the public keys found in the validated server's certificate chain (or in the raw public key, if the server provides that instead). If a computed fingerprint exactly matches one of the configured pins, the client continues with the connection as normal. Otherwise, the client MUST treat the SPKI validation failure as a non-recoverable error. Appendix A provides a detailed example of how this authentication could be performed in practice.
TLS连接和握手成功后，客户机将为在已验证服务器的证书链中找到的公钥（或原始公钥，如果服务器提供的话）计算SPKI指纹。如果计算出的指纹与其中一个配置的管脚完全匹配，则客户端将继续正常连接。否则，客户端必须将SPKI验证失败视为不可恢复的错误。附录A提供了如何在实践中执行此验证的详细示例。
Implementations of this privacy profile MUST support the calculation of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded ASN.1 representation of the SPKI of an X.509 certificate.
此隐私配置文件的实现必须支持将指纹计算为X.509证书的SPKI的DER编码ASN.1表示形式的SHA-256[RFC6234]散列。
Implementations MUST support the representation of a SHA-256 fingerprint as a base64-encoded character string [RFC4648]. Additional fingerprint types MAY also be supported.
实现必须支持将SHA-256指纹表示为base64编码字符串[RFC4648]。还可能支持其他指纹类型。
DNS over TLS incurs additional latency at session startup. It also requires additional state (memory) and increased processing (CPU).
TLS上的DNS在会话启动时会产生额外的延迟。它还需要额外的状态（内存）和增加的处理（CPU）。
Latency: Compared to UDP, DNS over TCP requires an additional round-trip time (RTT) of latency to establish a TCP connection. TCP Fast Open [RFC7413] can eliminate that RTT when information exists from prior connections. The TLS handshake adds another two RTTs of latency. Clients and servers should support connection keepalive (reuse) and out-of-order processing to amortize connection setup costs. Fast TLS connection resumption [RFC5077] further reduces the setup delay and avoids the DNS server keeping per-client session state.
延迟：与UDP相比，TCP上的DNS需要额外的延迟往返时间（RTT）来建立TCP连接。TCP Fast Open[RFC7413]可以在先前连接中存在信息时消除RTT。TLS握手增加了另外两个RTT的延迟。客户端和服务器应支持连接保持（重用）和无序处理，以分摊连接设置成本。快速TLS连接恢复[RFC5077]进一步减少了设置延迟，并避免DNS服务器保持每个客户端会话状态。
TLS False Start [TLS-FALSESTART] can also lead to a latency reduction in certain situations. Implementations supporting TLS False Start need to be aware that it imposes additional constraints on how one uses TLS, over and above those stated in [BCP195]. It is unsafe to use False Start if your implementation and deployment does not adhere to these specific requirements. See [TLS-FALSESTART] for the details of these additional constraints.
TLS错误启动[TLS-FALSESTART]在某些情况下也会导致延迟减少。支持TLS False Start的实现需要注意，它对如何使用TLS施加了额外的限制，超过了[BCP195]中所述的限制。如果您的实现和部署不符合这些特定要求，则使用假启动是不安全的。有关这些附加约束的详细信息，请参见[TLS-FALSESTART]。
State: The use of connection-oriented TCP requires keeping additional state at the server in both the kernel and application. The state requirements are of particular concern on servers with many clients, although memory-optimized TLS can add only modest state over TCP. Smaller timeout values will reduce the number of concurrent connections, and servers can preemptively close connections when resource limits are exceeded.
状态：使用面向连接的TCP需要在内核和应用程序的服务器上保持额外的状态。虽然内存优化的TLS只能在TCP上添加适度的状态，但在具有许多客户端的服务器上，状态要求尤其值得关注。较小的超时值将减少并发连接的数量，并且当超过资源限制时，服务器可以抢先关闭连接。
Processing: The use of TLS encryption algorithms results in slightly higher CPU usage. Servers can choose to refuse new DNS-over-TLS clients if processing limits are exceeded.
处理：使用TLS加密算法会导致略高的CPU使用率。如果超出处理限制，服务器可以选择通过TLS客户端拒绝新的DNS。
Number of connections: To minimize state on DNS servers and connection startup time, clients SHOULD minimize the creation of new TCP connections. Use of a local DNS request aggregator (a particular type of forwarder) allows a single active DNS-over-TLS connection from any given client computer to its server. Additional guidance can be found in [RFC7766].
连接数：要最小化DNS服务器上的状态和连接启动时间，客户端应最小化新TCP连接的创建。使用本地DNS请求聚合器（一种特定类型的转发器）允许通过TLS连接从任何给定的客户端计算机到其服务器的单个活动DNS。更多指南请参见[RFC7766]。
A full performance evaluation is outside the scope of this specification. A more detailed analysis of the performance implications of DNS over TLS (and DNS over TCP) is discussed in [TDNS] and [RFC7766].
全面性能评估不在本规范范围内。[TDNS]和[RFC7766]中讨论了DNS over TLS（和DNS over TCP）性能影响的更详细分析。
IANA has added the following value to the "Service Name and Transport Protocol Port Number Registry" in the System Range. The registry for that range requires IETF Review or IESG Approval [RFC6335], and such a review was requested using the early allocation process [RFC7120] for the well-known TCP port in this document.
IANA已将以下值添加到系统范围中的“服务名称和传输协议端口号注册表”。该范围的注册需要IETF审查或IESG批准[RFC6335]，并且该审查是使用本文档中已知TCP端口的早期分配过程[RFC7120]请求的。
IANA has reserved the same port number over UDP for the proposed DNS-over-DTLS protocol [DNSoD].
IANA已通过UDP为建议的DNS over DTLS协议[DNSoD]保留了相同的端口号。
Service Name domain-s Port Number 853 Transport Protocol(s) TCP/UDP Assignee IESG Contact IETF Chair Description DNS query-response protocol run over TLS/DTLS Reference This document
服务名称域名端口号853传输协议TCP/UDP受让人IESG联系IETF主席描述DNS查询响应协议运行于TLS/DTLS参考本文档
Earlier draft versions of this document proposed an upgrade-based approach to establish a TLS session. The client would signal its interest in TLS by setting a "TLS OK" bit in the Extensions Mechanisms for DNS (EDNS(0)) flags field. A server would signal its acceptance by responding with the TLS OK bit set.
本文档的早期草稿提出了一种基于升级的方法来建立TLS会话。客户端将通过在DNS扩展机制（EDNS（0））标志字段中设置“TLS OK”位来表示其对TLS的兴趣。服务器将通过设置TLS OK位进行响应来发出接受信号。
Since we assume the client doesn't want to reveal (leak) any information prior to securing the channel, we proposed the use of a "dummy query" that clients could send for this purpose. The proposed query name was STARTTLS, query type TXT, and query class CH.
由于我们假设客户端不想在保护通道之前泄露任何信息，因此我们建议使用“虚拟查询”，客户端可以为此发送该查询。建议的查询名称是STARTTLS、查询类型TXT和查询类CH。
The TLS OK signaling approach has both advantages and disadvantages. One important advantage is that clients and servers could negotiate TLS. If the server is too busy, or doesn't want to provide TLS service to a particular client, it can respond negatively to the TLS probe. An ancillary benefit is that servers could collect information on adoption of DNS over TLS (via the TLS OK bit in queries) before implementation and deployment. Another anticipated advantage is the expectation that DNS over TLS would work over port 53. That is, no need to "waste" another port and deploy new firewall rules on middleboxes.
TLS OK信令方法既有优点也有缺点。一个重要的优势是客户端和服务器可以协商TLS。如果服务器太忙，或者不想向特定客户机提供TLS服务，它可能会对TLS探测做出负面响应。一个附带的好处是，服务器可以在实现和部署之前（通过查询中的TLS OK位）收集关于通过TLS采用DNS的信息。另一个预期优势是，TLS上的DNS将在端口53上工作。也就是说，不需要“浪费”另一个端口，也不需要在中间盒上部署新的防火墙规则。
However, at the same time, there was uncertainty whether or not middleboxes would pass the TLS OK bit, given that the EDNS0 flags field has been unchanged for many years. Another disadvantage is that the TLS OK bit may make downgrade attacks easy and indistinguishable from broken middleboxes. From a performance standpoint, the upgrade-based approach had the disadvantage of requiring 1xRTT additional latency for the dummy query.
然而，同时，由于EDNS0标志字段多年来一直保持不变，因此不确定中间盒是否会通过TLS OK位。另一个缺点是TLS OK位可能使降级攻击变得容易，并且无法与损坏的中间盒区分开来。从性能角度来看，基于升级的方法的缺点是需要为虚拟查询增加1xRTT延迟。
Following this proposal, DNS over DTLS was proposed separately. DNS over DTLS claimed it could work over port 53, but only because a non-DTLS server interprets a DNS-over-DTLS query as a response. That is, the non-DTLS server observes the QR flag set to 1. While this technically works, it seems unfortunate and perhaps even undesirable.
根据该提案，单独提出了DTLS上的DNS。DNS over DTLS声称它可以在端口53上工作，但这只是因为非DTLS服务器将DNS over DTLS查询解释为响应。也就是说，非DTLS服务器观察设置为1的QR标志。虽然这在技术上是可行的，但它似乎是不幸的，甚至是不可取的。
DNS over both TLS and DTLS can benefit from a single well-known port and avoid extra latency and misinterpreted queries as responses.
TLS和DTL上的DNS都可以从一个已知端口中获益，并避免额外的延迟和将查询误解为响应。
Use of DNS over TLS is designed to address the privacy risks that arise out of the ability to eavesdrop on DNS messages. It does not address other security issues in DNS, and there are a number of residual risks that may affect its success at protecting privacy:
通过TLS使用DNS旨在解决因窃听DNS消息而产生的隐私风险。它不解决DNS中的其他安全问题，并且存在许多可能影响其成功保护隐私的剩余风险：
1. There are known attacks on TLS, such as person-in-the-middle and protocol downgrade. These are general attacks on TLS and not specific to DNS over TLS; please refer to the TLS RFCs for discussion of these security issues. Clients and servers MUST adhere to the TLS implementation recommendations and security considerations of [BCP195]. DNS clients keeping track of servers known to support TLS enables clients to detect downgrade attacks. For servers with no connection history and no apparent support for TLS, depending on their privacy profile and privacy requirements, clients may choose to (a) try another server when available, (b) continue without TLS, or (c) refuse to forward the query.
1. TLS上存在已知的攻击，例如中间人攻击和协议降级攻击。这些是针对TLS的一般攻击，而不是针对TLS上的DNS的攻击；有关这些安全问题的讨论，请参阅TLS RFC。客户机和服务器必须遵守[BCP195]的TLS实施建议和安全注意事项。DNS客户端跟踪已知支持TLS的服务器，使客户端能够检测降级攻击。对于没有连接历史记录且明显不支持TLS的服务器，根据其隐私配置文件和隐私要求，客户端可以选择（a）在可用时尝试另一台服务器，（b）在没有TLS的情况下继续，或（c）拒绝转发查询。
2. Middleboxes [RFC3234] are present in some networks and have been known to interfere with normal DNS resolution. Use of a designated port for DNS over TLS should avoid such interference. In general, clients that attempt TLS and fail can either fall back on unencrypted DNS or wait and retry later, depending on their privacy profile and privacy requirements.
2. 一些网络中存在中间盒[RFC3234]，已知会干扰正常的DNS解析。通过TLS为DNS使用指定端口应避免此类干扰。一般来说，尝试TLS但失败的客户端可以返回未加密的DNS，也可以等待稍后重试，具体取决于其隐私配置文件和隐私要求。
3. Any DNS protocol interactions performed in the clear can be modified by a person-in-the-middle attacker. For example, unencrypted queries and responses might take place over port 53 between a client and server. For this reason, clients MAY
3. 在clear中执行的任何DNS协议交互都可以由中间攻击者修改。例如，未加密的查询和响应可能发生在客户端和服务器之间的端口53上。因此，客户可能会
discard cached information about server capabilities advertised in cleartext.
丢弃明文中公布的有关服务器功能的缓存信息。
4. This document does not, itself, specify ideas to resist known traffic analysis or side-channel leaks. Even with encrypted messages, a well-positioned party may be able to glean certain details from an analysis of message timings and sizes. Clients and servers may consider the use of a padding method to address privacy leakage due to message sizes [RFC7830]. Since traffic analysis can be based on many kinds of patterns and many kinds of classifiers, simple padding schemes alone might not be sufficient to mitigate such an attack. Padding will, however, form a part of more complex mitigations for traffic-analysis attacks that are likely to be developed over time. Implementors who can offer flexibility in terms of how padding can be used may be in a better position to enable such mitigations to be deployed in the future.
4. 本文件本身并没有具体说明抵制已知流量分析或侧通道泄漏的方法。即使使用加密的消息，位置良好的一方也可以从对消息时间和大小的分析中收集某些细节。客户端和服务器可以考虑使用填充方法来解决由于消息大小引起的隐私泄漏[RCF7830]。由于流量分析可以基于多种模式和多种分类器，单纯的填充方案可能不足以缓解此类攻击。但是，填充将成为可能随时间发展的流量分析攻击的更复杂缓解措施的一部分。能够在如何使用填充方面提供灵活性的实现者可能更适合在将来部署此类缓解措施。
As noted earlier, DNSSEC and DNS over TLS are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.
如前所述，DNSSEC和DNS over TLS是独立且完全兼容的协议，每个协议解决不同的问题。使用其中一个并不会减少对另一个的需求或效用。
[BCP195] 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, May 2015, <https://www.rfc-editor.org/info/bcp195>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<https://www.rfc-editor.org/info/bcp195>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[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, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<http://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, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，DOI 10.17487/RFC7120，2014年1月<http://www.rfc-editor.org/info/rfc7120>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<http://www.rfc-editor.org/info/rfc7469>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <http://www.rfc-editor.org/info/rfc7766>.
[RFC7766]Dickinson，J.，Dickinson，S.，Bellis，R.，Mankin，A.，和D.Wessels，“TCP上的DNS传输-实施要求”，RFC 7766，DOI 10.17487/RFC7766，2016年3月<http://www.rfc-editor.org/info/rfc7766>.
[CONFIDENTIAL-DNS] Wijngaards, W. and G. Wiley, "Confidential DNS", Work in Progress, draft-wijngaards-dnsop-confidentialdns-03, March 2015.
[保密DNS]Wijngaards，W.和G.Wiley，“保密DNS”，正在进行的工作，草稿-Wijngaards-dnsop-SecretentialDNS-032015年3月。
[DNSCRYPT-WEBSITE] Denis, F., "DNSCrypt", December 2015, <https://www.dnscrypt.org/>.
[DNSCRYPT-WEBSITE]Denis，F.，“DNSCRYPT”，2015年12月<https://www.dnscrypt.org/>.
[DNSCurve] Dempsky, M., "DNSCurve: Link-Level Security for the Domain Name System", Work in Progress, draft-dempsky-dnscurve-01, February 2010.
[DNSCurve]Dempsky，M.，“DNSCurve:域名系统的链接级安全”，正在进行的工作，草稿-Dempsky-DNSCurve-01，2010年2月。
[DNSoD] Reddy, T., Wing, D., and P. Patil, "DNS over DTLS (DNSoD)", Work in Progress, draft-ietf-dprive-dnsodtls-06, April 2016.
[DNSoD]Reddy，T.，Wing，D.，和P.Patil，“DTLS上的DNS（DNSoD）”，正在进行的工作，草案-ietf-dprive-dnsodtls-062016年4月。
[DNSSEC-TRIGGER] NLnet Labs, "Dnssec-Trigger", May 2014, <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[DNSSEC-TRIGGER]NLnet实验室，“DNSSEC触发器”，2014年5月<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[IPSECA] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. Mohaisen, "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", Work in Progress, draft-osterweil-dane-ipsec-03, July 2015.
[IPSECA]Osterweil，E.，Wiley，G.，Okubo，T.，Lavu，R.，和A.Mohaisen，“丹麦语义学和IPsec的机会主义加密：IPSECA”，正在进行的工作，草稿-Osterweil-DANE-IPsec-032015年7月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <http://www.rfc-editor.org/info/rfc3234>.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 3234，DOI 10.17487/RFC3234，2002年2月<http://www.rfc-editor.org/info/rfc3234>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <http://www.rfc-editor.org/info/rfc3646>.
[RFC3646]Droms，R.，Ed.“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，DOI 10.17487/RFC3646，2003年12月<http://www.rfc-editor.org/info/rfc3646>.
[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>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<http://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <http://www.rfc-editor.org/info/rfc7626>.
[RFC7626]Bortzmeyer，S.，“DNS隐私注意事项”，RFC 7626，DOI 10.17487/RFC7626，2015年8月<http://www.rfc-editor.org/info/rfc7626>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <http://www.rfc-editor.org/info/rfc7828>.
[RFC7828]Wouters，P.，Abley，J.，Dickinson，S.，和R.Bellis，“edns tcp keepalive EDNS0选项”，RFC 7828，DOI 10.17487/RFC78282016年4月<http://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <http://www.rfc-editor.org/info/rfc7830>.
[RFC7830]Mayrhofer，A.，“EDNS（0）填充选项”，RFC 7830，DOI 10.17487/RFC7830，2016年5月<http://www.rfc-editor.org/info/rfc7830>.
[TDNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", 2015 IEEE Symposium on Security and Privacy (SP), DOI 10.1109/SP.2015.18, <http://dx.doi.org/10.1109/SP.2015.18>.
[TDNS]Zhu，L.，Hu，Z.，Heidemann，J.，Wessels，D.，Mankin，A.，和N.Somaiya，“面向连接的DNS以提高隐私和安全性”，2015年IEEE安全和隐私研讨会（SP），DOI 10.1109/SP.2015.18<http://dx.doi.org/10.1109/SP.2015.18>.
[TLS-DTLS-PROFILES] Dickinson, S., Gillmor, D., and T. Reddy, "Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS", Work in Progress, draft-ietf-dprive-dtls-and-tls-profiles-01, March 2016.
[TLS-DTLS-PROFILES]Dickinson，S.，Gillmor，D.，和T.Reddy，“TLS上DNS和DTLS上DNS的认证和（D）TLS配置文件”，正在进行的工作，草稿-ietf-dprive-DTLS-and-TLS-PROFILES-01，2016年3月。
[TLS-FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-ietf-tls-falsestart-02, May 2016.
[TLS-FALSESTART]Langley，A.，Modadugu，N.，和B.Moeller，“传输层安全（TLS）错误启动”，正在进行的工作，草案-ietf-TLS-FALSESTART-022016年5月。
This section presents an example of how the out-of-band key-pinned privacy profile could work in practice based on a minimal pin set (two pins).
本节提供了一个示例，说明了带外钥匙固定隐私配置文件在实践中如何基于最小pin集（两个pin）工作。
A DNS client system is configured with an out-of-band key-pinned privacy profile from a network service, using a pin set containing two pins. Represented in HTTP Public Key Pinning (HPKP) [RFC7469] style, the pins are:
DNS客户端系统配置有来自网络服务的带外密钥锁定隐私配置文件，使用包含两个pin的pin集。以HTTP公钥锁定（HPKP）[RFC7469]样式表示，这些引脚为：
o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
o pin-sha256=“fhkylhvi0n70e47cjlrtrnyvcsyndjugbr79cfavi=”
o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
o pin-sha256=“dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w=”
The client also configures the IP addresses of its expected DNS server: perhaps 192.0.2.3 and 2001:db8::2:4.
客户端还配置其预期DNS服务器的IP地址：可能是192.0.2.3和2001:db8:：2:4。
The client connects to one of these addresses on TCP port 853 and begins the TLS handshake: negotiation of TLS 1.2 with a Diffie-Hellman key exchange. The server sends a certificate message with a list of three certificates (A, B, and C) and signs the ServerKeyExchange message correctly with the public key found in certificate A.
客户端连接到TCP端口853上的其中一个地址，并开始TLS握手：通过Diffie-Hellman密钥交换协商TLS 1.2。服务器发送包含三个证书（a、B和C）列表的证书消息，并使用证书a中的公钥对ServerKeyExchange消息进行正确签名。
The client now takes the SHA-256 digest of the SPKI in cert A and compares it against both pins in the pin set. If either pin matches, the verification is successful; the client continues with the TLS connection and can make its first DNS query.
客户端现在获取证书A中SPKI的SHA-256摘要，并将其与pin集中的两个pin进行比较。如果任一pin匹配，则验证成功；客户端继续TLS连接，并可以进行第一次DNS查询。
If neither pin matches the SPKI of cert A, the client verifies that cert A is actually issued by cert B. If it is, it takes the SHA-256 digest of the SPKI in cert B and compares it against both pins in the pin set. If either pin matches, the verification is successful. Otherwise, it verifies that B was issued by C and then compares the pins against the digest of C's SPKI.
如果两个pin都与证书A的SPKI不匹配，则客户端将验证证书A是否由证书B实际颁发。如果是，则获取证书B中SPKI的SHA-256摘要，并将其与pin集中的两个pin进行比较。如果任一pin匹配，则验证成功。否则，它将验证B是由C发出的，然后将这些引脚与C的SPKI摘要进行比较。
If none of the SPKIs in the cryptographically valid chain of certs match any pin in the pin set, the client closes the connection with an error and marks the IP address as failed.
如果加密有效的证书链中没有任何SPKI与pin集中的任何pin匹配，则客户端将关闭连接并显示错误，并将IP地址标记为失败。
Acknowledgments
致谢
The authors would like to thank Stephane Bortzmeyer, John Dickinson, Brian Haberman, Christian Huitema, Shumon Huque, Simon Joseffson, Kim-Minh Kaplan, Simon Kelley, Warren Kumari, John Levine, Ilari Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei Tatuya, Tim Wicinski, and Glen Wiley for reviewing this specification. They also thank Nikita Somaiya for early work on this idea.
作者感谢Stephane Bortzmeyer、John Dickinson、Brian Haberman、Christian Huitema、Shumon Huque、Simon Josefson、Kim Minh Kaplan、Simon Kelley、Warren Kumari、John Levine、Ilari Liusvaara、Bill Manning、George Michaelson、Eric Osterweil、Jimmi Tatuya、Tim Wicinski和Glen Wiley对本规范的审查。他们还感谢Nikita Somaiya在这个想法上的早期工作。
Work by Zi Hu, Liang Zhu, and John Heidemann on this document is partially sponsored by the U.S. Dept. of Homeland Security (DHS) Science and Technology Directorate, Homeland Security Advanced Research Projects Agency (HSARPA), Cyber Security Division, BAA 11-01-RIKA and Air Force Research Laboratory, Information Directorate under agreement number FA8750-12-2-0344, and contract number D08PC75599.
Zi Hu、Liang Zhu和John Heidemann在本文件上的工作部分由美国国土安全部（DHS）科学和技术理事会、国土安全高级研究项目局（HSARPA）、网络安全部、BAA 11-01-RIKA和空军研究实验室赞助，信息董事会，协议编号FA8750-12-2-0344，合同编号D08PC75599。
Contributors
贡献者
The below individuals contributed significantly to the document:
以下个人对该文件作出了重大贡献：
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: http://sinodun.com
Email: sara@sinodun.com
URI: http://sinodun.com
Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States
美国纽约州纽约市布罗德街125号18楼Daniel Kahn Gillmor ACLU 10004
Authors' Addresses
作者地址
Zi Hu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States
Zi Hu USC/信息科学研究所美国加利福尼亚州马里纳德雷市海军部路4676号1133室90292
Phone: +1-213-587-1057
Email: zihu@outlook.com
Phone: +1-213-587-1057
Email: zihu@outlook.com
Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States
梁祝南加州大学/信息科学研究所美国加利福尼亚州马里纳德雷市海军部路4676号1133室90292
Phone: +1-310-448-8323
Email: liangzhu@usc.edu
Phone: +1-310-448-8323
Email: liangzhu@usc.edu
John Heidemann USC/Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 United States
约翰·海德曼南加州大学/信息科学研究所美国加利福尼亚州马里纳·德雷市海军部路4676号1001室90292
Phone: +1-310-822-1511
Email: johnh@isi.edu
Phone: +1-310-822-1511
Email: johnh@isi.edu
Allison Mankin Independent
艾利森·曼金独立报
Phone: +1-301-728-7198
Email: Allison.mankin@gmail.com
Phone: +1-301-728-7198
Email: Allison.mankin@gmail.com
Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
杜安·韦塞尔Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿，邮编：20190
Phone: +1-703-948-3200
Email: dwessels@verisign.com
Phone: +1-703-948-3200
Email: dwessels@verisign.com
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org