Wild card in named.conf for multple PTR zones (or h2n help)?
andris at hpl.hp.com
Fri Apr 3 04:05:21 UTC 2009
> From: "Mike Bernhardt" <bernhardt at bart.gov>
> We use h2n to generate our db files, but NOT to generate named.conf. We
> recently add the network 10.160.0.0:255.240.0.0 to h2n, which then generated
> db.10.160, db.10.161, etc.
> All of these 16-bit networks will reside in the same zone. Is there a way to
> either get h2n to generate one db for the entire range, or to configure
> named.conf to use all 16 db files in one zone statement?
The simplest and most "natural" way to get the PTR records for 10.160/12
into a single zone file would be to create them in a "db.10" file that
represents the "10.in-addr.arpa" zone. To do that in h2n, just use
"-n 10/8" or "-n 10:255.0.0.0" instead of "-n 10.160.0.0:255.240.0.0".
If you have the situation where there are portions of 10/8 that are
delegated to other name servers, i.e., a "spcl.10" file exists with
the following records:
; Delegate the 16 16-bit `in-addr.arpa' zones representing
; 10.144.0.0/12 to the SFO name servers.
$GENERATE 144-159 $ NS sfo1.bart.gov.
$GENERATE 144-159 $ NS sfo2.bart.gov.
then use the following h2n options:
-n 10/8 mode=S # declare network space to be a supernet
-a 10.144/12 # do not create PTRs for delegated address space
Without the "mode=S" argument, h2n would assume that the overlapping
network spaces was unintended and issue an error message.
More information about the bind-users