If you’re in the tech world, you’ve probably heard the term "DNS load balancer" thrown around like confetti at a New Year’s party. But let me tell you, just like "DevOps," the true meaning of DNS load balancing is getting lost in translation. People treat it like a magic wand: wave it around, and voilà, your scaling problems vanish! But not so fast, my friend. There's more to it than meets the eye.

Here’s the deal: DNS load balancing is often seen as a simpler alternative to application-level load balancing, and sometimes it is. But slapping it onto your network setup without understanding its nuances is like putting lipstick on a pig and calling it a beauty queen. Spoiler alert: it’s still a pig.

DNS load balancing isn't just about rerouting traffic. It's not a one-size-fits-all solution. If you think it's just a matter of spinning up a new instance and letting DNS handle the rest—well, buckle up, because you're in for a wild ride.

It's high time we give DNS load balancing the respect it deserves and dig deeper. This isn't just about distributing network load; it’s about understanding latency, failover, caching, and the limitations of DNS itself. So, let’s cut through the noise and give DNS load balancing the spotlight it deserves. Stay with me.

What is DNS load balancing?

If you think DNS load balancing is just fancy tech jargon, think again. It's like spreading a domain across multiple servers to avoid users getting stuck if one server is busy or down.

DNS is essentially the Internet's phonebook. Instead of mapping names to phone numbers, it maps domain names to IP addresses. Imagine remembering "172.16.205.3" instead of "yourcoolwebsite.com"—not happening.

In an ideal world, one server handles everything. But in reality, servers crash and traffic surges. So, DNS has multiple IP addresses to choose from, spreading the load across servers to prevent failures.

How DNS Load Balancing works?

You might have heard that DNS load balancing is all about clients grabbing the first IP they see. On most Linux distros, DNS is like a dealer shuffling cards, handing out IP addresses in a new order every time with the round-robin method. Sounds smooth, right? Multiple clients get multiple servers, and just like that, your load's distributed. But here's the kicker: this isn’t as foolproof as it sounds.

First off, DNS isn't your babysitter. It won't check if your servers are throwing a tantrum or if the network decided to take a long weekend. So, if you’re relying on DNS to always steer traffic clear of problems, brace for impact. Your clients might just be walking into a brick wall, because DNS keeps dishing out the same IPs even if your servers have hit rock bottom.

Now, let's talk caching. Both resolvers (that's middleman DNS servers for you) and clients love to cache these addresses to cut corners. Sure, it speeds things up and reduces network chatter, but here comes the drama: the Time-to-Live (TTL). Set a long TTL, and your clients are left reading yesterday’s news—they won't know about server changes till it’s embarrassingly late. Go for a short TTL, and you've got the digital equivalent of a gossipy neighbor—lots of updates, but also a ton of unnecessary yakking that clogs the system.

So, let’s not kid ourselves: DNS load balancing isn't your silver bullet. It's more like a Rubik's Cube that fights back. And if you think you've got it all figured out, odds are, you're missing a piece of the puzzle.

Setting the Stage

We've crafted a nifty little app in the godsend of programming languages, Zig. What's it do? Just spits back your current IP address—no fuss, no state, no databases, no NFS, nada. Why? Because we can, and also because we've been eyeballing those tech influencers who keep hyping up the "multicloud life." So, what did we do? We went full multicloud-diversity by deploying one server on each of these cloud titans: Hetzner, OVH, and Scaleway.

Time for a server roll call:

• Server A with IP 1.2.3.4, reppin' Hetzner
• Server B flaunting 2.3.4.5, courtesy of OVH
• Server C strutting 3.4.5.6, all thanks to Scaleway

Taking a page out of some no very professional tech influencers, we pimped out our DNS settings. Now, our righteous domain, givememyip.xyz, doesn't just send you to any one server—it mixes it up! Run a 'dig' query and you're in for a Russian roulette of server options:

• A, B, C
• A, C, B
• B, A, C
• B, C, A
• C, A, B
• C, B, A

Voilà! Instantaneous load balancing. Depending on who's asking, we dish out a different server. And hey, if we're feeling extra crafty, we could even match you up with the closest server to slash those response times. Pretty neat, right?

Here come the reality

Picture this: One of your servers starts acting like it's in a bad mood—either going down or grinding to a crawl. You've got external monitoring in place that flags this misbehavior. So, what's next?

You might think, "No big deal, browsers and tools like curl will just hop on over to the next DNS entry, right?" Well, the real answer is more like a frustrating "it depends." The behavior varies based on the type of hiccup. If the server is slow, don't expect a jump. Got a 500 error? Still no jump. But if there's no socket open on port 443, then yes, it’ll leap to the next entry like a cat spotting a laser dot.

You might be saying, "Fine, Loic, can't I just yank the problematic IPs out of the DNS pool?" In theory, sure. A monitoring tool could assess server health, and if things look grim, remove the IP from the DNS pool. But here comes the plot twist: DNS propagation.

Remember, DNS isn't a chatty Cathy. Even if you make a change, there's no guarantee that it's instant news across the Internet. Not everyone plays by the TTL rules, so you could still have requests hitting your downed server for hours. And the kicker? If the server is fully down, you're flying blind—you won't even know those requests are dropping into the void.

Another potential complication worth noting is the unpredictability of traffic routing. For example, an internet service provider could encounter a DNS issue that funnels all traffic to a single server on your end. In such scenarios, you have little to no control over the situation.

When Should You Use DNS Load Balancing?

In summary, DNS load balancing should only be used when you meet the following criteria:

1. Public IP addresses remain stable and don't frequently change.
2. Each public IP doesn't correspond directly to an individual server.
3. Every public IP should act as a virtual IP, shared between at least two load balancer servers.

In a nutshell

We've yapped on and on about DNS load balancing, but let's get real—this isn't your golden ticket to the magical land of Perfect Uptime. Think of it more like that rusty multi-tool you find at the bottom of your backpack when you're lost in the woods. Sure, it's got a few useful gadgets, but it's not going to build you a five-star hotel out of twigs and leaves. And in our world, it's certainly not going to magically create a flawless network.

You'll still need to babysit your servers like they're toddlers on a sugar high, and don't even get me started on the joyride that is DNS propagation and TTL settings. It's like navigating a maze designed by a sadistic clown. So, buckle up, buttercup. The moral of the story? Stock your tech toolbox with everything but the kitchen sink, invest in monitoring that's tougher than a bouncer at an exclusive club, and for the love of all that is holy, always have a Plan B (and C, and D). Because in the world of networking, the only guarantee is that nothing is guaranteed.

If you have a problem and no one else can help. Maybe you can hire the Kalvad-Team.