BIND9 dynamic configuration sharing from a master
rob0 at gmx.co.uk
Fri Jan 30 03:39:02 UTC 2004
In article <bv9jap$2kcb$1 at sf1.isc.org>, Kevin Darcy wrote:
>>I know I can rig this up manually quite easily, but I just wondered if
>>there was a means to dynamically update a slave's configuration within
>>BIND's own capabilities.
> Nope. I've submitted an "autoslaving" patch, but it basically sank
> without a trace.
> One alternative method is to have a special zone, slaved by the entire
> community of slaves, containing no leaf records except one TXT or PTR
> record (_nota_bene_, PTR records can benefit from label compression)
> naming each zone that should be slaved. Every time you add/delete a zone
> to/from the master, add/delete the corresponding record to/from that
> zone too. All of the slaves then have a cron job to check the "special"
So there seems to be no getting around the cron job.
>>Has anyone else done something like this? Comments appreciated.
> OK, that's kind of like the "special zone" method, except that you're
Yes it is, it seems very similar. It's working well. I expanded it, even
broadened the purpose, by now sharing a modular ACL file and a list of
slaved domains in addition to the "blacklist" thing that started it. I
can't do major configuration changes this way, but it does what we're
likely to need most often.
> transfers to occur "naturally". One of the beauties of the "special
> zone" method is that it doesn't require any non-DNS transfer mechanisms
> or the establishment of trust relationships for same. So it works well
> across trust boundaries (e.g. firewalls) and/or multiple levels of slaves.
Yes. It's too bad that the "also-notify" feature can't trigger an action
external to BIND, but like I said, this is easily worked around. Thanks
Kevin and Barry for your comments.
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply
More information about the bind-users