8.4.4 reverse zone problems

[Kevin Darcy]

David Price wrote:

>I am having a problem with a BIND 8.4.4 server refusing to recognize a 
>reverse zone.
>
>I have a /20 block of IPs, for example lets say: 10.20.192.0/20. The 
>zone command in the named.conf looks like [[zone "20.10.in-addr.arpa" { 
>type master; file "20.10.in-addr.arpa.hosts"; };]]. The zone file then 
>contains a rather long list of all of our pointer records in the form of 
>[[192.1 IN PTR host.domain.com.]] (topped with the appropriate SOA and 
>NS records of course). This works well in 8.3.3. For some reason 8.4.4 
>behaves as if the zone command isn't even in the named.conf file - it 
>fails to respond to dig against the reverse zone. I tried everything I 
>could think of but 8.4.4 refuses to recognize the zone file. One thing I 
>tried was to use 192.20.10.in-addr.arpa for the zone. This seemed to 
>work for the 192.20.10.in-addr.arpa records anyway. So I'm thinking 
>there may be a problem with Bind 8.4.4 not recognizing the 
>larger-than-a-standard-C-block reverse zone.
>
>The platform is RedHat 7.3, BIND 8.3.3 works perfectly, and all the 
>forward zones work fine regardless of BIND version. Is this a BIND bug, 
>am I missing something, or am I doomed to break the huge zone file into 
>bunches of separate /24 sized zones?
>  
>
BIND is not netmask- or netclass-aware; it just views reverse zones and 
reverse records as a series of labels that just happen to be numbers. I 
have reverse zones in production at the /24, /16, /8 and /0 (i.e. the 
in-addr.arpa zone) levels.

Suggestions:
1. look at your log files for errors
2. run named-checkzone on the zone file and/or named-checkconf on the 
named.conf file
3. post your named.conf and/or zonefiles here (just a representative 
sample will do-- e.g. the zone "top" and a few of the PTR records, or 
the "options" block and a few zone definitions -- but don't try to 
"anonymize" anything otherwise you may unintentionally obscure the real 
cause of the problem).

- Kevin