Metazones or Something Else?
/dev/rob0
rob0 at gmx.co.uk
Tue Aug 5 14:41:14 UTC 2014
On Tue, Aug 05, 2014 at 09:31:31AM -0400, Brian Cuttler wrote:
> On Tue, Aug 05, 2014 at 09:21:07AM -0400, Brian Cuttler wrote:
> > rndc addzone sounds like a very interesting tool, but
> > if you want an automated sync, will require something to
> > read the source config of the master and then write the
> > requisit slave zone information for the dns slave server(s).
> >
> > Offsite slave servers will require a lot of trust.
>
> - I guess not just trust, but some form of ACL so that remote
> managers can add/remove/edit only certain zones. This may be
> even a larger security issue than a technical issue.
The slave trusts the master. The master would have to control the
access permissions. Dual-level access control would be hard to
implement, and not make much sense.
rndc.conf(5) does not provide flexibility in controlling access to
specific subcommands. (Evan, is that a feature you have thought
about?) So you'd probably have to use something like a web form,
authenticating users and keeping track of which user controls which
zones.
> > Rsync solution for onsite servers will result in duplicate
> > copies of the master or the slave, unless you automate a
> > wrapper for that too (and I'm inclined to think in terms of
> > # sed, which I use in a surprising number of my scripts).
named-checkconf -p", piped through sed, can easily convert master
zones to slaves. But "rndc addzone" can be automated. Have the web
form ssh to the slave[s] with the name of the new zone, there run a
script to add the zone.
As an alternative, you could have the controls channel accessible to
the master over the network (perhaps a VPN for added security), and
simply have the web form do the "rndc addzone" remotely.
Lots of choices, not easy to say what's best. Except that addzone
(and delzone also) works at runtime, not requiring a separate "rndc
reconfig" to load (or remove) zones.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
More information about the bind-users
mailing list