DNS Load Balancing — How It Works and Best Practices

DNS load balancing uses the Domain Name System to distribute traffic across multiple servers. Instead of returning a single IP address for a domain, the DNS server returns multiple IP addresses or different addresses based on the query origin. This spreads the load and improves reliability.

It is the simplest form of load balancing. You do not need a dedicated load balancer appliance. You do not need to configure health checks or session persistence at this level. DNS load balancing is coarse-grained but effective for many use cases.

The main limitation is that DNS resolvers and browsers cache responses. If a server goes down, some users will still be directed to it until their cached DNS entry expires. For situations where quick failover matters, DNS load balancing is best combined with other methods.

Round-Robin DNS

Round-robin DNS is the simplest load balancing method. You create multiple A or AAAA records for the same domain, each pointing to a different server IP. The DNS server rotates the order of these records with each response. The first user gets server A first, the second user gets server B first, and so on.

Most DNS resolvers return the records in the order they receive them. The client typically tries the first IP address in the list. If that connection fails, it tries the next one. This means traffic is distributed roughly evenly across all listed servers.

Round-robin DNS works well for stateless services like web servers serving static content. It is not ideal for stateful applications where users need to stick to the same server for the duration of their session. A user might connect to server A for the initial page load but get server B for the next request if the browser re-resolves the DNS.

The biggest problem is that round-robin does not account for server health. If server A goes down, DNS continues to return its IP address. Clients that receive the down server's address first experience a connection failure before falling back to another server. This delay degrades the user experience.

Weighted DNS Load Balancing

Weighted distribution lets you control how much traffic each server receives. Instead of equal distribution, you assign a weight to each server. A server with weight 10 gets twice the traffic of a server with weight 5. This is useful when your servers have different capacities.

Weighted DNS is typically implemented using SRV records or through DNS provider-specific features. AWS Route 53 supports weighted routing policies. Cloudflare's load balancing supports weights. Most enterprise DNS providers include this as a feature.

Use weighted distribution when you are rolling out new servers or retiring old ones. You can gradually shift traffic to new servers by increasing their weight over time. If the new servers perform well, you increase the weight. If they have problems, you reduce the weight back to zero.

Geographic DNS Load Balancing

Geo DNS routes users to the server closest to their geographic location. The DNS provider determines the user's approximate location based on the resolver's IP address or the client's subnet if EDNS Client Subnet is supported. It then returns the IP address of the nearest server.

This improves performance by reducing latency. A user in London connects to a European server instead of one in the United States. CDNs use this technique extensively. Cloudflare, AWS CloudFront, and Akamai all route traffic based on the user's location.

Geo DNS also helps with regional compliance. If you need to keep European user data on European servers, geo DNS ensures users in the EU are directed to EU-based servers. Non-EU users can be directed to servers in other regions. This satisfies data residency requirements without building separate infrastructure for each region.

For a detailed explanation, see our Geo DNS guide.

DNS Load Balancing with Failover

The best DNS load balancing solutions include health monitoring and automatic failover. The DNS provider continuously checks each server's health by pinging it, connecting to a specific port, or making an HTTP request. If a server fails the health check, the provider stops returning that server's IP address in responses.

This solves the main weakness of basic round-robin DNS. With health monitoring, traffic is only directed to servers that are actually working. When a failed server recovers, it is automatically added back to the rotation.

DNS failover is not instant. Resolvers cache the old DNS response for the duration of the TTL. If your TTL is 300 seconds, it takes up to 5 minutes for all resolvers to stop using the failed server's IP. Some resolvers ignore TTL and cache for longer. DNS failover alone is not sufficient for applications that need sub-minute recovery times.

For faster failover, combine DNS load balancing with application-level load balancing. Use DNS for global traffic distribution and a hardware or software load balancer for local traffic management. The DNS layer handles regional routing. The load balancer handles server-level distribution within each region. For more on failover strategies, see our DNS failover guide.

Best Practices for DNS Load Balancing

Use short TTLs. If you are using DNS for load balancing, a TTL of 60 to 300 seconds is appropriate. Short TTLs allow you to react quickly to server failures and traffic changes. The trade-off is more DNS queries, which increases load on your nameservers.

Do not rely solely on DNS for critical traffic management. DNS is slow to change compared to application-level load balancing. Use DNS for coarse routing and a dedicated load balancer for fine-grained traffic distribution.

Monitor your DNS traffic patterns. A sudden increase in DNS queries for a specific domain could indicate a DDoS attack or a configuration error. Most DNS providers offer analytics that show query volumes, top queried records, and geographic distribution of queries.

Test your failover scenarios regularly. Take a server offline and verify that traffic shifts to the remaining servers. Measure how long it takes for the first client to be redirected after the failure. Document the expected recovery time and set up alerts for when it exceeds that threshold.