The Old Rule of Thumb is Dead
If you took a networking certification exam ten years ago, you were taught a very strict rule: "DNS uses UDP on Port 53." TCP on Port 53 was only used for one specific administrative task: Zone Transfers (AXFR) between primary and secondary nameservers.
Because of this outdated dogma, millions of corporate firewalls, cloud security groups, and home routers were configured to explicitly allow UDP/53 while dropping TCP/53 to "reduce the attack surface."
In 2026, this configuration is a ticking time bomb. The DNS landscape has fundamentally shifted. If you block TCP Port 53 today, you will experience intermittent resolution failures, broken email security, and complete DNSSEC validation breakdowns. Here is the technical reality of why DNS absolutely requires both protocols.
The 512-Byte Limit of UDP
The User Datagram Protocol (UDP) is fast. It is a "fire-and-forget" protocol. When a client asks a DNS server for an IP address, it sends a single UDP packet. The server replies with a single UDP packet. There is no handshaking, no connection state to manage, and minimal overhead. For the early internet, this was perfect.
However, standard DNS over UDP had a hardcoded payload limit: 512 bytes.
If a DNS response was smaller than 512 bytes, it fit perfectly into a single UDP packet. But what happens when the response is larger?
When a DNS server attempts to send a response larger than 512 bytes over UDP, it sets the Truncation bit (TC flag) in the header. This flag tells the client: "I have the answer, but it's too big for this UDP packet. Please reconnect to me using TCP."
The client must then drop the UDP packet, initiate a 3-way TCP handshake with the server on Port 53, and request the data again over the stable TCP connection, which handles fragmentation and large payloads seamlessly.
Why DNS Payloads Are Exploding
For decades, the 512-byte limit wasn't an issue. A simple A record response is usually under 100 bytes. However, three major shifts have caused DNS payloads to bloat massively:
1. DNSSEC (Cryptographic Signatures)
As discussed in our DNSSEC guide, securing DNS requires attaching large cryptographic signatures (RRSIG) and public keys (DNSKEY) to the responses. A standard DNSSEC-signed response almost always exceeds 512 bytes. If TCP is blocked, the resolver cannot retrieve the keys, validation fails, and the domain refuses to load.
2. EDNS0 (Extension Mechanisms for DNS)
To delay the shift to TCP, the IETF introduced EDNS0 in 1999. EDNS0 allows clients and servers to negotiate larger UDP payload sizes (often up to 4096 bytes). However, transmitting 4096 bytes over UDP causes IP fragmentation. Many network routers and firewalls blindly drop fragmented UDP packets, assuming they are malicious. When EDNS0 UDP fragmentation fails, the system must immediately fall back to TCP.
3. Massive TXT Records and IPv6
The rise of complex email security policies means domains frequently publish massive DMARC, DKIM, and SPF TXT records. Combine this with dual-stack environments returning both IPv4 (A) and IPv6 (AAAA) records simultaneously, and responses regularly trigger the UDP Truncation bit.
The Shift to DoH and DoT (100% TCP)
The final nail in the UDP coffin is the modern push for privacy. Traditional DNS is unencrypted. To prevent ISPs from snooping on browsing habits, the industry is standardizing on DNS over TLS (DoT) and DNS over HTTPS (DoH).
- DoT uses Port 853.
- DoH uses Port 443 (standard HTTPS).
Both of these protocols are entirely encrypted, and both run exclusively over TCP. As operating systems (like Windows 11, iOS, and Android) default to DoH/DoT where available, the volume of UDP DNS traffic is actively shrinking.
Auditing Your Firewall Configurations
As a network administrator, you must immediately audit your firewall rules (AWS Security Groups, Azure NSGs, iptables, ufw).
Incorrect Configuration:
# Denying TCP will break modern DNS
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j DROP
Correct Configuration:
# Both protocols must be explicitly allowed for authoritative servers
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
When debugging intermittent DNS failures (where some queries work but long TXT queries fail), always check for TCP/53 drops. Use our DNS Lookup Tool to query your domain; our backend utilizes modern TCP fallback to guarantee we retrieve your full, untruncated zone file every time.