NS record question

[Roy Arends]

On Tue, 27 Mar 2001, Doug Barton wrote:

> Brad Knowles wrote:
> > 
> > At 9:27 PM -0800 3/26/01, Doug Barton wrote:
> > 
> > >         First off, while there have been security issues in the past with
> > >  bind 8 code (and may be again in the future) for the most part the code is
> > >  in fairly good shape. Yes, it's ugly in places, but it's got collectively
> > >  millions of hours of operational experience, and has had lots of eyes on
> > >  it, black hats and white.
> > 
> >         Indeed, it has had a lot of people looking at it, and all of the
> > ones I know of that have looked at it have found it extremely
> > unpleasant.  There's dreckage and bletchery in there going back to
> > the original undergraduate work done on BIND, long before Paul Vixie
> > got involved, etc....
> 
> 	Blah blah blah. I'm actually pretty tired of this argument. I realize that
> bind 8 has some ugly spots, but it's still the bugs we know, vs. the bugs
> we don't know in bind 9. I'm also a little suspicious of all the people who
> claim that there is this or that present in the bind 8 source, but haven't
> actually submitted any fixes. 

I can understand you're tired of that argument, this doesn't make it any
less true though. I know its the ol' catch-22 when it comes to moving on
to a new code-base release. And its indeed "bugs we know vs bugs we don't
know", but what I think is more important: bugs that get fixed vs bugs
that do not get fixed. Only serious security related bugs for bind 8 get
fixed (That was one of the reasons to release 8.2.3-REL).

> >         Indeed, with the newer features added to BIND 8 (e.g., DNSSEC,
> > etc...), those would seem to be far less secure, less fully
> > implemented, and overall just less fully "cooked" than their
> > implementations in BINDv9 -- even in 9.1.0, much less the latest
> > release candidate for 9.1.1.
> 
> 	Ummm... how do you make the leap of logic that says that new features
> added to a new code base are better or more stable than new features added
> to an established code base? My point earlier was that both code bases have
> their own unique problems. 

Very simple. Stain on stain problem. BIND 8 is, ehhh, lets just say that
it doesn't win a beauty contest. DNSSEC on top of that is what I would
call, a hack. Its just an add on, a so called "reference implementation"
and frankly it doesn't follow rfc 2535 the way it should (as mentioned
previously), remember the NXT bug, and the TSIG bug when I'm talking about
a complicated protocol build on a "dreckage and bletchery" code base.

> >         Yes, there may be some remaining issues that BINDv9 has with
> > regards to scaling and suitability for use in the largest possible
> > environments (e.g., as a root nameserver), but for anything short of
> > that kind of environment, the new "programming by contract" model,
> > etc... should make the code more inherently secure, and overall much,
> > much more robust.
> 
> 	Once again, I have nothing but respect for the people at nominum, and the
> herculean task that faces them. However, as I pointed out previously the
> migration path still has too many hurdles (and unseen pitfalls) for most
> people, IMO. I would feel a lot better about it if someone at nominum was
> willing to be a little more flexible in terms of listening to the concerns
> already voiced in this area, but c'est la vie. 

Whoa, I've heard a lot of arguments lately how things "should be done",
most of them in conflict. BIND 9 follows standards, better then BIND 8
does. Yes, more anal, but I consider that as better. If you have any
concerns when it comes to the BIND 9 code, feel free to share, we have
several lists for different levels and are willing to listen and discuss
arguments. Any protocal enhancements/changes can be discussed at
namedroppers/dnsop.

> Also, the mere fact that most of the code in bind 9 is produced "by
> contract," doesn't really enter into this discussion. I am a
> proffesional programmer and I know the problems associated with this
> kind of project. Thus my concerns.

I can see your concerns. But I still rather see a team of professionals
responsible for implementing a standard, than some historic piece of code
created in an ancient lab by undergrads, by the grace of god picked up by
a professional who actually made it work and done something good with
it.

Regards,

Roy Arends
Nominum