RE: Does blocking TCP DNS packets keep your Bind safe?

["Loomis, Rip" <GILBERT.R.LOOMIS () saic com>]

Todd--
(2 of the three URLs you supplied were related
to a bug in certain IP stacks that BIND
helped identify.  The third was...well, I'll
talk about that later.)

BIND 9 has a specific behavior defined by
default--if it encounters a situation that
it can't handle, it shuts down.  There was
a bug in several IP stacks that resulted in
BIND getting invalid packets during portscans...
and BIND shut down.  If you wanted BIND to
not shut down, then there's a one-line #define
to change.  Keep in mind that the bug is *not*
in BIND...it's in several IP stacks.  The only
reason that we all got this far without finding
the bug is that all sorts of programs out there
just try to limp along in such situations, with
BIND 8 included.  BIND 9's current behavior is
flushing out a *lot* of bugs, both in BIND 9
and other programs/OSs.

I didn't say in my previous message that BIND 9.1.0
was 100% ready for widespread fielding...my
apologies if I was unclear.  I expect that 9.1.1
will be, however we will likely wait for 9.2.x to
really push things for the folks we're fielding
this to.

Why is a security professional willing to be
concerned about "features and feature flexibility"?
Because I *am* a professional.  If I were living
in an ivory tower, I might be able to tell everyone
out there to switch to a DNS server with a
completely different configuration format and a
completely different methodology.  I do believe
in general in the "write a bunch of small programs
that each do one thing well" method...stunningly
enough, that's really what programming by contract
turns out to be.  I also don't see how tinydns
is addressing the IETF RFCs on DNSSEC...other than
djb complaining about them.  None of his writings
have convinced me that DNSSEC is worthless...and
there's currently no other horse (besides BIND)
in the DNSSEC race.

BTW, many of djb's other writings about BIND
(specifically including your third URL) also contain
factual errors which would appear to indicate
that he is letting antagonism get in the way of
his considerable intellect.[1]  I can go into them
in detail if anyone cares, but please contact me
off list so I don't waste everyone's bandwidth.
The biggest one is that the TSIG/NXT BIND 8 bugs
are due to the programming methods used in BIND
9...when they're actually symptoms of the reason
why BIND 9 was a total re-write.

What's the fundamental issue here?  Neither SMTP
nor DNS is a "relatively simple network protocol"
in my humble opinion.  If anything, DNS is worse
and is currently getting *more* complex as DNSSEC
is added on to address previous security-relevant
issues.  To each his own, and hopefully
we will at some point have multiple DNS server
software implementations which are both secure
and interoperable, and we can each use the one
that fits our taste the best.  For right now,
*none* of the DNS server software out there is
perfect on every absolute scale.  (Lest anyone
think I'm a shill for BIND and the ISC, suffice
it to say that I've spent more time in the last
year beating my head against bugs and issues
in that code than I like to think about...and
BIND 9.0.0 would have been BIND 8.9.1pre1 by
the Linux kernel numbering system, since it
was barely alpha-quality code in many places.
I also *really* hope that since CRLs don't
exist in DNSSEC, we can find some equivalent
of OCSP so that we can have some hope of
recovery from an inadvertant compromise.  Oh,
and there's the key management issues...ah,
forget it and let's all go have a Guinness.)

--Rip

[1]  I won't speculate as to whether this
     (letting personal antagonism take precedence
     over intellectual decisions) has ever
     happened before to him...but I know that
     it has happened to me, and I don't count
     myself near as good a programmer as djb.
     Nonetheless, knowing some of the facts
     tends to make me discount much of his rant.

-----Original Message-----
From: Todd
To: firewall-wizards () nfr net; Loomis, Rip
Sent: 3/15/2001 11:39 PM
Subject: RE: [fw-wiz] Does blocking TCP DNS packets keep your Bind safe?

rip, all,

bind9 just isn't secure.  i'm sorry, but it isn't.  i appreciate the
sentiment that comes with "we shipped junk for years but now we've
really
fixed it" sentiment, but bind version 9 has already had more than one
security vulnerability.  see, for example:

http://www.sans.org/newlook/digests/SAC/tool.htm
http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Fl
ist%3D1%26mid%3D161399
http://cr.yp.to/djbdns/ad/unbind.html

there are also several significant security problems noted in the bind9
CHANGES file, indicating that bind is not the solution to all problems.
in particular, bind9 has had instances of crashing when port scanned and
overwriting existing zone files by mistake.

while i agree that bind9 is an improvement, it's obivously not a
solution
for the incoming traffic problem.

i would agree with darren:  C is a hard language to code securely in.
i would disagree with darren, though, that djbdns is somehow lacking in
functionality. the "richness" that he cites is part of the problem.  i'm
not afraid of sendmail.cf, either--i'm afraid of any MTA that has to
implement its own rewrite language just to function.  if we want secure
programs we need small, single function programs that are auditable,
simple and cleanly written.  i simply don't understand why 'richness' is
an advantage in implementations of relatively simple network protocols
that absolutely *have* to be secure.

djbdns is one example of software that is simple, fast and secure.  dan
bernstein writes software in small, understandable bundles.  i would
agree
that they are sometimes tough to migrate to (especially when you've
gotten
used to 'rich' software that does everything under the sun and just
happens to crash often or give up root to remote users occassionally).

comments about features and feature flexibility from security
professionals concerns me.

i certainly can't write secure code in C.  it's obvious that most people
can't.  Dan Bernstein seems to be able to.  i think we should take his
software more seriously.

todd.

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards