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