BIND 9

BIND version 9 is a major rewrite of nearly all aspects of the

underlying BIND architecture. This re-architecting of BIND was

necessitated by the expected demands of:

- Domain name system growth, particularly in very large

zones such as .COM

- Protocol enhancements necessary to securely query and

update zones

- Protocol enhancements necessary to take advantage of

certain architectural features of IP version 6

These demands implied performance requirements that were not

necessarily easy to attain with the BIND version 8

architecture. In particular, BIND must not only be able to

run on multi-processor multi-threaded systems, but must take

full advantage of the performance enhancements these

architectures can provide. In addition, the underlying data

storage architecture of BIND version 8 does not lend itself to

implementing alternative back end databases, such as would be

desirable for the support of multi-gigabyte zones. As such

zones are easily foreseeable in the relatively near future,

the data storage architecture needed revision. The feature

requirements for BIND version 9 included:

- Scalability

Thread safety

Multi-processor scalability

Support for very large zones

- Security

Support for DNSSEC

Support for TSIG

Auditability (code and operation)

Firewall support (split DNS)

- Portability

- Maintainability

- Protocol Enhancements

IXFR, DDNS, Notify, EDNS0

Improved standards conformance

- Operational enhancements

High availability and reliability

Support for alternative back end databases

- IP version 6 support

IPv6 resource records (A6, DNAME, etc.)

Bitstring labels

APIs

BIND version 9 development has been underwritten by the following

organizations:

Sun Microsystems, Inc.

Hewlett Packard

Compaq Computer Corporation

IBM

Process Software Corporation

Silicon Graphics, Inc.

Network Associates, Inc.

U.S. Defense Information Systems Agency

USENIX Association

Stichting NLnet - NLnet Foundation

BIND 9.1.0a1

This is an unreleased alpha version of BIND 9.1.0.

For a detailed list of user-visible changes from

previous releases, see the CHANGES file.

Building

BIND 9 currently requires a UNIX system with an ANSI C compiler,

basic POSIX support, and a good pthreads implementation.

We've had successful builds and tests on the following systems:

AIX 4.3

COMPAQ Tru64 UNIX 4.0D

COMPAQ Tru64 UNIX 5 (with IPv6 EAK)

FreeBSD 3.4-STABLE

HP-UX 11

IRIX64 6.5

NetBSD-current (with "unproven" pthreads)

Red Hat Linux 6.0, 6.1, 6.2

Solaris 2.6, 7, 8 (beta)

To build, just

./configure

make

Several environment variables that can be set before running

configure will affect compilation:

CC

The C compiler to use. configure tries to figure

out the right one for supported systems.

CFLAGS

C compiler flags. Defaults to include -g and/or -O2

as supported by the compiler.

STD_CINCLUDES

System header file directories. Can be used to specify

where add-on thread or IPv6 support is, for example.

Defaults to empty string.

STD_CDEFINES

Any additional preprocessor symbols you want defined.

Defaults to empty string.

To build shared libraries, specify "--with-libtool" on the

configure command line.

If your operating system has integrated support for IPv6, it

will be used automatically. If you have installed KAME IPv6

separately, use "--with-kame[=PATH]" to specify its location.

To see additional configure options, run "configure --help".

"make install" will install "named" and the various BIND 9 libraries.

By default, installation is into /usr/local, but this can be changed

with the "--prefix" option when running "configure".

If you're planning on making changes to the BIND 9 source, you

should also "make depend". If you're using Emacs, you might find

"make tags" helpful.

Building with gcc is not supported, unless gcc is the vendor's usual

compiler (e.g. the various BSD systems, Linux).

Parts of the library can be tested by running "make test" from the

bin/tests subdirectory.

Bug Reports and Mailing Lists

Bugs reports should be sent to

bind9-bugs@isc.org

To join the BIND 9 Users mailing list, send mail to

bind9-users-request@isc.org

If you're planning on making changes to the BIND 9 source

code, you might want to join the BIND 9 Workers mailing list.

Send mail to

bind9-workers-request@isc.org

"named" command line options

-c <config_file>

-d <debug_level>

-f Run in the foreground.

-g Run in the foreground and log

to stderr, ignoring any "logging"

statement in in the config file.

-n <number_of_cpus>

-t <directory> Chroot to <directory> before running.

-u <username> Run as user <username> after binding

to privileged ports.

Use of the "-t" option while still running as "root" doesn't

enhance security on most systems. The way chroot() is defined

allows a process with root privileges to escape the chroot jail.

The "-u" option is not currently useful on Linux kernels older

than 2.3.99-pre3. Linux threads are actually processes sharing a

common address space. An unfortunate side effect of this is that

some system calls, e.g. setuid() that in a typical pthreads

environment would affect all threads only affect the calling

thread/process on Linux. The good news is that BIND 9 uses the

Linux kernel's capability mechanism to drop all root powers except

the ability to bind() to a privileged port. 2.3.99-pre3 and later

kernels allow a process to say that its capabilities should be

retained after setuid(). If BIND 9 is compiled with 2.3.99-pre3 or

later kernel .h files, the "-u" option will cause the server to

run with the specified user id, but it will retain the capability

to bind() to privileged ports.

On systems with more than one CPU, the "-n" option should be used

to indicate how many CPUs there are. If the "-n" option is not

provided, named will attempt to determine the number of available

CPUs and use all of them.