Understanding dot in the end of hostname

Dns, Networking

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.