Wild card in named.conf for multple PTR zones (or h2n help)?

Andris Kalnozols 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.

------
Andris



More information about the bind-users mailing list