DNS Transport over TCP - Implementation Requirements
Extracted elements (29)
Response reordering over TCP is explicitly permitted and recommended because recursive resolvers may process queries concurrently in ways that produce out-of-order completions. RFC 1035's reordering text only addressed UDP, leaving TCP ambiguous; this document clarifies that the same principle applies to TCP.
Servers are advised to use short idle timeouts (on the order of seconds) rather than long fixed timeouts because long server timeouts cause resource exhaustion under heavy load and enable trivial TCP DoS attacks by clients leaving idle connections open.
TCP is elevated from a fallback option to a valid alternative transport on equal footing with UDP. Resolvers MAY use TCP before ever trying UDP, which departs from RFC 5966's requirement to send UDP queries first.
TCP was previously treated as an optional fallback for DNS (only for zone transfers or responses exceeding 512 bytes), but the growth of DNSSEC, IPv6, and privacy-focused DNS (e.g., DNS-over-TLS) increased response sizes and the need for TCP, making mandatory TCP support necessary for modern DNS implementations.
Some DNS server implementations may abort a TCP session if the first 'read' from the TCP layer does not contain both the length field and the entire message. This document explicitly forbids such behavior to ensure interoperability.
When DNS-over-TCP is used as a transport for DNS private exchange (e.g., DNS-over-TLS), implementors must be aware of TCP Fast Open and ensure that data requiring protection is not accidentally transmitted in the clear during TFO.
When using TCP Fast Open (TFO) with anycast DNS services, all servers sharing the anycast address must use the same TFO key so that they generate identical Fast Open cookies for a given client IP address; otherwise clients will fall back to the regular three-way handshake.
All general-purpose DNS implementations MUST support both UDP and TCP transport. This updates Section 6.1.3.2 of RFC 1123, making TCP support a required part of a full DNS protocol implementation.
All recursive and authoritative servers MUST send responses using the same transport as the query arrived on; in the case of TCP, this MUST also be the same connection.
Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet.
Both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single persistent TCP connection to amortise connection setup costs.
DNS clients MUST take care to minimise the idle time of established DNS-over-TCP sessions, and SHOULD close the TCP connection of an idle session unless an idle timeout has been established using some other signalling mechanism.
DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that there be no more than one connection for regular queries, one for zone transfers, and one for each protocol on top of TCP.
DNS clients SHOULD pipeline their queries and SHOULD NOT wait for an outstanding reply before sending the next query. DNS servers MUST expect to receive pipelined queries and SHOULD process TCP queries concurrently.
DNS servers MUST NOT close a connection simply because the first 'read' from the TCP layer does not contain the entire DNS message; servers SHOULD apply the connection timeouts as specified in Section 6.2.3.
If a DNS server finds that a DNS client has closed a TCP session before all pending responses have been sent, then the server MUST NOT attempt to send those responses. The server MAY cache those responses.
It is RECOMMENDED that the default server application-level idle period be on the order of seconds. Servers SHOULD reset the idle timeout on the receipt of a full DNS message rather than on receipt of any part of a DNS message to avoid slow-read attacks.
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.
Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields.
Stub and recursive resolvers MUST be able to process responses that arrive in a different order than that in which the requests were sent, regardless of the transport protocol in use.
Stub resolver implementations MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries; TCP MAY be used before sending any UDP queries. If the resolver already has an open TCP connection to the server, it SHOULD reuse this connection.
When sending multiple queries over a TCP connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions.
An idle DNS-over-TCP session is defined differently for clients and servers: a client considers a session idle when it has no pending queries and no outstanding responses; a server considers it idle when it has sent responses to all queries received on that connection.
Query pipelining allows sending multiple DNS queries over a single TCP connection without waiting for outstanding replies. Servers are expected to process pipelined queries concurrently and may return out-of-order responses identified by Message ID matching.
Operators of recursive servers are advised to use Access Control Lists (ACLs) to accept connections only from expected clients. For UDP this guards against reflection attacks (RFC 5358); for TCP it prevents unknown clients from exhausting concurrent connection limits.
Servers should reset idle timeouts only upon receipt of a complete DNS message, not on any partial segment read, to prevent slow-read attacks where an attacker sends data slowly to keep a connection alive and exhaust server resources.
Wider use of DNS over TCP exposes servers to a higher risk of DoS attacks, including intentional connection exhaustion attacks. Servers are advised to engage in TCP connection management, including maintaining connection state, setting idle timeouts, controlling request queues, and limiting connections per source IP/subnet.
Each DNS message sent over TCP is preceded by a two-octet (16-bit) length field that gives the message length in bytes, not including the two-octet length field itself. Clients and servers SHOULD pass the length field and the message to the TCP layer at the same time (e.g., in a single 'write' call) to maximize likelihood of transmission in a single TCP segment.