Should I Upgrade

[Jim Reid]

>>>>> "Charles" == Charles Bodley <Bodley at tflogic.com> writes:

    Charles> I am running 8.2.3, are there any real benefits to
    Charles> upgrading to 9.x. From the messages I've seen on this
    Charles> list 9.x has problems. 

Sure BIND9 has problems, but so does BIND8. Or any other complex piece
of software for that matter. Whether you should upgrade to BIND9 or
not depends on local circumstances we know nothing about. But as a
general rule, most folk will be better off running BIND9. Most of the
"problems" people report with BIND9 refer to syntax and semantic
errors in zone files that BIND8 overlooked. Consult the BIND9
migration notes for details of the issues that need to be looked at
when considering the upgrade. Some of the other problems are the usual
bleeding edge issues that can be expected to crop up with new software.

Most people who study the code would agree that BIND9 is far better
than BIND8: consistent coding style, careful checking, programming by
contract, etc, etc. The standard of software engineering in BIND9 is
higher than BIND8 so this should give you a warm feeling about the
code quality.

In most other ways, BIND9 is better. It is much stricter at conforming
to the standards. It supports ALL the current DNS RFCs: EDNS0, DNSSEC,
TSIG, IXFR, (Secure) Dynamic Update, etc. It supports the new
(horrible!) record types for IPv6: A6 and DNAME records. If you need
to use these, BIND9's the only implementation. The Secure DNS tools in
BIND9 are way, way better than those in 8.2. BIND9 is also
multi-threaded, so it can walk and chew gum at the same time. On
multiprocessor systems, this is a big win. However there are some
issues with vendor's thread libraries.  BIND9 is slower than BIND8,
but this should only matter in extreme cases like Internet root
servers that get thousands of queries every second.

Internally BIND9 should be more robust than other name servers. It
uses tasks: essentially name server operations like loading zones,
servicing queries, refreshing SOA records, etc. Each group of tasks is
allocated some number of threads, other resources like memory or queue
lengths and rate limiters. This should mean it's less vulnerable to
denial of service attacks. Flooding the server wth queries shouldn't
affect the server's ability to transfer zones or check the SOA serial
number on the zones it slaves.