Confused about /24 in-addr.arpa NS delegation debug problem

Gary Wallis wgg1970 at gmail.com
Thu Jan 6 23:30:20 UTC 2011


(Some dig output lines deleted to keep short)

Why does this not work (but below next dig with +trace seems to imply 
that it should?):

[root at web0 /]# dig -x 81.95.147.100

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> -x 81.95.147.100
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10895
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;100.147.95.81.in-addr.arpa.    IN      PTR

;; Query time: 489 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Fri Jan  7 02:20:28 2011
;; MSG SIZE  rcvd: 44

But this returns the PTR: (WTF?)

[root at web0 /]# dig -x 81.95.147.100 +trace

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> -x 81.95.147.100 +trace
;; global options:  printcmd
.                       80166   IN      NS      j.root-servers.net.
.                       80166   IN      NS      i.root-servers.net.
...snip
.                       80166   IN      NS      b.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 83 ms

arpa.                   172800  IN      NS      f.root-servers.net.
arpa.                   172800  IN      NS      b.root-servers.net.
...snip
arpa.                   172800  IN      NS      e.root-servers.net.
;; Received 508 bytes from 192.58.128.30#53(j.root-servers.net) in 165 ms

81.in-addr.arpa.        86400   IN      NS      SEC1.APNIC.NET.
81.in-addr.arpa.        86400   IN      NS      SEC3.APNIC.NET.
81.in-addr.arpa.        86400   IN      NS      NS3.NIC.FR.
81.in-addr.arpa.        86400   IN      NS      NS-PRI.RIPE.NET.
81.in-addr.arpa.        86400   IN      NS      TINNIE.ARIN.NET.
81.in-addr.arpa.        86400   IN      NS      SNS-PB.ISC.ORG.
81.in-addr.arpa.        86400   IN      NS      SUNIC.SUNET.SE.
;; Received 223 bytes from 192.5.5.241#53(f.root-servers.net) in 166 ms

147.95.81.in-addr.arpa. 172800  IN      NS      ns1.theplanet.com.
147.95.81.in-addr.arpa. 172800  IN      NS      ns2.theplanet.com.
;; Received 93 bytes from 202.12.29.59#53(SEC1.APNIC.NET) in 317 ms

147.95.81.in-addr.arpa. 86400   IN      NS      ns2.callingcloud.net.
147.95.81.in-addr.arpa. 86400   IN      NS      ns1.callingcloud.net.
;; Received 96 bytes from 207.218.247.135#53(ns1.theplanet.com) in 106 ms

100.147.95.81.in-addr.arpa. 86400 IN    PTR     ns3.callingcloud.net.
147.95.81.in-addr.arpa. 86400   IN      NS      ns1.callingcloud.net.
147.95.81.in-addr.arpa. 86400   IN      NS      ns2.callingcloud.net.
147.95.81.in-addr.arpa. 86400   IN      NS      ns3.callingcloud.net.
;; Received 176 bytes from 174.121.136.101#53(ns2.callingcloud.net) in 
106 ms


The Planet (now SoftLayer) supposedly has setup straight class C 
delegation to ns1/2.callingcloud.net

What am I missing here? What dig command can point to the delegation 
problem?


Thanks for any advice, hints or even the bloody answer.


---
PD

The ns1/3 NSs work as expected:

[root at web0 /]# dig @ns1.callingcloud.net -x 81.95.147.100 +short
ns3.callingcloud.net.
[root at web0 /]# dig @ns2.callingcloud.net -x 81.95.147.100 +short
ns3.callingcloud.net.
[root at web0 /]# dig @ns3.callingcloud.net -x 81.95.147.100 +short
ns3.callingcloud.net.





More information about the bind-users mailing list