Secondary zone creation

[Kevin Darcy]

Ted Stephens wrote:

> Is there anyway to have the secondary zone automaticlly created? I am
> now going to the secondary name server and manully creating the zome.

There is nothing in the DNS protocol or in BIND to support this.
However, various folks have rolled their own scripts and whatnot to
automate this process. The basic approaches I'm aware of are:

1) For relatively-small namespaces, you can have a script running on the
slaves which walks the namespace tree, and updates the named.conf file
with zones to start/stop slaving,

2) You can scrounge the logs on the slaves looking for new
NOTIFY messages and, after appropriate verification (since NOTIFYs can
be spoofed), start slaving those zones. Since delivery of NOTIFYs is not
guaranteed, you may want to run a "slave driver" script on the master,
which checks for master/slave replication and keeps forcing NOTIFYs for
newly-added zones (by making dummy changes to them) until all the slaves
that should be replicating the zone are doing so. As for slave-zone
deletion, you can scrounge the logs looking for expired zones, or for
zones where the master is no longer answering serial-number queries
authoritatively. Be careful about the latter approach, however, since a
simple syntax error can cause the master to temporarily stop answering
authoritatively, and you wouldn't want all of your slaves becoming lame
in that scenario before there was time to detect and correct the problem
on the master.

3) Create a special name in one of your zones which is a "zone index",
i.e. a list of zones that a particular slave or set of slaves should be
slaving. You could use TXT or PTR records for this. The slaves would
review the list periodically -- either by making a special query, or
just looking in their slave copy of a zone, if the index is contained
there -- and then make the necessary changes to their named.conf files.
Some folks delegate a whole zone for the zone index. If you do that, you
could even use the "view" mechanism of BIND 9 to present different
versions of the list to different slaves.

4) Abandon AXFR/IXFR completely. Define all of the zones as "master" on
all of the nameservers, and then use some out-of-band replication
mechanism (FWIW, Dan Bernstein recommends rsynch-over-ssh) to copy both
the nameserver config files and zonefiles to the slaves. This approach
is fundamentally incompatible with using Dynamic Update to maintain your
zone data, however, since it massively breaks update forwarding.

Caveat: I only have direct experience with #1, which I use on our
intranet. The others I have only heard about second-hand.


- Kevin