8.3 vs 8.4

[Jim Reid]

>>>>> "Jan" == Jan Gyselinck <bind-users at lists.b0rken.net> writes:

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

I'm making no assumptions about someone's choice of hardware. I was
just giving an example of what cheap commodity hardware can deliver.
Presumably high-end servers should have much better throughput than
that because of better I/O bandwidth, faster buses/caches/CPUs, etc,
etc. 

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

Sun is currently sells 2GB of RAM for a SunBlade 1000/2000 at $1200.
It'll probably be half that price from a reseller. Do the arithmetic.
It won't take more than a few postings from you whining about BIND9's
memory usage before the cost of your time will exceed the cost of more
RAM.

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

    Jan> No, it's still the case. 

If that's the case, I hope you've reported it to ISC. And kept a core
dump. BTW if your environment is giving problems for BIND9 there will
probably be underlying problems that BIND8 is masking: like too many
queries going to too few boxes, under-provisioned servers and so on.
Something is badly wrong if a name server is maxing out the hardware.

    Jan> Config file options changed.

Really? Which ones? And anyway, shouldn't you be explicitly be setting
the config file options you care about rather than relying on the
server's default settings for them?

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

The fact that you're forced to use hardware that doesn't seem to be up
to the job? Or the fact you don't appear to be able to do something
about that?

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

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

There's no wonder about it: just compare and contrast the code. One
code base is very highly structured and has extensive assertion
checking, is anal about checking function parameters and buffer
overflows, etc, etc. Oh and it rigorously implements the DNS
protocols. The other gives a bad name to spaghetti code and has almost
no internal consistency checking.

To use an analogy, someone could rip out the padding, airbags and
safety belts from their car to save weight and make it go faster. But
would they be safer? And is that extra performance really necessary?
[It seems to be necessary in your shop. However it looks like there
are other reasons for that: a firm commitment to unsuitable hardware
for one.]

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

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

Fine, that's your loss. And if you can live with it, go ahead.