Starting TLS over DNS

Today, nearly all DNS queries ( and ) 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 ongoing efforts are beginning to identify privacy concerns about DNS (). Prior work has addressed some aspects of DNS security, but none addresses privacy between a DNS client and server using standard protocols. DNS Security Extensions (DNSSEC, ) provide response integrity by defining mechanisms to cryptographically sign zones, allowing end-users (or their first-hop resolver) to verify replies are correct. DNSSEC however does nothing to protect request or 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. More recently, DNSCurve defines a method to provide link-level confidentiality and integrity between DNS clients and servers. However, it does so with a new cryptographic protocol and so does not take advantage of TLS. ConfidentialDNS and IPSECA use opportunistic encryption to provide privacy for DNS queries and responses. However, it is unclear how a client can locate an RR specific to its first-hop resolver. Finally, others have suggested DNS-over-TLS. Recent work suggests DNS-over-TLS (), and the Unbound DNS software includes a DNS-over-TLS implementation. However, neither defines methods to negotiate TLS use over an existing connection; unbound instead requires DNS-over-TLS to run on a different port. The mechanism described in this document enables DNS clients and servers to upgrade an existing DNS-over-TCP connection to a DNS-over-TLS connection. It is analogous to STARTTLS used in SMTP , IMAP and POP . This document defines only the protocol extensions necessary to support TLS negotiation. It does not describe how DNS clients might validate server certificates or specify trusted certificate authorities. Solutions for certificate authentication are outside the scope of this document.

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.

Clients and servers indicate their support for, and desire to use, DNS-over-TLS by setting a bit in the Flags field of the EDNS0 OPT meta-RR. The "TLS OK" (TO) bit is defined as the second bit of the third and fourth bytes of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, immediately adjacent to the "DNSSEC OK" (DO) bit :

DNS clients MAY set the TO bit in queries sent using UDP transport to signal their general ability to support DNS-over-TLS. [For discussion: is this a bad idea because ignorant middleboxes might drop the TO=1 UDP queries?] DNS clients MAY set the TO bit in the initial query sent to a server using TCP transport to signal their desire that the TCP connection be upgraded to TLS. DNS clients MUST NOT set the TO bit on subsequent queries when using TCP or TLS transport (to avoid ambiguity). Since the motivation for DNS-over-TLS is to preserve privacy, DNS clients SHOULD use a query that reveals no private information in the initial TO=1 query to a server. To provide a standard "dummy" query, it is RECOMMENDED to send the initial query with RD=0, QNAME="STARTTLS", QCLASS=CH, and QTYPE=TXT ("STARTTLS/CH/TXT") analogous to administrative queries already in widespread use . After sending the initial TO=1 query using TCP transport, DNS clients MUST wait for the initial response before sending any subsequent queries over the same TCP connection.

A DNS client that receives a response using UDP transport that has the TO bit set MUST handle that response as usual. It MAY record the server's support for DNS-over-TLS and use that information as part of its server selection algorithm in the case where multiple servers are available to service a particular query. [For discussion: UDP is subject to spoofing and a client which depends on TO=1 in a UDP response may be tricked into never upgrading to TLS.] A DNS client that receives a response to its initial query using TCP transport that has the TO bit set MUST immediately initiate a TLS handshake using the procedure described in . A DNS client that receives a response to its initial query using TCP transport that has the TO bit clear MUST not initiate a TLS handshake and SHOULD utilize the existing TCP connection for subsequent queries. DNS clients SHOULD remember server IP addresses that don't support DNS-over-TLS (including TLS handshake failures) and SHOULD NOT request DNS-over-TLS from them for reasonable period. (We suggest 1 hour, or when the client discovers a new resolver.)

A DNS server receiving a query over UDP MUST ignore the TO bit. A DNS server receiving a query over an existing TLS connection MUST ignore the TO bit. A DNS server receiving an initial query over TCP that has the TO bit set MAY inform the client it is willing to establish a TLS session, as described in the next section. A DNS server receiving subsequent queries over TCP MUST ignore the TO bit. (A client wishing to start TLS after the initial query MUST open a new TCP connection to do so.)

A DNS server sending a response over UDP SHOULD set the TO bit to indicate its general support for DNS-over-TLS, as long as it is willing and able to support a TLS connection with the particular client. A DNS server receiving an initial query over TCP that has the TO bit set MAY set the TO bit in its response. The server MUST then proceed with the TLS handshake protocol. A DNS server receiving a "dummy" STARTTLS/CH/TXT query over TCP MUST respond with RCODE=0 and a TXT RR in the Answer section. Contents of the TXT RR are strictly informative (for humans) and MUST NOT be interpreted by the client software. Recommended TXT RDATA values are "STARTTLS" or "NO_TLS".

After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping and normal DNS queries SHOULD take place. Both clients and servers SHOULD follow existing DNS-over-TCP timeout rules, which are often implementation- and situation-dependent. In the absence of any other advice, the RECOMMENDED timeout values are 30 seconds for recursive name servers, 60 seconds for clients of recursive name servers, 10 seconds for authoritative name servers, and 20 seconds for clients of authoritative name servers. Current work in this area may assist DNS-over-TLS clients and servers select useful timeout values . As with current DNS-over-TCP, DNS servers MAY close the connection at any time (e.g., 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. DNS servers SHOULD use the TLS close-notify request to shift TCP TIME-WAIT state to the clients. DNS servers SHOULD enable fast TLS session resumption to avoid keeping per-client session state.

Middleboxes may be present in some networks that interfere with normal DNS resolution and create problems for DNS-over-TLS. A DNS client attempting DNS-over-TLS with a middlebox could have one of the following outcomes (as discussed in prior RFCs ): The DNS client sends a TO=1 query and receives a TO=0 response. In this case there is no upgrade to TLS and DNS resolution occurs normally, without encryption. The DNS client sends a TO=1 query and receives a TO=1 response, but the TLS handshake fails because the server's certificate cannot be authenticated. In this case the client SHOULD close the established connection and fall back to unencrypted DNS for a reasonable period (as discussed in ). The DNS client sends a TO=1 query and receives a TO=1 response, but the middlebox does not understand the TLS negotiation. Middleboxes SHOULD clear TO in replies if they are not prepared to pass through TLS negotiation. Clients SHOULD retry DNS without TO set if negotiation fails, and then retry with TLS after a reasonable period (see ). The DNS client sends a TO=1 query but receives no response at all. The middlebox might be silently dropping the query, despite stating that the "Z" Flags are to be ignored by receivers. The client SHOULD fall back to normal (unencrypted) DNS for a reasonable period (as discussed in ). In general, clients that attempt TLS and fail can either fall back on unencrypted DNS, or wait and retry later, depending on their privacy requirements. [For discussion: should IETF recommend defaulting to postpone and retry instead of non-private operation? This is a policy decision.]

DNS-over-TLS incurs additional latency at session startup. It also requires additional state (memory) increased processing (CPU). Latency: Compared to UDP, DNS-over-TCP requires an additional round-trip-time (RTT) of latency to establish the connection. The TLS handshake adds another two RTTs of latency. Using a single connection for multiple requests amortizes the connection setup costs. Moreover, TLS connection resumption can further reduce the setup delay. State: The use of connection-oriented TCP requires keeping additional state in both kernels and applications. TLS has marginal increases in state over TCP alone. The state requirements are of particular concerns on servers with many clients. Smaller timeout values will reduce the number of concurrent connections, and servers can preemptively close connections when resources limits are exceeded. Processing: Use of TLS encryption algorithms necessarily results in increased CPU usage. Servers can choose to refuse new DNS-over-TCP clients if processing limits are exceeded. 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 a technical report .

This document defines a new bit ("TO") in the Flags field of the EDNS0 OPT meta-RR. At the time of approval of this draft in the standards track, as per the IANA Considerations of RFC 6891, IANA is requested to reserve the second leftmost bit of the flags as the TO bit, immediately adjacent to the DNSSEC DO bit, as shown in .

The goal of this proposal is to address the security risks that arise because DNS queries may be eavesdropped upon, as described above. There are a number of residual risks that may impact this goal. 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; we refer to the TLS RFCs for discussion of these security issues. Any protocol interactions prior to the TLS handshake are performed in the clear and can be modified by a man-in-the-middle attacker. For this reason, clients MAY discard cached information about server capabilities advertised prior to the start of the TLS handshake. As with other uses of STARTTLS-upgrade to TLS, the mechanism specified here is susceptible to downgrade attacks, where a person-in-the-middle prevents a successful TLS upgrade. Keeping track of servers known to support TLS (i.e., "pinning") enables clients to detect downgrade attacks. For servers with no connection history, clients may choose to refuse non-TLS DNS, or they may continue without TLS, depending on their privacy requirements. This document does not propose new ideas for certificate authentication for TLS in the context of DNS. Several external methods are possible, although each has weaknesses. The current Certificate Authority infrastructure is used by HTTP/TLS . With many trusted CAs, this approach has recognized weaknesses . Some work is underway to partially address these concerns (for example, with certificate pinning , but more work is needed. DANE provides mechanisms to root certificate trust with DNSSEC. That use here must be carefully evaluated to address potential issues in trust recursion. For stub-to-recursive resolver use, certificate authentication is sometimes either easy or nearly impossible. If the recursive resolver is manually configured, its certificate can be authenticated when it is configured. If the recursive resolver is automatically configured (such as with DHCP ), it could use DHCP authentication mechanisms ). Ongoing discussion of opportunistic TLS (connections without CA validation, ) may be relevant to DNS-over-TLS.

We would like to thank Stephane Bortzmeyer, Brian Haberman, Paul Hoffman, Kim-Minh Kaplan, Bill Manning, George Michaelson, Eric Osterweil and Glen Wiley for reviewing this Internet-draft.