Installing bind is not very clear for me

Leandro ingrogger at
Fri Sep 4 18:41:19 UTC 2015

I think that regarding security issues, is better to prevent as much as 
Here we have two different opinions:
People that agree to use firewall and people against (or arguing that is 
not necessary):

I would like to hear both and then decide. If we share our points maybe 
can get a better conclusions

So I would like to learn about firewall techniques to protect a DNS.
And for people against firewall , wich are the security considerations 
to take in order to protect the service without firewall.


On 04/09/15 14:27, Mike Hoskins (michoski) wrote:
> On 9/4/15, 1:12 PM, "bind-users-bounces at on behalf of
> /dev/rob0" <bind-users-bounces at on behalf of rob0 at>
> wrote:
>> On Thu, Sep 03, 2015 at 11:02:23PM +0200, Reindl Harald wrote:
>>> Am 03.09.2015 um 22:59 schrieb Robert Moskowitz:
>>>> On 09/03/2015 04:35 PM, Leandro wrote:
>>>>> Ok ...
>>>>> I got BIND 9.10.2-P3  working.
>>>>> I compiled with
>>>>> ./configure --with-openssl --enable-threads --with-libxml2
>>>>> --with-libjson
>>>>> make
>>>>> make install
>>>>> Json statistics channel is working and chroot is not longer
>>>>> mandatory.
>>>> But do make sure you have selinux enforced.  Or run behind
>>>> multiple firewalls...
>>> behind *multiple firewalls* - ?!?! - oh come on and get serious
>>> instead promote snakeoil -
>> I quite agree here.  Firewalls that attempt to filter DNS have
>> terrible reputations for *breaking* DNS.  A single firewall is bad
>> enough; multiple firewalls sounds like a disaster.
> True, have fixed many of those over the years, though in fairness this is
> often a matter of expecting to run a firewall (or anything) "out of box"
> without understanding the config.  If that's the stance of the admin, you
> likely have a lot more to worry about security-wise than named chroot.  :-)
>>> typically BIND is *not* running as root and hence does not need
>>> any special handling compared to any other network service
>> I don't know if we can say what is "typical".  We can say, for
>> running on Linux at least, that running as root is safe.  A
>> compromised named would get root after having dropped superuser
>> privileges, so it wouldn't be able to do much.
> I probably misunderstand your response or am reading too much into the
> wording.  Named doesn't run as root due to -u giving up permissions.  That
> combined with the fact chroot itself has known shortcomings is why it's
> fallen out of BCP amongst name server operators.  It's not that anyone
> suggests the alternative to chroot is to just run as root.  You are still
> running as a non-privileged user post-startup, and permissioning things
> appropriately to minimize damage in the event of a compromise.
>> Regardless, again I quite agree that special handling is not
>> necessary.  Look at the various BIND9 security announcements over
>> the years.  When have you seen one which involved a compromise of
>> any kind?
>> I cannot say with authority that BIND9 has never had a compromise,
>> but I am confident in saying I have never seen one.
> I appreciate the viewpoint, and I can even agree with it, but the past is
> not necessarily a key to the future.  The reality is none of the nastiest
> 0-days were ever expected.  As a security professional you try to insulate
> against potential risks, not just things you have already observed.  It's
> up to each operator to determine appropriate cost/benefit, and this is not
> an argument for chroot, but I do caution against an "I've never seen it
> before so wouldn't worry about it" stance on security.
> _______________________________________________
> Please visit to unsubscribe from this list
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list