DNS Transport over TCP - Implementation Requirements
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.
This document is current and has been amended. 2 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 18 must, 20 should, 6 may.
1 Introduction
- MUSTDNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.
- REQUIREDThis document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation.
5 Transport Protocol Selection
- MUSTSection 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.
- MUSTo Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet.
- MUSTo 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.
- MUSTo Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
- MUSTa DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.
- MAYStub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons.
- MAYTCP MAY be used before sending any UDP queries.
- SHOULDIf the resolver already has an open TCP connection to the server, it SHOULD reuse this connection.
- MUSTIn addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on.
- MUSTIn the case of TCP, this MUST also be the same connection.
6.2.1 Connection Reuse
- SHOULDTo amortise connection setup costs, both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single persistent TCP connection.
- MUST NOTWhen 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.
6.2.1.1 Query Pipelining
- SHOULDIn order to achieve performance on par with UDP, DNS clients SHOULD pipeline their queries.
- SHOULD NOTWhen a DNS client sends multiple queries to a server, it SHOULD NOT wait for an outstanding reply before sending the next query.
- SHOULDClients SHOULD treat TCP and UDP equivalently when considering the time at which to send a particular query.
- MUSTDNS servers (especially recursive) MUST expect to receive pipelined queries.
- SHOULDThe server SHOULD process TCP queries concurrently, just as it would for UDP.
- SHOULDThe server SHOULD answer all pipelined queries, even if they are received in quick succession.
6.2.2 Concurrent Connections
- MUSTTo mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server.
- RECOMMENDEDIt is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top of TCP (for example, if the resolver was using TLS).
- MAYSimilarly, servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client IP address or subnet.
- SHOULDThese limits SHOULD be much looser than the client guidelines above, because the server does not know, for example, if a client IP address belongs to a single client, is multiple resolvers on a single machine, or is multiple clients behind a device performing Network Address Translation (NAT).
6.2.3 Idle Timeouts
- MUSTTo mitigate the risk of unintentional server overload, DNS clients MUST take care to minimise the idle time of established DNS-over-TCP sessions made to any individual server.
- SHOULDDNS clients SHOULD close the TCP connection of an idle session, unless an idle timeout has been established using some other signalling mechanism, for example, [edns-tcp-keepalive].
- RECOMMENDEDTo mitigate the risk of unintentional server overload, it is RECOMMENDED that the default server application-level idle period be on the order of seconds, but no particular value is specified.
- MAYIn practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit.
- MAYServers MAY use zero timeouts when they are experiencing heavy load or are under attack.
- SHOULDFor this reason, 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.
6.2.4 Teardown
- SHOULDDNS clients SHOULD retry unanswered queries if the connection closes before receiving all outstanding responses.
- MUST NOTIf a DNS server finds that a DNS client has closed a TCP session (or if the session has been otherwise interrupted) before all pending responses have been sent, then the server MUST NOT attempt to send those responses.
- MAYOf course, the DNS server MAY cache those responses.
7 Response Reordering
- RECOMMENDEDAuthoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use.
- MUSTStub 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.
- SHOULDIn order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order.
- MUSTSince pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID.
- MUSTIf the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields.
8 TCP Message Length Field
- SHOULDDNS 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.
- MUST NOTTo clarify, DNS servers MUST NOT close a connection simply because the first "read" from the TCP layer does not contain the entire DNS message, and servers SHOULD apply the connection timeouts as specified in Section 6.2.3.
11.2 Informative References
- SHOULDSection 6.2.1 adds a new recommendation that TCP connection reuse SHOULD be supported.
- SHOULDSection 6.2.1.1 adds a new recommendation that DNS clients SHOULD pipeline their queries and DNS servers SHOULD process pipelined queries concurrently.
- SHOULDSection 6.2.3 adds a new recommendation that DNS clients SHOULD close idle sessions unless using a signalling mechanism.
- RECOMMENDEDSection 7 clarifies that servers are RECOMMENDED to prepare TCP responses in parallel and send answers out of order.