Dns-operations mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

I have been working on a newer version of the script to address a number
of issues.  For anyone interested in testing it out, it is probably best
to keep the new script in its own folder, separate from the original
t1zone script.  The new code has been renamed to reflect the fact that
this is no longer only meant for the T1 servers -- the code is working
equally well on T2 servers.

The new code can be found here: http://opennic.oss/opennicZone/
The files you want are checkZone.sh, makeZone.sh, makeZone.child, and
opennicZone.conf.dist (which should be renamed to opennicZone.conf after
your changes are made).

Also of note is zone.example, which shows how the zone file has
changed... Comment lines have been added to the beginning of each zone
showing the master info along with the contact for that zone.  Note that
under "bbs" there is a 'Source' comment showing that the master server
was likely not responding at the moment I ran the script (may be of use
for troubleshooting).  The "oz" zone shows how the scripts deal with
serial number reversions, rejecting any server with a higher serial than
the master has.

There may be other files in the folder as I run testing, but they can be
ignored.

--------------------

Changes of note:
- First off, ALL of the filenames have been changed.  "checkZone.sh" is
now the script to run from crontab.  If you simply want to generate a
new zone.opennic file, you can run "makeZone.sh".  If you want to
generate the zone info for a single TLD, call "makeZone.child <TLD>".

- I run this script from a shared NFS folder.  With that in mind, the
config files are now built in folder $HOSTNAME so that there is no
overlap between machines.  If you run "makeZone.sh", the completed
zone.opennic file will be in that folder, rather than outputting to the
console.

- Your old config file should work, but there are new entries available
now.  I also found a smoother method of building arrays, which you may
want to use.  Of particular importance - don't miss the command path
entries at the beginning of the config file.  ALL of these entries are
required in your config file.

- Config files can now be saved either in the same folder as the
scripts, or in /etc/.  The expected filename is "opennicZone.conf".  If
you run this script from multiple servers, you could store the common
parts of the config in the script folder, and put machine-specific
config options in /etc/opennicZone.conf.  For instance, only one of my
servers is running in chroot, so on that machine I have an entry in
/etc/opennicZone.conf for CHROOTNAMEDCONF.

- The config option xIP[] can now also contain server names (such as
ns2.opennic.glue).  When found, this name will exclude on both ipv4 or
ipv6.

- Each zone is generated under its own child process.  The multitasking
allows the script to run in about a minute and a half now.  CPU usage
should still be very minimal, as most of the time spent generating the
zones is in waiting for the master servers to reply to queries.

- This script will work equally well for either a T1 or T2 server

- Auto-detection is attempted to determine if the machine running the
script is a T1 server hosting any of the TLDs.  It checks ifconfig for
any IPs (ipv4 and ipv6) which match the master server for each zone.
This is done by resolving the hostname (for instance, ns2.opennic.glue)
locally.  If your DNS is configured to provide your NAT address (for
instance 10.0.0.1), then this could also create a match for marking
yourself as the master of the zone.  This feature allows me to use the
same config file for all of my T1 and T2 servers.  Please let me know if
you see any quirks with this feature!

--------------------

One issue I am still working on... My test server is running the script
under the bind user in a fully chrooted setup.  After a new zone file is
created, the following command is run:

# /usr/sbin/named-checkconf -t /var/chroot/bind9/ /etc/bind/named.conf

which results in the following error: "isc_dir_chroot: permission
denied".  I have been through my chroot folder, and the file permissions
appear to be correct, but if anyone is interested in helping to
troubleshoot the problem, I can supply more detail.  Note that the same
command works perfectly when run as root.