Reverse DNS lookup problem 1

[awingnut]

This is driving me nuts and I need some new eyes to figure out what I'm doing wrong. I have several subnets that are set up for reverse lookup. One is not working but for the life of me I cannot see what is wrong. The file loads on the master with no errors, however, when I attempt to look up addresses on that subnet, I get the SRVFAIL error. In addition, the 'named' log has a 'Lame server' error for that lookup. Can someone give me some ideas as to how to debug this? TIA.

 

[Kreichek]

Could You place here the content of the zone so that we can figure out whether there is a lame delegation or other misconfigured element?

---
Jordan Jordanov
Network administrator
Faculty of German Engineering Education and Industrial Management
Technical University of Sofia, Bulgaria

 

[awingnut]

Thanks for the reply. I thought I posted the zone but with the holiday and all, apparently not, so here it is:

$TTL 86400
128-26.55.158.72.in-addr.arpa.					IN	SOA	xserveoda.55.158.72.in-addr.arpa.	support.aimaudit.com.	( 
							2006052504	;       serial
							2H	;       refresh
							2H	;       retry
							1W	;       expiry
							1D	 ) ;       minimum
; nameservers

128-26.55.158.72.in-addr.arpa.					IN	NS	ns2.cl.bellsouth.net.	
128-26.55.158.72.in-addr.arpa.					IN	NS	ns3.cl.bellsouth.net.	
128-26.55.158.72.in-addr.arpa.					IN	NS	xserveobd.aimaudit.com.	
128-26.55.158.72.in-addr.arpa.					IN	NS	xservetwo.aimaudit.com.	
128-26.55.158.72.in-addr.arpa.					IN	NS	xserveone.aimaudit.biz.	

;hosts

130							IN	PTR	ImageONE-RAID.dev.aimaudit.com.
131							IN	PTR	aimwebserver.dev.aimaudit.com.
132							IN	PTR	4dserverxp.dev.aimaudit.com.
133							IN	PTR	aimdlink1.dev.aimaudit.com.
134							IN	PTR	xraidc1.dev.aimaudit.com.

 

[Kreichek]

Quite strange... Actually I even can't get the name servers authoritative for the domain. Here's what I get:

# dig -t ns 128-26.55.158.72.in-addr.arpa.

; <<>> DiG 9.2.1 <<>> -t ns 128-26.55.158.72.in-addr.arpa.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: [COLOR=blue red]NXDOMAIN[/color], id: 6872
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;128-26.55.158.72.in-addr.arpa. IN      NS

;; AUTHORITY SECTION:
158.72.in-addr.arpa.    10791   IN      SOA     ns.bellsouth.net. hostmaster.bellsouth.net. 2006060301 10800 3600 604800 10800

;; Query time: 7 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sun Jun  4 01:26:22 2006
;; MSG SIZE  rcvd: 110

Are you sure You have a delegation for the domain?

---
Jordan Jordanov
Network administrator
Faculty of German Engineering Education and Industrial Management
Technical University of Sofia, Bulgaria

 

[Kreichek]

Sorry, ignore my previous post. I think your domain is not correct. For the classless IN-ADDR.ARPA delegation to work properly there must be CNAME records pointing to the seperate domain for the PTR records. Have a look at this:

# dig -t cname 130.55.158.72.in-addr.arpa

; <<>> DiG 9.2.1 <<>> -t cname 130.55.158.72.in-addr.arpa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52103
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;130.55.158.72.in-addr.arpa.    IN      CNAME

;; ANSWER SECTION:
130.55.158.72.in-addr.arpa. 10531 IN    CNAME   130.[COLOR=blue red]128.55.158.72.in-addr.arpa.[/color]

;; AUTHORITY SECTION:
158.72.in-addr.arpa.    10641   IN      NS      ns.atl.bellsouth.net.
158.72.in-addr.arpa.    10641   IN      NS      ns.mia.bellsouth.net.
158.72.in-addr.arpa.    10641   IN      NS      ns.rdu.bellsouth.net.
158.72.in-addr.arpa.    10641   IN      NS      ns.bellsouth.net.

;; ADDITIONAL SECTION:
ns.atl.bellsouth.net.   290     IN      A       205.152.0.20
ns.mia.bellsouth.net.   6470    IN      A       205.152.16.20
ns.rdu.bellsouth.net.   6470    IN      A       205.152.32.20
ns.bellsouth.net.       6697    IN      A       205.152.0.5

;; Query time: 8 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sun Jun  4 01:44:18 2006
;; MSG SIZE  rcvd: 223

See, your domain is not 128-26.55.158.72.in-addr.arpa., but 128.55.158.72.in-addr.arpa.. I couldn't find another mistake...


---
Jordan Jordanov
Network administrator
Faculty of German Engineering Education and Industrial Management
Technical University of Sofia, Bulgaria

 

[awingnut]

Thanks for the reply and sorry to take so long to get back to this. To be honest it was so long with no reply, I had given up. This is still a problem for me that I need to resolve.

Your comment is very interesting. BellSouth only gave me 1/2 the class C. I wonder why it looks like we have the whole thing. Isn't that an ISP problem? I need to get this clear in my mind before I complain to them.

 

[awingnut]

Let me rephrase that. I thought to specify 1/2 a class c that the mask bits had to be included (26). I'm not sure what 128 without the mask bits is supposed to be. I'll try it.

 

[awingnut]

That certainly fixed it. However, I'm not sure what will happen when my ISP gives another part of that range to another user. Thanks.

 

[Kreichek]

Well, you are actually given exactly a half of what is called a class C-sized network, with 126 hosts. The subnet mask should be 255.255.255.128 or with prefix /25, not /26. In order to delegate you only the arpa domain for your hosts, your provider created the domain 128.55.158.72.in-addr.arpa and created CNAME records which point to hosts in that new domain. In that way it was possible to include in this domain only your hosts and delegate you only this domain so that you can manage it yourself. Anyway, your provider should inform you if he proposes to make any changes to this delegation in the future.

---
Jordan Jordanov
Network administrator
Faculty of German Engineering Education and Industrial Management
Technical University of Sofia, Bulgaria

 

[awingnut]

Thanks but they didn't give us 1/2 (that was a mistake on my part). They gave us 64 hosts (1/4) which is why I was using 26 bit mask. I doubt they will notify us if they make any changes. I'm sure we will find out the hard way. A least I understand what they did now. I should report the error to them and have them correct it proactively.