[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Starting a GPL'ed Blackhole Service to Replace MAPS



On Wed, Jul 25, 2001 at 11:44:21AM +1000, Steve Kowalik wrote:
> On Tue, Jul 24, 2001 at 03:00:57PM -0500, Nathan E Norman uttered:
> > In my opinion this boils down to a religious issue:  some hate Dan
> > Bernstein (and by extension his software), and I hate BIND because
> > it's a massive bloated buggy pile of crap.  I don't think either of us
> > will convince the other that he is incorrect :)
> > 
> And exactly which parts of BIND are buggy? Or bloated, for that matter. I
> find BIND nice and easy to work with.

First, there's no need to Cc: me on list mail.  I read the lists.  I
always follow threads I've posted to.  Please configure your MUA to
respect my Mail-Followup-To: header ... I know mutt and gnus support
MFT, and I see you're using mutt, so I don't understand why you're ignoring
the header.

I am respecting your MFT header even though I suspect it may be
broken.

As far as BIND being buggy, a simple bugtraq search should yield a few
clues.  There have been at least 2 remote exploits in the past 24
months that I can remember.

Bloated ... hmm, let's see.  I want to install a nameserver that's
only authoritative (let's pretend I want to set up an RBL that
blacklists spammers).  Hmm, BIND wants to play caching nameserver as
well.  Ok, I'll just shut that feature off ... still, the code is
there and how do I really know it won't get activaed somehow?  If I
knew the code was bug-free, I wouldn't worry.  However, most computer
scientists are willing to ever certify code as bug-free ... and BIND
has never been audited (i believe this is true of at least BIND 4 and
BIND 8 ... I have not run BIND 9 since downloading a beta and being
less than impressed).

Let's turn it around ... I want to install a caching-only nameserver
that my customers (I'm pretending I still work for an ISP :) can beat
on.  Whoops, this BIND still has authoritative code in it.  Sure hope
it's all bug-free.  I wonder how efficient the caching is ... what
happens when the cache fills up?  According to Dan Bernstein (who
admittedly is not an objective observer) BIND discards the _newest_
entry into the cache.  That's obviously wrong.  (BTW, it can easily be
determined if Bernstein is lying ... BIND 9 is all open source.  It's
just a matter of finding the time :)

You find BIND "nice and easy to work with".  That's fine, but what is
your level of experience with BIND?  I have run BIND authoritative for
about 300 zones (small potatoes in the ISP arena) and caching for
~5000 customers.  As the configuration grew larger, administration
became a PITA.  Interdependencies between features meant that an
innocent (read stupid) mistake by a junior admin would blow the whole
thing sky high.  The config syntax is cryptic and confusing for a
beginner.  BIND allows you to break the RFCs, and usually doesn't say
anything about it (it does complain about MX CNAMEs IIRC).  Try
writing a script which automatically configures BIND and doesn't mess
with the existing configuration ... it's a hassle.  I looked at the
BIND webmin module, and while it worked it was brutal and exerted far
too much control over the format of the file ... I wasn't willing to
relinquish that to a script.  Thus began my search for a better DNS
daemon ...

Like Phil, I don't want to start a flame war.  If you like BIND ...
that's fine.  Just make sure you like it because _you_ have
investigated the matter, not because an O'Reilly book says BIND is the
way to go, or because it's "the defacto standard".  

I'm a firm believer in "use what works".  That's why I tend to not
flame Windows users ... it "works" for them.  I think they're
misguided, but they're not eveil or something.  I feel the same way
about BIND ... it does the job, but does it poorly in my experience.

Cheers,

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd.                 | than a perfect plan tomorrow.
mailto:nnorman@micromuse.com   |   -- Patton

Attachment: pgp37zy3_QkXV.pgp
Description: PGP signature


Reply to: