8.3 vs 8.4

Jim Reid jim at rfc1035.com
Thu Dec 4 11:31:24 UTC 2003


>>>>> "Osmo" == Osmo Laitinen <ossi at pp.inet.fi> writes:

    >> what are those circumstances?  unless you're on ultrix or
    >> sunos4, we think that bind9 is a drop-in replacement for bind8.
    >> what are we (still) missing?  -- Paul Vixie

    Osmo> Speed, perhaps?
    Osmo> ftp://ftp.cup.hp.com/dist/networking/briefs/lp2kr_dns_server_results.txt
    Osmo> According to this document Bind 8 is faster than Bind 9

True, but so what? Very few name servers get the sort of query load
that means performance is truly critical. Unless a server is getting
upwards of say 500 queries per second -- and you should look long and
hard at why that's happening -- the reduced throughput from BIND9
compared to BIND8 simply won't matter or even be noticeable. Just
about the only people with valid reservations about the performance of
BIND9 are the folk who run the root servers: 5000+ qps.

    Osmo> And I don't know if this one has any revelance:
    Osmo> http://people.freebsd.org/~dougb/whybind8.html

This URL contains a lot of nonsense quite frankly. It ignores reality.
For instance, Mr Barton says "stick with the devil you know". That's
fine: up to a point. The devil he knows has been riddled with security
holes and the subject of endless CERT advisories. BIND9 hasn't had
any. Well there was one in the OpenSSL library it used for DNSSEC: not
BIND9's fault. On security grounds alone, the choice between these two
devils couldn't be clearer.

The devil he knows is an agglomeration of hacks and kludges that can
be traced back to a proof-of-concept grad school project at Berkeley
in the mid-1980's. The code quality is poor and is a maintenance
nightmare. BIND9's code is much cleaner. For starters, it has a
coherent design. And it can exploit modern architectures -- 64-bit
machines and threading on multiprocessors. There's also extensive
assertion checking which effectively eliminates buffer overflows and
memory leaks. BIND8 has none of these defensive programming features.
That's the main reason why it's faster. What's preferable: fast and
dangerous or less fast and safe? BIND9 also stores zones in discrete
data structures. BIND8 puts everything into a monolithic cache. This
creates bugs and protocol violations. BIND8 doesn't and can't get the
semantics of a zone cut right. BIND9 does. BIND9 can answer queries
while it loads zone files. BIND8 can't.

The devil he knows doesn't implement the DNS protocol properly. BIND9
does. In fact, he makes a virtue out of the fact BIND8 doesn't follow
the protocol. Mr. Barton says BIND9 doesn't allow multiple CNAMEs,
unlike BIND8. That's quite correct. Multiple CNAMEs are illegal and
have been expressly forbidden since DNS was invented. Go and read
RFC1034. Anyone who relies on this aberration is wrong. And so is
anyone who uses this as a pretext for sticking with BIND8.

He implies BIND9 is undesirable because someone needs to set up a key
to use rndc to control the server. Boo-hoo. Isn't it better to have an
athenticated communication channel to control the server? By default,
BIND8 just sets up the control channel and accepts commands from
anything that connects to it. BIND9 has to be configured to set up a
control socket. Which has to be safer. And anyway, BIND9 comes with a
tool to do that configuration for the naive administrator.

The claim about the resolver "falling down under large or sustained
loads" appears to be anecdotal. This happened in the earliest BIND9
releases which were immature. Out of this, an urban legend seems to
have emerged. AFAIK, nobody has reported or even seen this problem in
the current or recent versions of BIND9. When was the last time
somebody complained about this in bind-users?

He says the config and zone file formats changed with BIND9. That's
misleading and inaccurate. They haven't. One or two obscure named.conf
features in BIND8 are not implemented in BIND9. The BIND9 parser
checks these for syntax and reports them as being ignored. So there's
some level of backwards compatibility for them. Anyway few people
really need or use the corner case features that BIND9 doesn't yet
implement. Apart from using a UNIX domain control socket, a BIND8
named.conf file will simply drop into BIND9 and just work. [Well I
suppose someone could get bitten by BIND9 using case-sensitive ACL
names, unlike BIND8.] The format of zone files has not changed at
all. It's still as described in RFC1034 and RFC1035. The difference is
BIND9 enforces that syntax. BIND8 doesn't. Oh BTW, BIND9 comes with
tools for checking the syntax of named.conf and zone files. So there's
no excuse for getting it wrong. Not that there ever was an excuse....

It's true the logging system and log messages from BIND9 are different
from BIND8's. So scripts that process the name server's logs will need
to be updated: hardly a show-stopper, eh? And yes, the output of dig
changed. This is annoying. But dig is only a (very useful) utility.
It's not the name server. It beggars belief that someone would use
differences in the output of a query tool as a justification for their
choice of name server. Where's the logic behind that? It's not as if
an old version of dig won't work with a BIND9 server.

Yes, BIND9 uses more resources than BIND8. This simply won't matter
unless someone is running a name server on tiny hardware, say an M68K
box with 8MB of RAM. Very few name servers get the sort of query
traffic (500 qps or more) or load 100,000+ zones that would make the
extra memory footprint of BIND9 an issue. And at these extremes, there
are other options.

So what are the choices? With BIND8, you get a server that's based on
a "design" that's 20 years old and no longer suitable today. The coding
standards are dubious: 1500+ lines of C for ns_resp()! BIND8 doesn't obey
the protocol particularly well and allows or facilitates violations:
multiple CNAMEs, incorrect delegations, syntax errors in zone files,
etc. BIND8's been implicated in lots CERT advisories. But hey, it's a
bit faster than BIND9. Not that more than a handful of DNS installations
really need that extra performance.

And all this is before we get into all the good stuff that's been
added to BIND9: views, EDNS0, IPv6 support, fine-grained control of
dynamic updates, etc, etc. Better the devil you know, eh?


More information about the bind-users mailing list