Re: automatic slave
On Fri, Mar 11, 2005 at 04:10:04PM +0100, Mark Lijftogt wrote:
> On Fri, Mar 11, 2005 at 08:43:06AM -0600, Rodney Richison wrote:
> > What solutions are available to automate dns slave zone creation?
> > When I create or change a zone file, I'd like the slave dns machine
> > to automagically pick up the new zone.
>
> pdns with mysql backend, and mysql replication is an option aswell you
> could look into.
i tried pdns, didn't like it. it was even more of a memory hog than bind was,
which kind of defeated the purpose. you don't need something as complicated
as pdns for only a few zone files, but if you have hundreds or thousands it
wants so much memory that it's unusable.
it also had serious problems importing bind zone files into the database
(including, of all things, case-sensitivity in interpreting the zone files! i
had to write some scripts to pre-process the zone files before pdns would even
import them).
also, i think that storing DNS in a database is a dubious proposition....all
the hassles of DB administration for data that is mostly static - it changes
occasionally, but not often enough to need what a database has to offer.
the "supermaster" feature of pdns was a pretty good idea, though...the
implementation wasn't quite perfect when i tried it, but it had a lot of
potential.
for my dns setup, i wrote a set of scripts to generate bind zonefiles from
templates (most zones are basically the same...scripts can generate them, then
they can be hand-edited if necessary with vi or whatever).
plus some more scripts to generate named.conf include fragments which told
bind that it was either a primary or secondary for a domain.
source input to both of these scripts was just a text file with a list of
domain names, one per line. for the primaries, that was all that was needed.
for the secondaries, another file was needed which listed the master
server(s).
so, for example, if i wanted to secondary a bunch of domains from someone else
(e.g. as a favour swap - you secondary mine and i'll secondary yours), i'd
create one text file containing the list of domains to secondary, and another
to define what server IP addresses to secondary them from. e.g. "foo.domains"
and "foo.servers". these would be used to generate "named.conf.foo" which
would be #included in named.conf, with secondary zones stored in
/var/cache/bind/secondaries/foo/
(i never got around to it, but it would have been fairly easy to set up a
password protected web interface to allow the other ISP to manage their own
domains file)
there was also another script which used scp to copy config files from the
master to the secondary, and ssh to execute 'make' on the secondary.
and a Makefile on the primary and another on the secondary to rebuild the bind
config files whenever the zone definitions file was updated. the Makefile
also used RCS to keep a revision history of all changes, so i could tell when
a change was made, who made it, and (most importantly) could revert to a
previous state at any time.
this system evolved over a year or so, but if i needed to write it again[1], it
would take about half a day to write the sh & perl & Makefile scripts.
adding a new domain or removing an old one was as easy as editing a text file
and running 'make'. that's a common feature to most of my sysadmin automation
scripts....they pretty much all boil down to: edit a file, run make. make
is, IMO, the best systems administration automation tool around.
this has the advantage of:
1. uses bind rather djbdns, so no requirement to run your system in DJB's One
True Way of Moronic Systems Administration. supports all of the DNS
requirements, rather than just the ones that DJB likes.
2. eveything is plain text, and bind zone files are actually human-readable
rather than line-noise. easily edited with vi or whatever, and easily backed
up.
3. no dependence on postgresql or mysql, so no chance of DNS failing if the db
server goes down, and no chance of someone with a poor grasp of SQL
accidentally deleting or making incorrect changes to all zones.
4. it's scalable to any number of servers, and any number of zone sources.
5. adheres to the KISS (Keep It Simple, Stupid) principle.
6. it's an example of the unix "small tools" approach to problem solving, with
all scripts written as filters rather than with hard-coded input & output
filenames. by keeping everything simple and in plain text files it's very
flexible - easy to add features or make global changes, just modify the
script(s) and run make to have it regenerate everything according to your new
policy.
craig
[1] one day i might need to write it again. i wrote it for my previous job,
and i didn't keep a copy of it for myself. no need to, it is the ideas in it
that are important, the implementation is trivial. and i'll probably do it
better the next time around.
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: