Zone created on master --> automatic add/transfer on slave servers possible?

Kevin Darcy kcd at
Fri Jan 21 03:19:38 UTC 2005

pbox at 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>,
>>"pbox at" <pbox at> wrote:
>>>Hello There!
>>>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 
master server.

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

                                                         - Kevin

More information about the bind-users mailing list