Zone created on master --> automatic add/transfer on slave servers possible?
kcd at daimlerchrysler.com
Fri Jan 21 03:19:38 UTC 2005
pbox at fantasymail.de wrote:
>Well you have right but i wasnt able to believe this. Its a pain
>to add 1 zone on each nameserver separately. I saw a lot in the
>mail archives. My simple hope was that there is a option that can
>be used in named.conf that the primary dns "talk" to the defined
>slave servers and force them to add the slave zone self to be
>able to accept the zone informations (with xfer or which option
>is be there for it).
>If anyone know a solution for this please let me know,thanks!
>Barry Margolin schrieb:
>>In article <csld56$2mm7$1 at sf1.isc.org>,
>>"pbox at fantasymail.de" <pbox at fantasymail.de> wrote:
>>>I am very confused with the configuration settings between
>>>master .ns1 (primary) and slave ns2-ns4 (i run 3 slave servers)
>>>servers. I did much rftm and searched in that list or with google.
>>>My simple question is - whether its possible that slave servers
>>>can create on request from the primary dns the zone and accept
>>>the update automaticly when i add a zone on primary dns.
>>>Is this possible? Its a waste of time to add the zones always by
>>>hand on 4 different dns servers. I hope anybody can help me!
>>This has got to be the MOST frequently asked question in this group.
>>Did you try searching the archives before asking?
>>The answer is that the DNS protocol provides no mechanism for this. But
>>it shouldn't be hard for you to write a script in a language like perl
>>that reads your master's named.conf and creates a named.conf file for
>>the slaves, and then uses scp to copy it over to them.
As Barry said, there's nothing in the DNS protocol for this. And since
BIND sticks pretty close to the protocol specs, there's nothing in BIND
either. Commercial products, whether they be built on BIND or some other
codebase, of course add their own value in this regard. But I assume
you're looking for something free.
I use a couple of different methods in order to keep the slave-zone
definitions on my slave boxes up to date automatically:
1) for the internal DNS, since the (internal-root) namespace is very
limited, I have the slaves walk the tree, with some "pruning" rules
(e.g. don't descend into a part of the namespace if you don't recognize
at least one of the nameservers delegated the apex of that namespace),
and based on what they find in the NS records, make intelligent
decisions about what they should be slaving and what they should not.
This methodology doesn't require anything special to be configured when
a zone is created or deleted, and
2) for the external DNS, obviously walking the tree is not feasible, so
instead I maintain a special zone, which has one apex PTR record in it
for each zone to be slaved (the reason I use PTRs instead of TXTs like
some others do, is because PTRs can actually benefit from label
compression, and I'm a little compulsive when it comes to saving a few
bytes here or there). All of the slave boxes are slaves for this special
zone too, and periodically check its contents to see if they should
start slaving or stop slaving particular zones. This methodology
requires that the relevant PTR record(s) be added or deleted from the
apex of the special zone whenever a zone is added or deleted from the
Note that both of these approaches assume that the slave-zone
definitions can all be generated from some standard template. If you
need different zone options (e.g. allow-query etc.) for different zones,
then such simplistic methods will not suffice and you'll have to develop
and/or adapt some sort of "provisioning" protocol so that you can
centrally tell the slaves how to configure the slave zone on themselves.
At one point I sent some preliminary code to ISC/Nominum which
implemented an "auto-slaving" feature based on the receipt of a NOTIFY
message from an authenticated source (i.e. the master), together with a
user-specified template of how a slave-zone definition should look.
Didn't seem to be much interest in pursuing it though...
More information about the bind-users