TCP vs UDP and Why DNS Uses Both

How UDP and TCP differ

A transport protocol decides how bytes get from one application to another once IP has delivered packets between hosts. Both TCP and UDP use port numbers to identify the application, but they make very different promises. If the layer model is new to you, The OSI and TCP/IP Models shows where transports sit.

Neither protocol is better in general. UDP suits short request and response exchanges where the application can retry on its own. TCP suits bulk transfers and conversations where losing a byte in the middle is not acceptable.

Why DNS starts with UDP

Most DNS exchanges are tiny. A query for an A record is a few dozen bytes, and the answer usually fits in a few hundred. Over UDP the client sends one datagram and gets one back: one round trip, no handshake, and no connection state for the server to track. For a busy recursive resolver answering many thousands of clients, avoiding per-client connection state is a big saving.

Because UDP does not retransmit, the DNS client handles loss itself. A stub resolver or recursive resolver waits for a timeout, then retries the same server or tries another one. Each query carries a 16-bit ID, and modern resolvers also randomize the UDP source port, so a reply is only accepted if it matches both. That randomization is a key defense against forged answers, as described in DNS cache poisoning guidance.

The weakness of UDP is that the source address is not verified. An attacker can send small queries with a forged source address and have large answers delivered to a victim. That is the basis of DNS amplification attacks, and it is one reason operators rate-limit UDP responses.

When DNS switches to TCP

The original specification, RFC 1035, limited DNS messages over UDP to 512 bytes. EDNS(0), defined in RFC 6891, lets a client advertise a larger UDP buffer, but there is still a ceiling. When the answer does not fit, the server sends what it can and sets the TC (truncated) flag. The client is expected to ask again over TCP.

TCP is also used in these cases:

• Zone transfers. AXFR and IXFR copy zone data from a primary to secondary servers and normally run over TCP, because a full zone can be far larger than any datagram.
• Large DNSSEC answers. Signatures and keys add hundreds of bytes per response. DNSKEY queries and answers with many records are common TCP triggers.
• Encrypted transports. DNS over TLS (RFC 7858) uses TLS over TCP. DNS over HTTPS commonly uses HTTP/2 over TCP or HTTP/3 over QUIC/UDP; DNS over QUIC uses dedicated QUIC streams over UDP with its own reliability. See DoH vs DoT vs DoQ.
• Rate limiting. Some servers answer suspected spoofed traffic with small truncated responses. A real client retries over TCP and gets its answer; a spoofed victim never completes a handshake.

Over TCP, each DNS message is prefixed with a two-byte length field, so one connection can carry many queries and answers. You can watch the fallback happen with dig:

$ dig example.net TXT
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.28 <<>> example.net TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51734
;; flags: qr rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 1
...
;; Query time: 38 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (TCP)
;; MSG SIZE  rcvd: 1873

Test TCP reachability of an authoritative server directly:

$ dig +tcp @ns1.example.net example.net SOA +short
ns1.example.net. hostmaster.example.net. 2026101501 7200 3600 1209600 3600

If the first command hangs after the "Truncated" line, or the +tcp query times out while the same query over UDP works, something between you and the server is dropping DNS over TCP. For more on response sizes and buffer settings, read EDNS, Large Responses and TCP Fallback.

What RFC 7766 changed

For years many people treated TCP as a rarely used fallback, and some firewalls and load balancers were configured to allow only UDP 53. RFC 7766, published in 2016, set out the implementation requirements for DNS over TCP and made support for both transports a requirement for general-purpose implementations. Its main points are practical:

• Clients may send queries over TCP even without first getting a truncated UDP answer.
• Clients and servers should reuse connections for several queries instead of opening one connection per query.
• Clients may pipeline queries, sending several before the answers arrive, and servers may answer them out of order, matched by message ID.
• Servers should manage idle connections with timeouts so that open connections do not exhaust resources.

A later document, RFC 9210, adds operational requirements: operators of DNS services are expected to make them reachable over TCP, and network equipment should not block it. The EDNS keepalive option in RFC 7828 lets a server tell clients how long it is willing to hold an idle connection open.

Common mistakes and how they show up

Transport problems rarely break every lookup. They break the large or unusual ones, which makes them look intermittent. These patterns are worth checking first:

When a name works on one network and fails on another, a transport filter on one of the paths is a strong suspect. Why does DNS work on one network but not another? walks through that comparison.

How DNS Panopticon helps

Domain Visualizer and Website Recon resolve records through DNS-over-HTTPS resolvers rather than sending raw UDP or TCP queries from your network. That makes them useful for seeing what the public DNS says about a domain, but a clean result there does not prove that TCP 53 is open on your own servers or firewalls.

Use the tools for the record-level picture, then confirm transport reachability yourself with dig +tcp against each authoritative server from the networks your users are on. If you hold a zone export, Zone Analyzer can filter by record type so you can spot the TXT and other record sets most likely to produce large answers.