UDP or TCP for DNS?

Which transport protocol is most commonly used: UDP or TCP for DNS?
DNS uses both UDP and TCP on port 53. UDP (User Datagram Protocol) is the default transport for most DNS queries because it is fast and connectionless; TCP (Transmission Control Protocol) is used when reliability, ordering, or larger payloads are required — for example when a UDP reply is truncated, for DNSSEC-signed responses, or for zone transfers between authoritative servers.

How DNS normally uses UDP (and why)

When a client issues a DNS query, it typically sends a small packet over UDP to the target server at the DNS port, which is port 53. UDP is a lightweight transport protocol that avoids the overhead of establishing a connection, so the round-trip time is minimal. For the majority of name lookups — a query and a short response carrying address or resource record information — UDP provides the best trade-off between performance and resource usage. Servers and recursive resolvers can handle very high query rates with minimal per-query state because UDP does not require maintaining open connections.

What are the advantages of using UDP for DNS queries?

UDP offers specific operational benefits that make it the preferred first choice for DNS communication and the majority of use cases:

• Low latency: No handshake means a single round-trip for query → response, which helps applications resolve names quickly.
  
• Scalability: Servers do not hold per-client connection state, allowing higher throughput for DNS service.
  
• Efficiency for common sizes: Most DNS responses are small (150 bytes) and easily fit into a single UDP packet, so UDP is an appropriate protocol for typical DNS traffic.
  

The trade-off is that UDP does not guarantee delivery or ordering. When reliability or larger size matters, DNS relies on TCP.

When does DNS use TCP instead of UDP?

DNS switches to TCP in defined situations:

• Truncated UDP replies (TC bit): If a response exceeds the UDP payload capacity, the server sets the truncated bit. The client then retries the same query over TCP to receive the full response.
  
• Zone transfers (AXFR/IXFR): These server-to-server transfers deliver entire DNS zone contents and must be ordered and complete, so they use TCP.
  
• Large DNSSEC responses: When DNSSEC signatures inflate record sizes, TCP is needed to transport the larger packets reliably.
  
• Policy or inspection needs: Some middleboxes or security policies force TCP for inspection, logging, or tunnelling prevention.
  

In short: UDP is the fast path; TCP is the reliable path when the application (DNS) or network conditions require it.

How does DNS switch between UDP and TCP?

The fallback process is simple and deterministic:

A client sends a DNS query over UDP to destination port 53.The server prepares a response. If the response cannot be safely delivered in a single UDP packet (given the negotiated EDNS buffer), it returns a UDP empty reply with the TC (truncated) flag set. The client detects TC=1 and opens a TCP connection to the same server on port 53, resends the query, and receives the full, ordered response. For zone transfer, the entire exchange is negotiated and executed over TCP from the start.

This design preserves UDP’s low-latency benefits while providing TCP as a fallback connection for completeness.

EDNS and UDP packet size limits

EDNS(0) extensions allow a client to advertise a larger UDP buffer than the original 512-byte limit. Common negotiated sizes are 1232 or up to 4096 bytes. EDNS reduces the frequency of TCP fallbacks but increases the risk of IP fragmentation on networks with small MTUs. Operational best practice is to choose a conservative EDNS buffer (for example, 1232 bytes) that reduces unnecessary TCP retries while minimizing fragmentation that can disrupt DNS communication.

The importance of properly handling EDNS settings and buffer sizes was notably highlighted during DNS Flag Day 2020, which emphasized compliance with modern DNS standards and better interoperability between resolvers and authoritative servers.

Why do some DNS servers support both UDP and TCP?

Supporting both transports is required for protocol compliance and robust service:

• The DNS protocol specifies both transports for different needs (speed vs reliability).
  
• DNSSEC and modern records increase packet sizes; without TCP, some clients would never receive full signed responses.
  
• Secondary server transfer and replication require TCP’s reliable, ordered stream semantics.
  
• Network appliances, firewalls, or resolver implementations may prefer TCP for inspection or to support special policy requirements.
  

A server that only supports UDP risks failing to serve complete information to a subset of clients or failing zone replication.

Firewall and network configuration best practices

Network architects should configure firewalls and NAT devices with DNS behavior in mind:

• Permit both UDP and TCP on port 53 between clients, recursive resolvers and authoritative servers where DNS resolution and zone replication are needed.
  
• Expect resolvers to originate queries from ephemeral high-numbered ports while targeting destination port 53; design NAT rules accordingly.
  
• Monitor for TC flags and TCP fallbacks to detect problems with EDNS sizing, fragmentation, or blocked TCP.
  
• Rate-limit DNS traffic on both transports to reduce the impact of amplification attacks and abuse.
  

Encrypted DNS: DoT, DoH, and DoQ — when to consider them

Encrypted DNS transports aim to enhance privacy, integrity, and security between clients and resolvers by encrypting DNS queries and responses. Each protocol, however, operates differently and is suited for specific use cases.

DNS over TLS (DoT) typically uses TCP port 853, providing confidentiality and integrity between client and resolver. It establishes an encrypted channel using TLS, ensuring that DNS traffic cannot be easily intercepted or tampered with.

DNS over HTTPS (DoH) runs over HTTPS/TCP 443, blending DNS traffic into standard web traffic. This makes it harder for intermediaries to distinguish or block DNS requests, though it can complicate enterprise traffic inspection and policy enforcement.

Both DoT and DoH rely on TCP/TLS, complementing classic DNS operations rather than replacing them — for instance, UDP/TCP 53 remains necessary for server-to-server communication, such as zone transfers.

DNS over QUIC (DoQ) introduces a newer encrypted transport that combines TLS 1.3 security with the QUIC protocol’s performance benefits. Running over UDP port 8853, DoQ enables faster connection setup, multiplexing of multiple queries, and greater resilience to packet loss. By eliminating TCP handshakes, it achieves lower latency and improved efficiency while maintaining strong encryption and privacy protection.

Although DoQ adoption is still emerging, it represents the next step in encrypted DNS, offering an ideal balance between security, performance, and modern network compatibility for organizations seeking cutting-edge DNS privacy solutions.

Common troubleshooting and a short case study

Case: An authoritative DNS operator receives reports of intermittent resolution failures. Monitoring shows many UDP replies with TC=1 but few successful TCP retries.
Diagnosis: Firewall or middlebox is blocking TCP/53 or dropping fragmented large UDP packets.
Fix: Ensure authoritative servers accept TCP/53, update firewall rules to allow TCP/53 between resolvers and authoritative servers, and tune EDNS buffer size to reduce fragmentation while maintaining necessary response capacity. This restores reliable delivery of DNSSEC-signed resource records and large responses.

Practical checklist for admins

1. Allow UDP and TCP on port 53 for DNS traffic and zone transfers.
   
2. Monitor TC flags and TCP fallback rates to identify large responses.
   
3. Tune EDNS buffer size (e.g. 1232 bytes) to balance response size and fragmentation risk.
   
4. Ensure authoritative servers are reachable over TCP/53 for zone replication.
   
5. Consider DoT/DoH for privacy-sensitive client-to-resolver links while keeping classic DNS transports available.
   

FAQs concerning UDP or TCP for DNS 

Q — Does using TCP for DNS significantly slow down lookups?
A — TCP introduces a connection handshake, so a TCP-based lookup will often have slightly higher latency than a single UDP exchange. However, TCP is only used when necessary (large responses, DNSSEC, zone transfers), so the performance impact is limited to those cases. Proper caching, tuned EDNS settings, and keeping TCP available mitigate perceived delays.

Q — How can I check if a resolver or server is using TCP for DNS?
A — Use network tools like dig with the +tcp option (e.g. dig @resolver example.com +tcp) to force a TCP query and compare results. Packet captures (tcpdump/ Wireshark) can also show whether responses arrive over UDP or TCP and reveal truncated (TC) flags in UDP replies.

Q — What firewall rules should I apply for DNS?
A — Allow destination port 53 for both UDP and TCP between clients/resolvers and authoritative servers where resolution and zone transfers are required. For outbound queries from clients, permit UDP/TCP to destination port 53; for authoritative zones, ensure TCP/53 is allowed for secondary servers and replication. Also monitor and rate-limit to reduce abuse.

Q — How does DNSSEC affect the choice between UDP and TCP?
A — DNSSEC increases the size of DNS responses (signatures, RRSIGs), which raises the likelihood of truncation over UDP and therefore more TCP fallbacks. Proper EDNS sizing and supporting TCP/53 are essential to reliably serve DNSSEC-signed zones.

Q — Will enabling DoT or DoH remove the need to support UDP/TCP on port 53?
A — No. DoT and DoH provide encrypted client-to-resolver channels (ports 853 and 443) but do not replace classic DNS/53 for resolver-to-authoritative communication. You should support DoT/DoH for privacy where appropriate, while still allowing standard DNS transports for operational tasks.

Q — What monitoring metrics should I track to ensure DNS health?
A — Track UDP vs TCP query ratios, the rate of UDP responses with the TC (truncated) flag, TCP fallback success rates, EDNS buffer negotiation failures, and zone transfer success rates. Alert on spikes in truncation or failed TCP retries—they often indicate firewall issues, fragmentation problems, or misconfigured resolvers.

Q — Can DNS run entirely over TCP if needed?
A — Technically yes — DNS can operate over TCP for queries and transfers — but running all traffic over TCP removes UDP’s performance and scalability benefits. Most deployments use UDP for the fast path and TCP when reliability or larger payloads are required.

Q — How do I troubleshoot clients that never fall back to TCP after truncation?
A — Verify that the client’s network path allows TCP/53 (firewalls, NATs, middleboxes), confirm the resolver behavior (some resolvers may be misconfigured), and inspect for IP fragmentation issues due to oversized UDP packets. For stubborn cases, temporarily lower EDNS buffer size and capture traffic to observe whether TCP retries are attempted and if they are being blocked.

This topic shows that DNS is pragmatic: it uses UDP for speed and efficiency, but retains TCP on port 53 when reliability, order, or larger payloads are required. For resilient DNS service, network teams must treat port 53 as a dual-transport endpoint, tune EDNS and MTU behavior, and monitor both UDP and TCP paths so clients reliably receive the address and resource information they need.