Is there any other technique to distribute traffic between load balancers besides DNS?

First off, I have already read this: High availability of load balancers themselves

But this question doesn't go far enough.

It seems like DNS load balancing is the only way to distribute traffic among load balancers. (Besides using a load balancer, which obviously doesn't do anything to distribute the load if it all has to go through a single server in the end)

This seems like an abuse of the DNS protocol. My understanding is that DNS was designed for name resolution, not load balancing. What if I want a more complex load balancing algorithm besides round robin? Is this the only way to distribute traffic between load balancers? If it's not the only method, what other methods exist?

Granted, it does seem like it works well and is the current standard for all major companies, is that correct?

My understanding is that DNS was designed for name resolution, not load balancing.

For both, because (almost) all records can be sets, hence for a given question a client can get multiple answers and then is free to choose whatever item it prefers.

Which is why a frequent pattern is round-robin among replies, so that the client picks the "first" item, but it will be different each time.

Of course a client can implement a smarter algorithm, specially for the transition to IPv6 with A and AAAA records, see RFC 8305 "Happy Eyeballs Version 2: Better Connectivity Using Concurrency" but this is not load balance anymore.

So it all depends on what amount of "intelligence" there is on the client side.

SRV records allow to encode both a priority (fail over) and weight (load balance) for potentially any protocol over TCP or UDP, and allows not to have to hard code port numbers anymore. Sadly, browsers never implemented it. The newer iteration are SVCB and HTTPS records that allow kind of the same thing.

Note this in fact in the current draft:

SRV records specify a "weight" for unbalanced randomized load-balancing. SVCB only supports balanced randomized load-balancing, although weights could be added via a future SvcParam.

Following:

What if I want a more complex load balancing algorithm besides round robin?

Today, this means SRV records and some intelligence in the application (client side). Or a smarter nameserver that changes its replies based on external dynamic factor (what CDNs do for example).

The basic problem faced with load balancing at the DNS level is tailored to TTLs, and because some resolvers will not obey too small values for it.

You need to remember also that the authoritative nameserver that has the data only sees the recursive nameserver the client uses most of the time, not the client itself. So its choices are constrained also by that.

No, DNS is not the only way to switch between load balancers.

Consider this multi-tier load balancer design. Scalable and resilient.

• Layer 7 tier has many instances that provide application aware proxy to backends. Terminates TCP connection, and possibly TLS. HAProxy, for example.
• Layer 4 tier in front of that, which routes packets consistently. keepalived with IPVS, for example. Can even be stateless, with a suitable consistent hashing algorithm.
• ECMP routers provide redundant paths, and horizontal scaling of links.
• And finally, DNS so users can look up the service addresses.

Being clever about returning results is within the DNS spec, so it is possible to implement health checks, geo IP based results, and other dynamic features. gdnsd is an authoritative-only DNS server that can do such things.

However, DNS is heavily cached, so is slow to change. Quirky inconsistent client behavior also makes DNS round-robin impractical. So, DNS could be limited to finding the front door, the correct region where the load balancer hosts are located. Activating the disaster recovery environment would be disruptive, but the DNS change can cut over to an entirely separate infrastructure.

The most basic solution in DNS is indeed simply setting multiple records of the same type with different values and having your name server return all of them to clients when they request that resource record.
The effect of that is usually called round robin DNS and although it comes with several drawbacks, it is well supported by DNS servers and clients alike. The issues with using that technique probably apply to all DNS load balancing solutions.

In addition to Patrick's answer some DNS servers have some more intelligence built in or bolted on. Rather than returning the complete set of all records, the response is tuned. Some algorithms are:

• A health check can ensure fail-over by removing the records of failed nodes in a response and/or by using the records of standby servers instead.

• Several name servers have an implementation to provide different sets of DNS information, usually selected by the source address of the DNS request.

  • The more trivial use-case of that called is usually "split horizon DNS" where request from clients on campus or within the corporate network will trigger a different response compared to others.
  • The more advanced use case would be "GeoDNS" or similar. For example a website might have 2 servers (or clusters behind a load balancer IP) , one located in France and one in the US. With GeoDNS it's possible to create a DNS record for which clients from Europe would get IP address of French server and clients from US would get the American one.

But many other approaches exist outside of DNS based solutions.

• "Anycast" where a single destination IP address is shared by servers/load-balancers in multiple locations and routers direct packets addressed to this destination to the location nearest the sender.

• built-in logic in applications with service discovery and fail-over