elegant way to maintain slaves?

[Kevin Darcy]

As Barry pointed out, there is no reasonable way within the DNS protocol to find out all
of the zones for which a server is master (or even all zones for which it is
authoritative). So if you equate "elegant" with "codified by Internet standard", then the
answer is no.

However, it is not strictly necessary to use potentially-insecure inter-system "hacks" to
synchronize slaves (I'm taking a cue from your description of using scp as a "hack").

For limited namespaces, e.g. an internal-root architecture, you could have a
self-contained process on the slave machine(s) periodically walk the delegation tree and
determine which zones it/they should start or stop slaving. I have a script running on my
internal slaves which does exactly this, with the benefit of certain site-specific
conventions I have developed. If your slaves should be slaves for *every* zone that's on
the master (or, more specifically, every zone for which the master server is registered as
an NS and/or is specified in the SOA.MNAME), then this script could be made much simpler
than mine, which has to deal with the fact of distributed delegation, i.e. large chunks of
our namespace hosted on servers I don't control.

Alternatively, for large namespaces, e.g. the Internet DNS, where the above approach is
impractical, I believe it might be possible (I've never actually tried this) to trigger
slave-zone-creation from the receipt of a NOTIFY from the master. Just log NOTIFYs
properly and then have a script scan for them periodically in the logs. Unfortunately,
this approach only works for *adding* zones. You'd have to have some other process for
reaping dead zones, e.g. something that scans the logs for failed zone transfers due to
the master no longer replying authoritatively.

Admittedly, these approaches strain (if not break) the limits of "elegance"...


- Kevin

Saku Ytti wrote:

> I was wondering is there some way master can tell to the slave which zones
> to 'mirror'. Instead of having to define to each slave when you introduce
> new zone or using some scp-hack.
>
> something like
> zones_from master { type slave; masters{foo;}; file "/fum/bar/$zone"; deny{foo;bar;};};
>
> This might introduce some security problems, so handling $zone should be
> done with care.
>
> --
>         ytti