Master <--> slave named.conf "auto-generation"

Baird, Josh jbaird at follett.com
Fri Mar 14 02:58:18 UTC 2008


Kevin,
 
Could you elaborate on your "index" zone?  Sorry, but I'm a bit confused here.
 
Thanks,
 
Josh
________________________________

From: bind-users-bounce at isc.org on behalf of Kevin Darcy
Sent: Thu 3/13/2008 6:43 PM
To: bind-users at isc.org
Subject: Re: Master <--> slave named.conf "auto-generation"



bsd wrote:
> Hello,
>
> I would like to know if there is a way, whenever a new zone definition 
> is added to the primary master server, to have the slaves 
> automatically configure themselves with matching slave-zone definitions?
>
> If not - what are people currently using to acomplish this task?
>
> Have you got any good script that could help me achieve that in an 
> "elegant" way?
>
> What are the best path to achieve this knowing that I could have 
> master and slave file generated on one server (the master), how would 
> you handle the propagation of the named.conf (slave) file and signal 
> (rndc reload) and the slave?
>
>
> Any other advise / experience / experiment are welcome.
>
>
>  
We have a homegrown script that runs on all of our slaves (we have
dozens of them) nightly and looks at an "index" zone -- a zone with one
record per zone to be slaved. If the "index" zone has changed, it
rebuilds the named.conf based on the contents of the "index" zone and
does a reload. The big assumption of the script is that all of these
"automatic" zone definitions on all of the slaves are identical (with
the exception of "masters" and/or "also-notify"), but that's only a
_default_ assumption, since there is a provision for overriding the
"automatic" zone defintion with a "customized" version for any given
zone on any given slave. Also, since we have multiple levels of slaves,
there's a fairly elaborate "replication topology" subsystem for
determining the respective contents of the "masters" and "also-notify"
clauses on the various slaves.

                                                                        
                        - Kevin







More information about the bind-users mailing list