Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Shane Ambler

On 31/07/2013 01:31, Daniel Kalchev wrote:


But here is an idea: Remove BIND from HEAD overnight and see how many
 will complain ;-) If nobody complains, don't put it back in.


Or change the default to off. If you want bind add WITH_BIND=yes to src.conf

It's hard to say FreeBSD is a safe and secure OS when part of the base
install is always being shown to have security flaws. New features need
to prove they are reliable before they are accepted into a release yet
we allow something that has a long proven history of being a source of
security concerns.

For something that needs to be constantly updated in between system
updates then ports is the place to install it from.

I think it is less about whether bind is useful and needs to be in base
and more about should every user of FreeBSD be open to security issues
or should a user have the option to say yes I want potentially insecure
software on my machine. The ports system allows messages that make it
obvious to the user about security concerns.

Yes many users know the bind utilities and rely on them but a lot of
users have no idea how to use them. I expect that the bind tools are
used by a number of users that know what they are doing and need them
for testing and debugging issues, they also know how to install them
when they need them. I believe most users would not need or use these tools.

How many people setup and use a FreeBSD machine without adding something
from ports or packages?

And yes I setup my own dns server to resolve internal host names instead
of filling /etc/hosts with entries. As for the tools like dig and host,
I rarely use them.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread sthaug
  Considering the topic, and how many times it's come up. I'm not sure that's 
  a
  nything to
  be proud of. ;)
 
 Given not all CVE's are created equal and given the amount of
 internal self consistancy checks (all of which kill the server if
 they don't pass (and push the CVSS score to 7.x)) there are in BIND
 the number of advisaries is actually very small.
 
 Yes, this was a internal self consistancy check failing.
 
 We are human and despite code reviews, unit and system tests, static
 analysis checkers etc. some errors do make it through.

I'm also more than a little surprised about people dragging out
sendmail as a shining example of *good* (bug-free?) software. Does
nobody remember any history here? It wasn't *that* many years ago
that we seemed to have sendmail-bug-of-the-day...

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Dag-Erling Smørgrav
David Demelier demelier.da...@gmail.com writes:
 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

There are plans to do so.  It's not as trivial as people seem to think.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Daniel Kalchev


On 31.07.13 09:38, Shane Ambler wrote:

On 31/07/2013 01:31, Daniel Kalchev wrote:


But here is an idea: Remove BIND from HEAD overnight and see how many
 will complain ;-) If nobody complains, don't put it back in.


Or change the default to off. If you want bind add WITH_BIND=yes to 
src.conf


That is just as good solution as removing BIND from base. It is also 
easier and faster to ass it as package/point, instead of recompiling the 
whole base system.




It's hard to say FreeBSD is a safe and secure OS when part of the base
install is always being shown to have security flaws. New features need
to prove they are reliable before they are accepted into a release yet
we allow something that has a long proven history of being a source of
security concerns.


Stop right here! There is plenty of other software that is in base and 
is just as buggy or even more than BIND.
BIND, by the way benefits from the fact that it runs on many other 
platforms and that those bugs are typically found there, not on FreeBSD.
In contrast to that the perfect FreeBSD only code has bugs discovered 
only when someone stumbles on them in FreeBSD.




For something that needs to be constantly updated in between system
updates then ports is the place to install it from.


You don't have to update BIND constantly, especially if you are not 
using it. If you are using it, you will want it updated, no matter what.




I think it is less about whether bind is useful and needs to be in base
and more about should every user of FreeBSD be open to security issues
or should a user have the option to say yes I want potentially insecure
software on my machine. The ports system allows messages that make it
obvious to the user about security concerns.


You are reading too much into that messages. FreeBSD is not bug free, 
nor is any other piece of code.




How many people setup and use a FreeBSD machine without adding something
from ports or packages?


Anyone who can, does prefer to not install any ports. I have over a 
dozens servers (and a gazillion jailed instances) that don't have one 
single port installed. I find this feature of FreeBSD especially 
appealing and something we should keep.
By the way, for those inclined to ask me for statistics: this is my 
personal experience. It works for me. If you don't do that, it tells me 
nothing I care about. We might have different reasons to make different 
choices.


Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Mark Felder
On Wed, Jul 31, 2013, at 6:15, Daniel Kalchev wrote:
 
 On 31.07.13 09:38, Shane Ambler wrote:
 
  For something that needs to be constantly updated in between system
  updates then ports is the place to install it from.
 
 You don't have to update BIND constantly, especially if you are not 
 using it. If you are using it, you will want it updated, no matter what.
 

Let's take a moment and consider the state of the internet and DNS
attacks. The RRL and RPZ2 patchsets[1] are newer developments that
successfully add additional security and features to BIND. It was also
recently announced that due to the success of this work the RRL[2] patch
will be accepted by ISC into BIND mainline.

How many users of BIND on FreeBSD are going to realize they need to run
a copy of BIND from ports to get this extremely important protection? It
certainly isn't going to get backported to 8-STABLE or 9-STABLE; I don't
even know if it will show up in 10.0-RELEASE as a quick grep shows it's
not there. To put some perspective on it, FreeBSD 8.x users are
literally 6 years behind CURRENT... 

Now Redhat has a bugzilla[3] report backporting it to RHEL6, but
FreeBSD's policy is generally bugfixes and security fixes only, don't
introduce new features or behavior, and I don't expect that to change
especially for a piece of software in contrib. If a user was running
BIND from ports and they would more readily have that feature at their
disposal. The port maintainer could even put a sane default in the
example config. Unfortunately the number of FreeBSD BIND users who
realize they are afforded this protection are going to be slim, and the
number actually using it nearly as small. It's quite disappointing.

[1] http://ss.vix.su/~vjs/rrlrpz.html
[2]
http://www.isc.org/blogs/isc-adds-ddos-defense-module-to-bind-software/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=873624
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Erwin Lansing
On Wed, Jul 31, 2013 at 07:22:20AM -0500, Mark Felder wrote:
 
 Let's take a moment and consider the state of the internet and DNS
 attacks. The RRL and RPZ2 patchsets[1] are newer developments that
 successfully add additional security and features to BIND. It was also
 recently announced that due to the success of this work the RRL[2] patch
 will be accepted by ISC into BIND mainline.
 
 How many users of BIND on FreeBSD are going to realize they need to run
 a copy of BIND from ports to get this extremely important protection? It
 certainly isn't going to get backported to 8-STABLE or 9-STABLE; I don't
 even know if it will show up in 10.0-RELEASE as a quick grep shows it's
 not there. To put some perspective on it, FreeBSD 8.x users are
 literally 6 years behind CURRENT... 
 

3rd party, and especially those that are still being distributed as
experimental, will not be part of the base BIND code.  It will only
contain a direct import from the vendor sources.

After a -STABLE branche is branched into a -RELEASE branch, the latter
will only get security updates, sometimes backported depending on the
upstream life cycle.  For feature update, users have always been
dependent on ports as the BIND versions included in -RELEASE are quickly
falling behind.

On a side note, BIND 10 introduces a large number of 3rd party
dependencies, none of which are very attractive to include in the
FreeBSD base system by default.  This means that we can use BIND9 so
far, but for the long term, we'll have to look into a more viable
alternative anyway.

Erwin

-- 
Erwin Lansinghttp://droso.dk
er...@freebsd.orghttp:// www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Mark Felder
On Wed, Jul 31, 2013, at 7:37, Erwin Lansing wrote:
 
 3rd party, and especially those that are still being distributed as
 experimental, will not be part of the base BIND code.  It will only
 contain a direct import from the vendor sources.
 

I agree, experimental patches have no place in base. If this hits BIND
9.9 though I'd never even consider running BIND from base as an
authoritative server as it's missing this patch which can at least
partially mitigate a DoS.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread Daniel Kalchev


On 31.07.13 15:22, Mark Felder wrote:

On Wed, Jul 31, 2013, at 6:15, Daniel Kalchev wrote:

On 31.07.13 09:38, Shane Ambler wrote:

For something that needs to be constantly updated in between system
updates then ports is the place to install it from.

You don't have to update BIND constantly, especially if you are not
using it. If you are using it, you will want it updated, no matter what.


Let's take a moment and consider the state of the internet and DNS
attacks. The RRL and RPZ2 patchsets[1] are newer developments that
successfully add additional security and features to BIND. It was also
recently announced that due to the success of this work the RRL[2] patch
will be accepted by ISC into BIND mainline.

How many users of BIND on FreeBSD are going to realize they need to run
a copy of BIND from ports to get this extremely important protection? It
certainly isn't going to get backported to 8-STABLE or 9-STABLE;


There is one solution to this, which I proposed earlier. Just don't 
ship/build the BIND binary by default. You will end up with only the 
resolver available and not be concerned with things like DDoS 
amplification. If you want an authoritative name server, just install it 
from ports.


Another solution is to include the appropriate warning in named.conf for 
anyone setting up name server on FreeBSD to read. In fact, text like 
this is already present in say, 6-stable's version (I know, that version 
is very outdated already):


/*
*
*   _  _ _ _ _   _ _ ___ ___  _ _ *
*  / \|_   _|_   _| | \ | |_   _|_ _/ _ \| \ | |*
* / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |*
*/ ___ \| |   | | | |___| |\  | | |  | | |_| | |\ |*
*   /_/   \_\_|   |_| |_|_| \_| |_| |___\___/|_| \_|*
* *
*

The version of BIND in the RELENG_6 branch (FreeBSD 6.x) is NOT suitable
for use with DNSSEC, either as a validating resolver or an authoritative
name server.  If you plan to use DNSSEC for any purpose you should use a
newer version of BIND, preferably version 9.6.x or higher.

Additionally, this version of BIND (9.3.x) is beyond its End Of Life (EOL)
date and is no longer supported by ISC.

Newer versions are available in the ports tree (e.g., /usr/ports/dns/bind96)
or by upgrading your FreeBSD installation to version 8.0 or higher.
*/

A better solution would be to apply the RRL patch to BIND in 8-stable 
and 9-stable. FreeBSD does ship a very controlled version of BIND in 
base and keeping it patched is trivial, in comparison with someone 
applying the patches themselves on original BIND sources that were 
just released (in a port). FreeBSD does apply patches to other software 
in base: for example ssh and the HPN patches.


Even if you personally prefer some other DNS resolver/server that won't 
replace BIND In 8-stable or 9-stable (which will live in the coming 
years and result in the same problems).
Every FreeBSD installation does benefit from an mature and full feature 
recursive resolver being available in the base system. What else than 
BIND you propose? Why is it better and ... most importantly, considering 
the topic of this thread: why you think it will not be subject to many 
new SAs over time?

For.. if we don't have anything better at hand, BIND will apparently stay.

Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-31 Thread David Magda
On Wed, July 31, 2013 02:55, sth...@nethelp.no wrote:

 I'm also more than a little surprised about people dragging out
 sendmail as a shining example of *good* (bug-free?) software. Does
 nobody remember any history here? It wasn't *that* many years ago
 that we seemed to have sendmail-bug-of-the-day...

Seven years ago and ten years ago:

http://www.freebsd.org/security/advisories/FreeBSD-SA-06:17.sendmail.asc
http://www.freebsd.org/security/advisories/FreeBSD-SA-06:13.sendmail.asc
http://www.freebsd.org/security/advisories/FreeBSD-SA-03:13.sendmail.asc
http://www.freebsd.org/security/advisories/FreeBSD-SA-03:11.sendmail.asc
http://www.freebsd.org/security/advisories/FreeBSD-SA-03:07.sendmail.asc
http://www.freebsd.org/security/advisories/FreeBSD-SA-03:04.sendmail.asc

In the same time period, BIND has had eighteen advisories. OpenSSL has had
fourteen.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
People don't seem upset about not having a webserver, IMAP/POP daemon,
or LDAP server in base, so I don't understand what the big deal is about
removing BIND. If the concern is over the rare case when you absolutely
need a DNS recursor and there are none you can reach I suppose we should
just import Unbound. However, if you can't reach any DNS servers I
assume you can't reach the roots either, so I don't understand what a
local recursor will gain you.

I support removing BIND from base, but there's a larger conversation to
be had (again).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Tom Evans
On Tue, Jul 30, 2013 at 8:55 AM, David Demelier
demelier.da...@gmail.com wrote:
 Hi,

 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

 This will probably free by half the number of FreeBSD SA's in the future.


Sure, but no bind in base also implies no dig, nslookup or host.

Cheers

Tom
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Wiley, Glen
I think you could conceptually differentiate between DNS clients and
servers and remove bind without removing the DNS clients.

On 7/30/13 8:39 AM, Tom Evans tevans...@googlemail.com wrote:

On Tue, Jul 30, 2013 at 8:55 AM, David Demelier
demelier.da...@gmail.com wrote:
 Hi,

 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

 This will probably free by half the number of FreeBSD SA's in the
future.


Sure, but no bind in base also implies no dig, nslookup or host.

Cheers

Tom
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Garrett Wollman
In article
1375186900.23467.3223791.24cb3...@webmail.messagingengine.com,
f...@freebsd.org writes:

just import Unbound. However, if you can't reach any DNS servers I
assume you can't reach the roots either, so I don't understand what a
local recursor will gain you.

There are plenty of situations in which a remote recursive resolver is
untrustworthy.  (Some would say any situation.)  It doesn't have to be
BIND, but people do legitimately want the normal DNS diagnostic
utilities, which sadly have been tied together with BIND for some
years now.  (I don't know why anyone would ever use nslookup(1), but
host(1) and dig(1) are pretty much essential.)

It is a little bit disconcerting to see that big chunks of our BSD
heritage have turned into someone else's commercial product, but that
seems to be the way of the world these days.

-GAWollman

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Daniel Kalchev


On 30.07.13 15:21, Mark Felder wrote:

People don't seem upset about not having a webserver, IMAP/POP daemon,
or LDAP server in base, so I don't understand what the big deal is about
removing BIND.


I believe the primary reason these things are not in the base system is 
that they have plenty of dependencies, with possibly conflicting 
licenses etc.



If the concern is over the rare case when you absolutely
need a DNS recursor and there are none you can reach I suppose we should
just import Unbound.


There are many and good reasons to include an fully featured name 
server, or at least full recursive resolver. For example, for properly 
supporting DNSSEC.
We could in theory remove the BIND's authoritative name server 
executable... if that is attracting the SAs.


The justification reduce the number of SA's, that is, the bad PR is 
probably not enough. Going that direction, we should consider Comrade 
Stalin's maxim FreeBSD exists, there are problems, here is the solution 
-- no FreeBSD, no problems! :-)


Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
On Tue, Jul 30, 2013, at 7:45, Garrett Wollman wrote:
 
 There are plenty of situations in which a remote recursive resolver is
 untrustworthy.  (Some would say any situation.)  It doesn't have to be
 BIND, but people do legitimately want the normal DNS diagnostic
 utilities, which sadly have been tied together with BIND for some
 years now.  (I don't know why anyone would ever use nslookup(1), but
 host(1) and dig(1) are pretty much essential.)
 

If you're that paranoid about a remote resolver you'd have to be
paranoid about someone doing a MITM on your DNS lookups altogether,
since even having your own local recursor can't protect you from that as
99% of the web doesn't use DNSSEC. This will quickly turn into a
security yak-shaving contest, but I completely understand your
viewpoint.

I'd vote for keeping the bind utilities in base; I use them every day.
The ones provided with unbound work well, but finger memory...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
On Tue, Jul 30, 2013, at 7:47, Daniel Kalchev wrote:
 
 We could in theory remove the BIND's authoritative name server 
 executable... if that is attracting the SAs.
 

It's the same executable, that's the problem :-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mehmet Erol Sanliturk
On Tue, Jul 30, 2013 at 8:47 AM, Daniel Kalchev dan...@digsys.bg wrote:


 On 30.07.13 15:21, Mark Felder wrote:

 People don't seem upset about not having a webserver, IMAP/POP daemon,
 or LDAP server in base, so I don't understand what the big deal is about
 removing BIND.


 I believe the primary reason these things are not in the base system is
 that they have plenty of dependencies, with possibly conflicting licenses
 etc.

  If the concern is over the rare case when you absolutely
 need a DNS recursor and there are none you can reach I suppose we should
 just import Unbound.


 There are many and good reasons to include an fully featured name server,
 or at least full recursive resolver. For example, for properly supporting
 DNSSEC.
 We could in theory remove the BIND's authoritative name server
 executable... if that is attracting the SAs.

 The justification reduce the number of SA's, that is, the bad PR is
 probably not enough. Going that direction, we should consider Comrade
 Stalin's maxim FreeBSD exists, there are problems, here is the solution --
 no FreeBSD, no problems! :-)

 Daniel




Then , there exists a new problem :


There is no FreeBSD ...


Thank you very much .


Mehmet Erol Sanliturk
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Daniel Kalchev


On 30.07.13 16:13, Mehmet Erol Sanliturk wrote:




On Tue, Jul 30, 2013 at 8:47 AM, Daniel Kalchev dan...@digsys.bg 
mailto:dan...@digsys.bg wrote:



Going that direction, we should consider Comrade Stalin's maxim
FreeBSD exists, there are problems, here is the solution -- no
FreeBSD, no problems! :-)

Daniel




Then , there exists a new problem :


There is no FreeBSD ...


We already know Comrade Stalin's solution had... bugs. Not before 
millions parted with their lives...


When/if we remove BIND from FreeBSD, we might find out whether that 
solution has bugs, or not. Not until then, though.


Back to the topic :)

My take on this is that removing BIND from the base today is.. 
irresponsible. First, most who use FreeBSD expect an DNS server to be 
readily available. Some people would just avoid to use any ports etc.
BIND in base is well tested and known evil. If we are ever to replace it 
with something else, that something else has to prove itself - 
demonstrate that it is at least as good as BIND -- in the base system. 
In practice, not in theory.


This is very much an situation like replacing gcc with clang/llvm. 
However, in the case of BIND we have no licensing problems, stability 
problems, performance problems etc --- just concerns that BIND generates 
many SAs -- which might be actually good indicator, as it demonstrates 
that BIND is worked on.


I personally see no reason to remove BIND from base. If someone does not 
want BIND in their system, they could always use the WITHOUT_BIND build 
switch.


Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Ronald Klop
On Tue, 30 Jul 2013 15:32:44 +0200, Daniel Kalchev dan...@digsys.bg  
wrote:




On 30.07.13 16:13, Mehmet Erol Sanliturk wrote:




On Tue, Jul 30, 2013 at 8:47 AM, Daniel Kalchev dan...@digsys.bg  
mailto:dan...@digsys.bg wrote:



Going that direction, we should consider Comrade Stalin's maxim
FreeBSD exists, there are problems, here is the solution -- no
FreeBSD, no problems! :-)

Daniel




Then , there exists a new problem :


There is no FreeBSD ...


We already know Comrade Stalin's solution had... bugs. Not before  
millions parted with their lives...


When/if we remove BIND from FreeBSD, we might find out whether that  
solution has bugs, or not. Not until then, though.


Back to the topic :)

My take on this is that removing BIND from the base today is..  
irresponsible. First, most who use FreeBSD expect an DNS server to be  
readily available.


Interesting. What are your statistics of 'most' based on?

Ronald.


Some people would just avoid to use any ports etc.
BIND in base is well tested and known evil. If we are ever to replace it  
with something else, that something else has to prove itself -  
demonstrate that it is at least as good as BIND -- in the base system.  
In practice, not in theory.


This is very much an situation like replacing gcc with clang/llvm.  
However, in the case of BIND we have no licensing problems, stability  
problems, performance problems etc --- just concerns that BIND generates  
many SAs -- which might be actually good indicator, as it demonstrates  
that BIND is worked on.


I personally see no reason to remove BIND from base. If someone does not  
want BIND in their system, they could always use the WITHOUT_BIND build  
switch.


Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread sthaug
  For years, a lot of security advisories have been present for bind.
  I'm just guessing if it's not a good idea to remove bind from base?
 
  This will probably free by half the number of FreeBSD SA's in the future.
 
 
 Sure, but no bind in base also implies no dig, nslookup or host.

Exactly. It's a slippery slope - if we continue removing useful
functionality from FreeBSD there are fewer and fewer arguments for
why one should use FreeBSD and not Linux.

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.
2. The base system contains a lot of the useful functionality I need.

and every contrib part which is removed, detracts from this.

YMMV.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
On Tue, Jul 30, 2013, at 8:44, Ronald Klop wrote:
 
 Interesting. What are your statistics of 'most' based on?
 

Yes, this shouldn't be left to conjecture. A large community poll should
be the first step IMHO.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Wiley, Glen
The package would have to be reworked to remove the name server - not an
impossible task and you could make a case for it from an ideological
perspective, but is it worth the work?

On 7/30/13 8:59 AM, Mark Felder f...@freebsd.org wrote:

On Tue, Jul 30, 2013, at 7:47, Daniel Kalchev wrote:
 
 We could in theory remove the BIND's authoritative name server
 executable... if that is attracting the SAs.
 

It's the same executable, that's the problem :-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
On Tue, Jul 30, 2013, at 8:32, Daniel Kalchev wrote:
 
 
 This is very much an situation like replacing gcc with clang/llvm. 
 However, in the case of BIND we have no licensing problems, stability 
 problems, performance problems etc --- just concerns that BIND generates 
 many SAs -- which might be actually good indicator, as it demonstrates 
 that BIND is worked on.
 

There's a man with a name whose initials match DJB that would strongly
disagree. Now he's not always the best person to reference, but he's
made a succinct point with his own software, whether or not you like
using it. 

Unbound/NSD are suitable replacements if we really need something in
base, and they have been picked up by OpenBSD for a good reason --
clean, secure, readable, maintainable codebases and their use across the
internet and on the ROOT servers is growing.

 I personally see no reason to remove BIND from base. If someone does not 
 want BIND in their system, they could always use the WITHOUT_BIND build 
 switch.

I'd be inclined to agree if it wasn't such a wholly insecure chunk of
code. You don't see people whining about Sendmail in base when they
prefer Postfix or Exim, but Sendmail doesn't have a new exploit every
week. You do tend to need an MTA for getting messages off the system
more than you need a local recursor/cache, but at least it's not causing
you maintenance headaches. If you consider the possibility that a large
enough percentage of users really desire a local recursor/cache it
should be our duty to give them the best option available.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Tim Daneliuk

On 07/30/2013 08:13 AM, Mehmet Erol Sanliturk wrote:

On Tue, Jul 30, 2013 at 8:47 AM, Daniel Kalchev dan...@digsys.bg wrote:



On 30.07.13 15:21, Mark Felder wrote:


People don't seem upset about not having a webserver, IMAP/POP daemon,
or LDAP server in base, so I don't understand what the big deal is about
removing BIND.



I believe the primary reason these things are not in the base system is
that they have plenty of dependencies, with possibly conflicting licenses
etc.

  If the concern is over the rare case when you absolutely

need a DNS recursor and there are none you can reach I suppose we should
just import Unbound.



There are many and good reasons to include an fully featured name server,
or at least full recursive resolver. For example, for properly supporting
DNSSEC.
We could in theory remove the BIND's authoritative name server
executable... if that is attracting the SAs.

The justification reduce the number of SA's, that is, the bad PR is
probably not enough. Going that direction, we should consider Comrade
Stalin's maxim FreeBSD exists, there are problems, here is the solution --
no FreeBSD, no problems! :-)

Daniel





Then , there exists a new problem :


There is no FreeBSD ...


Thank you very much .




Exactly.  Either strip everything out of the base
including things like perl or admit that there is more
to a modern OS than just kernel and admin tools.



--
---
Tim Daneliuk
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
On Tue, Jul 30, 2013, at 8:42, sth...@nethelp.no wrote:
 
 and every contrib part which is removed, detracts from this.
 

And every contrib part that is added to base is another piece of
software that rots for the life of a major release and ends up getting
replaced by frustrated endusers with the latest in ports...

The tight integration of the base system that everyone appreciates and
respects is far below high-level software like BIND.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Ronald Klop

On Tue, 30 Jul 2013 16:04:46 +0200, Mark Felder f...@freebsd.org wrote:


On Tue, Jul 30, 2013, at 8:32, Daniel Kalchev wrote:



This is very much an situation like replacing gcc with clang/llvm.
However, in the case of BIND we have no licensing problems, stability
problems, performance problems etc --- just concerns that BIND generates
many SAs -- which might be actually good indicator, as it demonstrates
that BIND is worked on.



There's a man with a name whose initials match DJB that would strongly
disagree. Now he's not always the best person to reference, but he's
made a succinct point with his own software, whether or not you like
using it.

Unbound/NSD are suitable replacements if we really need something in
base, and they have been picked up by OpenBSD for a good reason --
clean, secure, readable, maintainable codebases and their use across the
internet and on the ROOT servers is growing.


I personally see no reason to remove BIND from base. If someone does not
want BIND in their system, they could always use the WITHOUT_BIND build
switch.


I'd be inclined to agree if it wasn't such a wholly insecure chunk of
code. You don't see people whining about Sendmail in base when they
prefer Postfix or Exim, but Sendmail doesn't have a new exploit every
week. You do tend to need an MTA for getting messages off the system
more than you need a local recursor/cache, but at least it's not causing
you maintenance headaches. If you consider the possibility that a large
enough percentage of users really desire a local recursor/cache it
should be our duty to give them the best option available.



DragonflyBSD also removed BIND from base some time ago.
http://www.shiningsilence.com/dbsdlog/2010/05/06/5853.html

Ronald.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Ronald Klop
On Tue, 30 Jul 2013 15:53:08 +0200, Tim Daneliuk tun...@tundraware.com  
wrote:



On 07/30/2013 08:13 AM, Mehmet Erol Sanliturk wrote:
On Tue, Jul 30, 2013 at 8:47 AM, Daniel Kalchev dan...@digsys.bg  
wrote:




On 30.07.13 15:21, Mark Felder wrote:


People don't seem upset about not having a webserver, IMAP/POP daemon,
or LDAP server in base, so I don't understand what the big deal is  
about

removing BIND.



I believe the primary reason these things are not in the base system is
that they have plenty of dependencies, with possibly conflicting  
licenses

etc.

  If the concern is over the rare case when you absolutely
need a DNS recursor and there are none you can reach I suppose we  
should

just import Unbound.



There are many and good reasons to include an fully featured name  
server,
or at least full recursive resolver. For example, for properly  
supporting

DNSSEC.
We could in theory remove the BIND's authoritative name server
executable... if that is attracting the SAs.

The justification reduce the number of SA's, that is, the bad PR is
probably not enough. Going that direction, we should consider Comrade
Stalin's maxim FreeBSD exists, there are problems, here is the  
solution --

no FreeBSD, no problems! :-)

Daniel





Then , there exists a new problem :


There is no FreeBSD ...


Thank you very much .




Exactly.  Either strip everything out of the base
including things like perl or admit that there is more
to a modern OS than just kernel and admin tools.





You have perl in base?
http://bsd.slashdot.org/story/02/05/14/0015234/freebsd-perl-to-be-removed
;-)

Ronald.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Chris Ross

On Jul 30, 2013, at 10:07 , Mark Felder wrote:
 On Tue, Jul 30, 2013, at 8:42, sth...@nethelp.no wrote:
 
 and every contrib part which is removed, detracts from this.
 
 And every contrib part that is added to base is another piece of
 software that rots for the life of a major release and ends up getting
 replaced by frustrated endusers with the latest in ports…

  I do generally agree with this point, but it's not every contrib part.
Many contrib additions can be useful to a majority, and not rotting
software.  Some will use more recent replacements from ports, others
won't, but it's not always bad.

 The tight integration of the base system that everyone appreciates and
 respects is far below high-level software like BIND.

  I agree with this point too, however I, like others have voiced, feel
strongly that diagnostic [client] tools like host and/or dig are not at
all high-level software and _need_ to be present in a base
system.  Whosever they are.

   - Chris


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Ronald Klop

On Tue, 30 Jul 2013 16:07:30 +0200, Mark Felder f...@freebsd.org wrote:


On Tue, Jul 30, 2013, at 8:42, sth...@nethelp.no wrote:


and every contrib part which is removed, detracts from this.



And every contrib part that is added to base is another piece of
software that rots for the life of a major release and ends up getting
replaced by frustrated endusers with the latest in ports...

The tight integration of the base system that everyone appreciates and
respects is far below high-level software like BIND.


+1

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Freddie Cash
On 2013-07-30 12:55 AM, David Demelier demelier.da...@gmail.com wrote:

 Hi,

 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

 This will probably free by half the number of FreeBSD SA's in the future.

Hasn't this discussion occurred several times already on the -current
mailing list over the past year? And hadn't unbound and/or ldns been
imported into - current already?

This just seems very familiar somehow...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Felder
On Tue, Jul 30, 2013, at 9:10, Ronald Klop wrote:
 
 DragonflyBSD also removed BIND from base some time ago.
 http://www.shiningsilence.com/dbsdlog/2010/05/06/5853.html
 

I was not aware of this; that's worth referencing. I'm not sure where
NetBSD stands but a quick search implies that they still have BIND in
base.

To all: please note that my emails on this subject are personal opinions
of mine and mine only; I have no idea what other @FreeBSD.org people
think. It's merely my own conclusion of where I think FreeBSD should be
headed after several years of FreeBSD administration. There are people
much wiser and informed than I who will be making the decision if this
ever comes to pass before 10.0-RELEASE...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Michael Grimm

On 2013-07-30 16:04, Mark Felder wrote:


Unbound/NSD are suitable replacements if we really need something in
base, and they have been picked up by OpenBSD for a good reason --
clean, secure, readable, maintainable codebases and their use across 
the

internet and on the ROOT servers is growing.


+1

I switched two years ago and disabled bind in /etc/src.conf. Thus, I 
could
skip some followup-work regarding SAs in the past multiplied by the 
number

of servers involved.

Regards,
Michael

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread O. Hartmann
On Tue, 30 Jul 2013 09:07:30 -0500
Mark Felder f...@freebsd.org wrote:

 On Tue, Jul 30, 2013, at 8:42, sth...@nethelp.no wrote:
  
  and every contrib part which is removed, detracts from this.
  
 
 And every contrib part that is added to base is another piece of
 software that rots for the life of a major release and ends up getting
 replaced by frustrated endusers with the latest in ports...
 
 The tight integration of the base system that everyone appreciates and
 respects is far below high-level software like BIND.

So Linux did already nullify the contributions in the base system by
eleminating ALL contributions but the kernel - the purest way one can
go.



signature.asc
Description: PGP signature


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Royce Williams
On Tue, Jul 30, 2013 at 6:29 AM, Michael Grimm
trash...@odo.in-berlin.de wrote:

 On 2013-07-30 16:04, Mark Felder wrote:

 Unbound/NSD are suitable replacements if we really need something in
 base, and they have been picked up by OpenBSD for a good reason --
 clean, secure, readable, maintainable codebases and their use across the
 internet and on the ROOT servers is growing.

I don't know enough about BIND replacements to identify them all by
sight, but according to bsdstats.org's ports/dns category:

http://bsdstats.org/ports.php?category=27

... across all OSes (I'm not sure how to filter on just FreeBSD), of
the 23996 systems reporting , 4966 (~20.71%) are running something
from ports that I roughly recognize as a potential replacement for
BIND in base:

bind84-base 15
bind9 152
bind9-base 187
bind9-dlz+mysql+db41 5
bind9-sdb-ldap 36
bind9-sdb-ldap-base 20
bind94 40
bind94-base 157
bind95 29
bind95-base 54
bind96 146
bind96-base 181
bind97 120
bind97-base 429
bind97-sdb 8
bind97-sdb-base 12
bind98 202
bind98-base 423
bind98-devel 13
bind99 259
bind99-base 405
bind99-devel 12
djbdns 629
djbdns-ipv6 392
nsd 140
powerdns 189
powerdns-devel 17
powerdns-recursor 120
udns 215
unbound 359

4966/23977 = 0.20712

Given how many PC-BSD boxes there are, and how many folks that are
running FreeBSD and bsdstats may not know why (or how) to replace
BIND, ~20% seems like a significant number.

I'm not advocating either way; I'm just providing some data points.

Royce
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread J David
Half the people will say:

There should be more stuff in base!

The other half will say:

There should be less stuff in base!

People don't generally change each other's minds about this because
they start from competing definitions of what is good that are 100%
opinion in nature.

(Spoken as a hardcore advocate of There should be less stuff in base!)

DNS client and DNS server functionality are quite different, and it
would be swell if there were a set of BIND-independent client tools
that were part of the base so that BIND could, at a minimum, be left
out via WITH_BIND=no in src.conf or similar without producing a
crippled system.  And/or people could install the DNS server of their
choice (whether unbound or BIND or whatever) using pkg.

If there isn't one already readily available, I might even volunteer
to help develop that set of client tools at such time as FreeBSD
coding standards allow C++11 in the tree. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread sthaug
  and every contrib part which is removed, detracts from this.
  
 
 And every contrib part that is added to base is another piece of
 software that rots for the life of a major release and ends up getting
 replaced by frustrated endusers with the latest in ports...
 
 The tight integration of the base system that everyone appreciates and
 respects is far below high-level software like BIND.

Speaking only for myself, I disagree rather strongly with this.

Looking at /usr/src/contrib on an 8.4-STABLE system, I use the
following frequently (often several times per day):

bind9
diff
less
libreadline (used by lots of other stuff)
ntp
nvi
tcp_wrappers
tcpdump
tcsh
telnet
top
traceroute

If you remove these contrib parts from FreeBSD, that means at least
12 packages I'd need to install on every new FreeBSD system to get
the system in a (for me) functional state. Certainly not a *major*
hassle - but having these parts integrated is part of the FreeBSD
attraction. I don't think we should work to make FreeBSD less
attractive...

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Ronald Klop

On Tue, 30 Jul 2013 16:14:57 +0200, Freddie Cash fjwc...@gmail.com wrote:

On 2013-07-30 12:55 AM, David Demelier demelier.da...@gmail.com  
wrote:


Hi,

For years, a lot of security advisories have been present for bind.
I'm just guessing if it's not a good idea to remove bind from base?

This will probably free by half the number of FreeBSD SA's in the  
future.


Hasn't this discussion occurred several times already on the -current
mailing list over the past year?


http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039830.html


And hadn't unbound and/or ldns been
imported into - current already?


http://lists.freebsd.org/pipermail/svn-src-all/2012-July/056004.html
And next messages.

Regards,
Ronald.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Ronald Klop
On Tue, 30 Jul 2013 16:55:09 +0200, Ronald Klop  
ronald-freeb...@klop.yi.org wrote:


On Tue, 30 Jul 2013 16:14:57 +0200, Freddie Cash fjwc...@gmail.com  
wrote:


On 2013-07-30 12:55 AM, David Demelier demelier.da...@gmail.com  
wrote:


Hi,

For years, a lot of security advisories have been present for bind.
I'm just guessing if it's not a good idea to remove bind from base?

This will probably free by half the number of FreeBSD SA's in the  
future.


Hasn't this discussion occurred several times already on the -current
mailing list over the past year?


http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039830.html


And hadn't unbound and/or ldns been
imported into - current already?


http://lists.freebsd.org/pipermail/svn-src-all/2012-July/056004.html
And next messages.


Even more:
http://svnweb.freebsd.org/base/head/contrib/ldns/
http://svnweb.freebsd.org/base/head/contrib/unbound/


Regards,
Ronald.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Peter Maxwell
On 30 July 2013 14:42, sth...@nethelp.no wrote:

   For years, a lot of security advisories have been present for bind.
   I'm just guessing if it's not a good idea to remove bind from base?
  
   This will probably free by half the number of FreeBSD SA's in the
 future.
  
 
  Sure, but no bind in base also implies no dig, nslookup or host.

 Exactly. It's a slippery slope - if we continue removing useful
 functionality from FreeBSD there are fewer and fewer arguments for
 why one should use FreeBSD and not Linux.


Having lots of third-party software in base is not one of those reasons
however.




 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.

Having bind in base does have one advantage in that it is more carefully
scrutinised that it would likely be in ports.




 2. The base system contains a lot of the useful functionality I need.


So does ports.




 and every contrib part which is removed, detracts from this.


No, it doesn't.  The base system should be just that - a base minimal
installation.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Daniel Kalchev


On 30.07.13 18:26, Peter Maxwell wrote:

On 30 July 2013 14:42, sth...@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.


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


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).


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


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.


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?


Daniel

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Daniel Kalchev


On 30.07.13 16:44, Ronald Klop wrote:
On Tue, 30 Jul 2013 15:32:44 +0200, Daniel Kalchev dan...@digsys.bg 
wrote:




Back to the topic :)

My take on this is that removing BIND from the base today is.. 
irresponsible. First, most who use FreeBSD expect an DNS server to be 
readily available.


Interesting. What are your statistics of 'most' based on?


Unfortunately, not much objective statistics. The bsdstats sample is 
rather small and obviously biased (towards people who would share their 
config, mostly).


I was hoping for some usable data from the Open Resolver Project 
(http://openresolverproject.org/)but there is not much useful 
information for this purpose there either. It is also very unlikely a 
pool would result in any meaningful data...


But here is an idea: Remove BIND from HEAD overnight and see how many 
will complain ;-)

If nobody complains, don't put it back in.

Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Freddie Cash
On 2013-07-30 7:55 AM, Ronald Klop ronald-freeb...@klop.yi.org wrote:

 On Tue, 30 Jul 2013 16:14:57 +0200, Freddie Cash fjwc...@gmail.com
wrote:

 On 2013-07-30 12:55 AM, David Demelier demelier.da...@gmail.com
wrote:


 Hi,

 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

 This will probably free by half the number of FreeBSD SA's in the
future.


 Hasn't this discussion occurred several times already on the -current
 mailing list over the past year?


 http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039830.html


 And hadn't unbound and/or ldns been
 imported into - current already?


 http://lists.freebsd.org/pipermail/svn-src-all/2012-July/056004.html
 And next messages.

Thanks for the references. I'm mostly mailing my phone these days and
searching for references and copy/paste aren't the easiest things to do. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Peter Maxwell
On 30 July 2013 16:58, Daniel Kalchev dan...@digsys.bg wrote:


 On 30.07.13 18:26, Peter Maxwell wrote:

 On 30 July 2013 14:42, sth...@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.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Wiley, Glen
Verisign is currently actively developing the getdns API description that
Paul Hoffman put together and documented at http://www.vpnc.org/getdns-api/

This includes a stub resolver, a recursive resolver and could provide
functionality independent of the BIND distribution.  We have adopted the
BSD coding standards for the project and will be making the github
repository public later this year.

On 7/30/13 11:58 AM, Daniel Kalchev dan...@digsys.bg wrote:

snip

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?

Daniel

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Daniel Kalchev

On 30.07.2013, at 19:49, Peter Maxwell pe...@allicient.co.uk wrote:

 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.
 

One can argue that BIND is the de facto standard on *nix shaped systems too.

Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Peter Maxwell
On 30 July 2013 21:03, Daniel Kalchev dan...@digsys.bg wrote:


 On 30.07.2013, at 19:49, Peter Maxwell pe...@allicient.co.uk wrote:

  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.
 

 One can argue that BIND is the de facto standard on *nix shaped systems too


Yes, that is precisely my point, the preceding sentences to what you
quoted...

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.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Chris H
 On Tue, Jul 30, 2013, at 8:32, Daniel Kalchev wrote:


 This is very much an situation like replacing gcc with clang/llvm.
 However, in the case of BIND we have no licensing problems, stability
 problems, performance problems etc --- just concerns that BIND generates
 many SAs -- which might be actually good indicator, as it demonstrates
 that BIND is worked on.


 There's a man with a name whose initials match DJB that would strongly
 disagree. Now he's not always the best person to reference, but he's
 made a succinct point with his own software, whether or not you like
 using it.

 Unbound/NSD are suitable replacements if we really need something in
 base, and they have been picked up by OpenBSD for a good reason --
 clean, secure, readable, maintainable codebases and their use across the
 internet and on the ROOT servers is growing.

 I personally see no reason to remove BIND from base. If someone does not
 want BIND in their system, they could always use the WITHOUT_BIND build
 switch.

 I'd be inclined to agree if it wasn't such a wholly insecure chunk of
 code. You don't see people whining about Sendmail in base when they
 prefer Postfix or Exim, but Sendmail doesn't have a new exploit every
 week. You do tend to need an MTA for getting messages off the system
 more than you need a local recursor/cache, but at least it's not causing
 you maintenance headaches. If you consider the possibility that a large
 enough percentage of users really desire a local recursor/cache it
 should be our duty to give them the best option available.

+1
Sorry to do that. But I simply couldn't have expressed it better, myself.

 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Chris H

 On 30.07.2013, at 19:49, Peter Maxwell pe...@allicient.co.uk wrote:

 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.


 One can argue that BIND is the de facto standard on *nix shaped systems too.

Considering the topic, and how many times it's come up. I'm not sure that's 
anything to
be proud of. ;)


 Daniel
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Bind in FreeBSD, security advisories

2013-07-30 Thread Mark Andrews

In message 9b0056db5b760c755dd4acc45bfbd1ad.authentica...@ultimatedns.net, C
hris H writes:
 
  On 30.07.2013, at 19:49, Peter Maxwell pe...@allicient.co.uk wrote:
 
  I personally prefer qmail over sendmail
  but I wouldn't suggest qmail should be in base for the reason that sendmai
 l
  is the de facto standard on *nix shaped systems.
 
 
  One can argue that BIND is the de facto standard on *nix shaped systems too
 .
 
 Considering the topic, and how many times it's come up. I'm not sure that's a
 nything to
 be proud of. ;)

Given not all CVE's are created equal and given the amount of
internal self consistancy checks (all of which kill the server if
they don't pass (and push the CVSS score to 7.x)) there are in BIND
the number of advisaries is actually very small.

Yes, this was a internal self consistancy check failing.

We are human and despite code reviews, unit and system tests, static
analysis checkers etc. some errors do make it through.

Mark

  Daniel
  ___
  freebsd-stable@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org