On Thu, 2004-12-02 at 16:47 -0800, william(at)elan.net wrote:
Having had the pleasure of seeing these kind of debates on other lists
several times (which made those lists unusable for at least a week) can
I ask that participants please do not engage in the following debates:
1. BIND vs DJBDNS
There is no need for a debate when the answer is so clear:
============ ROUND 1: BIND vs DJBDNS ==================================
How many LoC (w/out comments) in DJBDNS? : 9,932 lines
How many LoC (w/out comments) in BIND 9.2.2? : 204,970 lines
Security Guarantee in DJBDNS? : Yes, $500 USD (unclaimed)
Security Guarantee in BIND? : No.
How many public exploits for DJBDNS? : 0
How many public exploits for BIND? : 19+
The NIST ICAT search reveals 55 "Medium to High" BIND
============ ROUND 1: SendMail vs. qmail ==============================
How many LoC (w/out comments) in qmail? : 14,724 lines
How many LoC (w/out comments) in Sendmail? : 87,118 lines
Security Guarantee in qmail? : Yes, $500 USD (unclaimed)
Security Guarantee in SendMail? : No.
How many public exploits for qmail? : 0
How many public exploits for SendMail? : 28
The NIST ICAT search reveals 28 "Medium to High" SendMail
14 serious vulnerabilities discovered within the SendMail codebase
between 1996 and 1997: http://cr.yp.to/maildisasters/sendmail.html
============ BIND Security Explored... ================================
BIND SECURITY ADVISORIES:
|--> http://www.cert.org/advisories/CA-1997-22.html (1)
--> http://www.cert.org/advisories/CA-1996-04.html (1)
--> http://www.cert.org/advisories/CA-1998-05.html (3)
|-> http://www.cert.org/advisories/CA-1999-14.html (6)
|--> http://www.cert.org/advisories/CA-2000-03.html (REITERATED)
--> http://www.cert.org/advisories/CA-2000-20.html (2)
--> http://www.cert.org/advisories/CA-2001-02.html (4)
--> http://www.cert.org/advisories/CA-2002-15.html (1)
--> http://www.cert.org/advisories/CA-2002-19.html (2)
--> http://www.cert.org/advisories/CA-2002-31.html (4)
--> http://www.cert.org/advisories/CA-2003-01.html (1)
Just how bad is BIND's security track record? :
CERT Summary* ranking:
#1 2/Q 1998 http://www.cert.org/summaries/CS-98.06.html
#3 3/Q 1998 http://www.cert.org/summaries/CS-98.07.html
#3 4/Q 1999 http://www.cert.org/summaries/CS-99-04.html
#1 2/Q 2000 http://www.cert.org/summaries/CS-2000-02.html
#4 4/Q 2002 http://www.cert.org/summaries/CS-2002-04.html
June 28, 2002 - Buffer Overflows in Multiple DNS Resolver Libraries
- This was probably one of the single largest exploits (as regards
vendor** impact and potential damage) the Internet has ever seen.
In plain English, it was fucking HUGE.
- libraries affected (_HINT_ DJBDNS is _NOT_ in this list)?
- ISC BIND DNS resolver library (libbind)
- BSD DNS resolver library (libc)
- GNU DNS resolver library (glibc)
May 21, 1998 - BIND gets a SPECIAL CERT notice its so problematic:
May 28, 1998 - BIND gets ANOTHER special notice, more exploits!
Other DNS related GOOD reading:
Compare BIND vs DJBDNS with respect to 'ease of use':
Read up about DJBDNS security:
Trouble with DNS:
* The CERT Coordination Center periodically issues the CERT Summary to
draw attention to the types of attacks currently being reported to our
incident response team, as well as to other noteworthy incident and
vulnerability information. The summary includes pointers to sources of
information for dealing with the problems discussed here.
** With respect to the number of Vendors affected by this massive bug
which by my research indicates that it was revealed 2 full years prior
and even fixed within OpenWall affected all of the following Vendors:
Secure Computing Corporation
Sendmail (this ALONE is huge)
Sun Microsystems (SOLARIS)
and of course:
Internet Software Consortium (ISC)
- All versions of BIND 4 from 4.8.1 prior to BIND 4.9.9 are vulnerable.
- All versions of BIND 8 prior to BIND 8.2.6 are vulnerable.
- All versions of BIND 8.3.x prior to BIND 8.3.3 are vulnerable.
- BIND versions BIND 9.2.0 and BIND 9.2.1 are vulnerable.
- The status of BIND 4.8 is unknown, assume that it is vulnerable.
- BIND versions BIND 9.0.x and BIND 9.1.x are not vulnerable.
As you can see, this bug had been around a _LONG_ time.
2. Linux vs FreeBSD
I'm not touching the Linux vs FreeBSD argument with a ten foot pole,
instead I'll stipulate that OpenBSD (by reason of security) is better
than both, or perhaps (by reason of the desktop and driver support)
Linux is clearly better than any other alternative.
And for the record, people who state that DJBDNS is not free are
extremely wrong. The software is quite literally free. The only
argument people come up with is with respect to the LICENSE or rather,
the lack thereof. That being said, the VAST majority of those who slag
djbdns are simply ignorant souls spouting off regurgitated nonsensical
People who claim that they can not or will not work with either qmail or
djbdns are simply being difficult likely because they have already
invested much time in understanding either BIND or Sendmail or other
DJB States himself:
Note to programmers: You can and should switch from libresolv to the
djbdns client library, which has always been covered by the djbdns
security guarantee. I've put the .[ch] files (dns.h, dns_dfd.c,
dns_domain.c, dns_dtda.c, dns_ip.c, dns_ipq.c, dns_mx.c, dns_name.c,
dns_nd.c, dns_packet.c, dns_random.c, dns_rcip.c, dns_rcrw.c,
dns_resolve.c, dns_sortip.c, dns_transmit.c, dns_txt.c) and all
necessary lower-level .[ch] files into the public domain.
Placing documents in the public domain:
Software User's Rights:
What does all this mean for the free software world? Once you've
legally downloaded a program, you can compile it. You can run it. You
can modify it. You can distribute your patches for other people to
use. If you think you need a license from the copyright holder, you've
been bamboozled by Microsoft. As long as you're not distributing the
software, you have nothing to worry about.
So what if you are a distributor?
I often hear people complain because DJB stipulates that his software
(to be distributed) MUST be installed in specific location by reason of
cross platform compatibility, and I couldn't agree more. He has as
usual, an entire page dedicated: http://cr.yp.to/compatibility.html
Exception: You are permitted to distribute a precompiled var-qmail
package if (1) installing the package produces exactly the
same /var/qmail hierarchy as a user would obtain by downloading,
compiling, and installing qmail-1.03.tar.gz, fastforward-0.51.tar.gz,
and dot-forward-0.71.tar.gz; (2) the package behaves correctly, i.e.,
the same way as normal qmail+fastforward+dot-forward installations on
all other systems; and (3) the package's creator warrants that he has
made a good-faith attempt to ensure that the package behaves
Wow that doesn't seem unreasonable, or impossible. The Linux and other
distributions who refuse to work with qmail/djbdns are doing so because
they have either been repeating FUD so long they have forgotten what
their issue was but don't want to look bad by changing their tune now,
or because they have their own agenda (ie: own MTA package they wish to
(1) Binary package must retain hierarchy
(2) Must behave correctly on all architectures/systems
(3) Package creator agrees to make a good-faith attempt to ensure the
Wow, when you actually _READ_ documentation its amazing how SIMPLE the
issues really are and you can see how stupid and stubborn those
representing the various Distributions that lament about non-existent
license issues are being.
It is not acceptable to have qmail working differently on different
machines; any variation is a bug. If there's something about a system
(compiler, libraries, kernel, hardware, whatever) that changes qmail's
behavior, then that platform is not supported, and you are not
permitted to distribute binaries.
Building binary distributions:
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
please go to
Description: This is a digitally signed message part