BIND chroot environment in 10-RELEASE...gone?

[Kevin Oberman]

On Tue, Dec 3, 2013 at 8:05 AM, Mark Felder <feld at freebsd.org> wrote:

> On Tue, Dec 3, 2013, at 9:58, Royce Williams wrote:
> > On Tue, Dec 3, 2013 at 6:25 AM, Boris Samorodov <bsam at passap.ru> wrote:
> > >
> > > 03.12.2013 12:56, Michael Sinatra пишет:
> > >
> > > > I am aware of the fact that unbound has "replaced" BIND in the base
> > > > system, starting with 10.0-RELEASE.  What surprised me was recent
> > > > commits to ports/dns/bind99 (and presumably other versions) that
> appears
> > > > to take away the supported chroot capabilities.
> > >
> > > /usr/ports/UPDATING has some info about the matter.
> >
> >
> > Specifically, 20131112 says:
> >
> >   All bind9 ports have been updated to support FreeBSD 10.x after
> >   BIND was removed from the base system.  It is now self-contained
> >   in ${PREFIX}/etc/namedb, and chroot and symlinking options are
> >   no longer supported out of the box.
> >
> > Does that mean that those options now need to be manually configured
> > by each team running BIND?
> >
> > If so, that is a net negative for security.  Even if everyone running
> > public-facing BIND knows how to chroot, it means more work -- and more
> > potential implementation errors.
> >
>
> I had not seen that UPDATING entry... I assume that due to shortage of
> time by the maintainer and the urgency to just get the port working it
> has been discarded for now. You could try adding the features back to
> the port and seeing if the maintainer accepts them. Unfortunately I
> don't have any inside information to assist you further.
>

It was a deliberate decision made by the maintainer. He said the chroot
code in the installation was too complicated and would be removed as a part
of the installation clean-up to get all BIND related files out of /usr and
/etc. I protested at the time as did someone else, but the maintainer did
not respond. I thnk this was a really, really bad decision.

I searched a bit for the thread on removing BIND leftovers, but have failed
to find it.
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at gmail.com