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
                                                              D. Wessels
                                                           Verisign Labs
                                                              P. Hoffman
                                                                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
                                                              D. Wessels
                                                           Verisign Labs
                                                              P. Hoffman
                                                                May 2016

Specification for DNS over Transport Layer Security (TLS)




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.


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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].


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].


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].


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.


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].


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.


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.


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的知名端口。

2. Key Words
2. 关键词

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]中所述进行解释。

3. Establishing and Managing DNS-over-TLS Sessions
3. 通过TLS会话建立和管理DNS
3.1. Session Initiation
3.1. 会话启动

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.


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].


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,


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.


3.2. TLS Handshake and Authentication
3.2. TLS握手和认证

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].


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.


After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping.


3.3. Transmitting and Receiving Messages
3.3. 发送和接收消息

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).


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


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).


3.4. Connection Reuse, Close, and Reestablishment
3.4. 连接重用、关闭和重新建立

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.


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.


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.


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].


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.


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的其他要求和指南。

4. Usage Profiles
4. 使用概况

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].


4.1. Opportunistic Privacy Profile
4.1. 机会主义隐私档案

For opportunistic privacy, analogous to SMTP opportunistic security [RFC7435], one does not require privacy, but one desires privacy when possible.


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.


4.2. Out-of-Band Key-Pinned Privacy Profile
4.2. 带外密钥锁定隐私配置文件

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


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.


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.


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.


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.


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.


Implementations MUST support the representation of a SHA-256 fingerprint as a base64-encoded character string [RFC4648]. Additional fingerprint types MAY also be supported.


5. Performance Considerations
5. 性能注意事项

DNS over TLS incurs additional latency at session startup. It also requires additional state (memory) and increased processing (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.


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.


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].


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)性能影响的更详细分析。

6. IANA Considerations
6. IANA考虑

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 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


7. Design Evolution
7. 设计演变

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.


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.


8. Security Considerations
8. 安全考虑

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:


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是独立且完全兼容的协议,每个协议解决不同的问题。使用其中一个并不会减少对另一个的需求或效用。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[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, <>.

[BCP195]Sheffer,Y.,Holz,R.,和P.Saint Andre,“安全使用传输层安全性(TLS)和数据报传输层安全性(DTLS)的建议”,BCP 195,RFC 75252015年5月<>.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <>.

[RFC1034]Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 1034,DOI 10.17487/RFC1034,1987年11月<>.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <>.

[RFC1035]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 1035,DOI 10.17487/RFC1035,1987年11月<>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<>.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <>.

[RFC4648]Josefsson,S.,“Base16、Base32和Base64数据编码”,RFC 4648,DOI 10.17487/RFC4648,2006年10月<>.

[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, <>.

[RFC5077]Salowey,J.,Zhou,H.,Eronen,P.,和H.Tschofenig,“无服务器端状态的传输层安全(TLS)会话恢复”,RFC 5077,DOI 10.17487/RFC5077,2008年1月<>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <>.

[RFC5246]Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.2”,RFC 5246,DOI 10.17487/RFC5246,2008年8月<>.

[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, <>.

[RFC6234]Eastlake 3rd,D.和T.Hansen,“美国安全哈希算法(基于SHA和SHA的HMAC和HKDF)”,RFC 6234,DOI 10.17487/RFC6234,2011年5月<>.

[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, <>.

[RFC6335]Cotton,M.,Eggert,L.,Touch,J.,Westerlund,M.,和S.Cheshire,“互联网分配号码管理局(IANA)服务名称和传输协议端口号注册管理程序”,BCP 165,RFC 6335,DOI 10.17487/RFC6335,2011年8月<>.

[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <>.

[RFC7120]Cotton,M.,“标准轨道代码点的早期IANA分配”,BCP 100,RFC 7120,DOI 10.17487/RFC7120,2014年1月<>.

[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <>.

[RFC7469]Evans,C.,Palmer,C.,和R.Sleevi,“HTTP的公钥锁定扩展”,RFC 7469,DOI 10.17487/RFC7469,2015年4月<>.

[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, <>.

[RFC7766]Dickinson,J.,Dickinson,S.,Bellis,R.,Mankin,A.,和D.Wessels,“TCP上的DNS传输-实施要求”,RFC 7766,DOI 10.17487/RFC7766,2016年3月<>.

9.2. Informative References
9.2. 资料性引用

[CONFIDENTIAL-DNS] Wijngaards, W. and G. Wiley, "Confidential DNS", Work in Progress, draft-wijngaards-dnsop-confidentialdns-03, March 2015.


[DNSCRYPT-WEBSITE] Denis, F., "DNSCrypt", December 2015, <>.


[DNSCurve] Dempsky, M., "DNSCurve: Link-Level Security for the Domain Name System", Work in Progress, draft-dempsky-dnscurve-01, February 2010.


[DNSoD] Reddy, T., Wing, D., and P. Patil, "DNS over DTLS (DNSoD)", Work in Progress, draft-ietf-dprive-dnsodtls-06, April 2016.


[DNSSEC-TRIGGER] NLnet Labs, "Dnssec-Trigger", May 2014, <>.


[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.


[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <>.

[RFC3234]Carpenter,B.和S.Brim,“中间盒:分类和问题”,RFC 3234,DOI 10.17487/RFC3234,2002年2月<>.

[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <>.

[RFC3646]Droms,R.,Ed.“IPv6动态主机配置协议(DHCPv6)的DNS配置选项”,RFC 3646,DOI 10.17487/RFC3646,2003年12月<>.

[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, <>.

[RFC4033]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全介绍和要求”,RFC 4033,DOI 10.17487/RFC4033,2005年3月<>.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <>.

[RFC7258]Farrell,S.和H.Tschofenig,“普遍监控是一种攻击”,BCP 188,RFC 7258,DOI 10.17487/RFC7258,2014年5月<>.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <>.

[RFC7413]Cheng,Y.,Chu,J.,Radhakrishnan,S.,和A.Jain,“TCP快速开放”,RFC 7413,DOI 10.17487/RFC74132014年12月<>.

[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <>.

[RFC7435]Dukhovni,V.,“机会主义安全:大部分时间的一些保护”,RFC 7435,DOI 10.17487/RFC7435,2014年12月<>.

[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <>.

[RFC7626]Bortzmeyer,S.,“DNS隐私注意事项”,RFC 7626,DOI 10.17487/RFC7626,2015年8月<>.

[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <>.

[RFC7828]Wouters,P.,Abley,J.,Dickinson,S.,和R.Bellis,“edns tcp keepalive EDNS0选项”,RFC 7828,DOI 10.17487/RFC78282016年4月<>.

[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <>.

[RFC7830]Mayrhofer,A.,“EDNS(0)填充选项”,RFC 7830,DOI 10.17487/RFC7830,2016年5月<>.

[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, <>.

[TDNS]Zhu,L.,Hu,Z.,Heidemann,J.,Wessels,D.,Mankin,A.,和N.Somaiya,“面向连接的DNS以提高隐私和安全性”,2015年IEEE安全和隐私研讨会(SP),DOI 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-FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-ietf-tls-falsestart-02, May 2016.


Appendix A. Out-of-Band Key-Pinned Privacy Profile Example

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).


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:


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 and 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.


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.


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.




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。



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英国


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
   Phone: +1-213-587-1057

Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States


   Phone: +1-310-448-8323
   Phone: +1-310-448-8323

John Heidemann USC/Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 United States


   Phone: +1-310-822-1511
   Phone: +1-310-822-1511

Allison Mankin Independent


   Phone: +1-301-728-7198
   Phone: +1-301-728-7198

Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States


   Phone: +1-703-948-3200
   Phone: +1-703-948-3200

Paul Hoffman ICANN