DNS Transport over TCP - Implementation Requirements
Extracted elements (20)
DNSSEC deployments have made 512-byte truncation commonplace; for example, NXDOMAIN responses from NSEC3-signed zones are almost invariably larger than 512 bytes. This is the primary technical driver for mandating TCP support.
RFC 1035's two-minute idle timeout recommendation for TCP connections is replaced with a default on the order of seconds because experience with HTTP and other protocols has shown that long timeouts cause resource exhaustion under heavy load and can trivially enable denial-of-service attacks.
The RFC 1123 MUST-send-UDP-first rule is relaxed to SHOULD because a resolver with an existing open TCP connection to a server has good operational reasons to reuse it rather than opening a new UDP exchange that may be truncated.
UDP packets exceeding path MTU cause IP fragmentation, which is unreliable: many firewalls block fragmented packets, some devices refuse EDNS0 options entirely, making TCP the only robust mechanism for large DNS responses.
RFC 1035 Section 4.2.1 addressed response reordering only in the context of UDP. This document clarifies that the same reordering requirement applies over TCP: resolvers must not assume responses arrive in request order on any transport.
This document updates RFC 1035 and RFC 1123. It supersedes the text in RFC 1123 Section 6.1.3.2 that allowed TCP to be treated as optional, making TCP support a REQUIRED part of a full DNS protocol implementation.
A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect truncation or for other operational reasons, in particular if it already has an open TCP connection to the server. This relaxes the prior RFC 1123 MUST-send-UDP-first requirement.
All general-purpose DNS implementations MUST support both UDP and TCP transport. This applies to authoritative servers, recursive servers/forwarders, and stub resolvers alike.
Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet.
Client resolvers MUST be able to process responses that arrive in a different order from that in which the requests were sent, regardless of the transport protocol in use.
DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server, to mitigate the risk of unintentional server overload.
Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients.
Servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client.
Stub resolver implementations MAY omit TCP support only when specifically designed for deployment in restricted environments where truncation can never occur or where truncated DNS responses are acceptable.
Stub resolver implementations MUST support TCP since to do otherwise would limit their interoperability with their own clients and with upstream servers.
The default application-level idle period for TCP connections is RECOMMENDED to be on the order of seconds; no particular value is specified. Servers MAY allow dormant connections to remain open longer as resources permit.
EDNS0 (RFC 2671) allows clients to advertise a UDP receive buffer size larger than 512 bytes, enabling servers to send larger UDP responses without truncation. However, UDP fragmentation caused by exceeding path MTU has been found unreliable.
The TC (truncation) flag in the DNS response header signals that the server had to truncate the response to fit within the 512-byte UDP limit. A client receiving a response with TC set should retry the query over TCP.
Operators of recursive servers should ensure they only accept TCP (and UDP) connections from expected clients and not from unknown sources, to prevent reflector attacks (RFC 5358) over UDP and connection-exhaustion attacks over TCP.
Wider use of DNS over TCP exposes servers to higher risk of denial-of-service attacks via connection exhaustion. However, DoS mitigation techniques at the network level have improved substantially since DNS was first designed, and TCP-based DoS attacks against existing DNS infrastructure are not known to be commonplace.