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

[John Miller]

On Thu, Jan 14, 2016 at 4:01 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
> Am 14.01.2016 um 21:48 schrieb 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.
>
>
> no, you need to just put a symlink

Fair enough.

> how often do you *by hand* touch things?

Only when something's not working as expected, or when we want to
verify that configuration has changed.

> normally anything is done with backends and scripts

Yep - via Puppet and scripting for us, mostly.

> so after once configured it don't matter if things are bekow
> /var/named/chroot/ or on a higher directory - is it worth - well, the
> question is "does it harm" and it don't after initial deployment when done
> right

For the most part, I agree with you here.  That said, for someone with
very little BIND and Unix experience--say someone who primarily
manages Windows--to come in and understand a chrooted installation
isn't as easy as a non-chrooted install.  Granted, it's probably
easier than getting up to speed on SELinux, but you're still adding a
learning curve.

> security is about layers

Agreed as well - you need to keep up on patches, limit access, use
firewalls, set up secure zone transfers, rotate keys, use an
unprivileged user, architect your systems properly, etc.  I can also
see benefit in a chroot environment guarding against OS-level
attacks--key loggers, trojans, unauthorized daemons, shell
vulnerabilities, etc.: the attacker's damage is limited to BIND.
Likewise, if your server is in privileged network space, it may be
able to compromise other systems more easily.  Sounds like my original
reply was glib and misleading here.  I still think "what's the
tradeoff between ease of use and knowledge transfer" versus security
is worth discussion, however.

John