Google Public DNS and Akamai issues in India

A quick blog post on a interesting issue coming up due to combined problem of CDN failure on Google Public DNS and bad Akamai performance due to Tata-NTT peering issue.

 I was trying Zembra mail since there’s no more free Google Apps edition and one of my friend asked me to basic email on his domain up. It was more or less a straight task by installing Zembra with decent GUI.


I downloaded it on my Europe based server and during installation realized it was for 64 bit and thus I turned my head to my other server in India.
I started download again and it was slow. DEAD SLOW!


Something like this:

root@server2:~# wget
–2012-12-18 14:02:59–
Resolving (…,
Connecting to (||:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 701053545 (669M) [binary/octet-stream]
Saving to: `zcs-8.0.1_GA_5438.UBUNTU12_64.20121105164409.tgz.1′

0% [ ] 5,545,378 67.5K/s eta 2h 28m ^C


Would have taken 2hrs + on 512Kbps speed while server is on 100Mbps connection and I usually get 20Mbps or so for US/Europe based sources. Since I downloaded same 700MB file on Europe based server and it was quite fast 40Mbps+ while here just 512kbps.


I looked at route from Indian server and route was:

traceroute to (, 30 hops max, 60 byte packets
1 ( [AS36236] 1.310 ms 1.426 ms 1.716 ms
2 ( [AS17439/AS9584] 0.843 ms 0.951 ms 0.958 ms
3 ( [AS17439] 0.761 ms 0.762 ms 0.750 ms
4 * * *
5 ( [AS17439] 0.840 ms 0.938 ms 1.091 ms
6 ( [AS4755] 4.441 ms 3.891 ms 3.848 ms
7 * * *
8 ( [*] 27.175 ms 27.178 ms 27.927 ms
9 ( [AS6453] 143.917 ms 145.977 ms ( [*] 135.972 ms
10 ( [AS6453] 132.133 ms 133.902 ms 133.286 ms
11 ( [AS6453] 134.763 ms 133.217 ms 136.691 ms
12 ( [AS6453] 134.674 ms 137.558 ms *
13 * * *
14 ( [AS2914] 153.657 ms 155.550 ms 152.412 ms
15 ( [AS2914] 155.136 ms 151.697 ms ( [AS2914] 383.668 ms
16 * * *
17 * ( [AS2914] 271.296 ms 270.202 ms
18 ( [AS20940] 280.674 ms 282.407 ms ( [AS2914] 263.254 ms


Akami CDN node in Japan and route via Europe!!


This poor performance case is result of multiple issues:

  1. Datacenter is not running own DNS server but instead replying on Google Public DNS and which has upstream/full table connectivity outside in East Asia and not really in India. Thus Google DNS resolvers always pass IP of nodes outside India in Japan or sometimes in Malaysia. I blogged about it in detail sometimes back here.
  2. Datacenter is picking Tata-VSNL AS4755 for upstream for this route (not Airtel or Reliance), and interesting enough Tata does NOT peers with NTT Communications in Japan. They peer everywhere else except home market of NTT which I guess will be case with other ISPs as well. Thus nearest point for Tata to handle traffic to NTT is Europe which we can see in traceroute. 
  3. Since IP belongs to Akamai Japan, it brings traffic back to Asia over NTT Asia’s network and eventually passes it to Akamai. Strange that Akamai has not fixed this problem from long time. They must be knowing this since I posted this problem in NANOG mailing list last year and also blogged about it here.


OK – the fix!

I can surely do better then waiting for 2 hours to download that package! 
I quickly installed BIND and since BIND runs as “recursive resolver” by default, I simply pointed /etc/resolv.conf to

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# nameserver
# nameserver



OK – now running download again, let’s see how it works:


root@server2:~/tmp2# wget
–2012-12-18 14:31:55–
Resolving (…,
Connecting to (||:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 701053545 (669M) [binary/octet-stream]
Saving to: `zcs-8.0.1_GA_5438.UBUNTU12_64.20121105164409.tgz’

100%[============================================================================================================>] 701,053,545 3.07M/s in 3m 45s

2012-12-18 14:35:43 (2.98 MB/s) – `zcs-8.0.1_GA_5438.UBUNTU12_64.20121105164409.tgz’ saved [701053545/701053545]



Fast? Yeah a lot!



Simply doing a trace to destination this time takes me to: 

traceroute to (, 30 hops max, 60 byte packets
1 ( [AS36236] 2.089 ms 2.060 ms 2.047 ms
2 ( [AS17439/AS9584] 2.012 ms 2.002 ms 1.997 ms
3 ( [AS17439] 1.940 ms 1.949 ms 1.937 ms
4 ( [AS17439] 2.258 ms 2.668 ms 3.144 ms
5 ( [*] 2.199 ms 2.181 ms 2.174 ms
6 * ( [*] 1.683 ms 1.802 ms
7 ( [AS9498] 1.821 ms 1.775 ms 1.947 ms

An interesting case here is that NTT owns majority stake in Netmagic datacenter where this server is located! But likely they can’t do much since they need a license in India to offer their own network in Netmagic or simply peer more? 🙂


This is how I increased my download speed from 512Kbps to 24Mbps! 😉 

4 replies on “Google Public DNS and Akamai issues in India”

  1. Cool post. Maybe a little too technical for average users.
    Hey, do you any blog on speeding up internet connections in India??

    1. Hi Suresh
      Unfortunately there’s not much one can do about slow internet. Packets speed flow is capped by ISP and hence there’s no “easy trick” to make connection fast.

  2. Google Public Dns Finally started to work with Cdn networks in india. On Bsnl, Ping to akamai gets directed to akamai server on bsnl network.

Leave a comment

%d bloggers like this: