Fixing GSLB (Global Server load balancing)

Standard DNS protocol allows DNS servers to respond with multiple addresses in the replies for simple DNS lookup queries. This, and the way that the order of records is changed in every reply is collectively known as the “Round Robin DNS” technique to load balance across a set of servers.

Though a lot of organizations are using Round Robin DNS to load balance across servers in the same datacenter, some are also trying to use it as an HA solution by load balancing across multiple datacenters. In an event of a failure in one of the datacenter, using such an implementation, the impact could be limited, and with a slight change of DNS configuration (removing the IP of the datacenter which went down) the site could become fully operational again.

It would be nicer if the DNS servers could monitor and remove servers which are inactive or are throwing  errors of some kind. This is what GSLBs are all about. But what they really excel at, which regular DNS servers can’t do, is that they can figure out (in a slightly unscientific way) where a user is located geographically. This allows it to figure out which datacenter is closest to the end user. If a customer in Asia can get to a datacenter within Asia, instead of coming all the way to US, it could save the customer at least 200ms of latency which can significantly improve bandwidth and response from the website.

Though GSLBs, today, are very popular among the larger service providers there are some interesting drawbacks which can limit its usefulness. The core problem is that GSLBs use source IP within theGSLB_Architecture.PNG DNS request to figure out where the customer is located. This works beautifully if the customers laptop is sending these out directly, and in most cases will also work if the customer is using his/her ISP’s DNS server. Unfortunately if the customer uses some free public DNS service like the one google provides which recursively looks up the DNS records for the user, then GSLB would find datacenters which are closest to the DNS server requesting the information instead of the actual end user. A similar problem exists if the user is forced to use a DNS server over a VPN link. Read this post for a better understanding of this problem (Why DNS Based GSLB doesn’t work)

A few days ago Google came out with a solution to this problem which was announced here (A  proposal to extend DNS protocol). They don’t mention GSLB, but there is no doubt this will help solve the GSLB issue mentioned above. Unfortunately, I’m also sure that Google has other, more important reasons, to push for this change. They are interested in location information to “provide better services” (location-aware advertising).

DNS is the system that translates an easy-to-remember name like to a numeric address like These are the IP addresses that computers use to communicate with one another on the Internet.

By returning different addresses to requests coming from different places, DNS can be used to load balance traffic and send users to a nearby server. For example, if you look up from a computer in New York, it may resolve to an IP address pointing to a server in New York City. If you look up from the Netherlands, the result could be an IP address pointing to a server in the Netherlands. Sending you to a nearby server improves speed, latency, and network utilization.

Currently, to determine your location,
authoritative nameservers look at the source IP address of the incoming request, which is the IP address of your DNS resolver, rather than your IP address. This DNS resolver is often managed by your ISP or alternately is a third-party resolver like Google Public DNS. In most cases the resolver is close to its users, in which case the authoritative nameservers will be able to find the nearest server. However, some DNS resolvers serve many users over a wider area. In these cases, your lookup for may return the IP address of a server several countries away from you. If the authoritative nameserver could detect where you were, a closer server might have been available.

Our proposed DNS protocol extension lets recursive DNS resolvers include part of your IP address in the request sent to authoritative nameservers. Only the first three octets, or top 24 bits, are sent providing enough information to the authoritative nameserver to determine your network location, without affecting your privacy.

Regard less, its a step in the right direction and would significantly help in making web applications more available.



Balancer561 said…
Google is more interested in local aware advertising? What a shock.

Hey, if getting smacked by an ad for Duang Dee coffee in a street corner bistro in Chiang Mai means that one of my own customers in Thailand will still be able to order over my site....more power to Google.

More worldwide balancing please.
Adamos said…

It is not true that Google DNS and other similar services are faking geographic location of DNS server.
Apparently google's DNS is not a single machine, but world-wide cluster and from any point of the network it will reach the closes server.
Try tracerouting from your LAN.

Here is my traceroute from London.

traceroute to (, 30 hops max, 38 byte packets
1 *.*.*.* (*.*.*.*) 0.357 ms 0.298 ms 0.428 ms
2 *.*.*.* (*.*.*.*) 0.169 ms 0.146 ms 0.149 ms
3 ( 17.130 ms 16.180 ms 18.427 ms
4 ( 21.624 ms 18.482 ms ( 151.763 ms
5 ( 24.239 ms ( 20.658 ms 19.546 ms
6 ( 17.487 ms ( 17.494 ms 17.443 ms
7 ( 26.915 ms 17.598 ms ( 17.670 ms
8 ( 17.715 ms 17.842 ms 17.768 ms

Now, because server is closer, it does not use ip address for it's own lookups. So what I have found, that it's querying back my DNS by using address.
Geoiplookup reveals that it's located in Belgium.
So it works as for which continent / hemisphere it is. So it's good enough as it's below 15ms ping range, so european networks can have one GSLB distribiution points.

Popular posts from this blog

Chrome Frame - How to add command line parameters

Creating your first chrome app on a Chromebook

Brewers CAP Theorem on distributed systems