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!

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!

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.

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, 

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

Simple, isn’t it?

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

Have a rocking IPv6 year ahead!

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:

1. 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.
2. 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!

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!

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:

1. BSNL DNS resolvers – 218.248.255.194 & 218.248.255.196
2. Google Public DNS – 8.8.8.8 & 8.8.4.4
3. OpenDNS – 208.67.222.222 & 208.67.220.220
4. 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 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:

Next, localhost?

Anyways, so here’s ping summary:

1. BSNL – 28ms
2. Google Public DNS – 122ms
3. OpenDNS – 220ms
4. 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:

1. BSNL resolver took 28ms
2. Google Public DNS took  125ms
3. OpenDNS took 219ms
4. 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:

1. BSNL took 223ms
2. Google Public DNS took 398ms
3. OpenDNS took 487ms
4. 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:

1. 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.
2. 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.
3. 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.
4. 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.

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]

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]

i totally disagree to it …..

as per me:

Glue records – MOST fundamental DNS record which actually start the lookup!

Lets understand how to come in basic scenario……

Observe two sites – harisri.in & anuragbhatia.com

There’s a basic difference in terms of DNS in both sites. Nameservers of harisri.in are ns1.anuragbhatia.com & ns2.anuragbhatia.com which belongs to a totaly seprate zone, but nameservers for anuragbhatia.com are ns1.anuragbhatia.com, ns2.anuragbhatia.com & so….. i.e domain is having nameservers which are sub zones of  domain itself.

Working of DNS in both cases

anuragbhatia.com
Query for ns starts:

ISP->Root servers-gtld servers->returing ns – ns1.anuragbhatia.com, ns2.anuragbhatia.com and so with ip’s 66.117.40.216, 69.26.176.28…….

and thus got ip of resolvers…..so work of DNS is over.

Now observe route for DNS lookup of harisri.in

Query for ns starts:

ISP->root server->cc tld server- in servers->returning ns – ns1.anuragbhatia.com & ns2.anuragbhatia.com

Now important here is nameservers are given in form of hostnames (NOT ip) and thus a lookup will continue for resolving ns1.anuragbhatia.com and so in way as

ns1.anuragbhatia.com – seprating ns1. and lookng for anuragbhatia.com, got nameservers – ns1.anuragbhatia.com, and ns2.anuragbhatia.com with ip’s and now on those dns servers query will ask for ip for ns1.anuragbhatia.com (confusing here? …yes i know!)

This means if we want to get ns for anuragbhatia.com we will get ns1.anuragbhatia.com & ns2.anuragbhatia.com with ip’s BUT if we want ns for harisri.in, we will get ns in hostnames and a seprate lookup will be done to resolve those hostnames and important is ….whenever a domain has nameservers of any other domain, then nameserver’s host names are resolved on dns of 2nd and NOT via glue records……..

Thus now we can understand glue records as the MOST fundamental dns records which provide glue for a hostname on root servers.

And interesting fact is glue records are on root servers and NOT dns servers, though we MUST have corresponding A records on DNS hosting for every glue record.

A more interesting thing about these records is these have many names as per different registrars…….some call it nameservers records, some call it child nameservers, some give it as option for registering nameservers etc.
Thus a nameserver woeks with three most fundamental records:

1. Glue records (on root server of that tld)
2. A records corresponding to glue on dns host
3. NS records at dns host for deligating zone on those specific servers.

FAQ

Are glue records essential part of DNS?

Yes! they are…..you can have your site working without any glue records but at the end the nameservers you are using must have glue, e.g you can have nameservers of your site as ns1.your-web-host.com and your-web-host.com might have namesevers dns1.nameserver.com and then namesevers.com will be having ns1.nameserver.com thus….at last glue is on ns1.nameserver.com

How many glue records one can create?

Its virtually infinite but you might experience issues becoz of registrar limits.

Glue records, much similar to A records, can i use them as substitute to A records?

No, no and NEVER think of that.It will not work, as i already said that we MUST have A records entries for every glue record, thus as general glue records without any a is virtually nothing.

I  guess reason for its not working can be to prevent load on root servers, like if that way is allowed then people might use too many glue records without giving any load on their dns servers!

I can’t see any option like glue records in my domain control panel. What to do?

Contact your registrar/reseller, if they can’t help then shift your domain to any other registrar like – name, aapkadomain etc.

Is it necessary to have glue records if i want to use hostnames as nameservers for domains?

Confusing question, for now my answer is yes. I have tried using hostnames on name.com and Direct i when i didn’t had any glue records, all worked fine but when i tried entering those as namesevers for a domain on eNom, it gave errors.
i had nameservers like ns21.anuragbhatia.com & ns22.anuragbhatia.com which have A entried on namserver hosting anuragbhatia.com itself. And finally when i provided glue to those nameservers, they worked fine with eNom also. Thus thats all depends on regitsrar’s policies, and it will be always better to have glue for nameserver records.

What will happen if we have un-matched set a record and glue records for a given hostname?

Nothing will wrk!

i mean to say you will get arbit results. In fact a few months back it took me 1hr to find out a similar issue where i get different ip for a hostname from different locations. So all i can say – be careful!!!