2N/A BIND version 9 is a major rewrite of nearly all aspects of the
2N/A underlying BIND architecture. This re-architecting of BIND was
2N/A necessitated by the expected demands of:
2N/A - Domain name system growth, particularly in very large
2N/A - Protocol enhancements necessary to securely query and
2N/A - Protocol enhancements necessary to take advantage of
2N/A certain architectural features of IP version 6
2N/A These demands implied performance requirements that were not
2N/A necessarily easy to attain with the BIND version 8
2N/A architecture. In particular, BIND must not only be able to
2N/A run on multi-processor multi-threaded systems, but must take
2N/A full advantage of the performance enhancements these
2N/A architectures can provide. In addition, the underlying data
2N/A storage architecture of BIND version 8 does not lend itself to
2N/A implementing alternative back end databases, such as would be
2N/A desirable for the support of multi-gigabyte zones. As such
2N/A zones are easily foreseeable in the relatively near future,
2N/A the data storage architecture needed revision. The feature
2N/A requirements for BIND version 9 included:
2N/A Multi-processor scalability
2N/A Support for very large zones
2N/A Auditability (code and operation)
2N/A Firewall support (split DNS)
2N/A - Protocol Enhancements
2N/A IXFR, DDNS, Notify, EDNS0
2N/A Improved standards conformance
2N/A - Operational enhancements
2N/A High availability and reliability
2N/A Support for alternative back end databases
2N/A - IP version 6 support
2N/A IPv6 resource records (A6, DNAME, etc.)
2N/A BIND version 9 development has been underwritten by the following
2N/A Sun Microsystems, Inc.
2N/A Compaq Computer Corporation
2N/A Process Software Corporation
2N/A Silicon Graphics, Inc.
2N/A Network Associates, Inc.
2N/A U.S. Defense Information Systems Agency
2N/A Stichting NLnet - NLnet Foundation
2N/A BIND 9.0.0b1 is the first public release of BIND 9 code. It will
2N/A be most useful to advanced users working with IPv6 or DNSSEC.
2N/A BIND 9.0.0b1 is not functionally complete, and is not a release
2N/A candidate for BIND 9.0.0. The ISC anticipates a number of additional
2N/A beta releases between now and May, when BIND 9.0.0 is scheduled to
2N/A The ISC does not recommend using BIND 9.0.0b1 for "production"
2N/A We hope users of BIND 9.0.0b1 will provide feedback, bug fixes, and
2N/A enhancements. If you are not in a position to do so, it would
2N/A probably be better to wait until subsequent releases.
2N/A Much of the core technology planned for BIND 9.0.0 is in this beta
2N/A release. Some of the highlights are:
2N/A Support for bitstring labels, DNAME, and A6 records.
2N/A IPv6-aware resolver (follows A6 chains, can use IPv6 to
2N/A talk to other nameservers).
2N/A The nameserver listens on an IPv6 socket.
2N/A All new RR types supported.
2N/A The server generates DNSSEC responses for secure zones.
2N/A DNS messages using UDP have been limited to 512
2N/A bytes. This is too small for DNSSEC replies, whose
2N/A signature and key records can be large. EDNS0 allows
2N/A larger UDP messages to be sent.
2N/A EDNS0 is understood by the server, and used by the
2N/A Some of the more significant items that will be implemented or
2N/A enhanced in a future beta are
2N/A The server does not currently validate DNSSEC
2N/A Notify is not yet implemented.
2N/A Some config file items are not yet implemented.
2N/A Selective Forwarding
2N/A Future releases will contain a lot more documentation,
2N/A but a preliminary version of the Administrator's
2N/A BIND 9 currently requires a UNIX system with an ANSI C compiler,
2N/A basic POSIX support, and a good pthreads implementation.
2N/A We've had successful builds and tests on the following systems
2N/A COMPAQ Tru64 UNIX 4.0D
2N/A NetBSD current (with "unproven" pthreads)
2N/A Red Hat Linux 6.0, 6.1
2N/A Solaris 2.6, 7, 8 (beta)
2N/A "make install" will install "named" and the various BIND 9 libraries.
2N/A By default, installation is into
/usr/local, but this can be changed
2N/A with the "--prefix" option when running "configure".
2N/A Shared libraries will be built if "--with-libtool" is added to the
2N/A "configure" command.
2N/A If you're planning on making changes to the BIND 9 source, you
2N/A should also "make depend". If you're using Emacs, you might find
2N/A "make tags" helpful.
2N/A Building with gcc is not supported, unless gcc is the vendor's usual
2N/A compiler (
e.g. the various BSD systems, Linux).
2N/A Parts of the library can be tested by running "make test" from the
2N/ABug Reports and Mailing Lists
2N/A Bugs reports should be sent to
2N/A To join the BIND 9 Users mailing list, send mail to
2N/A bind9-users-request@isc.org
2N/A If you're planning on making changes to the BIND 9 source
2N/A code, you might want to join the BIND 9 Workers mailing list.
2N/A bind9-workers-request@isc.org
2N/A"named" command line options
2N/A -f Run in the foreground.
2N/A -g Run in the foreground and log
2N/A to stderr, ignoring any "logging"
2N/A statement in in the config file
2N/A -t <directory> Chroot to <directory> before running.
2N/A -u <username> Run as user <username> after binding
2N/A to privileged ports.
2N/A Use of the "-t" option while still running as "root" doesn't
2N/A enhance security on most systems. The way chroot() is defined
2N/A allows a process with root privileges to escape the chroot jail.
2N/A The "-u" option is not currently useful on Linux. Linux threads
2N/A are actually processes sharing a common address space. An unfortunate
2N/A side effect of this is that some system calls,
e.g. setuid() that
2N/A in a typical pthreads environment would affect all threads only affect
2N/A uses the Linux kernel's capability mechanism to drop all root
2N/A powers except the ability to bind() to a privileged port.
2N/A On systems with more than one CPU, the "-n" option should be used
2N/A to indicate how many CPUs there are.
2N/A The APIs for the libraries in BIND 9 are not yet frozen.
2N/A We expect the existing library interfaces in the release to be
2N/A quite stable, however, and unless we've specifically indicated that
2N/A an interface is temporary, we don't anticipate major changes in