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

[Jim Ohlstein]

On 12/4/13, 4:47 AM, Erwin Lansing wrote:
> On Wed, Dec 04, 2013 at 08:16:06AM +1100, Mark Andrews wrote:
>>
>> As for 9.9.x ESV it will be support for to at least June 2017, which
>> is 5+ years from BIND 9.9.0, and 4 years after 9.9.x was announced
>> as the ESV series with BIND 9.9.3.
>>
>> BIND 9.6 went ESV in Mar 2010 and will be EoL in Jan 2014.
>>
>> BIND 9.10 in is alpha at the moment.
>>
>> BIND 10 is still in development.
>>
>
> Thanks for chiming in Mark.  As you can see, there's some confusion
> about BIND9's lifetime, so getting this straight from the horse's mouth
> is good.

With due respect, I don't see any confusion at all. BIND 9.9 will be 
supported for at least another 3.5 years. Had anyone actually asked that 
question they would have known the answer. It's right here at 
https://www.isc.org/downloads/software-support-policy/.

There's really no excuse for not having gotten this right. As a result, 
everyone will now see at least two changes from 9 -> 10 -> 11 instead of 
perhaps just one, even if you accept the wisdom of removing BIND at all.


>
> I did a presentation at the recent ICANN meeting about why BIND was
> removed from base, slides are at
> http://people.freebsd.org/~erwin/presentations/20131118-ICANN-FreeBSD-DNS.pdf
>
> Note that most of the reasons all fall back to reducing code base and
> complexity, and some of the other bullets all follow from that.  It has
> more to do with how BIND was integrated into FreeBSD than BIND itself
> and unbound just has the advantage that it does not have an authoritatve
> part (and key management etc), with associated options and potential
> security vulnerabilities, and thus hopefully will be easier to maintain
> in the base system.
>

I get this but from a security point of view, the changes make a system 
at best as secure (with a lot of work for each individual user) and at 
worst, a whole lot *less* secure if chroot(8) is not properly configured.

I know that people are concerned about the number of security advisories 
but as you and others have pointed out, it's a highly scrutinized piece 
of software, and also, I'd add, one which is a frequent object of attack 
due to its widespread use.

For the people who are so concerned about the SA's, they still have the 
option to set WITHOUT_BIND_NAMED in src.conf, or at least they did 
before it was deprecated. Even if they were tracking RELEASE they did 
not need to enable BIND in rc.conf. A program that never runs is rarely 
a security risk.

Now a bit of a rant about 10 in general:

I think it's clear that 10 is a departure from previous versions in 
several ways. There's a new default compiler. The iconv/libiconv change. 
The removal of BIND from base (which was not as it was billed to us 
earlier). There are of course others as well. The compiler has not been 
a problem for me yet. I've been using clang for awhile now since this 
was planned awhile ago. The other two changes caused a great deal of 
trouble in my test box. Ports did not want to rebuild because libiconv 
would not build. I prefer to set my own options for a lot of ports and 
so packages often do not work for me. I had to resort to installing all 
of my ports as packages, rebuilding them with my options and then 
removing the unneeded packages that were installed as dependencies for 
the pre-built packages' options that I didn't need. That has (so far) 
solved the libiconv/iconv issue but it will put a machine that depends 
on custom configurations of ports out of business for hours or more in 
the process. And that's before I installed a jail (and all of the 
necessary bits for that jail to communicate with the outside world) and 
installed BIND in that jail, and moved all of my zones, etc from 
/var/named/etc/named in the host to /usr/local/etc/named in the jail and 
reconfigured named.conf. A lot of work. And the sad part is that part of 
the reason for BIND being removed from base in 10 was because of a 
"misunderstanding".


-- 
Jim Ohlstein