DNS Transport over TCP - Operational Requirements
This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Curr
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 11 must, 18 should, 10 may.
1 Introduction
- MUSTIt updates [RFC1123], Section 6.1.3.2 to clarify that all DNS resolvers and recursive servers MUST support and service both TCP and UDP queries and also updates [RFC1536] to remove the misconception that TCP is only useful for zone transfers.
2.1 Uneven Transport Usage and Preference
- MUST| DNS resolvers and recursive servers MUST support UDP, and SHOULD | support TCP, for sending (non-zone-transfer) queries.
- MAY| A name server MAY limit the resources it devotes to TCP queries, | but it SHOULD NOT refuse to service a TCP query just because it | would have succeeded with UDP.
3 DNS-over-TCP Requirements
- MUST| All DNS resolvers and servers MUST support and service both UDP | and TCP queries.
- MUST* DNS servers (including forwarders) MUST support and service TCP for receiving queries so that clients can reliably receive responses that are larger than what either side considers too large for UDP.
- MUST* DNS clients MUST support TCP for sending queries so that they can retry truncated UDP responses as necessary.
- MAY| A name server MAY limit the resources it devotes to queries, but | it MUST NOT refuse to service a query just because it would have | succeeded with another transport protocol.
- MUSTDNS resolver and server operators MUST support and provide DNS service over both UDP and TCP transports.
- MUSTLikewise, network operators MUST allow DNS service over both UDP and TCP transports.
4.1 Connection Establishment and Admission
- MAYFor this reason, clients MAY track and limit the number of TCP connections and connection attempts to a single server.
- MAYMobile clients that cache connection failures MAY do so on a per-network basis or MAY clear such a cache upon change of network.
- MAYAdditionally, DNS clients MAY enforce a short timeout on unestablished connections rather than rely on the host operating system's TCP connection timeout, which is often around 60-120 seconds (i.e., due to an initial retransmission timeout of 1 second, the exponential back-off rules of [RFC6298], and a limit of six retries as is the default in Linux).
- SHOULDServices not intended for use by the public Internet, such as most recursive name servers, SHOULD be protected with access controls.
- MAYPer [RFC7766], applications and administrators are advised to remember that TCP MAY be used before sending any UDP queries.
- MUST NOTNetworks and applications MUST NOT be configured to refuse TCP queries that were not preceded by a UDP query.
- SHOULDDNS servers SHOULD enable TFO when possible.
- SHOULDFurthermore, DNS servers clustered behind a single service address (e.g., anycast or load balancing) SHOULD either use the same TFO server key on all instances or disable TFO for all members of the cluster.
- MAYDNS clients MAY also enable TFO.
4.2 Connection Management
- SHOULDSince host memory for TCP state is a finite resource, DNS clients and servers SHOULD actively manage their connections.
- SHOULDOperators of DNS server software SHOULD be aware that operating system and application vendors MAY impose a limit on the total number of established connections.
- SHOULDOperators SHOULD understand how to increase these limits if necessary and the consequences of doing so.
- SHOULDLimits imposed by the application SHOULD be lower than limits imposed by the operating system so that the application can apply its own policy to connection management, such as closing the oldest idle connections first.
- MAYDNS server software MAY provide a configurable limit on the number of established connections per source IP address or subnet.
- SHOULDOperators SHOULD be aware of these trade-offs and ensure this limit, if configured, is set appropriately based on the number and diversity of their users and whether users connect from unique IP addresses or through a shared Network Address Translator (NAT) [RFC3022].
- SHOULDDNS server software SHOULD provide a configurable timeout for idle TCP connections.
- SHOULDDNS clients and servers SHOULD signal their timeout values using the edns-tcp-keepalive EDNS(0) option [RFC7828].
- MAYDNS server software MAY provide a configurable limit on the number of transactions per TCP connection.
- MAYSimilarly, DNS server software MAY provide a configurable limit on the total duration of a TCP connection.
4.3 Connection Termination
- NOT RECOMMENDEDIn most cases, it is NOT RECOMMENDED to change parameters related to the TIME_WAIT state.
4.5 Defaults and Recommended Limits
- SHOULDOperators SHOULD use application-specific monitoring, system logs, and system monitoring tools to gauge whether their service is operating within or exceeding these limits and adjust accordingly.
6 Logging and Monitoring
- SHOULD NOTDevelopers of applications that log or monitor DNS SHOULD NOT ignore TCP due to the perception that it is rarely used or is hard to process.
- SHOULDOperators SHOULD ensure that their monitoring and logging applications properly capture DNS messages over TCP.
- SHOULDApplications that capture network packets (e.g., with libpcap [libpcap]) SHOULD implement and perform full TCP stream reassembly and analyze the reassembled stream instead of the individual packets.
- SHOULDDevelopers SHOULD also keep in mind connection reuse, query pipelining, and out-of-order responses when building and testing DNS monitoring applications.
10.2 Informative References
- MUSTThe Best Current Practice document [RFC5625] provides DNS proxy implementation guidance including the mandate that a proxy "MUST [...] be prepared to receive and forward queries over TCP" even though it suggests that, historically, TCP transport has not been strictly mandatory in stub resolvers or recursive servers.
- SHOULDThat is, if a response with the TC bit set is received, "[...] the querier SHOULD reissue its query using TCP in order to receive the larger response."
- MUSTThe Best Current Practice document [RFC7720] declares that root name service "MUST support UDP [RFC0768] and TCP [RFC0793] transport of DNS queries and responses."
- MUSTThe Experimental specification [RFC8094] details a protocol that uses a datagram transport (UDP) but stipulates that "DNS clients and servers that implement DNS over DTLS MUST also implement DNS over TLS in order to provide privacy for clients that desire Strict Privacy [...]." This requirement implies DNS over TCP must be supported in case the message size is larger than the path MTU.
- SHOULDThe document points out that the new experimental resource record types are expected to carry large payloads, resulting in the suggestion that "applications SHOULD use TCP -- not UDP -- to perform queries for the SMIMEA resource record."