Global Server Load Balancing (GSLB): DNS-Based Site Selection

01 /How DNS-based GSLB works

Every connection begins with a name lookup. If the authoritative answer for www.example.com can vary per query, it can point each client at the data centre best placed to serve it. A GSLB device is an authoritative DNS server, or a proxy in front of one, that orders the A and AAAA records it returns based on live measurements of each site.

Each site runs its own local server load balancer with a VIP. GSLB decides which VIP to advertise; local SLB decides which real server behind it takes the connection. The ServerIron generation could do both on one box.

02 /The authoritative DNS proxy model

There are two ways into the resolution path. The first makes the GSLB device the authoritative server for the zone. The second, which the original Foundry GSLB application note described for the ServerIron, is the proxy model: the existing authoritative servers stay in place, the GSLB device fronts them on a VIP and inspects each response on the way out. When a response contains addresses of sites it monitors, it reorders them so the preferred site comes first.

03 /Site selection metrics

The device evaluates a chain of metrics per query and stops at the first that yields a single winner. The order is configurable; a typical chain runs health, then proximity or RTT, then load, then a tie-breaker.

04 /TTL trade-offs and DNS caching

GSLB only works if resolvers come back and ask again; the TTL on the returned record controls that. A short TTL (30 to 60 seconds) drains a failed site within a minute, at the price of many more queries and slightly higher latency on first connections. A long TTL is cheap but pins clients to a dead site until it expires.

Real caching is worse than the TTL implies. Some resolvers clamp low TTLs to a floor. Browsers and operating systems keep their own caches. Some runtimes resolve a name once at start-up and never again. Plan for a tail of clients arriving at the old site long after expiry, and keep the old VIP answering or redirecting for them.

05 /Worked example: global server load balancing across two sites

Illustrative values. Site A advertises VIP 192.0.2.10, site B 198.51.100.10, both on TCP 443. The GSLB device is authoritative for www.example.com, checks each VIP over HTTPS every 10 seconds, marks a site down after 3 failures, and answers with a TTL of 30 seconds. The metric chain is health, then round-trip time, then least connections. Local balancers check their real servers every 5 seconds, so a single server restart is absorbed locally before the site check notices.

$ dig www.example.com @ns1.example.com | grep -E 'IN\s+A'
www.example.com.   30   IN   A   192.0.2.10
# site A VIP stops answering at 09:00:00; third failed check at 09:00:30
gslb1# show gslb site
site A  vip 192.0.2.10    state DOWN   fails 3/3   last 09:00:30
site B  vip 198.51.100.10 state UP     rtt 41ms   conns 812
$ dig +short www.example.com @ns1.example.com
198.51.100.10

Add the timers from the client's side. Detection takes 30 seconds. A resolver that cached the old answer at 08:59:59 keeps it until 09:00:29, so the first client behind it sees the new VIP between 09:00:30 and 09:01:00; clients with their own operating system or browser cache keep trying site A for longer. The honest failover figure is about a minute for most users and several minutes for the tail, so site A's VIP should keep answering with a redirect during that tail.

RFC 8767 adds a further delay: a resolver may keep serving an expired record while it cannot reach any authoritative server, with a suggested retention of 1 to 3 days, so a GSLB device that is itself unreachable does not drain a dead site at all.

06 /Anycast versus GSLB

IP anycast announces the same prefix from several sites and lets BGP route each client to the topologically nearest one. It needs no DNS tricks and reacts to site failure at routing-convergence speed. It suits stateless, short-transaction services such as DNS itself, and long-lived TCP sessions poorly, because a mid-session route change lands the client on a site with no record of the connection. GSLB reacts more slowly but keeps each session on one site and can weigh load and health, not just topology. Many deployments run anycast for DNS and GSLB for the application; see core routing.

07 /Round-robin DNS, GSLB and anycast compared

Anycast has one prerequisite the others lack: every site announces the same prefix and every network in between must accept it. Publishing route origin authorisations for the anycast prefix is what stops a mis-origination elsewhere from silently absorbing part of the client base.

08 /Active/active versus active/DR sites

In an active/active design every site serves traffic and GSLB spreads clients by proximity or load. It uses all the hardware and proves every site daily, but the application must tolerate users split across sites, which usually means replicated state. In an active/DR design GSLB returns only the primary site while healthy and switches every answer to the standby when checks fail. It is simpler and the standby can be smaller, but the failover path runs only during incidents, so test it on a schedule.

09 /How GSLB and local SLB fit together

GSLB health checks target the site VIP; when the local balancer marks every real server down, the VIP fails and GSLB stops advertising the site. Local SLB handles persistence, Layer 7 switching and server-level failover inside the site. Keep the GSLB check interval longer than the local one so a single server restart does not flap the site out. The load balancing hub follows this two-tier model.

10 /Failure modes and pitfalls

• The GSLB device as single point of failure. One authoritative server that happens to be clever trades a site outage for a name outage. Run two devices in different sites, or keep the proxy model with the existing name servers behind it.
• Split-brain health. The device reaches site A over its own path while users on another transit provider cannot. Check from more than one vantage point, or feed an external monitor's verdict in as a metric.
• AAAA records left unmanaged. A device that steers only A records lets IPv6 clients resolve a static AAAA answer and land on the dead site.

11 /Expert tips

• Set the site check interval to at least twice the local real-server check interval, so a local failover always completes before the site is pulled.
• Query the device from a resolver you do not control during a failover drill; the TTL you configured and the TTL resolvers honour differ.
• Keep a plain, unsteered name per site so operators and monitors can reach a specific site regardless of policy.

Global server load balancing is a timer problem dressed as a DNS problem: check interval, failure count, TTL and the resolver's own habits decide the outcome. With those settled, the local tier spreads the connections that arrive at the chosen site VIP.