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

[Sam M]

> -----Original Message-----
> 
> On Wed, Feb 13, 2008 at 10:10:02AM +0100,
>  Sam M <sam.m at servwise.com> wrote
>  a message of 29 lines which said:
> 
> > I was just wondering why there is no function in Bind to automaticly
> > add/signal NEW zones to slave DNS servers?
> 
> No. There is currently no such function in the DNS protocol. So, it
> would have to be done in a proprietary way, anyway.
> 
> There is a discussion at the IETF but no results yet:
> 
> http://www.bortzmeyer.org/files/draft-regnauld-ns-communication-00.html
> 
> > At the moment I have to add records to a slave zones file as well as
> > a master zones file and transfer the slave zones file to my slave
> > servers using a third-party transfer method e.g sftp, https
> 
> That's strange. Why transferring the zone files yourself when DNS zone
> transfer is here?

Sorry I meant transfer of the slave named.conf file (The file that holds the
slave entries for the slave servers) not the actual zone files themselves.

> > I've heard some mention security issues, but I don't see why that
> > can't be overcome, surely it can't be as bad as having to resort to
> > some third-party method which is probably more insecure than
> > building a properly secure method within the bind program itself.
> 
> The main issue is control: most nameservers administrators certainly
> do not want new zones to appear without any approbation from them.

Let's say you're a domain seller or run a hosting company like myself, all
of your setup is reliant on automation, speed and working right first time,
every time. 

We have control panels that automate master zones/named.conf and slave
named.conf file creation but only on the local machine, we then need to
transfer that slave data to our slave servers (Or as we have it now it is
requested every 30 mins by the slave servers). Now this works (Mostly) but
it is slow and is prone to problems. (Like my previous post about duplicate
named.conf entries causing bind to fail). 

If the management and transfer was handled by bind itself then some better
intelligence could be included, like you can't add a domain that is already
on the server or intelligently removing duplicates etc, because the two
binds are directly talking to each other they can question each other's
actions and resolve issues without causing down time or miss-configuration
and they can do it instantly and proactively.

> The security issue is not a technical one: sure, we can design new
> protocols, but it does not give us a trust model.
> 
> ns3.nic.fr is a slave for ".cl" and ".my". We certainly do not want
> any of them to be able to suddenly be able to create new zones on this
> machine.

I'm not a security expert (obviously) but I'm sure that's something that can
be worked out, there is already a dynamicDNS protocol included in bind that
introduces key encryption, I'm sure that could be modified without too much
hassle for a similar use but for new zone transfers to slave servers.