A DNS lookup is usually a short exchange
When you visit a website, a DNS resolver may need to ask another DNS server for a record that helps locate it. A typical question and answer are small, so DNS has traditionally used UDP for many of these exchanges. With UDP, the sender can transmit a query without first establishing a connection. That keeps the exchange simple when one question can be answered in one response.
UDP does not guarantee that a packet arrives, arrives only once, or arrives in order. DNS software accounts for this: if a response does not arrive in time, a resolver can retry, sometimes using a different server. Caching also means that many lookups can be answered without contacting an authoritative server each time. UDP is useful here not because delivery is guaranteed, but because a brief request and response often do not need a connection.
Why a resolver may retry over TCP
DNS also supports TCP, commonly on the same port number, 53. TCP establishes a connection and delivers a byte stream reliably and in order. One reason to use it is that a DNS answer may be too large to fit comfortably in a UDP response. This can happen when an answer contains many records or DNSSEC-related data, though not every such lookup requires TCP.
Modern DNS can use an extension called EDNS to advertise a larger UDP response size. That helps, but sending very large UDP packets can cause problems on networks where packets must be fragmented or are filtered. A server can instead send a response marked as truncated. When a resolver sees that indication, it can repeat the question over TCP to obtain the complete answer. A TCP retry after a UDP response is therefore often normal behavior, not evidence that the first query was wrong.
Resolvers may also choose TCP without waiting for a truncated UDP answer. The choice depends on the software and the situation. If you are checking packet captures or firewall logs, do not assume that every TCP connection on port 53 represents an error—or that allowing UDP alone is sufficient for reliable DNS operation.
Some DNS work is designed for TCP
Ordinary lookups are not the only traffic DNS servers handle. A zone transfer, which copies DNS zone data between authorized servers, uses TCP. Unlike a short lookup, a transfer may involve a substantial sequence of records. It also needs appropriate access controls: supporting TCP does not mean a server should let anyone request a copy of its zone.
TCP support matters operationally even if most visible lookups use UDP. A firewall rule that permits UDP port 53 but blocks TCP port 53 may leave simple queries working while larger responses or transfers fail. That can make a problem seem intermittent: one name resolves, while another does not. When investigating, check the path and permissions for both transports rather than treating a successful small lookup as proof that DNS is fully reachable.
What the transport choice does—and does not—tell you
UDP versus TCP describes how a DNS message travels; it does not, by itself, say whether the answer is trustworthy or private. TCP improves delivery of a complete response, but ordinary DNS over TCP is not automatically encrypted. DNSSEC, where deployed and validated, addresses the authenticity of DNS data rather than encrypting the lookup. Encrypted DNS methods are separate arrangements with their own transport details.
For basic troubleshooting, start with the pattern of failure. If small answers work but certain larger answers time out, consider whether truncated responses can be retried over TCP and whether oversized UDP packets are being lost. If both UDP and TCP queries fail, look more broadly at the server address, network path, and DNS configuration. The useful rule of thumb is simple: UDP efficiently handles many short lookups, while TCP provides a dependable way to carry answers and operations that need it.
