How can I send visitors to the closest server using DNS?
Solution 1:
Yes, there are currently two popular solutions to this problem.
The first is called Anycast, where the same IP block is literally in use in multiple locations around the world. That is to say, the name servers for your domain always return the same IP address, but that IP address is actually assigned to more than one set of physical servers.
You can read more about it here http://en.wikipedia.org/wiki/Anycast
The second technique again involves AnyCast, however this time, the IP address range being anycasted referes to our name servers themselves. As the nameservers will only requests from clients who they are closest too (as determined by the magic of BGP), they can themselves return IP addresses that are logically local to the client.
An example of this is google's l.google.com domain
From a host in Australia
crimson:~ dave$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com is an alias for www-notmumbai.l.google.com.
www-notmumbai.l.google.com has address 66.249.89.99
www-notmumbai.l.google.com has address 66.249.89.147
www-notmumbai.l.google.com has address 66.249.89.103
www-notmumbai.l.google.com has address 66.249.89.104
From a host in the US
[dave@odessa ~]$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.95.99
www.l.google.com has address 74.125.95.147
www.l.google.com has address 74.125.95.104
www.l.google.com has address 74.125.95.106
www.l.google.com has address 74.125.95.105
www.l.google.com has address 74.125.95.103
So, the CNAME for www.google.com resolves to www.l.google.com, but when you resolve that, depending on your location, your client receives a different set of IP addresses. This is because the name server that received the request for www.l.google.com was the local nameserver, relative to the client.
Solution 2:
I had same problem. Our company has customers in Russia and China and they all need very fast connection to our service. We used Amazon Route 53 Geo dns and just created two records, one will route customers from China to our Tokyo region cluster and customers from Russia to London.
Solution 3:
If you only want to localise servers for Asia, North America and Europe, then you could decide to run both your webapp and your DNS yourself.
With DNS, you could use something like the Split-Horizon DNS approach, which could either be achieved through integrated functionality of your DNS server (they may call it GeoDNS), or through a firewall that would redirect different IP-address ranges to different running instances of your DNS server (you could run several different copies of the server on your local machine, which will listen at different local IP-addresses).
You could probably get expected results in ≈90% of cases by replying to DNS requests from RIPE and AfriNIC IP-addresses with an A record of your host in Europe, requests from APNIC — host in Asia, and requests from the IP-addresses from the /8 blocks administered by ARIN, LACNIC and the rest of the /8 address space with an A record of your server in North America. This will have some wrong results in certain situations (some /8 blocks are shared between Europe and North America, some address space is anycast etc), but the worst that would happen is some extra latency to the affected party, so, it shouldn't be a big deal.
(And, yes, there should be a way to make these things easier, but, so far, it seems like there is none.)