DNS-Based Load Balancer

In the previous page, we saw the client-side load balancer, where the client picks the server itself. In this page, we split traffic even earlier: at the moment a user looks up our domain name. This is the DNS-based load balancer.

Definition

DNS (Domain Name System) is the system that turns a name like sl.io into an IP address like 203.0.113.10. Computers talk using IP addresses, not names.

Analogy: DNS is a phone book. You look up a name and get a number.

A DNS-based load balancer uses this lookup to share traffic. For one name, DNS gives different server addresses to different users. No machine sits in the middle of the request.

1User A asks: "Where is sl.io?"  → DNS answers 203.0.113.10 (Server 1)
2User B asks: "Where is sl.io?"  → DNS answers 203.0.113.11 (Server 2)
3User C asks: "Where is sl.io?"  → DNS answers 203.0.113.12 (Server 3)

Let's follow one lookup to see how it works.

How It Works

The site owner adds several records for one name. Each record points to one server.

1sl.io   →   203.0.113.10
2sl.io   →   203.0.113.11
3sl.io   →   203.0.113.12

When a user opens sl.io, this happens:

11. Browser asks DNS          "What is the address of sl.io?"
22. DNS replies               a list of addresses, in a rotated order
33. Browser takes the first   203.0.113.11
44. Browser → Server 2        sends the request directly

DNS rotates the order of the list for each lookup. So different users get a different address first. This simple method is called round robin DNS.

Here is how any program can see the list:

import java.net.InetAddress;

public class DnsLookup {
    public static void main(String[] args) throws Exception {
        InetAddress[] addresses = InetAddress.getAllByName("sl.io");
        for (InetAddress address : addresses) {
            System.out.println(address.getHostAddress());
        }
    }
}

After the lookup, DNS is out of the picture. The user talks directly to the server.

One more thing matters here. Answers are cached, which means saved for reuse, so DNS is not asked again and again.

Caching and TTL

Every DNS answer has a TTL (Time To Live). It tells everyone how many seconds they may reuse the answer before asking again.

Here is what breaks. Server 2 crashes, but users already saved its address.

1TTL = 300 seconds (5 minutes)
2 
310:00  User looks up sl.io → gets Server 2's address, saves it
410:01  Server 2 crashes
510:01  DNS owner removes Server 2 from the list
610:01 - 10:05  User still uses the saved address → errors ✗

DNS has no way to tell the user "that address is dead, forget it." The user keeps trying until the TTL runs out.

We can choose a short or a long TTL:

A short TTL helps, but it never fully fixes the problem. Some systems keep answers longer than the TTL says.

Next, let's make DNS a bit smarter.

Smarter DNS Balancing

Plain round robin DNS is blind. It hands out all addresses, even dead ones. Modern DNS services add more rules:

• Health checks. The DNS service tests each server. If one fails, it stops returning that address.
• Weighted answers. Give a strong server a bigger share of the answers, like weighted round robin.
• Location-based answers. Return the server closest to the user. We cover this in the global load balancer page.

1Health-checked DNS:
2Server 1 healthy → returned
3Server 2 failed  → removed from answers ✓
4Server 3 healthy → returned

Even with health checks, cached answers can still point to the dead server until the TTL ends. So DNS failover is always a bit slow.

Now let's compare this with the types we already know.

DNS-Based vs. Other Load Balancers

Advantages

• Very simple. Add a few records. No new machine to build.
• Cheap. Most DNS services cost very little.
• No extra hop. After the lookup, users go straight to the server.
• Works with anything. Every browser, phone, and program already uses DNS.
• Can balance across locations. Addresses can point to servers in different data centers.

Limitations

1. Slow failover. Caching means users can reach a dead server until the TTL ends.

2. Uneven load. Many users share one DNS resolver, such as one at a big internet provider. If it saves one address, thousands of users go to the same server.

1Big ISP's DNS saves Server 1's address.
250,000 users behind it → all go to Server 1 ✗
3Servers 2 and 3 are almost idle.

3. Blind to load. DNS does not know how busy a server is. It cannot do least connections.

4. No control after the lookup. DNS cannot retry, limit traffic, or read the URL.

5. Hard to predict. You do not control caches, so exact traffic shares are only a guess.

When to choose it:

• To spread traffic across a few entry points, such as several load balancers or data centers.
• When you need a cheap, simple start.

When to avoid it alone:

• When you need fast failover or fine control. Put a server-side load balancer behind it instead.

In real systems, DNS is usually the first layer:

1Client → DNS → Load Balancer 1 → App Servers
2              → Load Balancer 2 → App Servers

DNS picks a load balancer. The load balancer picks the server, and it handles health checks and fast failover.

Summary

1DNS-based load balancer → DNS gives different server addresses to different users
2→ Round robin DNS rotates the list of addresses
3→ Answers are cached for the TTL, so failover is slow
4→ Health checks and weights make DNS smarter, but caching remains
5→ Advantages: simple, cheap, no extra hop, works with every client
6→ Limits: slow failover, uneven load, blind to server load
7→ Best for: spreading traffic across a few entry points, used before a server-side load balancer

DNS can already choose between servers, but what if those servers sit in different countries? Sending users to the nearest