Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

60 views
Skip to first unread message

bsd

unread,
Mar 13, 2008, 4:40:47 AM3/13/08
to
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.


Thx.

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Gregober ---> PGP ID --> 0x1BA3C2FD
bsd @at@ todoo.biz
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

P "Please consider your environmental responsibility before printing
this e-mail"

Baird, Josh

unread,
Mar 13, 2008, 9:24:27 AM3/13/08
to
No functionality for this exists in BIND. The way that I have accomplished this in the past is to keep a separate named.conf (ie, named-slave.conf) on the master and use a simple script that scp'd the named.conf over to all of the slaves, used sudo via ssh to copy the named.conf to the proper location and then did a "rndc reconfig" (better than using "rndc reload" if all you are doing is modifying named.conf).

This seems to work fine, and I still use this method for my external environment.

Josh

Chris Buxton

unread,
Mar 13, 2008, 1:44:00 PM3/13/08
to
Any reasonably-useful multi-server DNS management package should be
able to do this for you. Examples include:

Men & Mice Suite
CMU's NetReg

And several other competitors.

Chris Buxton
Professional Services
Men & Mice

Chris Thompson

unread,
Mar 13, 2008, 2:46:19 PM3/13/08
to
On Mar 13 2008, bsd wrote:

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

Well, you'll get responses telling you about management packages,
commercial or otherwise, that will do this sort of thing. As for
the possibility of using the DNS protocols themselves to do achieve
the desired effect, take a look at last month's thread "Why no function
to automatically add new zones to slave servers?" on bind-users.

What do we do? Generate the BIND configuration files from a common
master specification with some simple Perl scripts, rsync them to
the nameservers (4 currently, I don't claim this would scale well
to hundreds), over ssh of course, and then do an "rndc reconfig"
also over ssh. All done from a control point which doesn't have
to be on any of the nameservers themselves. One could do the rndc
over the network as well, but as you need ssh access for the rsync
you might as well use it for rndc as well.

Is this "elegant" ? Well, I wrote most of it, so my opinion may be
biased :-) It's certainly much more reliable than the methods we
were using before.

--
Chris Thompson
Email: ce...@cam.ac.uk


Kevin Darcy

unread,
Mar 13, 2008, 6:43:04 PM3/13/08
to
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


John Wobus

unread,
Mar 13, 2008, 9:27:59 PM3/13/08
to
On Mar 13, 2008, at 4:40 AM, bsd wrote:
> 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.

My experience does not include dynamic DNS, but...

Sites with large DNS setups often generate their zone files and
the relevant portions of the named.conf files from a database. The
app that does this generation transfers the zones and relevant
named.conf
to the master and transfers the slave-oriented named.conf to the slaves,
e.g. using rsync, and does the appropriate rndc commands. My site does
this.

If you want to maintain DNS as flat files on one nameserver, a way to
do it is
to make the 'slaves' into masters, and transfer an included piece of the
named.conf file as well as all the zone files to them using rsync.
Then you can
do all your work on the flat files on one nameserver (the 'primary
master'?), and run a script
that does nothing more than transfers files and runs a remote rndc
command. And notify
and zone transfer issues never bite you. I've never been at a site that
does exactly this, but I have been at a site that managed three
identical masters
from the same database rather than using slaves.

John Wobus


Baird, Josh

unread,
Mar 13, 2008, 10:58:18 PM3/13/08
to
Kevin,

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

Thanks,

Josh
________________________________

From: bind-use...@isc.org on behalf of Kevin Darcy
Sent: Thu 3/13/2008 6:43 PM
To: bind-...@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.
>
>
>

Chris Buxton

unread,
Mar 14, 2008, 12:43:37 PM3/14/08
to
We at Men & Mice have audited installations that use rsync instead of
zone transfers. All changes are done on a staging server, and that
config is then automatically rsync'd to the production servers (all
masters, no slaves) once it passes some sanity tests. Access to the
staging server is controlled and usually monitored/logged, and the
testing and rsyncing operation might be kicked off by the management
system, manually, or by fam.

Of course, we prefer to see installations using our software. But for
those customers who don't trust zone transfers, notify, etc., rsync
works fine. This was the original replication strategy suggested by
Prof. Bernstein for djbdns, and probably is still his first choice.

Chris Buxton
Professional Services
Men & Mice

On Mar 13, 2008, at 6:27 PM, John Wobus wrote:

> On Mar 13, 2008, at 4:40 AM, bsd wrote:

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

Kevin Darcy

unread,
Mar 14, 2008, 4:02:14 PM3/14/08
to
% dig _index axfr

; <<>> DiG 9.3.2 <<>> _index axfr
; (1 server found)
;; global options: printcmd
_index. 86400 IN SOA ns1.chysler.com.
dnsadm.chrysler.com. 221 21600 3600 3600000 3600
_index. 3600 IN NS ns1.chrysler.com.
_index. 3600 IN NS ns2.chrysler.com.
_index. 3600 IN PTR .
_index. 3600 IN PTR chrysler.com.
_index. 3600 IN PTR abc.chrysler.com.
_index. 3600 IN PTR xyz.chrysler.com.
_index. 3600 IN PTR in-addr.arpa.
_index. 3600 IN PTR 172.in-addr.arpa.
_index. 3600 IN PTR 16.172.in-addr.arpa.
_index. 3600 IN PTR 17.172.in-addr.arpa.
...

(Just an anonymized example, of course, but you get the idea).

The reason for using PTRs instead of TXT RRs is that they benefit from
label compression.


- Kevin

Baird, Josh wrote:
> Kevin,
>
> Could you elaborate on your "index" zone? Sorry, but I'm a bit confused here.
>
> Thanks,
>
> Josh
> ________________________________
>
> From: bind-use...@isc.org on behalf of Kevin Darcy
> Sent: Thu 3/13/2008 6:43 PM
> To: bind-...@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.
>>
>>
>>
>>

Niall O'Reilly

unread,
Mar 18, 2008, 6:54:00 AM3/18/08
to
On 14 Mar 2008, at 20:02, Kevin Darcy wrote:

> % dig _index axfr

Another interesting approach is Paul Vixie's 'metazone' concept
(Try Google).

I've not used it, as I discovered it after I had something else
in place. It seems more richly expressive than Kevin's
'index zone' method.


Best regards,

Niall O'Reilly
University College Dublin IT Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9


0 new messages