Thanks for the advice, Mike. We chrooted our install because it was "best practice" security-wise, but from an administration standpoint, it's been a bit of a headache: for example, you have to keep straight what goes in /etc and /var/named/chroot/etc, you end up setting a $BIND_CHROOT environment variable for everyone to keep paths shorts at the CLI, etc.
I'd recommend _not_ chrooting for internal-only servers: it hasn't been worth the trouble for us. For public-facing nameservers, I'd consider a little more carefully, but with everything running on its own VM these days, plus SELinux, containers, etc., there are tools out there that provide at least the security of a chroot environment, and almost certainly better. The days of "hardware's expensive; let's run everything on one box," where a chroot environment might have been valuable, are _way_ behind us! John On Thu, Jan 14, 2016 at 10:42 AM, Mike Hoskins (michoski) <micho...@cisco.com> wrote: > Yes you can run without the chroot. Years ago it was considered best > practice to chroot and most power users would have said you were insane not > to do so. Now there are increasingly many who say it's not worth the effort > (fairly easy to get around in many cases) -- do a bit of google engineering > and you will see pros/cons. > > If you are using packages from your distro (looks like it from the "el6" and > ancient version) this will often just be pulled in by default. If you build > your own packages, use upstream repos, ISC packages or something like this: > > http://www.five-ten-sg.com/mapper/bind > > Then you can just install without the chroot. Entirely up to you, BIND can > work either way. As I said, if you search a bit you'll find older "best > practices" like these which suggest chroot (note the dates!): > > https://www.cymru.com/Documents/secure-bind-template.html > > https://deepthought.isc.org/article/AA-00768/0/Getting-started-with-BIND-how-to-build-and-run-named-with-a-basic-recursive-configuration.html > > Then increasing amounts of documentation saying it is largely irrelevant due > to adding minimal value due to some known issues in the chroot mechanism > itself, named -u, etc: > > https://deepthought.isc.org/article/AA-00874/0 > > """ > If following the preceding advice (running BIND as an unprivileged user on a > dedicated server) chrooting is "de-emphasized." Our operations experts feel > that chrooting does not substantially improve security under those > conditions and do not affirmatively recommend it, but they do not explicitly > discourage it. > """ > > From: <bind-users-boun...@lists.isc.org> on behalf of Harshith Mulky > <harshith.mu...@outlook.com> > Date: Thursday, January 14, 2016 at 1:46 AM > To: "bind-users@lists.isc.org" <bind-users@lists.isc.org> > Subject: What is the use of having a chroot path during installation of Bind > > Hello, > > > When installing bind, the following 2 are installed > > > bind-9.8.2-0.17.rc1.el6.x86_64 > bind-chroot-9.8.2-0.17.rc1.el6.x86_64 > > > What is the need of this bind-chroot? > > > > I see all files in /var/named path are softlinks to > /var/named/chroot/var/named > > > and > > > /etc/named.conf is softlink to /var/named/chroot/etc/named.conf > > > > > What is this chroot binding? And why is this chroot Binding Required? > > > > Can the named server function without this chroot Binding? _______________________________________________ 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
