(This article is the last in the series starting with
In the previous article, we looked at the two different ways in which SteelApp can use DNS to provide a GLB service, and in this article, we take a closer look at the way DNS works in detail.
DNS in more detail
Behind the scenes, the DNS system is very sophisticated. It’s not just a single list of DNS names and IP addresses; it’s a distributed set of connected databases that must be searched to find the information required.
This section describes some of the fine details of DNS that are relevant to Global Load Balancing. As you learn more about DNS, you’ll come across terms like “NS records” and “CNAMEs” and how they relate to Global Load Balancing.
An NS record tells the DNS system where the name server for a particular domain is located. When a client looks up a domain, it starts at one of the root name servers, going up through a chain of DNS servers until it finds the one it wants.
The NS record for our example domain, sueztechnology.com, tells the world where the DNS servers that know about sueztechnology.com are located.
A CNAME is like a nickname for a particular domain name. For example, if the web server for www.sueztechnology.com was located in the BigPipe Hosting Facility in Egypt, then the name ‘www.sueztechnology.com’ might be a CNAME (nickname) for another name, such as ‘hosting.bigpipe.net.eg’ in Egypt.
What this means is that when a computer tries to look up the IP address for www.sueztechnology.com, it receives a DNS response saying “Use ‘hosting.bigpipe.net.eg’ instead”. So the system makes a new DNS request for that name, and uses the IP address it receives for the new name. This is all completely transparent to the end user.
In our Global Phone Book, it’s just as if Suez Technology had outsourced its call center to a different organization. The phone book entry for “Suez Technology Technical Support” might say “Use ‘Acme Egypt Support Services’”, and the phone book would return the number for that organization any time someone looked up “Suez Technology Technical Support.”
Why are NS records and CNAMEs important?
NS records and CNAMEs are useful tools. Usually, when you deploy a DNS proxy like SteelApp GLB, you will arrange that DNS requests are directed to it by modifying either an NS record, or by adding a CNAME. This way, you’re telling the remote computers to query the SteelApp GLB device rather than the DNS server directly.
Alternatively, if you are using SteelApp’s built-in DNS service, SteelApp acts as a local DNS authority, and responds directly with a tailored DNS response. All of this complexity is completely hidden from end users – they continue to access your service using the common name as before and are unaware of the workings of DNS!
Please refer to the SteelApp GLB documentation for more information on how to deploy SteelApp GLB and configure your DNS using NS and CNAME records.
In order to reduce the load on DNS servers, many clients cache DNS responses for a period of time. Additionally, clients often route their DNS requests through intermediary cache servers. This DNS caching behavior improves the performance of Internet services, because clients do not have to resolve DNS names every time they access a service, and a local cache can reply faster than a remote DNS server.
Remembering DNS responses can cause problems when a datacenter fails and its IP address becomes unavailable. If a client or intermediary cache has cached a DNS entry to the datacenter that has just failed, the client will attempt to contact that datacenter without checking with the GLB device first. This problem is dealt with in two ways.
Some client software performs a new DNS lookup when it discovers that the IP address it cached is unavailable. This behavior improves compatibility with GLB systems. For example, Internet Explorer on Windows XP SP2 or later works this way.
DNS responses contain a TTL (Time-To-Live) field that tells systems how long they should cache items for. For a GLB system, it’s appropriate to set the TTL to a low value, such as 30 seconds. SteelApp GLB is able to change the TTL of any DNS responses it modifies in case the DNS server does not provide a suitable SSL value.
GLB devices determine the location of the remote user, based on where the DNS request came from. This location information is then used to decide which data center is closest to the user.
When the DNS request comes from an intermediate DNS cache, the GLB device will use the location of the cache device. However, this rarely causes a problem; the cache is normally located close to the user for performance reasons, and if the user is using a proxy device, the cache and the proxy are located in the same location (as in the case of some ISPs). So DNS caches have little impact on the effectiveness of the proximity decisions that a GLB device makes.
Global Load Balancing is a tried and tested way of improving the availability and speed of Internet-based services, and DNS can be thought of as the Internet’s ‘Phone Book’, telling computers where different services are located. DNS-based Global Load Balancers are by far the most common type of GLB device.
There is widespread support amongst software vendors and infrastructure providers to ensure that DNS-based GLB systems are as effective as possible, and significant improvements has been made in the last few years that deal with early application incompatibilities.
SteelApp Global Load Balancing
In this series of articles, we used the fictional example of “Suez Technology.” While the IP addresses and other examples used in this article are entirely fictitious, GLB is a proven technique which is implemented by many Riverbed customers for high profile sites on the Internet, as well as for intranet applications.