Re: [webmin-l] Partial reverse domain naming convention

[Steve C. <cam...@cn...>]

Kris Deugau wrote:
> Steve Campbell wrote:
>   
>> After trying the above, and verifying the zone name that it creates, I 
>> find that the zone creates "ignoring out-of-zone data" errors in the log 
>> once I apply the changes. The only way I can get the zone to load is by 
>> creating a zone of the name xx.yy.zz and letting in name the zone 
>> zz.yy.xx.in-addr.arpa. This zone will load, transfer to a similarly 
>> defined slave, and everything else it's supposed to do. It's just not 
>> properly named.
>>     
>
> Hmm.  What naming convention are you supposed to use?  I've tried 
> several, and all load fine (BIND 9.3.4, on Debian Etch).  No complaints 
> about bad zone data either, despite my manually hacking the zone file 
> together.  (It was faster than using Webmin to do it.  <g>)  Data is 
> essentially identical in structure to example 3 in the O'Reilly book.
>
> Note that certain naming conventions WILL cause problems if the zone 
> file name is exactly the same as the zone name - there's no hard 
> requirement on BIND's part for that to be true, however.
>
>   
>> The old server is running the less restrictive Bind 8 and the new is 
>> running Bind 9. Not sure what part of the zone files Bind is checking 
>> against, but it thinks that those addresses aren't part of the reverse 
>> zone 0/25.zz.yy.xx.in-addr.arpa.
>>     
>
> Can you post any of the zone data here?
>
> -kgd
>
>   

Kris,

Here are the steps I use and the results of the entries:

Webmin -> Servers ->Bind -> Create Master Zone:
 Zone Type->Reverse (address to names) checked
 Domain Name/Network  ->12.109.111.0/25

The rest is standard input which is mostly the Internal View, the email 
address, etc.

The generates a zone file which whose contents are:
$ttl 38400
0/25.111.109.12.in-addr.arpa.    IN    SOA    cndns4.cnpapers.net. 
campbell.cnpapers.com. (
            1209035889
            10800
            3600
            604800
            38400 )
0/25.111.109.12.in-addr.arpa.    IN    NS    cndns4.cnpapers.net.

and which generates the zone info in named.conf:
zone "0/25.111.109.12.in-addr.arpa" {
        type master;
        file "/var/named/12.109.111.0_25.Internal.rev";
        };

At this point, the zone will load without errors.

Now, if I open the zone to add reverse addresses by clicking the newly 
created zone/view:
Add Reverse Address Record -> 12.109.111.11
Hostname -> Exchange-1.xxxxxxxx.yyyyyyy
Update Forward -> (either way)

The zone file looks like the following:
$ttl 38400
0/25.111.109.12.in-addr.arpa.    IN    SOA    cndns4.cnpapers.net. 
campbell.cnpapers.com. (
            1209035892
            10800
            3600
            604800
            38400 )
0/25.111.109.12.in-addr.arpa.    IN    NS    cndns4.cnpapers.net.
11.111.109.12.in-addr.arpa.    IN    PTR    Exchange-1.sleeponthebest.com.

And restart named, I start getting the "ignoring out-of-zone data, as 
shown by the logs.

Apr 24 07:26:52 cndns4 named[13875]: loading configuration from 
'/etc/named.conf'
Apr 24 07:26:52 cndns4 named[13875]: 
/var/named/12.109.111.0_25.Internal.rev:9: ignoring out-of-zone data 
(11.111.109.12.in-addr.arpa)
Apr 24 07:26:52 cndns4 named[13875]: zone 
0/25.111.109.12.in-addr.arpa/IN/Internal: loaded serial 1209035890.

This all works on the older servers running Bind 8. I have run 
named-checkzone in different ways and get little to help me. The 
out-of-zone message is sort of a catch-all for a lot of different 
problems like SOA records, Origin entries and the like, so I'm not have 
much luck.

It appears I may need to use some GENERATE$ lines somewhere - just not sure.

Now if I create a zone named in Webmin as  12.109.111, all works well 
locally, but this is not what is proper and not what was delegated to 
me. This is for a company outside of our ranks here, and we are doing 
this as a result of hosting their email and web services a while back. 
Whomever is transfering the Class C/25 range to us has specified what 
zone name we are to use, so I have little leeway there.

Another problem sort of related to this - I have inside and outside 
views. Bind requires a zone to be in both views if it's in either, 
although I think it just complains if it's not. Since the PTR records 
for both the inside and outside reverse zone are the same, I guess I 
still need both, but when I add a new reverse address, and specify that 
I want to update the forward address also, how does it know which 
forward zone to update? It doesn't seem to follow views in this respect, 
which make me think I'm not doing something right here also.

Thanks for the thought and time,

Steve