3. Establishing and Managing DNS-over-TLS Sessions
3.1 Session Initiation
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 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
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
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 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).
3.4 Connection Reuse, Close, and Reestablishment
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.
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.
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].