Why no function to automatically add new zones to slave servers?

[Graeme Fowler]

Hi

On Wed, 2008-02-13 at 09:26 -0500, Jeff Reasoner wrote:
> I am certain that people have written out-of-band (scripted) solutions.
> I would also imagine something like this is built into DNS management
> solutions and possibly also DLZ.

I've written several custom DNS management solutions in my time,
including one extremely large one using DLZ. They started with a
"classic" munge-config-file, scp, restart and AXFR method; moved to one
which used rsync (to avoid the overhead of the AXFR which, believe me,
grows very large with several hundred thousand domains) and then
switched to DLZ.

Using a DB backend like DLZ renders the concept of master & slave
redundant (in fact, so does using rsync in terms of the classic
master-and-slave AXFR process) - all servers are masters, in effect, but
*some other business process* controls the data.

That last sentence is the clincher - most of the time, it's a business
process and not a technical issue that requires definition and solution.

When using DLZ, as long as all servers in the system have access to the
same data - the replication of which is up to you, given the differing
number of backend systems that it can talk to - then you can add and
remove zones almost at will. It's how you control that process that
matters.

Getting back to the OP's problem: As long as your master is setup to
permit zone transfers to the slave, all you have to manage is the
config. Using an include statement with a directory full of zone
definitions in their own files is a simple way to do it - when you add a
new zone to the master, copy the zone definition file to the slave using
the method of your choice, change the type to "slave" and then reload it
- the slave will then request a zone transfer from the master. When you
get to several (tens/hundreds of) thousand zones, you'll see why this
doesn't scale well (esp. with an EXT3 filesystem at both ends)!

Graeme