Part 1

Despite having set up this website as the internet presence for my company way back in October 2009, I only finally got round to implementing the geo-targeting component in January 2010. It turned out to be more difficult than expected, partially due to a lack of information about the topic and partially because what information there is was mostly written around 2003-2004 and has subsequently become out of date or in some cases, unavailable.

These notes were written to help others on the internet to repeat what we implemented here at ned Productions Ltd. for our own web hosting i.e. to configure their own geo-targeting DNS server aka. "poor man's geo-directional load balancing". From just US$5/month through this setup you can approach the sophistication of top-end commercial DNS services such as UltraDNS or Dyn Inc. who will charge you anywhere from US$50-US$200 a month upwards not including networking traffic charges. Note that I said approach - the one thing the big boys can do which no small operator can afford is Anycast DNS which allows a single DNS server to physically live in multiple geographic locations at once, and therefore to allow a uniformly low DNS query latency all around the planet. The best anyone without anycast can do is a sub-500ms time globally and sub-200ms time in the US and Europe - and no matter how much you spend on network quality, no one can beat those latencies because the speed of light is finite.

If you find the following too complicated, you can always hire our services either for Plone based webhosting or simply as a "man who can".

A Quick Overview of How Internet Services Work

Anytime you ever access anything on the internet, there are always two stages which are performed:

Stage 1: Resolving IPs

Internet servers - that being any computing device or part thereof which can be approached for data without prior agreement - provide services on a series of  numeric ports each of which is reserved for a certain kind of service. For example, to deliver email the port number is 25, to retrieve a web page it is 80 and to convert between internet server names and their unique number (an IP) it is port 53. There are hundreds more of these services, and each has its own unique port number.

A server may run many or none of these services - usually one doesn't allow public access unless one has a very good reason to do so. When a person types a web address into a web browser, it has the form of:

What happens here is the the http:// tells the web browser to contact the internet server called www.nedproductions.biz on port 80 using the HTTP protocol, and to fetch the content called /wiki. (The fact that the service type is duplicated is down to a quirk of history: the http:// specifies the service to the web browser, whereas the www. specifies the service at the DNS level. We'll see why this is important later).

However it doesn't end there yet: in order to contact the server called www.nedproductions.biz the web browser must find out what its "real" name is  as far as the computer is concerned i.e. its IP address which takes the form of a unique number. To do this, it asks whatever DNS server is configured on the local machine (usually the ISPs) to do the translation. If that DNS server doesn't know, it forwards its request to one which does which in this case would be the root nameserver for all .biz domains (which is currently operated by Neustar, the guys who provide the UltraDNS service above). It is configured by domain registrars with the nameservers capable of resolving each .biz subdomain, so in this case it will return ns1.nedproductions.biz as the primary nameserver as that is what is listed as the primary nameserver in that domain's whois.

The webserver then contacts that domain's primary nameserver and asks it to resolve what it thinks the "www." part is. This could be another subdomain of nedproductions.biz, or indeed another domain entirely in which case yet another traversal of the DNS servers will be required.

All this traversing takes time. Generally speaking, the root nameservers tend to be close to most of the rich world's population as is shown on this map so for them the first lookup tends to be not much slower than their broadband connection's latency. I live in Cork, Ireland and here's how long it takes to look up www.nedproductions.biz from my home:

~ # dig www.nedproductions.biz +trace                         [root @ untangle]

; <<>> DiG 9.5.1-P3 <<>> www.nedproductions.biz +trace
;; global options:  printcmd
.                       345760  IN      NS      E.ROOT-SERVERS.NET.
.                       345760  IN      NS      L.ROOT-SERVERS.NET.
.                       345760  IN      NS      J.ROOT-SERVERS.NET.
.                       345760  IN      NS      M.ROOT-SERVERS.NET.
.                       345760  IN      NS      H.ROOT-SERVERS.NET.
.                       345760  IN      NS      F.ROOT-SERVERS.NET.
.                       345760  IN      NS      G.ROOT-SERVERS.NET.
.                       345760  IN      NS      D.ROOT-SERVERS.NET.
.                       345760  IN      NS      A.ROOT-SERVERS.NET.
.                       345760  IN      NS      K.ROOT-SERVERS.NET.
.                       345760  IN      NS      B.ROOT-SERVERS.NET.
.                       345760  IN      NS      C.ROOT-SERVERS.NET.
.                       345760  IN      NS      I.ROOT-SERVERS.NET.
;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 63 ms

biz.                    172800  IN      NS      H.GTLD.biz.
biz.                    172800  IN      NS      B.GTLD.biz.
biz.                    172800  IN      NS      F.GTLD.biz.
biz.                    172800  IN      NS      G.GTLD.biz.
biz.                    172800  IN      NS      A.GTLD.biz.
biz.                    172800  IN      NS      E.GTLD.biz.
biz.                    172800  IN      NS      C.GTLD.biz.
;; Received 325 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 143 ms

nedproductions.biz.     7200    IN      NS      NS0.TNREV.COM.
nedproductions.biz.     7200    IN      NS      NS0.TNREV.ORG.
;; Received 94 bytes from 199.7.64.126#53(G.GTLD.biz) in 162 ms

www.nedproductions.biz. 60      IN      CNAME   www.geo.nedproductions.biz.
www.geo.nedproductions.biz. 3600 IN     CNAME   eu.iso.nedproductions.biz.
eu.iso.nedproductions.biz. 60   IN      CNAME   europe1.nedproductions.biz.
europe1.nedproductions.biz. 60  IN      A       94.23.159.78
;; Received 121 bytes from 98.142.216.143#53(NS0.TNREV.COM) in 150 ms

I have about a 60-65ms latency on my home ADSL line, so as you can see the bottommost TLD lookup is nearly as fast as it can be. Meanwhile looking up .biz takes 143ms, asking the .biz nameserver for the nedproductions.biz nameserver takes a further 162ms and finally to ask ns1.nedproductions.biz for www.nedproductions.biz takes yet another 150ms.

In other words, in the worst case scenario, going to a completely cold website from my house takes 63 + 143 + 162 + 150 = 518ms. This is before any web content is begun to be loaded! Luckily these servers cache their most commonly used lookups, so a realistic worst case scenario is more like 3x 63 + 150 = 339ms which is still a whole third of a second!

Now my ADSL connection is unusually laggy - I live many kilometers away from my exchange, so ultimately my internet browsing experience is always going to be poor no matter what I do. Most people will have negligble latencies for DNS lookups right up until the last stage because it will be that stage which is least frequently used.

So, to summarise, the first stage when loading a web page is to convert its name into an IP address. This happens once when you first visit a site and usually it doesn't need to be done again per daily site visit, so it's a once-off cost. If you can afford the services of one of the anycast DNS providers, you can reduce this first time cost to less than 100ms for anyone on the planet. If you can't, the best you can hope for is sub-500ms for all, sub-300ms for most and sub-200ms for Europe and the US.

Stage 2: Loading the Content

The second stage is to contact that IP address and ask for the page, and then to repeatedly recontact that IP address for each and every item the page loads in (e.g. images, CSS styling and so on). If that IP address is half a second away, your website will load very slowly indeed no matter what other optimisations you do simply because of the round trip times required.

Because of the finite speed of light, no matter where you place your server it's going to take half a second to access from somewhere in the world. For example, if you locate your server in Russia then you'll find that Australian visitors will experience very slow page loads, timeouts and other things which put them rapidly off using your site. Even if you locate your server in New York - currently the best globally connected place on the internet, the experience is always going to be subpar. For example, using the wonderful http://just-ping.com/ I found the following for my personal website http://www.nedprod.com/ which is located in the London Docklands in England:

As is fairly obvious, Europe gets the quickest access, then there is a jump to the East Coast of the US, then India & Russia along with the West Coast of the US, and finally another jump to Australia/Japan/China etc. The poor Australians must wait a minimum of 0.4 seconds per item when accessing nedprod.com which translates into a page load time of thirty to forty seconds!

It is for this reason that ideally speaking you'd want a set of geographically distributed servers and serving their own particular region - this way everyone gets much quicker access. If you run ping tests to various locations around the world you will find that the "centre" is roughly the East Coast of the US stretching as far west as India/Bangladesh and stretching as far east as Hong Kong. Therefore if you place one server in central Europe and another server on the West Coast of the US you can dramatically reduce the latency for global users.

I'll save you the suspense and show you the results for www.nedproductions.biz:

This is a much better result where all of the US and Europe is well under 100ms, all of Oceania is well under 200ms and even China with its latency inducing Great Firewall is sub-200ms (unfortunately India does not do well - it's 250ms+ from either of our servers). As you can see from the IP, it varies according to location and for the most part it gets the region correct (the obvious mistakes are Hong Kong and Singapore which are using the European server when I have configured their regions to use the US server - alas, the non-commercial IP-to-region mapping file is not perfect for all IPs).

To put this in perspective I have standardised the results by equally weighting the US and Europe and ranking by order:

Obviously how good this looks depends on how much weight one gives to Western countries seeing as we are testing European and US locations. However seeing as those two locations are the only two with reasonably priced server space, if one is looking for a poor man's geodirecting DNS solution  (i.e. not expensive) then you're probably going to be replicating my setup. And besides, if you could afford even two small content caching VPSs (one the northern coast of Australia and the other in India) then you could do wonders for the part of the red line where it exceeds 100ms - you could easily bring everywhere other than Africa under 100ms globally.

To put this in perspective a similar global infrastructure bought commercially would cost several thousand US dollars per month and tens of thousands of dollars per month if anyone uses it much. By doing the work yourself with low end VPSs you can get this under US$100/month for a two site setup - maybe even a four site setup if your web solution is economical on memory (e.g. a simple nginx + PHP).

Go here for the second part of this guide