Metazones or Something Else?

Brian Cuttler brian at
Tue Aug 5 15:43:24 UTC 2014

On Tue, Aug 05, 2014 at 09:41:14AM -0500, /dev/rob0 wrote:
> 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.

The slave trusts the master, for zone files, but creating
a new zone? 

What I was thinking of is not so much the on-site master/slave
pair, I was wondering, and will allow that this may very well
be well outside of the problem scope we are talking about, but
what do you do with a remote secondary DNS that is being run on
your behalf by another institution? That question being asked,
I will also ask that we table it as the trust complexity is much
much larger and likely not was what asked in the first place.

I took the question out of the park, I will agree with you that
for a master/slave pair belonging to a single management entity
that trust and creation of zones need not be overly complex.

> 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.
> -- 
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
> _______________________________________________
> Please visit to unsubscribe from this list
> bind-users mailing list
> bind-users at
   Brian R Cuttler                 brian.cuttler at
   Computer Systems Support        (v) 518 486-1697
   Wadsworth Center                (f) 518 473-6384
   NYS Department of Health        Help Desk 518 473-0773

More information about the bind-users mailing list