Secondary NS setup q?

[Kevin Darcy]

Network Admin [JPeterson] wrote:

> Okay, this may have been covered already but I'm just dense.. I have
> searched the archives but can't find anything that quite matches our desired
> configuration
> We have two unix boxes (FreeBSD) NS1 and NS2 - our primary admin shells are
> on NS1, we are an ISP and we host several hundred domains and add more on a
> daily, sometimes hourly basis. When we add a customer domain we add their
> entry to /etc/namedb/named.conf and put a file in /etc/namedb/db.domain-name
> then we telnet to NS2 and add the slave directive for the domain to
> /etc/namedb/named.conf and do an ndc reload on both boxes.  Is there a
> better (fewer steps) way to accomplish this? i.e. some way to have NS2 grab
> new info from NS1's named.conf file without having us telnet over and do it
> by hand?

There is nothing built into BIND for this. For our internal DNS here, I run a
script nightly on all of the slaves which checks all delegations, starting with
the internal root and walking on down, and identifies which zones the slave
server should start or stop slaving. Obviously, this approach isn't feasible
for Internet servers :-)

In theory you could trigger the creation of a zone from the receipt of the
first NOTIFY for the zone from the master (make a separate logging channel for
the "notify" category, if that makes things easier). For security's sake
though, just make sure you first check the delegations to verify that the
master is legitimate and that you are actually supposed to be a slave for the
zone, otherwise you might be vulnerable to spoofing or
bogus-zone-creation-denial-of-service attacks. This methodology doesn't help
with zone deletions, although I don't think it would be too hard to write a
script which would run through named.conf, check DNS for the existence and/or
delegations of all the defined slave zones, and reap the ones that are no
longer valid.

Another thought, off the top of my head:  write a zone-creation script which as
part of its operation would insert records -- TXT records maybe -- under some
well-defined name or zone via Dynamic Update to alert the slaves as a kind of
"TODO" list. The slaves would query this name/zone periodically, and when they
find something there for them, create the necessary slave definitions, then
delete the "TODO" items from the master via Dynamic Update.

Or you could use any out-of-band mechanism you like. The possibilities are
endless.


- Kevin