Why DNS Uses UDP and When It Switches to TCP

Every time your browser resolves a hostname, it sends a UDP packet to a DNS resolver on port 53. UDP has no handshake — the packet goes out and a response comes back, usually in under 50 milliseconds. For a simple A-record lookup, that speed matters more than reliability, because if the packet is lost, the client just asks again.

But DNS was designed with a hard constraint: UDP payloads were capped at 512 bytes in the original 1987 RFC 1035. A response that exceeds that limit had to set a flag called TC (Truncated) and instruct the client to retry the query over TCP instead. TCP adds latency — the three-way handshake alone can take 100 milliseconds on a slow network — but it handles arbitrarily large payloads reliably.

The 512-byte ceiling became a problem as DNSSEC was introduced. DNSSEC responses include cryptographic signatures, which easily exceed 512 bytes. In 1999, RFC 2671 introduced EDNS0 (Extension mechanisms for DNS), which lets a client advertise a larger buffer size in its UDP query — typically 4,096 bytes. If both sides support EDNS0, the size ceiling rises and TCP fallbacks become rare for most queries.

Zone transfers are different. When a primary DNS server hands its entire zone database to a secondary server, it always uses TCP (via the AXFR query type) regardless of size. The designers reasoned that zone transfers are large, infrequent, and transactional — exactly the use case TCP was built for.

The 512-byte rule from 1987 shaped 35 years of DNS infrastructure, and residual assumptions about it still appear in firewall rules that block DNS over TCP.