Load Balancing Without a Load Balancer
What if I told you that you could distribute traffic across multiple servers without buying or configuring a single ? Just using DNS?
Here's how it works: instead of a single A record pointing to one IP, you create multiple A records for the same domain, each pointing to a different server.
api.example.com A 10.0.0.1
api.example.com A 10.0.0.2
api.example.com A 10.0.0.3
When a client resolves api.example.com, the server returns all three IPs. The client (usually the browser or OS) picks one, typically the first in the list. The DNS server rotates the order with each query (Round Robin), so different clients get different "first" IPs.
This is DNS load balancing, and it's been around since the early days of the internet. It's dead simple, requires zero infrastructure beyond a DNS provider, and works at a global scale.
GitHub uses it. AWS uses it for their own services. It's often the first layer of traffic distribution before requests even reach your actual load balancers.
DNS Round Robin in Action
Before going further, it is worth being precise about what makes this different from every other balancer in this chapter.
A proxy sees every packet and can act on every request. A server answers one question, once, and the client then connects directly to whatever it was told.
That one structural fact produces every advantage and every limitation in this lesson.
Nothing in the protocol says a client must use the first address. Most do, some sort them, and browsers do something more complicated.
So the distribution you get is the sum of every client's own behaviour, which is the difference between this and every other balancer: a decides, and a DNS server suggests.
That is all visible from any machine, on real domains, in about ten seconds.
The rotation in the first block is the load balancing, and it works only because most clients take the first entry.
The column is the second lesson. It counts down as a cached record ages and it jumps back up, because a public resolver is an anycast pool. "DNS is cached" really means "some cache answered", and which one is not under anybody's control.
The first two are load balancing. The other two are how the decision gets moved somewhere else.
Querying a name twice tells you most of this, and it is a genuinely useful reflex when debugging why users in one region reach the wrong data centre.