Bind in FreeBSD, security advisories

[Peter Maxwell]

On 30 July 2013 16:58, Daniel Kalchev <daniel at digsys.bg> wrote:

>
> On 30.07.13 18:26, Peter Maxwell wrote:
>
>> On 30 July 2013 14:42, <sthaug at nethelp.no> wrote:
>>
>>
>>  Yes, I know everything can be installed from packages/ports. Two of
>>> *my* main reasons for using FreeBSD is that:
>>>
>>> 1. It's an integrated *system*, not just a kernel.
>>>
>>>  That's not an argument for retaining something that is non-essential for
>> most people and can easily be installed from ports.  There is very little
>> that is actually essential in base... having to turn sendmail off on every
>> new installation already does my nut in but having mail facilities is
>> essential, so it has to be there.
>>
>
> I am surprised why so many people insist having an MTA is necessary, but
> having well testes recursive DNS resolver is not.
> Even on a typical "client" installation, it is more likely the resolver
> will be useful, than the MTA.
>

Sendmail - or something equivalent - is required to handle system mail from
things like system utility scripts, e.g. periodic.  A caching or recursive
DNS resolver, strictly, is not essential.  Given the number of SAs in bind,
it would arguably be better positioned in ports from an upgrade point of
view.




>
> By the way, both sendmail and BIND are off by default...


No, sendmail is on by default, cf.
http://www.freebsd.org/doc/en/books/handbook/mail-changingmta.html

It's only inbound SMTP handling that is default off.  To turn sendmail off
completely, you need to do something like set sendmail_enable="NONE" in
your rc.conf and have a replacement already setup.




>
>
>  Having bind in base does have one advantage in that it is more carefully
>> scrutinised that it would likely be in ports.
>>
>
> This too..
>
> I have always viewed FreeBSD not as an product, but instead as an toolkit.
> A toolkit, from which to build the OS you need.
> So far, FreeBSD has worked better for that purpose than any other toolkit
> around (plus, I am biased).
>

It's less useful as a toolkit when you need to upgrade, say, sshd or
openssl but for whatever reason cannot upgrade the base system... it can be
quite a bit of hassle managing the ports version while you've still got the
base version there.  It's not difficult but it's still a pain; when you're
dealing with hundreds of servers, every corner-case makes ongoing
maintenance harder.

My position would be that if it is third-party and not absolutely
essential, it should be in ports.



>
> There are a number of knobs, that let you customize FreeBSD to your
> heart's content.
>

Eh, hmmm, sort of.  As above, some things require upgrading the base system
which can be a bit of an issue in production environments when you cannot
arrange a suitable maintenance window - a scenario that is very common
indeed.  You are then forced to start using ports to replace the
functionality in base and it all gets rather non-standard and messy.




>
> In theory, everything but the absolute minimum of the base system might be
> removed.. and have everything depend on ports. However, the base system is
> just that -- one collection of code that gets built and tested together.
> This brings quality.
>

Yet, as the OP pointed out: bind is not what I would term "quality",
there's more SAs posted than I've had hot dinners.  Given it is
non-essential, it could quite easily be stripped out.




>
> Having said this, it is perfectly ok to replace BIND with any other
> resolver + name server.... as long as there is suitable candidate that has
> passed enough testing. Is there one? Do we know enough of their quirks?
>

That's not a good idea: any environment larger than a home network or SME
that relies on bind will not find it easy to migrate.  It's one thing
asking people to tolerate a 2min inconvenience to make a choice to install
bind from ports (when they've can also choose bind or, say, djbdns, etc),
it's quite another to suggest to them they should be using different
software, essentially on a whim.  I personally prefer qmail over sendmail
but I wouldn't suggest qmail should be in base for the reason that sendmail
is the de facto standard on *nix shaped systems.