creating a new zone on master, how to replicate on the slave ?

Kevin Darcy kcd at daimlerchrysler.com
Mon Mar 26 20:29:11 UTC 2001


adnet wrote:

> hi,
>
>  i try to set-up things so that when i create a new zone file in my
> named.conf and zone directory  the same thing get replicated to the
> slaves. For now on i must copy the named.conf with changing the "master"
> to "slave".
>
>  is there any way to do this once ?

For a limited, internal-root namespace, you could run a script on each
slave which walks the namespace and determines which zones to start/stop
slaving. That's what I do internally here.

If the namespace is too large for that, e.g. the Internet, then in theory
you could probably have a script on the slave search the logs for
NOTIFY messages, verify that it really should be slave for the zone(s), and
add it/them to the local named.conf. Since NOTIFY messages can get lost, or
logs can get truncated/corrupted, you could probably make this more robust
by having a script on the master which checks the slaves periodically for
recently-added zones and forces extra NOTIFYs until all of them
auto-configure themselves and become authoritative.

Another approach would be to have some sort of central repository of domain
names -- a "domain listing" -- stored in the DNS itself, e.g. some special
name which owns a bunch of PTR (yes, PTR) records representing domains to
be slaved. The slaves could periodically query or zone-transfer that name,
determine a "delta" (i.e. any adds or deletes, relative to the previous
list), and make the appropriate changes to their named.conf files. The
reason for using PTR records rather than, say, TXT records, is that
PTR records benefit from name compression (and of course there is nothing
that says PTR records must *only* be used for reverse records). The domain
list could potentially get rather large. In fact, if it gets too large, the
queries made by the slaves, if that is their method of accessing the list,
should be TCP queries right off the bat (as opposed to doing a default
UDP query, only to have a TCP retransmission), or one should consider
creating a special zone just for this domain list and replicating the list
out to the slaves via AXFR/IXFR. You may want to put access controls on
this list, because it could potentially be valuable information to a
hacker. Also, if different slaves should slave different sets of domains,
you could use the BIND 9 "view" mechanism to give a different list to each
slave.

And there's nothing to say that the last two approaches --
NOTIFY-scrounging and "domain listing" -- couldn't be *combined* to make a
very robust slave auto-configuration mechanism.

Of course, there are plenty of out-of-band ways to do slave
auto-configuration. I'm just listing some of the methods that could be
employed without using other protocols besides DNS. Generally speaking, the
more protocols one uses to get a particular job done, the more complex,
unreliable and potentially insecure the mechanism becomes...


- Kevin




More information about the bind-users mailing list