Amazon AWS Route 53 GEO DNS Configurations

by on April 28, 2013 · 4 comments· LAST UPDATED April 28, 2013

in Amazon Web Services

You can send visitors to different servers based on country of their IP address using Amazon Route 53 cloud based dns server. For example, if you have a server in Amsterdam, a server in America, and a server in Singapore, then you can easily route traffic for visitors in Europe to the Amsterdam server, people in Asia go to the Singapore server and those in the rest of the world be served by the American server. This will results into the various kinds of benefits such as:

  1. Better performance as you are sending web site visitors to their nearest web server.
  2. Reduced load on origin.
  3. Geomarketing/online advertising.
  4. Restricting content to those geolocated in specific countries (I am not a big fan of DRM).
  5. In some cases you can get potentially lower costs and more.

In this post, I will explain how to configure and test GeoDNS using AWS Route 53 service.

Our sample setup

Fig.01: Sample geodns setup for HTTP/SMTP service

Fig.01: Sample geodns setup for HTTP/SMTP service


Please note that IPs (1.1.1.1) or CNAMEs (w.usa.cyberciti.biz) can be hosted by AWS or your own server anywhere in the world.

AWS Route 53 routing policy

From the Route 53 documents:

If your application is hosted on Amazon EC2 instances in multiple EC2 regions, you can reduce latency for your end users by serving their requests from the EC2 region for which network latency is lowest. Route 53 latency-based routing lets you use DNS to route end-user requests to the EC2 region that will give your users the fastest response.

It is possible to use Route 53's Latency Based Routing (LBR) feature with non-AWS endpoints or IP address. Route 53 don't restrict what IPs or CNAMEs you can tag with a region. AWS dns server will route traffic to those IPs/CNAMEs "as if" those IPs or CNAMEs were hosted in whichever AWS region you choose to tag. The following is the current list of regions supported by Route 53 LBR:

  1. Nothern Virginia, US: us-east-1
  2. Nothern California, US: us-west-1
  3. Oregon, US: us-west-2
  4. Ireland, EU: eu-west-1
  5. Singapore, Asia: ap-southeast-1
  6. Tokyo, Asia: ap-northeast-1
  7. Sydney, Asia: ap-southeast-2
  8. Sao Paulo, South America: sa-east-1

Configuration

First, open the Amazon Route 53 console at https://console.aws.amazon.com/route53/ > Choose your existing domain > Click on the Go to Record Sets button > Click on the Create Record Set button.

CNAME geodns settings for USA Dallas server

  1. Set Name to www.l.
  2. Choose Type to CNAME.
  3. Set TTL to 30 seconds.
  4. Set Value to w.usa.cyberciti.biz. seconds.
  5. Set Routing Policy to Latency.
  6. Set Region to us-west-1.
  7. Set ID to Dallas, TX, Data Center.
  8. Click the Create Record set button to save the changes.
Fig.02: CNAME geodns settings for Dallas/USA server.

Fig.02: CNAME geodns settings for Dallas/USA server.

Set an IP address for CNAME w.usa.cyberciti.biz

Visit the Amazon Route 53 console at https://console.aws.amazon.com/route53/ > Choose your existing domain > Click on the Go to Record Sets button > Click on the Create Record Set button.

  1. Set Name to w.usa.
  2. Set Type to A - IPv4 address.
  3. Set TTL to 30 seconds.
  4. Set Value to 1.1.1.1. Please replace IP address 1.1.1.1 with your actual AWS endpoint or any other valid public IP address in US.
  5. Set Routing Policy to Simple.
  6. Click the Create Record set button to save the changes.
Fig.03: Set an IP address for CNAME w.usa.cyberciti.biz.

Fig.03: Set an IP address for CNAME w.usa.cyberciti.biz.

Repeat this process for the rest of your HTTP and SMTP services. At the end, your setup should look like as follows:

Fig.04: Showing all CNAME and AWS geo mapping for each region (click to enlarge).

Fig.04: Showing all CNAME and AWS geo mapping for each region (click to enlarge).

Fig.05: IP address for all CNAMEs.

Fig.05: IP address for all CNAMEs.

Test it

Use the following dig or host dns lookup command line utilities to verify new settings:
% dig +short www.l.cyberciti.biz.
Sample outputs from various locations:

## Asia  ##
w.sg.asia.cyberciti.biz.
3.3.3.3
 
## Office in UK ## 
w.europe.cyberciti.biz.
2.2.2.2
 
## IDC in US ##
w.usa.cyberciti.biz.
1.1.1.1
 

The following images shows the accuracy of geo name-to-IP address resolutions around the world for www.l.cyberciti.biz:

Fig.06: Route 53 geo location accuracy

Fig.06: Route 53 geo location accuracy

Limitations

Use of proxy servers, third party DNS servers other than your ISPs and VPN may give a false geo location to end-users.

GeoIP limitations - Credit XKCD

GeoIP limitations - Credit XKCD

The dig command output from my home using Google free DNS servers:
% dig +short www.l.cyberciti.biz. @8.8.8.8
Sample outputs:

w.sg.asia.cyberciti.biz.
3.3.3.3

However, OpenDNS sent visitor to EU data center
% dig +short www.l.cyberciti.biz. @208.67.222.222
Sample outputs:

w.europe.cyberciti.biz.
2.2.2.2

Conclusion

The Route 53 provides a simple, and accurate geo targeting based on LBR. This is useful to direct traffic to a server geographically closer to the end-user. The server can be hosted with AWS or anywhere else in the world. The next logical step is to set up a database replication and upload your Python/PHP/Perl and other files (JS/CSS/Images) to servers so that end users can view the same content.

References
TwitterFacebookGoogle+PDF versionFound an error/typo on this page? Help us!

  • ChrisUeland

    nice article!

  • Gaurav Galia

    Excellent.. I am following you since I learn linux and most of the things I catch up from you are into productions.

    Thanks.

  • 4thaugust1932

    http://www.geoscaling.com/ offers free geo based DNS

  • Rahul Bansal

    Thanks for nice and I think only useful article around.

    Though, I did not get purpose of getting CNAME involved? Wont’ using A addressed directly will simplify records?

    Also, why not add health-checks as it could automatic failover?

Previous post:

Next post: