TCP is a first-class DNS transport
01DNS turns names into records. A resolver is a client that asks a DNS server for those records. Both ends need a working TCP path, not just UDP.
This is a separate exchange: a resolver selects TCP directly and reuses open C1. No prior UDP failure is required.
Source for this drawing: RFC 7766 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Support both transports; keep the reply on its request path.
- All general-purpose DNS implementations MUST support both UDP and TCP. This includes stub resolvers, recursive servers or forwarders, and authoritative servers.
- Stub and recursive resolvers MAY choose TCP before any UDP query. If an open TCP connection to the server exists, the resolver SHOULD reuse it.
- Recursive and authoritative servers MUST reply using the query’s transport; for TCP, they MUST also use the same connection.
TC is the truncated-response flag: the UDP response is incomplete. Section 4 describes retrying over TCP after TC=1; the old 512-byte UDP limit applies without EDNS. EDNS can advertise larger UDP capacity, but does not remove the need for TCP. The TCP handshake is summarized, not animated as DNS data. These are implementation requirements, not a promise every network permits port 53.
Read the RFC section ↗