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"
This seems to work fine, and I still use this method for my external environment.
Josh
Men & Mice Suite
CMU's NetReg
And several other competitors.
Chris Buxton
Professional Services
Men & Mice
>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
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
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.
>
>
>
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.
>
; <<>> 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.
>>
>>
>>
>>
> % 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