Re: re: djbdns is not free

Ok lets try this,

 "Use what you understand, what you want to use, and where it is
applicable for use"


Ok, I concede, your answer is much better.

If one doesn't want to upgrade and doesn't need features and does want
to take some time figuring out how djb-products work, then do so. If you
have been taught to write bind zone files use that. If you want a
clickety-click interface, use the bloody Windows DNS server.*


Hrm, well I suppose if you really want the clicky clicky.

(* = or the many other frontends for eg bind,djbdns,powerdns,nsd etc)

They are at 9.2.4 already btw ;)


Actually 9.3.0 unless you mean the 9.2.x chain, in either case:

bind   9.2.4 LoC: 200,235
bind   9.3.0 LoC: 215,751
djbdns 1.05  LoC:   9,932

Hello?  McFly?! WTF is going on that over 200,000 lines of code is
required just to send itty bitty fucking text records in UDP packets.
SURELY I'm getting the point across here.

I'm not liking the trend.  I believe firmly that less is more.  This is
what is so great about OpenBSD.  Once a product is "complete" in that it
does what it set out to do, "patches" should actually REMOVE code.
Whilst I am aware of the problems associated with "features" have a look
at the BIND scenario.

Do I use 9.2.x?
or I do I use 9.3.x?
Just what is the difference?
Hey what is bind 4.x.x?
Oooo and whats this bind 8.x.x?

I'm sure you at least see where I am going with this.

Without features you can't have much bugs now can you ? :)


djbdns is a fully functional DNS server.  I have never had to patch it
or alter it in any way other than to suit my own meddling.

There are always people complaining about bind, that it is fat, has bugs
etc, but they always forget that most of the time they where the folks
asking for all the features. For that matter, if you want to have


This is what is great about djbdns.  Looking inside djbdns-1.05.tar.gz I
see the date "Feb 2001" repeatedly.  Simply amazing.

something simple as IPv6 support, you will need to go to a third party
for djbdns. Not even thinking about stuff like dnssec, updates and the


Please do not trivialize IPv6 that way, its by no means trivial, and
there are many who believe that its fairly gimped, regardless I do not
see anything else out there as an alternative and the Japanese have now
rolled out a mirrored IPv6 root server in France and I believe Korea is
or already has their IPv6 root server ready to go or going.

Dan has some interesting things to say in a very comprehensive overview
of IPv6: http://cr.yp.to/djbdns/ipv6mess.html  Whilst I am not so
opinionated about IPv6, my main issue is precisely that no one is using
it, no one that _really_ matters (stated factually, not ignorantly),
that is to say, until North America does something intelligent like a)
acknowledge the rest of the world and b) actually work with them instead
of against them (so it would seem).

Observe the following:

Miscellaneous quotes from other people (* meaning BIND company employee
or owner):

Miscellaneous quotes from other people (* meaning BIND company
employee or owner):

      * Ian Jackson, 2001.02.08: ``I strongly agree.'' 
      * David Conrad*, 2001.03.14: ``More operational experience is
        required.'' 
      * Robert Elz, 2001.03.16: ``I suspect this is a pointless
        discussion.'' 
      * Paul Vixie*, 2001.04.28: ``Hint to whoever is in charge: the
        time to debate A6's merits at this level was: before it got
        put on the standards track, before a lot of code got written,
        and before a lot of operational deployment was put into
        various long and expensive pipelines. ... If we're going to
        abandon A6 then i for one am ready to listen to tony li's "too
        little, too soon" comment, through [sic] IPv6 itself into the
        waste bin, and go back to the whiteboard and solve more of the
        problems we actually have. There is NO justification for the
        rapid and early adoption of IPv6 in its present form unless A6
        or something very much like A6 is made a part of it.'' 
      * Jim Bound, 2001.04.30: ``A6 will be shipped on the street and
        its a done deal. Do I like A6 no. Do I think a better solution
        exists yes. But do I advocate deployment of A6 yes. Why
        because its time to move forward.'' 
      * Jim Reid*, 2001.07.17: ``When is djbdns going to support all
        the DNS protocols that you've so far failed to implement
        [like] A6/DNAME chaining?'' 
      * Matt Crawford (A6 spec author), 2001.07.20: ``Your reasoning
        is markedly incorrect if applied to A6.''


So why is there no "official IPv6" in djbdns?

In July 2002, IETF downgraded the A6, DNAME, and bit-label
specifications (RFC 2874 and RFC 2673) from Proposed Standard to
Experimental: ``A6, Binary Labels and DNAME DNS extensions should not
be widely deployed for use with IPv6 at this time.''


As regards how to add IPv6 to djbdns?  Why you must attempt to make it
sound like its so difficult I do not know.

code3 $ tar zxf ucspi-tcp-0.88.tar.gz
code3 $ wget http://www.fefe.de/ucspi/ucspi-tcp-0.88-ipv6.diff14.bz2
code3 $ bunzip2 ucspi-tcp-0.88-ipv6.diff14.bz2
code3 $ cd ucspi-tcp-0.88
code3 $ ucspi-tcp-0.88 $ patch -p1 < ../ucspi-tcp-0.88-ipv6.diff14 
code3 $ make setup check

code3 $ tar zxf djbdns-1.05.tar.gz
code3 $ wget http://www.fefe.de/dns/djbdns-1.05-test21.diff.bz2
code3 $ bunzip2 djbdns-1.05-test21.diff
code3 $ cd djbdns-1.05
code3 $ patch -p1 < ../djbdns-1.05-test21.diff
code3 $ make setup check

OR Gentoo makes life very easy:

code3 # emerge djbdns 

Easy enough, if not, there is no hope for mankind.

Then again depends on what you want to use something for ;)


I suppose, although I have a strong penchant for attempting to dissuade
individuals from intentionally doing what could be physically equated to
lacerating ones self repeatedly as regards aiding those who which to out
of convenience throw security to the wind.

Special SPF records in qmail? You will have to patch it yourself if you
want to make it work ;)


Lions and Tigers and Bears Oh My! NOT A PATCH!  Please... your email
started out quite well, but when you resort to "whining about patches"
you absolutely loose my interest... and certainly doesn't aide the
credibility of your argument(s).

This was the last bug, that was 2 years ago.. wheee!
Even OpenSSH had to be updated more than that.


Surely you are not simply casting all of this proof that BIND has a
HORRID security record out the window just because nothing has been
released since 2003.  Your time is inaccurate.

The last published BIND vulnerability was CAN-2003-0914
( http://www.securityfocus.com/bid/9114 ) and was updated August 06,
2004, and originally published November 26, 2004.

Do you know (now this is going to get personal) that people other than
you and I read what you are posting to this list?  Please try to take
that with a grain of salt or two, but you have already made several
statements that are either blatantly wrong or completely without merit.
As you can see I attempt to associate an on-line resource associated
with something I assert as much as possible to avoid pointless back and
forth.

    --> http://www.cert.org/advisories/CA-2002-19.html (2)


Not BIND and this includes glibc, guess what djb uses :)


See the title:

"Buffer Overflows in Multiple DNS Resolver Libraries"

Do you understand that with BIND comes a resolver?

Do you understand that this vulnerability was singlehandedly one of the
largest and probably the most significant exploit to date?  I assure
you, its completely relative to BIND in absolutely every way shape and
form.

In my LoC comparison, I also included libresolv, I did the same to be
fair with djb, yes thats right, the 9700+ lines includes a full resolver
library.

Not BIND and this includes glibc, guess what djb uses :)


Guess what djb uses?  I don't have to guess, about either djbdns or
bind, I've written extensively with both of them.  It seems to me that
you really do not know what you are talking about, so rather than
flaming you, I'll attempt to explain to you the difference.

It would help you greatly to actually consider ALL of the information
before responding to an e-mail.  It saves me time, and makes you look
better.  I can sum this up best by simply quoting paragraph 7. from the
Qmail security page:

I've mostly given up on the standard C library. Many of its
facilities, particularly stdio, seem designed to encourage bugs. A big
chunk of qmail is stolen from a basic C library that I've been
developing for several years for a variety of applications. The
stralloc concept and getln() make it very easy to avoid buffer
overruns, memory leaks, and artificial line length limits.


So you see, both qmail, djbdns, and other djb code all use this basic C
library.  Here is an example:

readclose.o:
00000000 r .LC0                   ./readclose.c:6
00000011 r .LC1                   ./readclose.c:6
00000012 r .LC2                   ./readclose.c:6
         U _GLOBAL_OFFSET_TABLE_  ./readclose.c:6
         U __errno_location       ./readclose.c:11
         U __guard                ./readclose.c:6
00000000 T __i686.get_pc_thunk.bx ./readclose.c:6
         U __stack_smash_handler  ./readclose.c:15
         U close                  ./readclose.c:9
         U error_intr             ./readclose.c:6
         U read                   ./readclose.c:10
000000f0 T readclose              ./readclose.c:18
00000000 T readclose_append       ./readclose.c:6
         U stralloc_copys         ./readclose.c:19
         U stralloc_readyplus     ./readclose.c:9

readclose.c:int readclose(int fd,stralloc *sa,unsigned int bufsize)
stralloc.h:int stralloc_copys(stralloc *,const char *);

Yes djbdns will still link libc because it does make use of some limited
aspects of it, however, its a) completely irrelevant to the issue in
question, which is INDEED related to BIND, and b) absolutely unrelated
to djbdns in any way shape or form.

Had you actually READ the article:
  - http://www.cert.org/advisories/CA-2002-19.html

djbdns
        djbdns does not have these bugs. djbdns has never used any
        BIND-derived code. djbdns, including the djbdns client
        library, is covered by a $500 security guarantee. The djbdns
        client library is free for use by other packages in place of
        BIND's libresolv. See http://cr.yp.to/djbdns.html.
        
        Elsewhere in this advisory, CERT and the BIND company suggest
        that administrators do not need to rush to upgrade their
        libresolv-based clients if they are using BIND 9 caches. The
        idea is that (1) BIND 9 caches never put CNAME records into
        the answer section of a DNS packet except at the top and (2)
        the BIND company believes that these libresolv bugs cannot be
        triggered by answer sections with all CNAME records at the
        top.
        
        dnscache, the caching component of djbdns, is like the BIND 9
        cache in all relevant respects. Specifically, it never puts
        CNAME records into the answer section except at the top. (This
        is the normal behavior for DNS caches; BIND 4 and BIND 8 are
        abnormal.)
        
        However, it is simply not true that clients are protected by
        caches. Attackers can send unusual packets directly to
        clients, using the same well-known techniques used to
        selectively forge DNS responses. I do not endorse the
        suggestion of relying on caches (whether BIND 9 or dnscache)
        as a ``solution'' to the libresolv bugs. All libresolv-based
        clients must be upgraded immediately.
        
        There are exceptions. Sites that use a local dnscache on every
        machine, with local firewalls preventing forgery of 127.0.0.1
        and with proper IP-address checks in client libraries, are
        immune to cache-to-client packet forgery, as are sites that
        use IPSEC. However, even at those sites, libresolv-based
        clients should be upgraded immediately; the ability of the
        cache to take control of client programs, rather than simply
        providing DNS data, is a violation of standard security
        policy.

    --> http://www.cert.org/advisories/CA-2002-31.html (4)


"Systems running various versions of BIND 4 and BIND 8"

that is not BIND9


By reason that you appear to think I am only pointing the finger at Bind
9 let me clarify with the following.  My last email was intended to
evoke some thinking.  Thinking about what?  Thinking about the
incredibly poor security track record of BIND.  Bind4, 8, 9, 15, 200, it
doesn't matter, they are all insanely huge and bloated, and please, do
not succumb to the comfortability you wrap yourself in with:

This was the last bug, that was 2 years ago.. wheee!


I assure you, there is more yet to be written about BIND and its many
incarnations.

  -----
    --> http://www.cert.org/advisories/CA-2003-01.html (1)


CERT® Advisory CA-2003-01 Buffer Overflows in ISC DHCPD Minires Library

DHCP != BIND ;)


No, quite astute of you to notice.  However, if you _READ_ the Advisory,
which is entitled "Buffer Overflows in ISC DHCPD Minires Library" I
would hope that one would turn their attention to the word 'Minires' and
more specifically that 'Minires' stands for 'Miniature Resolver'.  Now,
lets see... oh yes, reading the Advisory gets you:

During an internal source code audit, developers from the ISC
discovered several vulnerabilities in the error handling routines of
the minires library, which is used by NSUPDATE to resolve hostnames.
These vulnerabilities are stack-based buffer overflows that may be
exploitable by sending a DHCP message containing a large hostname
value. Note: Although the minires library is derived from the BIND 8
resolver library, these vulnerabilities do not affect any current
versions of BIND.


See where I'm going with that?  It was not just another cheap reference
to Bind somehow, it stands with my argument, that BIND has a horrid
track record.  Again, I iterate that just because nothing has been
announced lately, we have not heard the last from BIND yet.

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


DJBDNS isn't a resolver now is it, also check who shares source where.


Yes, actually djbdns _IS_ a resolver.  As was in my previous e-mail:

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,


Did you even _READ_ my e-mail at ALL?

6 years ago, and version 8, come on are you going to compare Win95 with
Redhat Fedora Core Turbo Pro next ? :)
Or comparing an iPod (apple) to a hmmm why the peep is there no company
called 'pear'? :) There is PHP's PEAR of course but that is not related,
oh that is what comparing apple's and pears is about.


You area COMPLETELY missing the point.  With many bricks you build a
building.  With the many exploits I show you, you see a very very shoddy
track record.  To any individual with even a meager understanding of
software, just using it, should be able to appreciate this.

  Compare BIND vs DJBDNS with respect to 'ease of use':
  - http://cr.yp.to/djbdns/blurb/easeofuse.html

  Read up about DJBDNS security:
  - http://cr.yp.to/djbdns/blurb/security.html


2 nice feature rants by djb ;)


Yes, but perhaps you should actually _READ_ them, and I should like to
correct your misuse of the word 'rant' in this case, because they are
most certainly not.

I have to admit that the code that is there works and is of great
quality, but without features and only basic support it is not much of
use in most situations now is it...


I have no clue what you do, but I work for a legitimately sized ISP, and
I have done a lot of consulting in this field, and I have not run into a
single situation where djbdns could not do what I wanted of it.

Sorry but your list does not make sense in the computer world.


I'm not sure what computer world you are from, but where I come from it
made a whole lot of sense.  Perhaps you could actually, re-read the
entire e-mail and consider my references and then you can reassert this
feeling with perhaps some more in-depth reasoning with aide in backing
up your assertions.

In the interest of not polluting the list with this topic further, since
I have had all that I need to say on this topic, since my only intent
was to illustrate the disgusting track record of both BIND and Sendmail.
You can use whatever your heart pleases, I won't judge you, nor do I
care.  However, when Stephen made his original post which IMO was ripe
with misinformation I felt obligated to indulge this topic with at least
one e-mail.

Please consider further deliberation on these topics via private
correspondence, I'm more than happy to respond.

Cheers,

James

-- 
James Couzens,
Programmer
                                                     ( ( (      
      ((__))         __\|/__        __|-|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

-------
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 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

signature.asc
Description: This is a digitally signed message part