A load balancer distributes traffic across the servers in a data centre. But what distributes traffic across the data centres themselves? When you run sites in London and New York — for latency, for redundancy, or because a regulator insists — something has to decide which site each user reaches. That something is Global Server Load Balancing, and the mechanism behind it is refreshingly familiar: DNS.
The idea: answer DNS queries intelligently
Every connection to your service starts the same way: the client resolves a hostname. GSLB works by making that resolution step smart. Instead of a static DNS record that always returns the same address, a GSLB-enabled authoritative DNS server chooses its answer per query — returning the IP address of whichever site best suits that client at that moment, based on geography, site health, or administrative policy.
Tula’s GSLB is powered by gdnsd, a high-performance authoritative DNS server with integrated health checking, geographic routing, and failover. The flow:
- A client (via its recursive resolver) queries your service hostname — say,
app.example.com. - gdnsd evaluates the query’s source address against its GeoIP database and checks the current health of each candidate site.
- It returns the address of the best matching healthy site — typically the geographically nearest.
- The client connects directly to that site, and keeps using the cached answer until the DNS TTL expires.
Two properties of this design are worth dwelling on. First, it is transparent to clients: anything that resolves DNS — browsers, mobile apps, APIs, IoT devices — benefits, with no special software or configuration anywhere. Second, it adds nothing to the data path: once the hostname is resolved, traffic flows straight to the chosen site. The steering happens before the connection exists.
What people use it for
Disaster recovery. When the primary site goes offline, gdnsd stops answering with its addresses and returns the standby site instead. New connections flow to the survivor without anyone changing a URL. (The details of failover timing deserve their own discussion — thresholds, TTLs, and the arithmetic of worst-case switchover — covered in the GSLB failover documentation.)
Geographic routing. European users reach your Frankfurt site, North Americans reach New York, and everyone’s round-trip times shrink. Tula supports mapping at continent or country granularity using MaxMind GeoIP2 data, with gdnsd extracting the query’s source — or the EDNS Client Subnet address, where the resolver provides one — and looking it up in memory at negligible cost.
Regulatory compliance. Where data residency rules require users in a jurisdiction to be served from approved locations, geographic zone mappings enforce it at the DNS layer.
Capacity distribution. Weighted DNS responses spread traffic across sites in controlled proportions, keeping any single data centre from being overwhelmed.
GSLB is not a replacement for local load balancing
A useful way to place GSLB in your architecture:
| Aspect | Local load balancing | GSLB |
|---|---|---|
| Scope | Servers within one site | Sites across the globe |
| Mechanism | Packet forwarding / proxying | DNS response steering |
| Granularity | Per connection or request | Per DNS TTL interval |
| Failover speed | Sub-second | Bounded by DNS TTL |
| Protocol awareness | L4 / L7 | DNS only |
The granularity row is the important one. A local load balancer makes a fresh decision for every connection; GSLB makes a decision that clients then cache for the TTL duration. GSLB therefore steers populations of users between sites, while the local balancer within each site handles the fine-grained work — spreading connections across servers, ejecting unhealthy backends, maintaining session persistence.
The two are complementary layers of the same system, and a typical Tula deployment uses both: GSLB chooses the data centre, then that site’s L4 or L7 VIPs distribute traffic across its servers. One platform provides both tiers.
What a deployment needs
Three ingredients:
- Two or more Tula nodes in different locations, each already running local load balancing for its site’s backends, each with a publicly routable VIP.
- Authoritative DNS delegation. Your registrar or parent zone must delegate the service hostname (or a subdomain, such as
lb.example.com) to the Tula GSLB nodes with NS records. This is the step people forget: GSLB only works if the world’s resolvers actually ask your nodes for answers. - Health checks per site, so gdnsd can detect an outage and stop advertising a dead site. TCP connect and HTTP/HTTPS checks are supported, probing each site at a configurable interval with sensible thresholds to avoid flapping on transient blips.
Configuration is done in the NetMan interface: define the GSLB zone with its SOA record, add records mapping hostnames to the sites’ VIP addresses, attach health monitors, and choose a routing policy — failover, round robin, weighted, or GeoIP. The GSLB configuration guide walks through each step.
Honest limitations
DNS-based steering has edges worth knowing about. Failover speed is bounded by the TTL — clients holding a cached answer keep trying the old site until it expires, so rapid-failover services run TTLs of 30–60 seconds and accept the extra query volume. A small minority of recursive resolvers ignore TTLs and cache longer than asked; nothing at any vendor fixes that. And GSLB steers where connections begin — it cannot move an established connection between sites mid-flight.
None of these undermine the model; they simply define it. GSLB is the coarse-grained, globally scoped tier of a load balancing architecture, and DNS — universal, cache-friendly, infinitely deployed — remains the most practical mechanism ever devised for it.
For a deeper treatment of the mechanics, start with the GSLB overview and the GeoIP routing documentation.
