What is Win2000's BIND version?

  • Thread starter Thread starter David Adner
  • Start date Start date
HM> The point was that the arguments among THOSE folks has
HM> degernated to the point where EACH claims the other side
HM> is lying which virtually guarantees that one or both sides
HM> is doing so.

As I said before, it's not the case that there are "sides" acting
collectively. There are no groups of "acolytes" (contrary to the false
portrayal as such, by a couple of people, of everyone who disagrees with
them), and the actual lying is limited to a scant few individual people. The
most prominent and most recurrent case is just one person, who presents to
various audiences a purported side-by-side comparison of server softwares that
is very obviously grossly distorted (and, as some have suspected from the
factual errors, possibly based upon no actual use of at least one the
softwares being compared). This distortion has been noted, separately, by
quite a number of other people. But, even though they reach the same
conclusions, they have no relationship with one another and aren't acting
collectively; any more than that single individual speaks for an entire
"side", either.
 
HM> [BIND] might be a de facto implementation but it is not an
HM> official reference implementation.

_Every_ DNS server software (including mine) qualifies for being "a /de facto/
implementation". (-:

HM> The versions of BIND don't even all do the same thing -- and
HM> many of these are not just the addition of features in later
HM> versions. Features appear and disappear as the version
HM> number increases.

Indeed. It is noticable that feeping creaturism abounds.
 
KP> I don't know that anything on the Internet can be called
KP> "official", since it's something of an anarchy and standards
KP> are enforced mostly by one's need to interoperate with other
KP> players.

It's ironic that you say this in a discussion forum for a DNS server
software. In the case of DNS there is a good example of something in Internet
that some people assert to be "official" (even though its status, in reality,
is merely the result of a Flash Crowd that is quite inert): ICANN's "."
content DNS servers.

Returning to Herb's comparison: The "There is just one thing that is
official, and all alternatives are the products of wicked people who wish to
conquer/subvert/divide Internet." argument is one argument from the
discussions of DNS servers and DNS server softwares that I don't recall having
seen in the operating system debates.
 
NC> Except (possibly) for djbdns ( http://cr.yp.to/djbdns.html ) all
NC> the DNS [servers] in popular (96%) use are related directly or
NC> indirectly to the original (or a later derivative) of the BIND
NC> stucture or code.

JdeBP> It's not just a possibility. "djbdns" is definitely not
JdeBP> related to BIND. And, actually, it's not just "djbdns"
JdeBP> that is not based upon BIND code. There are quite a lot
JdeBP> of DNS server softwares that aren't derivatives of BIND.

NC> Yes, the djbdns has distinct speed advantages in some
NC> scenario's, although I am not certain if it's due to fact that
NC> it does not support a few functions of (can i say legacy bind?).

Non sequitur. You start with "Yes", implying that I was talking about speed
advantages. I didn't mention speed. I didn't even mention one DNS server
software having advantages over another.

Switching to talking about speed:

I doubt that the inclusion of a few peripheral extra features is what causes
the differences in speed. After all, BIND would have to be very poorly
implemented indeed if it were the case that (for example) the fact that it
supported incremental "zone transfer" caused it to be slower than some other
software when it was responding to ordinary queries and not actually
performing "zone transfers" at all.

Conversely, there are design strategies, as opposed to server functions, that
_can_ affect speed significantly, and probably do. For example: The memory
footprint of the DNS server process (which is quite large in the case of BIND)
can affect speed; as can both the way that, and the point when, the DNS
database is compiled from source.

"legacy" is a much-misused noun, incidentally. I think that it does not apply
here.
 
JdeBP> It's not just a possibility. "djbdns" is definitely not
JdeBP> related to BIND. And, actually, it's not just "djbdns"
JdeBP> that is not based upon BIND code. There are quite a lot
JdeBP> of DNS server softwares that aren't derivatives of BIND.

NC> The percentage (for one reason or another) is small, [...]

I disagree. The lists of DNS server softwares that aren't derivatives from
BIND that several people have made are, as I recall, roughly the same length
as the ISC's list of DNS server softwares that are. (And, as I recall, the
former lists aren't even as long as they should be, since they don't include
some softwares, such as Microsoft's DNS server.)

JdeBP> Moreover, it's not just "djbdns" that (in contrast with
JdeBP> Microsoft's DNS server) doesn't imitate the BIND
JdeBP> all-of-the-hats-at-once design, either. For example:
JdeBP> PowerDNS doesn't.

NC> thank you, I'm not totally in favor myself of being too
NC> integrated, but even if we went more modular (which we are
NC> trying todo with "plugins" and possilbly unique *.dll's) we
NC> risk having files mixed up (sort of dll hell) due to any
NC> needed updates/versions.

I suspect that that's a result of the way that you have chosen for dividing
your software into modules, rather than something that is inherent in the
notion of modular DNS server softwares itself. Having files mixed up is not,
in my experience at least, a problem that is prominent in the use of existing
modular DNS server softwares.
 
Jonathan de Boyne Pollard said:
I don't know whence you obtained that 96% figure from, but the only survey
done in recent years whose results I've seen actually published puts BIND 4,
8, and 9 combined at 75% (of the servers that actually responded), with
"djbdns" at 8.5%, eNom DNS server at 3%, with the remainder being either
unidentifiable or softwares with a 1% or less share.

<URL:http://cr.yp.to/surveys/dns1.html>
Click to expand...

I'll go over this once more...
so you and any readers are not left ata loss.

short list (means is more items but these are major criteria)
#1 consider amount of internet traffic handled by the NS/DNS version
#2 consider ipv4, ipv6..capability (and potential for ipv8/16 in works)
#3 accuracy....these fluctuate quite a bit (do some tests...on own traffic)
#4 uptime/security...not much good if down (8% loss is not unusual)
#5 scalability (affects typical bandwidth growth compatibility)
#6 accessibility (if auth server...need to converse w/slave/remotes)
#7 configuration (can be adjusted/tuned and options selected)

We did this and much much more, we bow to no database untested.

Count only the teams (members) on the playing field...
not a stadium headcount. (you should be able figure that out).
It's a bit the same also when rating/ranking (win/loss of query performance).

Make or analyze some server logs on general use DNS or Web over
a 30 day or annual period...then parse ip's (including traffic %) and
batch queries to discover DNS server types (include routing servers).

Now you have your own data valid to your own needs/uses.
We did this (to varying degrees) with hundreds of people
from all over the world (our original dns test included servers from
almost 300 countries...whittled down to 100 presently...is global test).

Too bad you never took part (18-24 months ago) as thousands of
posts and questions/answers were covered during that period.

Other than above...get involved, take charge of your data/experiences.
<and not look so hard for rabbits to pull off ethernet...quicker todo yourself>

hth

--
'Seek and ye shall find'
NT Canuck
http://ntcanuck.com BIND-PE & DNS
http://ntcanuck.com/tq/ Tips & Tweaks
http://ntcanuck.com/net/board/index.php
news://news.grc.com/grc.techtalk.dns.bind_pe_beta
 
Back
Top