What is Domain Name System (DNS) based load balancing?
Load balancing is a distribution technique that helps spread workload and traffic across different network servers. This practice enables applications and websites to manage traffic efficiently and operate optimally.
DNS load balancing uses the domain name system (DNS) to distribute site traffic across several servers, increasing overall computing efficiency—raising throughput, optimizing performance, and minimizing downtime.
Local vs. Global load balancing
Load balancing was referred to as the distribution of traffic across servers in one location, usually a single data center. However, computing is increasingly global, underscoring the necessity for load balancing.
Global server load balancing (GSLB) is based on the same principle as traditional load balancing. However, workload distribution is no longer confined to a single local network or data center. Rather, the workload is distributed across the planet and through many data centers. This creates new challenges for modern load-balancing solutions since it must take into account key communication parameters—most notably, the connection quality between geographically dispersed sites at any given time and the actual requester’s geographical location.
Early-generation GSLB solutions relied on DNS Load Balancing, which limited both their performance and efficacy. Today, cloud computing provides an outstanding solution for both local and global load balancing, enabling one cloud-based service to handle both scenarios.
Why is DNS load balancing un-synchronized and not load-aware?
DNS solutions are considered acceptable for simple applications or website load balancing. Network administrators increasingly recognize that DNS load balancing cannot meet the requirements of enterprise-class GSLB for several reasons:
- DNS-based services use load-balancing pools, which are defined for different geographic regions.
- The load balancer administrator defines which web servers are available and how often traffic should be routed to them. This enables maximum exploitation of geographically dispersed infrastructure.
- DNS load balancing is based on a traditional round-robin distribution methodology.
- DNS records have no native failure detection. This means that requests can be directed to the next server in the list even if that server is not responsive.
- DNS-based load balancing is susceptible to delays. For a DNS change to take effect, it has to be recorded on the ISP level. ISPs only refresh their DNS cache once every Time to Live (TTL) cycle. Until the cache is updated, ISPs are unaware that the change took place, and traffic is routed to the wrong server. Workarounds for this issue—such as setting TTL to a low value—have been developed, but these can negatively impact performance and still not guarantee that all users are correctly directed. TTL reliance also means that changes to load distribution directives are propagated much slower, resulting in low response, delayed failover, and delayed load redistribution.
- Changes can be propagated unevenly since each ISP has its own DNS cache rules in place.
What is round-robin DNS?
Instead of using a software or hardware-based load balancer, round-robin DNS performs load balancing using an authoritative nameserver.
The load balancer reviews a list of servers and sends one connection to each server in turn. Each time it reaches the end of the list, it starts at the top of the list.
The problem with this round-robin distribution method is that it is not load-aware — the load balancer has no way of knowing if the next server in line is actually the optimum choice. This results in either server sub-utilization or overburdening.
The DNS Compromise: Costly appliances, split architecture, upstream caching issues
The DNS Compromise: Costly applicances, split architecture, upstream caching issues
How does DNS load balancing work?
Below is a hypothetical scenario of DNS load balancing:
- A given application runs on two servers, Server A and Server B. The TTL cycle is set at one hour (a common value).
- At any given moment, the load on Server A can increase such that the DNS load balancer needs to start routing traffic to Server B.
- If the load spike hits when the TTL cycle is still 20 minutes from the update, it will take 20 minutes for the load to be redistributed.
- In the meantime, all traffic is still routed to the overloaded server, causing greater delays, slowing delivery, and causing service degradation—even to the point of service failure.
- After 20 minutes, some ISPs will retain a DNS cache. This means that an unpredictable percentage of traffic will be wrongly routed, causing uneven performance.
Other types of DNS-based load balancing
Load balancers offer domain owners a variety of traffic routing options to select from.
- Geo-location is a frequently used dynamic algorithm. The load balancer directs requests from a specific region to a designated server or group of servers. For instance, all requests originating from the United States are directed to “Server A”, while requests from Ireland are directed to “Server B”.
- Proximity-based load balancing operates in a similar way. In this setup, load balancers direct traffic to the server nearest to the user. While dynamic algorithms follow slightly varying rules, the ultimate goal is to monitor server performance and optimize traffic allocation.
- There’s also a DNS-based load-balancing system that employs a weighted algorithm. Servers are allocated based on their ability to manage traffic. Consequently, traffic is proportionally assigned. For instance, if server one can handle double the traffic as server two, the load balancer will direct twice the volume traffic to server one by providing its IP address in response to DNS queries. This practice of load balancing algorithm is also known as weighted round-robin or weighted least connection.
- Some DNS-based load-balancing methods are dynamic. The load balancer considers the server’s response time when it is allocating traffic requests. Dynamic algorithms come in various forms. One example is “least connection”, where incoming traffic is directed based on whichever server has the least open connections.
