Getting started with BIND - how to build and run named with a basic recursive configuration
  • 05 Oct 2018
  • 6 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Getting started with BIND - how to build and run named with a basic recursive configuration

  • Dark
    Light
  • PDF

Article Summary

This is a simple 'first steps' primer to help you get started with BIND. For anything more complex you'll need to refer to the Administrator Reference Manual (ARM), man pages, textbooks, this Knowledgebase and numerous online fora. This article is aimed at those who are downloading and installing BIND themselves in a Linux or similar operating environment for the very first time and want to make sure that they can get it running before moving on to specific configuration steps.

1.  Downloading the software

BIND is available from http://www.isc.org/downloads/. Information on which versions are actively supported is also provided on the downloads page. For more details of how we number and identify our versions, you can refer to: http://www.isc.org/downloads/software-support-policy/version-numbering/.

Select the version of BIND that you would like to run and download the tar.gz file by clicking on Source Download. (If you're running in a Windows environment, BIND comes pre-compiled - download and refer to instructions provided for installation.)

Verify that the download is good against one of the signature files.  See https://www.isc.org/downloads/software-support-policy/openpgp-key/ if you're not sure how to do this (and to obtain ISC's current public pgp key).

2.  Building BIND

Decide where you're going to put the source code directory - but the location is your own preference, it doesn't make a difference operationally. You should however, protect your source code from potential tampering.

Unpack the tarball:

tar -zxvf <name of BIND tarball, e.g. bind-9.9.4-P1.tar.gz>

Navigate to the top level directory of the new source code directory.  

Read the README file - make sure that you have OpenSSL installed (if you'd like to implement DNSSEC signing/validation), a good source of randomness, and an ANSI C compiler.

At this point you need to think about where you'd like the installation to place the new binaries and which directory you want to be the default/base location for the configuration files. By default (i.e. if you don't specify anything different to the ./configure script), the binaries will be located in /usr/local/bin and /usr/local/sbin. Also by default, the binaries will 'look for' their configuration files in /etc. If you want any of these to be different, then check the options that you can supply to ./configure:

./configure --help

Why might I want to change the default file locations?
The installation will place BIND's binaries into /usr/local/bin and /usr/local/sbin. There are also other default locations for configuration and runtime variable files. Depending on the operating system environment you're running in, and whether you have system administration utilities that you're going to use to help start/stop and otherwise monitor BIND, you may want to locate BIND's files where those utilities expect to find them. If you have a version of named installed already, and it's a new enough version of BIND to support the -V option, you can find out what configure options were used when it was built by typing named -V.

Alternatively, you might prefer not to overwrite the files provided with the OS and want to run BIND independently - in which case you would supply options to configure to avoid collisions.

If you're happy with the defaults, then just go ahead and perform the configure step. The example below is ensuring that the build will be multi-threaded, uses OpenSSL, and also includes links to libxml2 so that XML-based statistics can be configured and generated:

./configure --with-openssl --enable-threads --with-libxml2

Building with openssl and libxml2 - what do you need to install first?
You need current versions of openssl and libxml2. You will most likely also need libssl-dev and libxml2-dev.

Next, test that the build step completes successfully, but without installing the binaries:

make

If this step has completed successfully, then you're ready to install the binaries.

The step below will overwrite any files already installed with the same name/location
This step assumes that you're not not already running BIND. If you are already running BIND, then make sure that you have a backup, or at least a plan to 'go back' to how things were, before doing this! If you prefer, you can stop after the 'make' step and copy the binaries into place manually, renaming the older versions first.  You'll either need to be running as root, or use sudo to obtain root privileges to do this:
sudo make install

3. Testing your binary with default options

BIND will run as a recursive server with default options - all you need to do is to create an empty named.conf file in the default location (the example below assumes that you ran ./configure without making any location changes):

sudo touch /etc/named.conf

Now you can test that the binary and your environment is good by starting named running in the foreground with the logging directed to stdout. You're also testing that your $PATH variable includes /usr/local/sbin. The -g option is very useful for troubleshooting problems with named:

sudo named -V
sudo named -g

Note what is being logged by default - and that it includes the configure options, what named has detected about its run-time environment and what interfaces the daemon is listening on. It also shows you the default empty zones that named loads. If there are any problems reported, now is the time to investigate and fix them. You can terminate the running foreground named with Ctrl-C.

4.  Testing your binary as a recursive server

You're now ready to run named as a background daemon. Before launching it, it's a good idea to set up the default options for the management tool rndc.

  • Navigate to the default directory for configuration files:
cd /etc
  • Create the default rndc.key file (that will be used by both named and rndc in lieu of any specific control configuration in named.conf or rndc.conf):
sudo rndc-confgen -a

Launch the named daemon (this is bypassing any system administration tools that your OS environment offers):

sudo named

Check that named is operating as expected; check the logfiles and remedy any problems if not:

sudo ps -ef|grep namedsudo rndc status

And finally, check that the daemon is responding:

dig @127.0.0.1 . NS

Above, the dig tool is simply sending a query to your nameserver asking it for the list of NS records authoritative for "." and you're testing that:

  • It answers queries (you should get a reply that near the end has a line: ;; SERVER: 127.0.0.1#53(127.0.0.1)   ).
  • It has access to the root nameservers (you should get an answer that lists the NS records!).

5. What next? ...

The steps above are really basic, but they're only intended to be a starting point. There are many options and topics that haven't been addressed, but now you have the framework, you can develop from there according to your needs. Some things you'll most likely want to research consider are:

  • Running named as a non-root user - read up on the -u run-time option
  • Running named in a chroot jail (many still do, but this shouldn't be necessary with modern versions of BIND)
  • Configuring non-default access control lists for recursion
  • If you're planning to run an authoritative server, adding zone statements and creating zone files for the domains you want to serve
  • Running different servers for authoritative and recursive services
  • In a multi-threaded environment, tuning the number of worker threads (runtime option -n) and, from BIND 9.9 and newer, tuning the number of listener tasks (runtime option -U) to optimize your server performance
  • Tailoring logging to your own needs
  • Integrating the management of BIND with your system administration tools and processes
  • Deploying more advanced features of BIND such as masters/slaves and zone transfers, dynamic updates, DNSSEC etc.
  • Providing services over IPv6 as well as over IPv4.

The following two Best Practices articles may also provide some useful guidance:

Best Practices for those running Recursive Servers

Best Practices for those running Authoritative Servers