Understanding RFC5966 for UDP and TCP DNS Load Balancing

View Categories

Understanding RFC5966 for UDP and TCP DNS Load Balancing

6 min read

DNS (Domain Name System) is a critical service that translates human-readable domain names into IP addresses, enabling internet communication. The primary protocol for DNS queries has traditionally been UDP (User Datagram Protocol), but TCP (Transmission Control Protocol) is also a supported option. RFC 5966 provides specifications and clarifications for the use of TCP in DNS to complement UDP. This article delves into RFC 5966, explaining the communication processes between DNS clients and servers and how load balancing can be implemented for both UDP and TCP traffic.

UDP vs. TCP in DNS Communication #

UDP for DNS: The Default Approach #

DNS queries are typically sent over UDP on port 53. UDP is a connectionless, lightweight protocol that excels at sending small packets of data with minimal overhead. A typical DNS request involves a client sending a query to a DNS server, and the server responding with the corresponding IP address.

The reason UDP is the default for DNS is its efficiency:

  • Low Latency: UDP doesn’t require a connection to be established before data transmission, minimizing delay.
  • Stateless Communication: Each request is independent, making it fast and simple.
  • Small Payloads: DNS requests are often very small, and UDP can handle this effectively without congestion.

However, UDP has limitations, notably in terms of reliability. Packets can be lost or arrive out of order. Additionally, DNS responses can exceed the typical UDP size limit (512 bytes for traditional DNS, extended to 4096 bytes with EDNS0), leading to truncation.

TCP for DNS: A Reliable Alternative #

TCP, unlike UDP, is a connection-oriented protocol that provides reliable data transmission by establishing a handshake and guaranteeing packet delivery in sequence. Traditionally, DNS over TCP was reserved for zone transfers between DNS servers (AXFR/IXFR operations) and fallback scenarios when a DNS response was too large for UDP.

DNS-over-UDP vs DNS-over-TCP network schema

RFC 5966 clarifies that DNS servers must support DNS over TCP for all queries, not just for exceptional cases. Key reasons for using TCP in DNS include:

  • Large Responses: DNSSEC (DNS Security Extensions) and other enhancements have led to larger DNS messages. If a response exceeds the UDP size limit, the client switches to TCP to retrieve the complete answer.
  • Reliability: TCP ensures that all packets are received in the correct order, addressing the reliability issues found with UDP.

How DNS Communication Works Over UDP and TCP #

UDP Communication #

  • The client sends a DNS query to the server via UDP.
  • The server processes the query and sends back a response, typically within the 512-byte limit.
  • If the server’s response exceeds this limit and truncation occurs, the client re-sends the query over TCP.

TCP Communication #

  • The client initiates a TCP connection with a three-way handshake.
  • The query is sent, and the server responds with the full DNS answer.
  • The connection is closed after the communication, though persistent connections can be maintained for multiple queries to reduce overhead.

Load Balancing for UDP and TCP in DNS #

Load balancing plays a crucial role in ensuring the reliability, availability, and scalability of DNS services, especially in high-traffic environments. It can distribute DNS requests across multiple servers, optimize resource usage, and improve response times. For DNS traffic, both UDP and TCP load balancing are important, but the methods differ slightly.

Load Balancing UDP DNS Traffic #

Since UDP is stateless, load balancing for UDP involves balancing individual requests without keeping track of connection states. There are several techniques for UDP load balancing:

  • Round-Robin DNS: The DNS resolver randomly distributes queries across multiple DNS servers, providing a simple way to spread traffic.
  • Anycast Routing: With anycast, the same IP address is advertised by multiple DNS servers in different locations. The network routes the client’s query to the nearest server, reducing latency.
  • IP Hashing: Some load balancers use the source IP address to route traffic consistently to the same DNS server. This ensures that the same client is routed to the same server for a certain time period.

Load Balancing TCP DNS Traffic #

Since TCP is connection-oriented, the load balancer must track the state of each connection to ensure that all packets of a session are routed to the same DNS server. Techniques for TCP load balancing include:

  • Session Persistence: Also known as “sticky sessions,” this method ensures that all packets from the same TCP session are routed to the same server. This is critical for maintaining the integrity of the TCP connection.
  • Layer 4 Load Balancing: Load balancers at Layer 4 (Transport Layer) distribute traffic based on IP addresses and TCP/UDP port numbers, ensuring that each connection or session is handled by the same server.
  • Layer 7 Load Balancing: At Layer 7 (Application Layer), the load balancer can inspect the DNS query itself and make intelligent routing decisions based on the content of the query, such as the domain name being requested.

Advantages of Implementing Load Balancing for DNS #

  • Redundancy and Failover: Load balancing ensures that if one server fails, others can take over seamlessly, providing continuous DNS resolution.
  • Scalability: As demand increases, additional servers can be added behind the load balancer without changing the client-side configurations.
  • Geographic Distribution: With anycast routing, DNS servers can be distributed across different geographic locations, allowing clients to reach the closest server for faster resolution.

DNS-over-UDP and DNS-over-TCP Load Balancing Configuration #

To load balance DNS traffic effectively using Relianoid Load Balancer, you can configure two separate farms specifically for DNS-over-UDP and DNS-over-TCP, both on port 53. The DNS-over-UDP farm handles standard DNS queries, which are typically smaller and connectionless, optimizing for speed and lower resource use. Meanwhile, the DNS-over-TCP farm is set up for DNS queries that exceed the typical UDP packet size (512 bytes) or require more reliable delivery, such as zone transfers. By segmenting these farms based on protocol, you ensure efficient handling of each traffic type on port 53, leveraging protocol-specific load distribution while enhancing resilience and reducing bottlenecks.

To do that, create the Farms in the section LSLB > Farms with L4xNAT profile and NAT mode as shown below.

DNS load balacing over UDP and TCP

Conclusion #

RFC 5966 emphasizes the importance of supporting TCP for DNS queries in addition to the traditional UDP-based requests. While UDP remains the primary protocol due to its efficiency, TCP provides reliability for large responses and DNSSEC queries. For DNS services to be scalable and resilient, especially under heavy traffic, implementing load balancing strategies for both UDP and TCP traffic is essential. These load balancing techniques ensure that DNS services remain responsive, secure, and able to handle growing demand.

By understanding and leveraging both protocols alongside proper load balancing, network administrators can build robust DNS infrastructures that meet modern internet demands.

SHARE ON:

Powered by BetterDocs