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

[Paul Vixie]

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

"proprietary" is too strong a word.  see below for an example.

> > There is a discussion at the IETF but no results yet:
> > 
> > http://www.bortzmeyer.org/files/draft-regnauld-ns-communication-00.html

that document has a much larger problem statement than slave synchronization.

> > > 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 keep meaning to clean up this code, write some man pages and a tech note,
and release it.  i do what you're describing to auto-synchronize slaves from
a master.  i call it "name server federations".  here's a real-world example.

$ORIGIN fh-sa.mz.vix.com.
$TTL 3600
@               SOA     ns.lah1.vix.com. hostmaster.vix.com. (
                                        2007082400      ; serial
                                        3600            ; refresh
                                        1800            ; retry
                                        604800          ; expiry
                                        42 )            ; minimum (version)
;
                NS      ns.lah1.vix.com.
                NS      ns.sql1.vix.com.
;
; RRtype overloading
;
;       RT is used for lists of nameserver names (masters, also-notify) since
;       it has an MX-like priority field and we want to be able to define the
;       fetch-order in some cases.
;
;       PTR is used for the zone markers.  has to point to real domain, just
;       as a sanity check.  they have to be under a "zones" subdomain.
;
;       A and AAAA mean what they always mean, but are local to this zone.
;       they have to be under a "servers" subdomain.
;
;       MG is used for referring to TSIG keys, which are exchanged outofband.
;
masters         RT      10 ns-lah1.servers
;allow-transfer MG      fh-sa.tsig.vix.com.
;               MG      ns-ext.
also-notify     RT      10 ns-ext.servers
;
ns-lah1.servers A       204.152.188.234
;               AAAA    2001:4f8:2::9
ns-ext.servers  A       204.152.184.64
                AAAA    2001:4f8:0:2::13
;
$ORIGIN zones
vix.com         PTR     vix.com.
anog.net        PTR     anog.net.
anog.org        PTR     anog.org.
redbarn.org     PTR     redbarn.org.
asbyrgi.net     PTR     asbyrgi.net.

we've let out the current unpleasantly-raw perl scripts to a few folks, who
are using it in production.  (but alas, none of them contributed back "man
pages" :-)).

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

right.

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

doing this internal to BIND is on the proposed feature list for BIND 10, and
the kind of synchronization you're describing is part of the larger problem
statement being addressed by the IETF.

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

the above real world example is subject to dynamic update, notify, and ixfr,
and i can add/change/delete the list of servers someone else slaves for me in
about 1.5 minutes on average (since there's a cron job on a 3-minute cycle.)

i'd really like to see something like this as a standard feature of the "DNS
hosting" market, with interoperability between competitors.  what i've lacked
is ambition to do the second 90% (documentation and release engineering) and
the third 90% (building consensus within the IETF).
-- 
Paul Vixie