What is the use of having a chroot path during installation of Bind

[John Miller]

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)
<michoski at 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-bounces at lists.isc.org> on behalf of Harshith Mulky
> <harshith.mulky at outlook.com>
> Date: Thursday, January 14, 2016 at 1:46 AM
> To: "bind-users at lists.isc.org" <bind-users at 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?