DNS failover, built in
A free GSLB enabled load balancer
Your nodes answer DNS for a zone you delegate to them, and they leave out any node that is not healthy. This is the layer that survives losing a whole server, a whole rack or a whole building, and it is the one most setups are missing.
The gap DNS failover fills
Say you did everything right. Two load balancers, both healthy, both serving. Your backends are checked and the dead ones get pulled. Then the machine your domain points at loses power.
Every visitor still gets that address, because DNS does not know anything happened. They wait, they time out, and they leave. The second node is sitting there in perfect health with nobody being sent to it.
This is the common gap
Load balancing inside your fleet is a solved problem that most people solve. Steering visitors away from a fleet member they cannot reach is a different problem, and it can only be solved before the connection is attempted. That means DNS.
How it works here
- You pick a subdomain to hand over, something like
gslb.example.com. - At your domain host you create the delegation: nameserver records pointing that subdomain at your nodes, plus glue records giving their addresses.
- In the GUI you make a zone and add the names you want answered, with the nodes that may answer for each.
- Your real site name becomes a CNAME to a name inside the delegated zone.
- From then on, every lookup is answered by your own nodes, and a node that is not healthy is left out of the answer.
The walkthrough guide does all of this properly, including how to test it before you depend on it, and there is a worked example for Amazon Route 53 in the how to section.
Choosing a TTL, honestly
TTL is how long a resolver may keep the answer. Short means faster failover and more queries. Long means fewer queries and a longer outage for anybody holding a stale record.
| TTL | Failover feels like | Worth it when |
|---|---|---|
| 30 seconds | Under a minute for most people | The site genuinely cannot be down, and you accept the query volume |
| 60 seconds | A minute or two | A good default for almost everybody |
| 300 seconds | Up to about five minutes | Failover is a nice to have rather than the point |
Be realistic about the promise. Some resolvers ignore short TTLs and keep records longer than they were told. Some browsers and operating systems cache on top of the resolver. A sixty second TTL means most visitors recover in about a minute and a few stragglers take longer. Anybody quoting you instant DNS failover is describing a lab.
GSLB is not a CDN
Both steer visitors, so they get confused with each other. A CDN puts copies of your content in many cities and serves from the closest one, which is about speed. GSLB decides which of your own servers to send somebody to, which is about availability.
You can run both. If you want your visitors in another country served from that country, you want a CDN, and this is not one. If you want your site to survive the room your server lives in catching fire, that is this.
What happens when everything is down
There is a setting for it, and it is worth thinking about rather than accepting the default. If every node fails its check, you can either answer with nothing, or answer with all of them anyway.
Answering with all of them is usually right. If every node looks dead, the most likely explanation is that your health checking is broken rather than that your entire fleet died at the same instant. Handing out an address that might work beats handing out nothing, which guarantees failure.
DNS failover and GSLB
Hand out the address of a node that is actually up.
Read moreActive and standby
One node takes changes, both serve traffic.
Read moreActive health checks
Probe every backend on a schedule and pull the dead ones out.
Read moreClustering
Every node holds the whole config. No central controller.
Read moreTwo phase apply
Nothing goes live until every node says the config is valid.
Read moreBackup and restore
One encrypted file that rebuilds the fleet somewhere else.
Read moreQuestions people ask
What is GSLB?
Global server load balancing. Instead of steering traffic after it arrives, you steer it before it arrives, by controlling the answer to the DNS lookup. Ask for the name and you are told the address of a node that is currently up. It is the only layer that can route around a site you cannot reach at all.
Why do I need DNS failover if I already have two load balancers?
Because a visitor has to reach one of them first. If your name resolves to a dead node, the visitor gets a timeout no matter how healthy the other node is. Something has to stop handing out the address of the node that is down, and that something is DNS.
Do I need a paid DNS provider for this?
No. Your nodes are the nameservers for the zone you delegate to them. You do not need a managed DNS product with health checking bolted on, and you are not paying per query or per health check.
How fast is DNS failover really?
Your TTL plus a few seconds, in the best case. In practice some resolvers hold records longer than they were told to, and some clients cache on top of that. Treat the TTL as a floor rather than a promise, and do not build anything that assumes failover is instant.
Can I use it for the apex of my domain?
Yes, because you are running the nameservers. The usual apex problem comes from needing a CNAME there, which is not allowed. Answering with an A record directly avoids it.
Test it by turning a node off
Ubuntu 22.04 or newer, root access, and about twenty minutes. The installer does the rest and it is safe to run twice.