Re: BIND9 dynamic configuration sharing from a master

In article <bv9jap$2kcb$1@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