Complete guide to DNS load balancing: Choosing the best method for your applications
GSLB Published on •13 mins
In my experience, DNS load balancing is one of those topics that people like to overcomplicate and make sound more convoluted than it actually is.
To understand DNS load balancing, there are two concepts to get your head around first; DNS resolution, and load balancing.
Once you’ve done that, and got a basic understanding of the different load balancing methods available (which I’ll outline here), it’s then just a matter of choosing the best solution to prevent server overload and solve the specific challenges in your environment.
All of which I’ll unpick for you here...
Table of contents
- What is DNS resolution and how does it work?
- When to use DNS as a load balancer
- What is DNS round robin?
- Beyond DNS round robin: Better DNS load balancing
- DNS load balancing security considerations
What is DNS resolution and how does it work?
The Domain Name System (DNS) is a naming convention that translates human-readable web addresses into IP-addresses, and vice versa.
How does DNS translate domain names into IP addresses?
With the Domain Name System (DNS), the user device connected to the Internet can communicate with a specific web-based application, which then returns the requested information to the correct user, without the user having to recall the unique IP address of the requested resource.
DNS is used to do the grunt work of looking up the web-based application name and translating the domain name into an IP address, which in return routes the client to its intended destination.
When to use DNS as a load balancer
The limitations of vertical scaling
Businesses are under increasing pressure to ensure consistent, reliable, and secure content delivery to a growing number of application users. However, you cannot grow a single server indefinitely to meet ever-increasing demands.
While you can certainly enhance a lone machine by adding more RAM, faster and larger hard drives, and more powerful CPUs, this approach eventually hits a wall. You'll reach a point where the motherboard can't accommodate more components, the power supply can't deliver enough wattage, or the physical size of the server becomes unwieldy. Even if you could overcome these hardware limitations, a single server on its own represents a single point of failure. And, if it goes down, your entire service is disrupted.
To truly handle significant and growing application traffic, you need to distribute the workload across multiple servers, creating a cluster. This means you have to add more machines to your infrastructure and find a way of managing them collectively. You need a system to intelligently distribute incoming requests across them, ensuring that no single server becomes overwhelmed while others sit underutilized. This is where load balancing comes into its own.
What is a load balancer?
A load balancer is a piece of hardware or software that distributes incoming user content requests or 'traffic' to healthy servers in a cluster, preventing a single server from becoming overloaded and ensuring uninterrupted application delivery.
It’s important to understand that a load balancer is different from what’s known as ‘load balancing’. One is a thing, and the other is a way of doing something.
For more on load balancers, check out our comprehensive guide: What is a load balancer?
What is a DNS load balancer?
In short, there is no such thing as a DNS load balancer. While the term is commonly used, it is actually a misnomer. Instead, DNS-based load balancing is the preferred term; a simple method of routing traffic to named servers using the Domain Name System (DNS).
By mapping a domain name to different IPs, DNS-based load balancing attempts to provide a degree of resilience by making more efficient use of the servers available in the cluster, minimizing the risk of a single server becoming overloaded. This makes it a potential technique for improving the performance of web services and applications.
Do you need a load balancer for DNS-based load balancing?
You don’t need a load balancer to do DNS round-robin load balancing, but you can’t do much else without one. For example, you can’t do Global Server Load Balancing (GSLB) without a load balancer, which means it’s unlikely that you’ll be able to solve your problem(s) without one.
While DNS round-robin and GSLB both technically allow you to do ‘load balancing’, there is a vast difference in what these two different solutions actually allow you to do, as shown below.
So the solution you need will depend on the problem(s) you’re trying to solve:
How does a load balancer overcome the challenge of server overload?
As the table above shows, ‘load balancing’ is a broad term that captures a wide range of possible outcomes and solutions, but for now, let’s just establish that you need ‘load balancing’ in some form at least to overcome the challenge of high traffic and server overload I outlined earlier.
What are the benefits of load balancing?
A load balancer can overcome the challenge of server load in the following ways:
1.Traffic management = increased availability
Load balancers route traffic to servers, and they ensure application availability – even during times of heavy traffic. The load balancer sits in front of your web servers, and before directing users to your application, checks the server:
- is functioning
- has available capacity
This ensures users begin their application experience in an environment that is both working and performing within expectations.
2. Redundancy = greater resilience
Redundancy avoids the dreaded single point of failure, which means services can continue — even in the event of downtime, or critical server maintenance.
For more on the single point of failure, check out this blog: The easiest way to reduce downtime — avoid a single point of failure.
3. Persistent sessions = A better user experience
When you begin your user journey on a web-based application, this information is stored with your session data locally in your browser. This helps because while browsing if you make different requests to different servers during the same session, this can lead to content errors, performance issues or other problems which cause users to abandon the application.
So it’s important to ensure that multiple requests from a user are all sent to one server for the length of their session – this is called ‘session persistence’ and can be handled by the load balancer.
4. Scalability = Ability to scale up (and down) to meet demand
With virtual load balancer appliances, it’s quick and easy for applications to increase resources to meet anticipated peaks in user demand, then scale back down again to usual operational levels later.
This is also much more cost-effective than buying hardware appliances which go unused for most of the year.
5. Health checks = Reduced downtime
Load balancing allows for complex health checks to and from the available servers, using a range of protocols. This reduces the likelihood of the user’s request being directed to a server that’s unable to facilitate their request — resulting in downtime or an interrupted connection.
The key point here is that not all methods of load balancing will give you all of the benefits outlined above. So what you need to establish is what problem(s) you’re trying to solve. In the meantime, let’s compare DNS-round robin load balancing with Global Server Load Balancing in more detail.
What is DNS round robin?
The most common DNS-based load balancing technique is round-robin DNS, although there are several different ways DNS load balancing can work, depending on the algorithm used.
DNS-based round-robin load balancing uses DNS to distribute traffic across multiple servers by assigning multiple IP addresses to a single domain name. It then cycles through them, one by one, every time a request is made.
What are the pros of round robin DNS?
Requests made to the domain name are distributed evenly across the different IP addresses. This can help to spread traffic and reduce the load on individual servers, which in turn can enhance application performance and stability. In this way, a degree of scalability, redundancy, and reliability can be achieved (albeit limited).
What are the cons of round robin DNS?
The biggest con of round robin DNS is that it does NOT provide health checks.
Instead, it blindly rotates through the IP addresses, regardless of whether those servers are actually online or functioning. This means if a server goes down, DNS round robin will still direct traffic to it, resulting in failed connections.
It also fails to provide session persistence.
It simply rotates through IP addresses, meaning a user's next request could be directed to a different server. This can cause problems for applications that rely on session data stored on a specific server, as the user might lose their session if their requests are routed to different servers.
How to configure DNS round robin
Your DNS round-robin config will vary, depending on the solution you choose.
However, although the exact steps differ, in summary all you need to do is add additional A records against your fully-qualified domain - regardless of whether that’s an internal DNS in your own infrastructure, or a public one.
For the precise configuration please refer to the documentation of your domain provider or your on-premise DNS solution.
Is DNS round robin load balancing suitable for all applications?
No, DNS round-robin is certainly not for everyone.
Its simplicity is also its downfall, meaning it’s unlikely to be a good fit for the following scenarios:
- Applications needing complex traffic routing: If you need to route traffic according to specific criteria, you’ll need to use a different load-balancing solution such as GSLB.
- Applications needing persistent connections: If you want persistent connections, DNS round-robin won’t solve this problem.
- Applications needing real-time server health checks: If you want health checks and monitoring, then you’ll need to employ a method such as GSLB.
Instead, DNS round-robin is much more likely to be useful for those with web-based applications with low traffic, where a degree of downtime is unlikely to cause too many problems.
Beyond DNS round robin: Better DNS load balancing
If you want to migrate the limitations of DNS round robin, GSLB direct-to-node is likely to be a much better fit.
At its most basic level, GSLB direct-to-node is essentially DNS round-robin but with health checks. So if you’re looking to increase resilience, then this is a far superior option. But it does much more than that.
How GSLB works with Layer 7 load balancing
Before explaining the ins and outs of GSLB direct to node, it's important to understand how GSLB typically works in tandem with Layer 7 load balancing.
Layer 7 load balancing deals with the content of the web-based application traffic, such as the HTTP/HTTPS requests. It makes intelligent decisions on URLs, and application-specific data such as headers and cookies, allowing for advanced routing and persistence.
GSLB, on the other hand, operates at a higher level, managing traffic flow across a distributed network of data centers or regions.
Together, they work like this:
- GSLB uses DNS to direct users to the most appropriate data center when they request a service. It considers things like geographical proximity or server availability.
- Once GSLB has done the initial routing, the Layer 7 load balancer within the chosen data center takes over. It distributes the traffic across the servers within that data center, with a much finer level of control, based on the content of the request.
Together they offer a much more intelligent and effective way of distributing application traffic.
How does GSLB direct to node work?
In a typical DNS round-robin deployment, requests are sent out to the configured nodes indiscriminately. However, with GSLB direct-to-node, the real servers undergo health checks to determine their availability. So if a server responds correctly it is kept within the pool of available nodes for the load balancer to send requests to. And if a server fails to respond correctly it is excluded from the pool of available nodes. GSLB direct-to-node passes the traffic straight to the application servers removing the need for a load balancer and massively increasing performance. However, in order to do that with enough granularity we recommend using a feedback agent on each server to dynamically change the weight in the GSLB. This is on top of the usual flexible health checks.
In this way, GSLB enables the load balancer(s) to provide intelligent DNS responses to inbound client queries for one or more subdomains. The responses given depend on the health of each endpoint and if Topology is configured, the location of those endpoints relative to the client making the request.
Where GSLB is deployed alongside application load balancing, the endpoints are usually the VIPs that are configured at each site. Where application load balancing is not used and only GSLB is configured, the endpoints are normally the Real Servers. DNS delegation is used to delegate responsibility for the subdomain (s) to the GSLB service on the load balancers.
Once delegated, it is the GSLB service on the load balancers that is responsible for providing the response to DNS queries for that subdomain. In a two-site setup with an HA pair of load balancers in each site, once GSLB and DNS delegation are correctly configured, the four load balancers act as intelligent name servers for the subdomains specified.
What are the pros of GSLB direct to node?
GSLB direct-to-node is the best alternative to a typical DNS Round-Robin deployment. It can provide an unlimited scale of your services as all request traffic is out of the band/ path of the load balancer, meaning there is no bottleneck. At scale is surprisingly granular in balancing large amounts of traffic to large amounts of application servers. Can be deployed in combination with topology based routing for site affinity. Very low cost, low resource, relatively simple and incredibly fast.
What are the cons of GSLB direct to node?
GSLB direct-to-node requires careful thought about the sheer number of health checks and feedback agent responses, although this is rarely an issue in production. It is out of path, so has less visibility of traffic flows than a load balancer. Limited persistence options, and no SSL offload or WAF. You should only use GSLB direct-to-node in extremely high throughput environments when your load balancer is no longer able to keep up with throughput.
What are the benefits of GSLB direct to node?
What sets GSLB direct-to-node apart is the following:
- Health checks: GSLB direct-to-node continually runs health checks against each of the servers in the pool. The health checks can be tailored to each installation to verify that the real servers are able to process requests correctly.
- Dynamic weighting: The load balancer has the ability to dynamically weight the servers within a pool based on actual server performance to smooth distribution and alleviate hot nodes.
- Topology distribution: With topology distribution, you can distribute requests to nodes/clusters/datacentres preferentially based on where the request is coming from. Topologies are something that we use in our site affinity GSLB implementations and also something we can leverage in a GSLB direct-to-node installation.
Global Server Load Balancing (GSLB) direct-to-node has the potential to be as fast as it is wordy. It removes the load balancer from the path of the load balancing, making it an ideal solution for unrestricted throughput.
How to configure GSLB direct to node
GSLB must be configured on the Primary appliance at each site. The GSLB configuration must be identical at both sites to ensure consistent DNS responses irrespective of which load balancer responds. The following steps assume that an HA pair is already configured in each site.
Full step-by-step configuration details can be found here:
https://pdfs.loadbalancer.org/global-server-load-balancing.pdf
Step 1: Global Names
The first step is to configure the Global Names. Global Names are the FQDNs that GSLB must respond to requests on. They must correspond to the configuration that is set in the DNS infrastructure.
Step 2: Members
Members are the individual IP addresses that a request can be resolved to and are associated with the Global Name via a Pool.
Step 3: Pools
The Pool ties the elements of the GSLB configuration together. The Members are assigned to the Pool and the Pool is assigned to the Global Name. The majority of the configuration is applied within the Pool.
Step 4: Topologies
Topologies are slightly confusingly placed at the end of the UI. To configure a Pool with a LB Method of twrr you must first configure a topology for it. The simple way to overcome this little hurdle is to first define your Pool with the LB Method set to wrr, configure your topologies and then go back and update the Pool to use twrr.
Step 5: DNS delegation and entry
Before the GSLB and its configuration can be tested in a meaningful way, DNS must be configured. Typically in a production environment it’s best to configure the DNS delegation and configuration for the network before you go to configure the GSLB on the load balancer appliances. This does depend on your DNS infrastructure.
Convergence of the DNS configuration can take hours to be fully synchronized. Because of this, it is practical to complete the DNS configuration before implementing the GSLB. You must consider that it’s a double-edged sword. If you add the DNS entries before the GSLB is configured then the network will not be able to correctly resolve those requests. Unfortunately, this can also be one of the most confusing parts of a GSLB implementation so getting it right in the first place is not always straightforward. For applications that have a corresponding deployment guide it’s worth reading that first as some of them contain product-specific DNS delegation guidance.
Is GSLB direct to node suitable for all applications?
GSLB direct-to-node offers much more than DNS round-robin in terms of solutions and is more likely to solve your application problem(s).
High-volume request workloads such as Veeam backup and recovery are also likely to benefit from GSLB direct-to-node, so the specifics of your environment will determine the most appropriate solution. If you want a run down of your options, feel free to reach out for some free advice.
DNS load balancing security considerations
Finally, it’s important to understand that a load balancer is fundamentally not a security product. And anyone who says otherwise is telling you porkies. Yes, it can play a role in a defense-in-depth approach, but I don’t recommend using it as your first line of defense. Fundamentally, a load balancer is designed to facilitate traffic distribution, not restrict it, and there are much better security solutions on the market than load balancers.
For an honest take on what load balancers can and can’t help you improve web application security, check out this white paper:
https://www.loadbalancer.org/white-papers/the-owasp-top-10-web-application-security-threats/
You might also find these resources on mitigating security threats with DNS useful:
Summary
You need to load balance web traffic to overcome the problem of server overload. This can be done with a variety of different load-balancing methods.
Basic DNS load balancing can be done using DNS round-robin, but GSLB direct-to-node is much more likely to help you overcome the challenges you face, with advanced traffic management, session persistence, and real-time health checks.