13 Jan

Understanding dot in the end of hostname

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! 🙂

10 Jan

Poor performance of K-root server (Delhi node)

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.