Boring exam days, anyways time for a quick blog post to keep taste in life. :)
One of my good friend informed me about eNom DNS servers failing randomly. He gave clothdiaperrevival.com as sample domain name for testing.
Quick Check from my home connection: anurag@laptop ~ $ dig clothdiaperrevival.com a @dns1.name-services.com +short 216.239.32.21 216.239.34.21 216.239.36.21 216.239.38.21 anurag@laptop ~ $ dig clothdiaperrevival.com a @dns2.name-services.com +short 216.239.36.21 216.239.32.21 216.239.38.21 216.239.34.21 anurag@laptop ~ $ dig clothdiaperrevival.
In last few days, I have been pushing discussion on APNIC & NANOG mailing lists about poor DNS infrastructure in India.
Thought to put a quick blog post on the issue.
So what’s exactly wrong?
To understand what’s wrong, let’s understand how DNS works at core level. DNS relies on a hierarchy model with . (dot) on top which is Root and TLD i.e Top Level Domains below Root, which further follow 2nd level domains which are popularly domain names we use.
Few days back I mentioned how reverse DNS setup of Airtel was incorrect. Sad to say it has not been fixed yet. In meanwhile I was looking at domain name - airtel.in the main domain which runs website for Bharti Airtel’s Indian operations. I am little surprised to find that DNS server of airtel.in are failing randomly! Problem: airtel.in uses 4 DNS servers from Mantra Online - a small ISP which Bharti took over years back.
This is a very popular mistake admins make - it’s missing . i.e dot in the end of hostname. This causes serious problems (and lot of frustration!).
E.g taking example of popular Google’s cname record ghs.google.com. As we know if one would like to use mail.domain.com., he has to point the CNAME record to “ghs.google.com”. Now here if one misses dot in the end of ghs.google.com. - it will give a real value like:
Seems like k-root servers are having issue again. This is not the first time BSNL is having such issues. Last year I reported issue with K root server (which was actually because of downtime at Delhi node). Here’s some data for today’s case: PING 193.0.14.129 (193.0.14.129) 56(84) bytes of data. 64 bytes from 193.0.14.129: icmp_req=1 ttl=44 time=309 ms 64 bytes from 193.0.14.129: icmp_req=2 ttl=44 time=312 ms 64 bytes from 193.0.14.129: icmp_req=3 ttl=44 time=312 ms 64 bytes from 193.