2. BIND Resource Requirements
2.1. Hardware Requirements
DNS hardware requirements have traditionally been quite modest. For many installations, servers that have been retired from active duty have performed admirably as DNS servers.
However, the DNSSEC features of BIND 9 may be quite CPU-intensive, so organizations that make heavy use of these features may wish to consider larger systems for these applications. BIND 9 is fully multithreaded, allowing full utilization of multiprocessor systems for installations that need it.
2.2. CPU Requirements
CPU requirements for BIND 9 range from i386-class machines, for serving static zones without caching, to enterprise-class machines to process many dynamic updates and DNSSEC-signed zones, serving many thousands of queries per second.
2.3. Memory Requirements
Server memory must be sufficient to hold both the cache and the
zones loaded from disk. The
max-cache-size option can
limit the amount of memory used by the cache, at the expense of reducing
cache hit rates and causing more DNS traffic. It is still good practice
to have enough memory to load all zone and cache data into memory;
unfortunately, the best way to determine this for a given installation
is to watch the name server in operation. After a few weeks, the server
process should reach a relatively stable size where entries are expiring
from the cache as fast as they are being inserted.
2.4. Name Server-Intensive Environment Issues
For name server-intensive environments, there are two configurations that may be used. The first is one where clients and any second-level internal name servers query the main name server, which has enough memory to build a large cache; this approach minimizes the bandwidth used by external name lookups. The second alternative is to set up second-level internal name servers to make queries independently. In this configuration, none of the individual machines need to have as much memory or CPU power as in the first alternative, but this has the disadvantage of making many more external queries, as none of the name servers share their cached data.
2.5. Supported Platforms
Current support status of various platforms and BIND 9 versions can be found in the ISC Knowledgebase:
In general, this version of BIND will build and run on any POSIX-compliant system with a C11-compliant C compiler, BSD-style sockets with RFC-compliant IPv6 support, POSIX-compliant threads, and the required libraries.
The following C11 features are used in BIND 9:
Atomic operations support from the compiler is needed, either in the form of builtin operations, C11 atomics, or the
Interlockedfamily of functions on Windows.
Thread Local Storage support from the compiler is needed, either in the form of C11
__threadGCC extension, or the
__declspec(thread)MSVC extension on Windows.
ISC regularly tests BIND on many operating systems and architectures, but lacks the resources to test all of them. Consequently, ISC is only able to offer support on a “best effort” basis for some.
2.5.1. Regularly tested platforms
As of Dec 2021, BIND 9.16 is fully supported and regularly tested on the following systems:
Debian 9, 10, 11
Ubuntu LTS 18.04, 20.04
Red Hat Enterprise Linux / CentOS / Oracle Linux 7, 8
FreeBSD 12.3, 13.0
Alpine Linux 3.15
The amd64, i386, armhf and arm64 CPU architectures are all fully supported.
2.5.2. Best effort
The following are platforms on which BIND is known to build and run. ISC makes every effort to fix bugs on these platforms, but may be unable to do so quickly due to lack of hardware, less familiarity on the part of engineering staff, and other constraints. With the exception of Windows Server 2016, none of these are tested regularly by ISC.
Windows Server 2012 R2, 2016 / x64
Windows 10 / x64
Other Linux distributions still supported by their vendors, such as:
Other CPU architectures (mips, mipsel, sparc, …)
2.5.3. Community maintained
These systems may not all have the required dependencies for building BIND easily available, although it will be possible in many cases to compile those directly from source. The community and interested parties may wish to help with maintenance, and we welcome patch contributions, although we cannot guarantee that we will accept them. All contributions will be assessed against the risk of adverse effect on officially supported platforms.
Platforms past or close to their respective EOL dates, such as:
Ubuntu 14.04, 16.04 (Ubuntu ESM releases are not supported)
FreeBSD 10.x, 11.x
2.6. Unsupported Platforms
These are platforms on which BIND 9.16 is known not to build or run:
Platforms without at least OpenSSL 1.0.2
Windows 10 / x86
Windows Server 2012 and older
Solaris 10 and older
Platforms that don’t support IPv6 Advanced Socket API (RFC 3542)
Platforms that don’t support atomic operations (via compiler or library)
Linux without NPTL (Native POSIX Thread Library)
Platforms on which
libuvcannot be compiled
2.7. Building BIND 9
To build on a Unix or Linux system, use:
$ ./configure $ make
Several environment variables affect compilation, and they can be set
configure. The most significant ones are:
The C compiler to use.
The C compiler flags. Defaults to include -g
and/or -O2 as supported by the compiler. Please
System header file directories. Can be used to specify where add-on thread or IPv6 support is, for example. Defaults to empty string.
Any additional preprocessor symbols you want defined. Defaults to empty string. For a list of possible settings, see the file OPTIONS.
The linker flags. Defaults to an empty string.
Needed when cross-compiling: the native C compiler to use when building for the target system.
Additional environment variables affecting the build are listed at the
end of the
configure help text, which can be obtained by running the
$ ./configure --help
If you’re planning on making changes to the BIND 9 source, you should
make depend. If you’re using Emacs, you might find
make tags helpful.
2.7.1. Required Libraries
To build BIND 9, the following packages must be installed:
BIND 9.16 requires
libuv 1.x or higher. On older systems, an updated
libuv package needs to be installed from sources such as EPEL, PPA,
or other native sources. The other option is to build and install
libuv from source.
OpenSSL 1.0.2e or newer is required. If the OpenSSL library is installed
in a nonstandard location, specify the prefix using
--with-openssl=<PREFIX> on the
configure command line.
Portions of BIND that are written in Python, including
dnssec-checkds, and some of
the system tests, require the
distutils.core modules to be available.
argparse is a standard
module as of Python 2.7 and Python 3.2.
ply is available from
distutils.core is required for
2.7.2. Optional Features
To see a full list of configuration options, run
To build shared libraries, specify
--with-libtool on the
configure command line.
To support the HTTP statistics channel, the server must be linked with
at least one of the following libraries:
If these are installed at a nonstandard location, then:
libxml2, specify the prefix using
To support compression on the HTTP statistics channel, the server must
be linked against
zlib (https://zlib.net/). If this is installed in
a nonstandard location, specify the prefix using
To support storing configuration data for runtime-added zones in an LMDB
database, the server must be linked with
(https://github.com/LMDB/lmdb). If this is installed in a nonstandard
location, specify the prefix using
To support MaxMind GeoIP2 location-based ACLs, the server must be linked
libmaxminddb (https://maxmind.github.io/libmaxminddb/). This is
turned on by default if the library is found; if the library is
installed in a nonstandard location, specify the prefix using
--with-maxminddb=/prefix. GeoIP2 support can be switched off with
For DNSTAP packet logging,
(https://developers.google.com/protocol-buffers) must be installed, and
BIND must be configured with
To support internationalized domain names in
(https://www.gnu.org/software/libidn/#libidn2) must be installed. If the
library is installed in a nonstandard location, specify the prefix using
--with-libidn2=/prefix or adjust
For line editing in
nslookup, either the
readline (https://tiswww.case.edu/php/chet/readline/rltop.html) or
libedit library (https://www.thrysoee.dk/editline/) must be
installed. If these are installed at a nonstandard location, adjust
readline is used by default, and
can be explicitly requested using
Certain compiled-in constants and default settings can be decreased to
values better suited to small machines, e.g. OpenWRT boxes, by
--with-tuning=small on the
configure command line.
This decreases memory usage by using smaller structures, but degrades
On Linux, process capabilities are managed in user space using the
(https://git.kernel.org/pub/scm/libs/libcap/libcap.git/), which can be
installed on most Linux systems via the
libcap-devel package. Process capability support can also be
disabled by configuring with
On some platforms it is necessary to explicitly request large file
support to handle files bigger than 2GB. This can be done by using
--enable-largefile on the
configure command line.
Support for the “fixed” RRset-order option can be enabled or disabled by
--disable-fixed-rrset on the
configure command line. By default, fixed RRset-order is disabled to
reduce memory footprint.
--enable-querytrace option causes
named to log every step
while processing every query. This option should only be enabled when
debugging because is has a significant negative impact on query
make install installs
named and the various BIND 9 libraries. By
default, installation is into /usr/local, but this can be changed with
--prefix option when running
--sysconfdir can be specified to set the directory where
configuration files such as
named.conf go by default;
--localstatedir can be used to set the default parent directory of
--sysconfdir defaults to
--localstatedir defaults to
Building on macOS assumes that the “Command Tools for Xcode” are
installed. These can be downloaded from
https://developer.apple.com/download/more/ or, if Xcode is already
installed, simply run
xcode-select --install. (Note that an Apple ID
may be required to access the download page.)