What is DNS load balancing?

DNS load balancing is a way of spreading traffic across several servers by publishing more than one IP address for the same hostname, or by varying which address the DNS server returns to each query. When clients look up www.example.com, they receive different answers, or the same answers in a different order, so their connections land on different servers. The simplest form is round-robin DNS, where you add several A or AAAA records with the same name; more advanced forms use weights, health checks and multiple answers chosen by a managed DNS provider.

It's cheap, needs no extra hardware, and works for any protocol that uses DNS, which makes it a popular first step towards running more than one server. But it distributes users rather than requests, it can't see how busy each server is, and caching blurs its decisions. In this article you'll learn how DNS load balancing works, the main methods, how clients actually pick an address, where it falls short compared with a dedicated load balancer, and how to set it up in a zone file, BIND and Amazon Route 53.

How DNS Load Balancing Works

A normal DNS record maps one name to one address. With DNS load balancing, a single name maps to a set of addresses, and the authoritative server decides which ones to hand out and in what order.

Round-Robin DNS

Round robin is just multiple records of the same type for the same name:

www.example.com.  300  IN  A  192.0.2.10
www.example.com.  300  IN  A  192.0.2.11
www.example.com.  300  IN  A  192.0.2.12

When you query it, you get all three records back. Many authoritative servers and resolvers rotate the order between responses, so the first address changes from one lookup to the next:

$ dig www.example.com A +short
192.0.2.11
192.0.2.12
192.0.2.10

$ dig www.example.com A +short
192.0.2.12
192.0.2.10
192.0.2.11

Because many clients try the first address in the list, rotating the order spreads new connections roughly evenly across the servers over time.

What Clients Actually Do with Multiple Addresses

The DNS server only controls what it returns. The client decides which address to use, and behaviour varies:

• Many clients take the first usable address and only try the next one if the connection fails.
• Operating systems may re-sort the list. Address selection rules (RFC 6724) can reorder addresses, for example to prefer IPv6 over IPv4 or addresses that share a longer prefix with the client's own address. This can undo the server's rotation.
• Modern browsers use Happy Eyeballs, which races IPv6 and IPv4 connection attempts and falls back between addresses quickly when one is slow.
• Resolvers cache the whole set, and some of them rotate the order themselves when answering clients from cache.

So round robin gives you an approximate, statistical spread, not an exact split. Over thousands of users it usually evens out reasonably well. Over a handful of large clients, such as a few corporate networks behind one resolver each, it can be very uneven.

Methods of DNS Load Balancing

Beyond plain round robin, managed DNS providers offer smarter ways to choose answers.

Method	How it works	Good for
Round robin	All records returned, order rotated	Simple setups with identical servers
Weighted	Each record gets a weight; answers are chosen in proportion	Unequal servers, canary releases, gradual migrations
Multivalue with health checks	Returns several healthy records, drops failed ones	Round robin that avoids dead servers
Geographic or latency-based	Answer depends on the user's location or network latency	Multi-region deployments
SRV records	Priority and weight fields tell the client how to choose	Protocols that support SRV, such as SIP and XMPP

Weighted Records

Weighted routing lets you send, say, 90% of lookups to your existing servers and 10% to a new cluster. The DNS server picks an answer for each query with probability proportional to its weight. Route 53, Cloudflare (through its load balancing product), NS1, Azure Traffic Manager and Google Cloud DNS all offer some form of weighted routing.

Weights apply to DNS responses, not to traffic. One response might be cached by a resolver serving a large office, sending hundreds of users to the same server, so treat the percentages as a rough guide.

Health-Checked Answers

Plain round robin has no idea whether a server is up. If one of three servers dies, roughly a third of new visitors get its address first, and they either wait for a timeout or rely on their client to try the next address.

Managed providers solve this with health checks. The provider probes each endpoint over HTTP, HTTPS or TCP from several locations, and stops including failed endpoints in its answers. Route 53 calls this a multivalue answer policy when combined with up to eight healthy records per response. The detailed mechanics of removing a dead endpoint and switching to a backup are a topic of their own, usually called DNS failover.

SRV Records

Some protocols look up SRV records, which have built-in load-balancing fields:

_sip._tcp.example.com.  300  IN  SRV  10 60 5060 sip1.example.com.
_sip._tcp.example.com.  300  IN  SRV  10 40 5060 sip2.example.com.
_sip._tcp.example.com.  300  IN  SRV  20 0  5060 sip-backup.example.com.

The fields after SRV are priority, weight, port and target. Clients use the lowest priority first and, within that priority, pick targets in proportion to their weights. Here, sip1 gets about 60% and sip2 about 40% of new connections, and sip-backup is only used if both are unavailable. Web browsers don't use SRV records for HTTP, so this only helps for protocols that support them.

DNS Load Balancing vs a Dedicated Load Balancer

DNS load balancing and a dedicated load balancer, such as HAProxy, NGINX, an AWS Application Load Balancer or a cloud provider's equivalent, work at different layers.

	DNS load balancing	Dedicated load balancer
Decision point	Once per DNS lookup, then cached	Every connection or request
Awareness of server load	None (only health, if checks are configured)	Can use connection counts, response times, and more
Failover speed	Limited by TTLs and client caching	Seconds, invisible to clients
Session persistence	None, beyond what caching happens to give	Cookies, source IP hashing, and so on
Single point of failure	No extra component	The load balancer itself must be redundant
Cost and complexity	Very low	Higher
Works across regions	Yes, naturally	Usually within one region, unless global

In practice, many architectures use both. DNS spreads users across regions or across several load balancers, and each load balancer spreads requests across the servers behind it. Cloud load balancers often publish several IP addresses under one hostname themselves, which is DNS load balancing applied to the load balancer.

The Limits of DNS Load Balancing

Caching Makes Decisions Sticky

Every answer is cached by resolvers for its TTL, and often by operating systems and browsers too. With a TTL of 3600 seconds, a resolver serving thousands of users keeps handing out the same set for an hour. Short TTLs, between 30 and 300 seconds, make the balance more responsive at the cost of more DNS queries.

Some clients and resolvers also impose their own minimum cache times or keep using an address for as long as a connection stays open. Long-lived connections, such as WebSockets or HTTP/2 connections that browsers reuse, stay on the same server regardless of TTL.

No Knowledge of Server Load

DNS doesn't know that one server is at 95% CPU while another is idle. If your servers have different capacities, use weights. If load varies a lot from minute to minute, a dedicated load balancer is a better fit.

Uneven Resolver Populations

A single large resolver can represent thousands of users. If it caches an answer that favours one server, that server takes a disproportionate share. This is especially noticeable with large ISP resolvers and corporate networks.

Large Responses

Each extra record makes the response bigger. A handful of A records is fine, but very large sets can push responses over the UDP size that resolvers advertise, forcing a retry over TCP. Most providers cap the number of records they return per response for this reason. Returning a subset of four to eight healthy addresses is usually plenty.

How to Set Up DNS Load Balancing

In a Zone File

The simplest setup is to add multiple records at your DNS provider or in your zone file. Include both IPv4 and IPv6 if your servers support it:

$TTL 300
www   IN  A     192.0.2.10
www   IN  A     192.0.2.11
www   IN  AAAA  2001:db8::10
www   IN  AAAA  2001:db8::11

In a provider's dashboard, this means creating several A records with the same name, one per address. Some dashboards show them as a single record with multiple values.

Controlling Order in BIND

By default, BIND varies the order of records in its responses rather than always returning them the same way. You can control this explicitly with rrset-order in named.conf:

options {
    rrset-order {
        name "www.example.com" order cyclic;
        order random;
    };
};

The options are fixed, random, cyclic and none, although support for fixed depends on how BIND was built. Remember that resolvers and client operating systems may reorder records anyway, so this only controls the first hop.

Weighted Routing in Route 53

In Route 53, weighted records share the same name and type but have different set identifiers and weights. This AWS CLI change batch sends roughly 80% of lookups to one server and 20% to another:

{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "blue",
        "Weight": 80,
        "TTL": 60,
        "ResourceRecords": [{ "Value": "192.0.2.10" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "green",
        "Weight": 20,
        "TTL": 60,
        "ResourceRecords": [{ "Value": "198.51.100.10" }]
      }
    }
  ]
}

Apply it with:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch file://weighted.json

Setting a weight to 0 stops that record being returned, unless every record in the set has a weight of 0. That makes weighted routing a handy way to drain a server before maintenance or to shift traffic gradually from an old platform to a new one.

The Same Thing in Terraform

resource "aws_route53_record" "www_blue" {
  zone_id        = var.zone_id
  name           = "www.example.com"
  type           = "A"
  ttl            = 60
  records        = ["192.0.2.10"]
  set_identifier = "blue"

  weighted_routing_policy {
    weight = 80
  }
}

resource "aws_route53_record" "www_green" {
  zone_id        = var.zone_id
  name           = "www.example.com"
  type           = "A"
  ttl            = 60
  records        = ["198.51.100.10"]
  set_identifier = "green"

  weighted_routing_policy {
    weight = 20
  }
}

Measuring the Distribution

To see what a DNS server actually hands out, query it many times and count which address comes first. This short Python script uses the dnspython library (pip install dnspython):

from collections import Counter

import dns.resolver

resolver = dns.resolver.Resolver(configure=False)
resolver.nameservers = ["192.0.2.53"]  # your authoritative server
resolver.cache = None

counts = Counter()
for _ in range(500):
    answer = resolver.resolve("www.example.com", "A")
    counts[answer[0].address] += 1

for address, hits in counts.most_common():
    print(f"{address:15} {hits:4} {hits / 5:.1f}%")

Run it against your authoritative nameserver directly, not a caching resolver, otherwise you'll mostly see the same cached answer. Sample output for the weighted example above:

192.0.2.10       401 80.2%
198.51.100.10     99 19.8%

What you see here is the DNS split. The real traffic split also depends on caching and client behaviour, so check your server access logs or monitoring too.

When DNS Load Balancing Is a Good Fit

DNS load balancing works well when:

• Your servers are stateless or share sessions through a database or cache, so it doesn't matter which one a user reaches.
• You need to spread users across regions or providers, where a single load balancer can't sit in front of everything.
• You want a low-cost way to add capacity without introducing a new component.
• You're migrating gradually, shifting a percentage of users to new infrastructure.

It's a poor fit when you need precise request-level balancing, fast and invisible failover, or sticky sessions. For those, put a proper load balancer behind the DNS name and let DNS do the coarse work.

---

FAQ: DNS Load Balancing

---

Conclusion

DNS load balancing spreads traffic by giving one hostname several addresses and letting the DNS server vary which ones it returns. Round robin is the simplest version, while weighted, multivalue and location-based policies from managed providers add control and health awareness. It needs no extra infrastructure and works across regions and providers, which is why it underpins so many larger architectures.

Its weaknesses all come from the same place: decisions happen once per lookup and are then cached, and DNS can't see how busy your servers are. Keep TTLs short, add health checks, use weights for unequal servers, and pair DNS with a dedicated load balancer when you need request-level control. Used that way, DNS becomes a reliable first layer of traffic distribution.