8.3 vs 8.4

Jan Gyselinck bind-users at lists.b0rken.net
Sat Dec 6 05:48:54 UTC 2003


On Thu, Dec 04, 2003 at 11:31:24AM +0000, Jim Reid wrote:
> >>>>> "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.

Well, upwards of say 500 queries a second is nothing for modern PC's.
But you presume that everybody can choose the hardware to run the
software on, that's completely wrong though.

It's a fact that a dual CPU Sun with BIND9 performs equally well
(worse in some case, better in other) than a BIND8.  Only, it
requires the double amount of memory (if not more) and it uses
the two CPU's while BIND8 can only use one CPU.  What an
improvement.

*snip*
> 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?

No, it's still the case.  Because BIND9 requires more memory, it'll
starve faster on the same hardware than BIND8.  Also, with BIND8
you get a straight signal when it's overloaded, it uses 100%
cpu on one cpu.  Not with BIND9, sometimes it's upto 80% and more,
sometimes it only hits 60%.  You can only see it by running some
digs and seeing large fluctuations in the time it takes to
respond.

> 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....

Config file options changed.  Don't use a BIND8 config file for BIND9
(unless it's very basic and, well, not suited for production use).
Logging is completely different for one.  And all the options needed
to make it actually run okay (nr of clients to allow etc) don't exist
in BIND8 anyway.
 
> 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.

No, that's not a show stopper.  But if there's no advantage in going
to BIND9 (other than support for the bleeding edge DNS additions),
the 'minor' pains are just an additional reason why not to migrate.
 
> 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.

Dream on.
1 GB RAM is not enough for BIND9 for a modest ISP.  And handling more
than 1 GB RAM requires more CPU and thus fast hardware.  So, if you're
a Sun-based ISP, forget about using low-end Suns.  A dual UltraSPARC-III
900 Mhz box won't do the job for you, even if you put in 8 GB RAM.
Don't spend your time in convincing me what you think about Sun,
I couldn't agree more, but that doesn't change the facts.

> 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.

A 'bit'?  Twice as fast is not what I call 'a bit'.  Makes you wonder,
BIND8, a product of coding and coding and fixing etc etc etc,
which makes some horrible source code, which is still faster than
BIND9, a product redesigned from the ground.
 
> 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?

Obviously for a lot of us those extra features don't outweight the
performance loss from BIND9.


Jan Gyselinck
 


More information about the bind-users mailing list