djbdns: An alternative to BIND

Mon Apr 11 18:41:46 UTC 2005

> Date: Mon, 11 Apr 2005 11:20:07 -0700 (PDT)
> From: "william(at)elan.net" <william at elan.net>
> Sender: owner-nanog at merit.edu
> 
> 
> 
> On Mon, 11 Apr 2005, Dean Anderson wrote:
> 
> [critisicism of AXFR in BIND9 snipped]
> 
> Again, the point of all of that is that they chose to implement protocol 
> that is non-standard, but knowing that they made sure that this would only 
> be used between BIND9 programs. This is proprietary protocol but as long 
> as its used only when their products are talking to each other, there is 
> nothing substantially wrong. Well ok, what maybe wrong is that they still 
> call it AXFR instead of clearly calling it something like AXFR-BIND9.
> 
> Note that it matters, but cisco has very many prorprietary additions, just 
> take "weight" in bgp routes for instance. Since these features are only 
> used for communication between two cisco routers there is nothing 
> seriously wrong with them having such a features.
> 
> > 5) Then, after criticism, finally decided to try to clarify the draft,
> > assuming that their employee who was a Working group co-chair would breeze
> > through the change. As justification for the change, they asserted it
> > would be easier for the 6 or 8 other DNS implementations to change their
> > installed base than to change BIND9. (holy cost-shifting, batman)
> 
> That is why some people now say its now IVTF and not IETF. Large vendors 
> (large by comparing their share in the market for particular area or 
> simply a very large company that things its owns the world) try to bully 
> everyone else to accept what they want because they own the market. Luckily
> for us this is not OASIS and IETF would not often accept such tactics, 
> although its getting worth lately...
> 
> In any case BIND folks got properly punished for attempting to do it and
> as long as they support standard way and inter-operate with other products
> its fine; and if they think their proprietary way is better for when two
> bind daemons talk to each other, that is fine too and I accept it.
> 
> >> Nobody should be producing product that "pretends" to be something else,
> >> that itself would be a problem and may even be illegal if BIND name is
> >> trademarked (and even if its not if somebody makes different product
> >> that is using bind name and that product does not work or works differently,
> >> it creates dillusion and bad reputation for makers of bind and so its
> >> something ISC could legally demand to be stopped).
> >
> > BIND is an acronym of Berkeley Internet Name Daemon.  I've heard that
> > Vixie claims a trademark on this, but it seems rather like the linux
> > trademark issue of a few years ago. I didn't hear that they purchased the
> > copyright from the University of California.  So, I don't think it is his
> > to trademark, and it was a common term in use well before ISC existed.
> > ISC didn't write BIND, but has only maintained and modified it over the
> > years.  They own modifications, at most.
> 
> Well, Paul Vixie wrote bind and he started ISC later to provide more 
> organization to his work and supporting it further, so I really dont
> see a problem with consdering BIND to be ISC product even if original
> acronym was more general (though I doubt he could get it trademarked
> because of all that)..

William,

Paul Vixie did NOT write the original BIND. The first BIND version
(4.3?) was written by the CSRG at UC Berkeley by Kevin Dunlap who was on
loan to CSRG by Digital (who also employed Paul at that time).

When Paul took over support of BIND at about 4.4, it was a horrid mess
and rapidly moving toward death. After some fixes and clean-up of the
code, the first real BIND from Paul was 4.8. ISC (including Paul) wrote
BIND 8. BIND 9 was contracted out to Nominum and one of the stipulations
was that the existing code base could not be used at all and another was
that the team that wrote BIND 8 should not work on BIND 9. For that (and
other) reason, Paul did not write any of BIND 9.

Paul is welcome to correct any of this as my memory is probably failing
on details.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634