anuragbhatia.com !!! » DNS

Concern about core DNS infrastructure in India

Anurag Bhatia — Mon, 12 Mar 2012 09:50:34 +0000

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.

So e.g mail.google.com is actually like

.
com.
google.com.
mail.google.com.

First 3 are real DNS zones with own delegation. Let’s see their DNS servers using dig:

anurag@laptop:~$ dig . ns +short
j.root-servers.net.
b.root-servers.net.
c.root-servers.net.
a.root-servers.net.
l.root-servers.net.
g.root-servers.net.
e.root-servers.net.
k.root-servers.net.
f.root-servers.net.
m.root-servers.net.
d.root-servers.net.
h.root-servers.net.
i.root-servers.net.

Next, com.

anurag@laptop:~$ dig com. ns +short
l.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
j.gtld-servers.net.
i.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.
k.gtld-servers.net.
m.gtld-servers.net.
c.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
b.gtld-servers.net.

Next, google.com.

anurag@laptop:~$ dig google.com. ns +short
ns2.google.com.
ns3.google.com.
ns4.google.com.
ns1.google.com.

So here dot was the “root zone” which is on top of hierarchy, next com is Top Level Domain, just like net, org, in, us etc. Next, google.com. is 2nd level domain. Nameservers which hold data for google.com domain name sit on gTLD servers of com while root holds ALL dns servers of all Top level domains. So root knows who knows about com/net/org/biz/asia/in/se/us etc.

There are 13 root servers in world theoritically but actual number is over 100 since they are using anycasting very much and have nodes across multiple places. You can read more on official site of Root Servers along with their location map here.

That was the fundamental part. Coming back on main point, what’s missing in India?

We have 4 root servers deployed at Delhi, Mumbai & Chennai which seems like decent number but there are NO gTLD servers at all. Thus India relies on external world for resolving gTLD domains like com/net/ org. This is real problem. If you are from India, I would suggest you to take traceroutes to each of gTLD servers i.e

l.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
j.gtld-servers.net.
i.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.
k.gtld-servers.net.
m.gtld-servers.net.
c.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
b.gtld-servers.net.

and pass me on directly on email or via comments on the page.

Here is my original post at NANOG mailing list.

airtel.in – bad DNS setup

Anurag Bhatia — Sun, 05 Feb 2012 20:18:45 +0000

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. Here are the DNS servers used by domain name:

aaadel.mantraonline.com.
dnsbom.mantraonline.com.
dnsdel.mantraonline.com.
dnsblr.mantraonline.com.

Now interesting part here is that out of these 4, only 1 behaves normally.

DNS server – dnsblr.mantraonline.com. seems working fine but rest all are rejecting queries “randomly” which is interesting. I have mostly seen DNS servers being up or down. This is probably first case when I can see DNS servers failing in random fashion.

Let’s query rest 3 DNS servers one by one:

anurag@laptop:~$ dig @aaadel.mantraonline.com airtel.in ns

; <<>> DiG 9.7.1-P2 <<>> @aaadel.mantraonline.com airtel.in ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 63903
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;airtel.in. IN NS

;; Query time: 81 msec
;; SERVER: 202.56.230.6#53(202.56.230.6)
;; WHEN: Mon Feb 6 01:25:20 2012
;; MSG SIZE rcvd: 27

In another 5 random tries, here’s what I get:

anurag@laptop:~$ dig @aaadel.mantraonline.com airtel.in ns

; <<>> DiG 9.7.1-P2 <<>> @aaadel.mantraonline.com airtel.in ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2044
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;airtel.in. IN NS

;; ANSWER SECTION:
airtel.in. 86400 IN NS dnsblr.mantraonline.com.
airtel.in. 86400 IN NS dnsdel.mantraonline.com.
airtel.in. 86400 IN NS aaadel.mantraonline.com.
airtel.in. 86400 IN NS dnsbom.mantraonline.com.

;; ADDITIONAL SECTION:
aaadel.mantraonline.com. 86400 IN A 202.56.230.6
dnsblr.mantraonline.com. 86400 IN A 202.56.250.5
dnsbom.mantraonline.com. 86400 IN A 202.56.240.5
dnsdel.mantraonline.com. 86400 IN A 202.56.230.5

;; Query time: 87 msec
;; SERVER: 202.56.230.6#53(202.56.230.6)
;; WHEN: Mon Feb 6 01:26:05 2012
;; MSG SIZE rcvd: 191

This time it worked. Pretty crazy. Same applies on other 2 DNS servers too:

anurag@laptop:~$ dig @dnsbom.mantraonline.com airtel.in ns

; <<>> DiG 9.7.1-P2 <<>> @dnsbom.mantraonline.com airtel.in ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 29601
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;airtel.in. IN NS

;; Query time: 82 msec
;; SERVER: 202.56.240.5#53(202.56.240.5)
;; WHEN: Mon Feb 6 01:28:21 2012
;; MSG SIZE rcvd: 27

anurag@laptop:~$ dig @dnsdel.mantraonline.com airtel.in ns

; <<>> DiG 9.7.1-P2 <<>> @dnsdel.mantraonline.com airtel.in ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34334
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;airtel.in. IN NS

;; Query time: 86 msec
;; SERVER: 202.56.230.5#53(202.56.230.5)
;; WHEN: Mon Feb 6 01:27:42 2012
;; MSG SIZE rcvd: 27

Pretty crazy case. Something is wrong at DNS servers itself – not sure what’s logic of rejecting queries randomly. But anyways – http://www.airtel.in will always open since 1/4 DNS server seems working normal. If that’s the case then Airtel still won’t be loosing much of traffic but unfortunately case is further complex.

Another problem…

Remember that 4 DNS servers mentioned here are the ones which are NS records at “airtel.in” zone at delegated servers. In other terms these are just servers which host and have NS entries for the zone but root nameservers of in-registry hold only 2 DNS servers in total which host zone. A quick whois check reveals that airtel.in is using:

Name Server:AAADEL.MANTRAONLINE.COM
Name Server:DNSDEL.MANTRAONLINE.COM

and thus missing the only server which gives consistent results. Incoming traffic never hits other 2 DNS servers which are just mentioned in NS.

Poor & bad DNS setup!

With hope that you hit right server this month rather then dead servers before reaching the working one, time for me to say Good night!

Understanding dot in the end of hostname

Anurag Bhatia — Thu, 12 Jan 2012 20:11:42 +0000

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:

mail.domain.com cname to ghs.google.com.domain.com – thus adding a domain name itself (many DNS control panels do take care of this issue, but quite a lot of them don’t).

So why does that happens?

To understand that, one has to remember that DNS is on a hierarchy based model with . (dot) as top level domain with other TLD’s like com, net, org etc below it i.e

So esstentially it’s much like pealing off. So for www.google.com, it’s like:

www.google.com.
google.com.
com.
.

So dot is at root level. It does has nameservers too!

anurag@laptop:~$ dig . ns +short
a.root-servers.net.
b.root-servers.net.
c.root-servers.net.
d.root-servers.net.
e.root-servers.net.
f.root-servers.net.
g.root-servers.net.
h.root-servers.net.
i.root-servers.net.
j.root-servers.net.
k.root-servers.net.
l.root-servers.net.
m.root-servers.net.

And thus if there’s no dot in end, it is (many times) assumed that the specified record value (say ghs.google.com) is a sub value under main zone and therefore the domain name itself is added making actual string like ghs.google.com.domain.com. and eventually nothing works!

And we see admins making faces like:

This not only applies to forward DNS, but reverse DNS too.

Here’s an interesting case of awfully crappy reverse DNS setup of domain name of popular Indian ISP – bharti Airtel. Domain name – airtel.in

Example of poor rDNS setup:

anurag@laptop:~$ dig airtel.in a +short
125.19.17.20
anurag@laptop:~$ dig -x 125.19.17.20 +short
;; Truncated, retrying in TCP mode.
www.airtelworld.com.17.19.125.in-addr.arpa.
www.myairtelmail.com.17.19.125.in-addr.arpa.
www.touchtelindia.com.17.19.125.in-addr.arpa.
www.airtelbroadband.in.17.19.125.in-addr.arpa.
www.airteltelephone.com.17.19.125.in-addr.arpa.
www.bharti-indiaone.com.17.19.125.in-addr.arpa.
www.bhartibroadband.com.17.19.125.in-addr.arpa.
www.airtel-broadband.com.17.19.125.in-addr.arpa.
www.airtelenterprise.com.17.19.125.in-addr.arpa.
www.airtellongdistance.com.17.19.125.in-addr.arpa.
www.live.airtelworld.com.17.19.125.in-addr.arpa.
www.airtel.co.in.17.19.125.in-addr.arpa.
www.airtel.in.17.19.125.in-addr.arpa.
www.masala.airtelworld.com.17.19.125.in-addr.arpa.
www.funplex.airtelworld.com.17.19.125.in-addr.arpa.
www.airtellive.com.17.19.125.in-addr.arpa.

So what’s really happening here?

Firstly IP has more then 1 PTR record – a configuration which is not recommended at all. Secondly, all of these records are incorrect because of missing dots.

Taking www.airtelworld.com as example. If admin wanted to have PTR of 125.19.17.20 pointed to www.airtelworld.com then it should be like:

20.17.19.125.in-addr.arpa. PTR www.airtelworld.com.

(but unfortunately it is like this right now):

20.17.19.125.in-addr.arpa. PTR www.airtelworld.com.17.19.125.in-addr.arpa.

Now, very likely they have configured reverse zones in /24 blocks so it will be like a 17.19.125.in-addr.arpa. zone and further on they can add IP addresses in sub levels like

1.17.19.125.in-addr.arpa.
2.17.19.125.in-addr.arpa.
3.17.19.125.in-addr.arpa.

in that manner

20.17.19.125.in-addr.arpa.

now, since admin missed a dot in the end of www.airtelworld.com PTR value, it resulted in addition of main zone which was 17.19.125.in-addr.arpa. in the end which turns out to be www.airtelworld.com.17.19.125.in-addr.arpa.

Completly incorrect and bad setup.

With hope that you won’t miss dot in the end of your hostnames, time for me to get back on cramming for next DDC exam!

Poor performance of K-root server (Delhi node)

Anurag Bhatia — Tue, 10 Jan 2012 11:12:53 +0000

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.0.14.129: icmp_req=4 ttl=44 time=312 ms
64 bytes from 193.0.14.129: icmp_req=5 ttl=44 time=313 ms

— 193.0.14.129 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 309.687/312.019/313.333/1.289 ms

Quick NS lookup for .com zone:

; <<>> DiG 9.7.1-P2 <<>> @193.0.14.129 com. ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43721
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;com. IN NS

;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.

;; Query time: 317 msec
;; SERVER: 193.0.14.129#53(193.0.14.129)
;; WHEN: Tue Jan 10 16:20:11 2012
;; MSG SIZE rcvd: 509

Looking at traceroute:

traceroute to k.root-servers.net. (193.0.14.129), 30 hops max, 60 byte packets

1 router.local (192.168.1.1) [AS8151/AS28513] 4.206 ms 5.041 ms 5.892 ms
2 117.212.40.1 (117.212.40.1) [AS9829] 32.243 ms 33.918 ms 36.122 ms
3 218.248.173.42 (218.248.173.42) [AS9829] 38.320 ms 42.492 ms 45.021 ms
4 203.190.136.17 (203.190.136.17) [AS9430] 337.645 ms 346.152 ms 346.837 ms
5 k.root-servers.net (193.0.14.129) [AS25152] 348.053 ms 349.664 ms 351.468 ms

Issue seems in connectivity between BSNL (AS9829) & AS9439 which belongs to Software Technology Parks Of India. Issue seems purely with BSNL and not with other major ISP’s like Bharti Airtel.

Checking K-root from Airtel Delhi node:

Tue Jan 10 16:34:48 GMT+05:30 2012
ping 193.0.14.129

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 193.0.14.129, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
DEL-ISP-MPL-ACC-RTR-9#

Next, traceroute from Airtel Delhi PoP to K-root:

Tue Jan 10 16:39:00 GMT+05:30 2012
traceroute 193.0.14.129

Type escape sequence to abort.
Tracing the route to k.root-servers.net (193.0.14.129)

1 218.100.48.6 0 msec 4 msec 0 msec
2 k.root-servers.net (193.0.14.129) [AS 25152] 0 msec 0 msec 0 msec
DEL-ISP-MPL-ACC-RTR-9#

All seems pretty good for Airtel.

Summary:

BSNL (AS9829) was earlier routing traffic directly to K-root server’s via RIPE NCC - AS25152 but because of some changes it’s now using STPI and which seems to be having badly choked port in niXi. BSNL should be using route to 25152:4 (RS-KROOT-DELHI) directly to fix this but I wonder if BSNL Network admins read my blog posts.

Btw my Web Designing exam tomorrow at college. Time to get start cramming!

Update:

17th Jan 2011

Issue seems fixed by now. Routing now direct skilling STPI.

Finding IPv6 from IPv4 address of a host

Anurag Bhatia — Mon, 02 Jan 2012 12:49:31 +0000

One of my friend asked me an interesting question about relating IPv4 with IPv6. His question was: in dual stack setup, if we have IPv4 of a router/host, how can we find IPv6 associated with it?

Well, as far as I know there’s no direct way to relate IPv4 with IPv6 but there’s a nice trick out. Say e.g we have Google Public DNS operating at IPv4 – 8.8.8.8. To find IPv6 address of same server (if it exists at all), we can lookup for reverse DNS to get hostname,


anurag@laptop:~$ dig -x 8.8.8.8 +short
google-public-dns-a.google.com.

Next, we can lookup for AAAA record associated with that hostname.


anurag@laptop:~$ dig google-public-dns-a.google.com. AAAA +short
2001:4860:4860::8888

Simple, isn’t it?

This actually works. Here’s a pure IPv6 DNS lookup:


anurag@server7:~$ dig @2001:4860:4860::8888 he.net aaaa
; <<>> DiG 9.7.1-P2 <<>> @2001:4860:4860::8888 he.net aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;he.net. IN AAAA
;; ANSWER SECTION:
he.net. 63215 IN AAAA 2001:470:0:76::2
;; Query time: 35 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Mon Jan 2 17:58:38 2012
;; MSG SIZE rcvd: 52

Have a rocking IPv6 year ahead!

Messed up SPF record of mtsindia.in domain

Anurag Bhatia — Fri, 02 Dec 2011 07:27:30 +0000

Yesterday I called MTS Data Card support but their IVRS system was failing in giving me my balance details. Eventually I decided to email their support and glad to say support email was also easily available on their website.

Today I saw acknowledgement mail in spam. No big deal but I usually dig around genuine mails which go in spam to find exact cause. In this case I found mail was sent to me from customercare.del@mtsindia.in and the server which relayed this mail was:

121.242.69.80 with rDNS pointer - mtsndmx1.mtsindia.in.

From email headers only one can tell main failure in mail:Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning customercare.del@mtsindia.in does not designate 121.242.69.80 as permitted sender) smtp.mail=customercare.del@mtsindia.in Thus clearly SPF failure. How?

Quick check on TXT record on root domain:

“v=spf1 a mx include:elabs5.com ~all” “v=spf1 ip4:208.43.252.104 ip4:208.43.252.105 ip4:208.43.252.106 ip4:208.43.252.107 ip4:173.192.233.178/28 ip4:173.193.227.227/27 ~all”

Here’s what’s wrong:

Two v=spf1 in SPF isn’t really good. Very likely most of systems will hit for TXT record and will get any on random and eventually use it ignoring whitelisted IP’s in other completely.
MTS missed to include 121.242.69.80 the server which is placed on Tata Communications backbone in SPF record. Most of other IP’s mentioned in their SPF belong to Softlayer datacenter.

Hope someone from MTS will find this post and eventually work on fix!

Dots in a hostname

Anurag Bhatia — Tue, 06 Sep 2011 18:54:45 +0000

Yesterday I had a very interesting discussion with our senior administrator.

I was configuring reverse DNS records for our /24 block and I decided to use format – IP.static.domain.com

thus if for IP 1.2.3.4, I pointed reverse DNS (PTR) to 1.2.3.4.static.domain.com

When I got chance to show my work to my senior administrator, he said – It’s wrong to use 1.2.3.4.static.domain.com in a hostname. Too many dots will make DNS resolution very slow (forward – reverse – again forward). And I should have used 1-2-3-4.static.domain.com

A very interesting point (and indeed a confusion!)

At first instance I was totally stunned myself and was thinking same as he said. He is senior admin and knows over a million more things then me and such feelings usually pushes you in case when you believe in someone without checking on facts.

(Disclaimer: No offence to my senior admin. He is a very smart person, and a good friend too).

After a while, I gave it a DEEP thought and discussed with a couple of more friends. I got clear idea about it.

Let’s understand how 1.2.3.4.static.domain.com will be resolved.

Here, first of all dns resolver will query com (root) servers for getting NS delegation of domain.com. Now as domain.com will reply with some NS (let’s call them ns1 & ns2). Next, DNS resolver will query ns1 for 1.2.3.4.static.domain.com and done – it will get back reply with A record – 1.2.3.4 (game over!). :)

Same thing happens even if we use 1-2-3-4.static.domain.com

So what “could have” caused slowdown?

There can be a significant slowdown IF for say in 1.2.3.4.static.domain.com

4.static.domain.com acts as a separate DNS zone rather then acting as nothing (when we create A record for 1.2.3.4.static.domain.com). If 4.static.domain.com has separate NS, and assume 3.4.static.domain.com is a further sub zone defined by some other NS …the one which are different then parent nameservers.

But in our case 4.static.domain.com or 3.4.static.domain.com or 2.3.4.static.domain.com is just nothing. The only thing was 1.2.3.4.static.domain.com which was simply an A record on parent domain name.

Hence 1.2.3.4.static.domain.com is same as 1-2-3-4.static.domain.com and I assume it’s rather an issue of convention admins prefer rather then any technical reason behind it.

Oh and btw I am back at blogging!

Which DNS resolver is good for you?

Anurag Bhatia — Thu, 27 Jan 2011 09:03:15 +0000

Which DNS resolver is better – ISP’s (default) DNS resolver, or Google Public DNS or the pioneer of DNS openDNS or even a local DNS server?

Let’s try to find out!

I am sitting on a BSNL data link, and I will try to perform few tests to find that out:

Available DNS resolvers to me:

BSNL DNS resolvers – 218.248.255.194 & 218.248.255.196
Google Public DNS – 8.8.8.8 & 8.8.4.4
OpenDNS – 208.67.222.222 & 208.67.220.220
Local DNS Server – BIND running on localhost – 127.0.0.1

Observing ping time:

BSNL DNS resolver:

— 218.248.255.194 ping statistics —

5 packets transmitted, 4 received, 20% packet loss, time 4001ms

rtt min/avg/max/mdev = 26.978/27.754/29.122/0.897 ms

— 218.248.255.194 ping statistics —5 packets transmitted, 4 received, 20% packet loss, time 4001msrtt min/avg/max/mdev = 26.978/27.754/29.122/0.897 ms

Google Public DNS:

— 8.8.8.8 ping statistics —

5 packets transmitted, 5 received, 0% packet loss, time 4001ms

rtt min/avg/max/mdev = 121.147/121.878/122.951/0.783 ms

OpenDNS:

— 208.67.222.222 ping statistics —

5 packets transmitted, 5 received, 0% packet loss, time 4005ms

rtt min/avg/max/mdev = 217.678/219.528/222.034/1.717 ms

Next, localhost?

Pinging local DNS server makes no sense as reply will be in less then 1ms!

Anyways, so here’s ping summary:

BSNL – 28ms
Google Public DNS – 122ms
OpenDNS – 220ms
Local DNS server – N/A

Next, we will try asking IP address of popular site facebook.com to all of these.

Here’s a sample query:

;; QUESTION SECTION:

;facebook.com. IN A

;; ANSWER SECTION:

facebook.com. 1022 IN A 69.63.189.11

facebook.com. 1022 IN A 69.63.189.16

facebook.com. 1022 IN A 69.63.181.12

;; Query time: 28 msec

;; SERVER: 218.248.255.194#53(218.248.255.194)

;; WHEN: Thu Jan 27 13:44:57 2011

;; MSG SIZE  rcvd: 248

We can see, BSNL resolver passed the IP almost instantly for a popular site. Popular here simply means that resolver must be having the record within it’s cache as per TTL of the zone.

Observing resolution time:

Asking for IP of facebook.com to rest of DNS servers, here’s summary:

BSNL resolver took 28ms
Google Public DNS took 125ms
OpenDNS took 219ms
Localhost took 558ms

We see a very big value from local host here. Reason, it had to find the IP via root DNS servers. In my case, this local DNS resolver used – b.gtld-servers.net (closest) to get Authoritative DNS servers of “facebook.com” and next, it asked those DNS servers for the IP of facebook.com

Note: Further anymore queries to facebook.com using local DNS will take almost 0ms for next 1022 seconds as defined in DNS zone of facebook.

So for a popular site – clearly BSNL DNS resolver is winner based on responce which is 5 times faster then Google Public DNS and almost 10times faster then OpenDNS.

Next, we try to find how much time it takes to resolve a less popular domain – crazybeam.com

(less popular = no caching of records at resolver)

Time taken by all resolvers:

BSNL took 223ms
Google Public DNS took 398ms
OpenDNS took 487ms
Local DNS server took 667ms

As we can see – BSNL resolver took quite more time here but still very low. Local DNS resolver took almost same time to resolve a less popular domain as it took to resolve a popular domain – reasons remains – no caching.

So finally, here’s the summary explaining results and recommendation of which resolver to use:

Google DNS is better then OpenDNS for India since OpenDNS has no mirrors in India. Closest mirror is Singapore, but actually most of data seems being routed from London. Here’s a traceroute for reference.
Running a local DNS server is good if you have mid-size organization where you have atleast 1000+ users. This will help in building a decent DNS cache which will servce queries instantly apart from saving bandwidth used for DNS lookups.
Local ISP DNS servers seems very good in initial testing based on very low latency values they give BUT remember – there’s a big problem associated with BSNL DNS resolvers – they do not store most of records till TTL is complete. That is – they perform very good for cached values as we can see, but they seem discarding cached records well before expiry of TTL. This makes them bit poor in performance as this does not happen with Google or openDNS at all. Hence for popular domains, Google takes ~120ms, while BSNL takes 220ms. OpenDNS remains bit slow for India.
Apart from that, one of other big problems perticularly with BSNL DNS servers is – they constantly time out thus giving high packet loss, and causing “Name not found” errors.

So finally my recommendation – if you are on Indian ISP network, it’s good to use Google Public DNS.

More about SPF records

Anurag Bhatia — Wed, 05 Aug 2009 11:03:26 +0000

Hello all!

Few days back I visited Official Google Apps forum (one of my favorite places ) and answered many questions. It was quite after some time i was there and found few cases/questions/problems as really interesting.

Here’s one of the questions asked there by a admin named aol985 about SPF records.

His question -

As described in http://www.google.com/support/a/bin/answer.py?hl=en&answer=33786 , I set SPF record for mashfilm.ru domain to “v=spf1 include:aspmx.googlemail.com ~all”. But aspmx.googlemail.com currently does not resolves. Is it correct?

Nice one!

He is right on fact that aspmx.googlemail.com does NOT resolve. Ok why?

anurag@root]$ dig aspmx.googlemail.com a

; <<>> DiG 9.3.4-P1.1 <<>> aspmx.googlemail.com a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42050
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aspmx.googlemail.com.          IN      A

;; Query time: 100 msec
;; SERVER: 66.33.216.208#53(66.33.216.208)
;; WHEN: Wed Aug  5 02:48:00 2009
;; MSG SIZE  rcvd: 38

[anurag@root]$

Thus no A record which means it won’t resolve, BUT one must remember that a zone can have many records working side by side offering their own feature, like – MX records can be there with/without A, same with txt records, and few other also.

Now observing the spf record by Google – “v=spf1 include:aspmx.googlemail.com ~all”

here include:aspmx.googlemail.com

means to include the spf record of aspmx.googlemail.com which makes sense as:

[anurag@root]$ dig aspmx.googlemail.com txt

; <<>> DiG 9.3.4-P1.1 <<>> aspmx.googlemail.com txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30134
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aspmx.googlemail.com.          IN      TXT

;; ANSWER SECTION:
aspmx.googlemail.com.   7178    IN      TXT     "v=spf1 redirect=_spf.google.com"

;; Query time: 14 msec
;; SERVER: 66.33.216.208#53(66.33.216.208)
;; WHEN: Wed Aug  5 02:54:02 2009
;; MSG SIZE  rcvd: 82

[anurag@root]$

Now it means spf record for aspmx.googlemail.com is “v=spf1 redirect=_spf.google.com”

Now trying to understand _spf.google.com

underscore right in start makes it different from a sub-zone since it can’t be used as a domain but will still remain a working sub zone in terms of DNS.

So now since it can’t be used as a sub domain i.e which can be used to be attached with web server and can supply pages via ftp, there is no meaning of A record for it here.

Checking txt string of _spf.google.com

[anurag@root]$ dig _spf.google.com txt

; <<>> DiG 9.3.4-P1.1 <<>> _spf.google.com txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52983
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf.google.com.               IN      TXT

;; ANSWER SECTION:
_spf.google.com.        300     IN      TXT     "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all"

;; Query time: 29 msec
;; SERVER: 66.33.216.208#53(66.33.216.208)
;; WHEN: Wed Aug  5 02:57:26 2009
;; MSG SIZE  rcvd: 229

[anurag@root]$

And here we got it!

So much information in just one hostname!

“v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all” is a part of SPF record which Google makes its Google Apps users to use.

Thus using

“v=spf1 include:aspmx.googlemail.com ~all” in spf tells that “this domain allows all of the server on this ip range – ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 as authorized to send email on behalf of that domain.

So that’s how spf works in this case.

[ratings]

Google’s SRV records

Anurag Bhatia — Mon, 02 Feb 2009 13:10:01 +0000

After recieving lots of emails regarding SRV records issue in Google Apps, i finally tried that in myeslf……unfortunately thats true that Google has missing info. about SRV records.

As per refering to official Google’s help here .

It has missing info. about the location servers.

Here are those missing SRV records…

_xmpp-client._tcp.YOURDOMAIN.TLD. IN SRV 5 0 5222 talk.l.google.com.

_xmpp-client._tcp.YOURDOMAIN.TLD. IN SRV 20 0 5222 talk1.l.google.com.

_xmpp-client._tcp.YOURDOMAIN.TLD. IN SRV 20 0 5222 talk2.l.google.com.

_xmpp-client._tcp.YOURDOMAIN.TLD. IN SRV 20 0 5222 talk3.l.google.com.

_xmpp-client._tcp.YOURDOMAIN.TLD. IN SRV 20 0 5222 talk4.l.google.com.

so finally saying…..just forget everything and have these SRV records to get your domain’s Gtalk working from external IM services…

I created a public G.docs spreadsheet here for easy viewing.

Feel free to post for any issues…

FAQ ON GApps SRV Records

[faq list Google Apps SRV Records]

[faq ask Google Apps SRV Records]

Hope this will help you out

[ratings]