# BIND 10 Guide

Administrator Reference for BIND 10
2010
Internet Systems Consortium, Inc.

This is the reference guide for BIND 10.

The most up-to-date version of this document, along with other documents for BIND 10, can be found at .

## Introduction

BIND is the popular implementation of a DNS server, developer interfaces, and DNS tools. BIND 10 is a rewrite of BIND 9. BIND 10 is written in C++ and Python and provides a modular environment for serving and maintaining DNS.

This guide covers the experimental prototype version of BIND 10.

BIND 10, at this time, does not provide a recursive DNS server. It does provide a EDNS0- and DNSSEC-capable authoritative DNS server.

### Supported Platforms

BIND 10 builds have been tested on Debian GNU/Linux 5, Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7, and CentOS Linux 5.3.

It has been tested on Sparc, i386, and amd64 hardware platforms.

It is planned for BIND 10 to build, install and run on Windows and standard Unix-type platforms.

### Required Software

BIND 10 requires Python 3.1. Later versions may work, but Python 3.1 is the minimum version which will work.

For this development prototype release, the only supported data source backend is SQLite3. The authoritative server requires SQLite 3.3.9 or newer. The `b10-xfrin`, `b10-xfrout`, and `b10-zonemgr` modules require the libpython3 library and the Python _sqlite3.so module.

Some operating systems do not provide these dependencies in their default installation nor standard packages collections. You may need to install them separately.

### Starting and Stopping the Server

BIND 10 is modular. Part of this modularity is accomplished using multiple cooperating processes which, together, provide the server functionality. This is a change from the previous generation of BIND software, which used a single process.

At first, running many different processes may seem confusing. However, these processes are started, stopped, and maintained by a single command, `bind10`. This command starts a master process which will start other processes as needed. The processes started by the `bind10` command have names starting with "b10-", including:

- `b10-msgq` &mdash; Message bus daemon. This process coordinates communication between all of the other BIND 10 processes.

- `b10-auth` &mdash; Authoritative DNS server. This process serves DNS requests.

- `b10-cfgmgr` &mdash; Configuration manager. This process maintains all of the configuration for BIND 10.

- `b10-cmdctl` &mdash; Command and control service. This process allows external control of the BIND 10 system.

- `b10-xfrin` &mdash; Incoming zone transfer service. This process is used to transfer a new copy of a zone into BIND 10, when acting as a secondary server.

- `b10-xfrout` &mdash; Outgoing zone transfer service. This process is used to handle transfer requests to send a local zone to a remote secondary server, when acting as a master server.

- `b10-zonemgr` &mdash; Secondary manager. This process keeps track of timers and other necessary information for BIND 10 to act as a slave server.

These are ran automatically by `bind10` and do not need to be run manually.

### Managing BIND 10

Once BIND 10 is running, a few commands are used to interact directly with the system:

- `bindctl` &mdash; interactive administration interface. This is a command-line tool which allows an administrator to control BIND 10.

- `b10-loadzone` &mdash; zone file loader. This tool will load standard masterfile-format zone files into BIND 10.

- `b10-cmdctl-usermgr` &mdash; user access control. This tool allows an administrator to authorize additional users to manage BIND 10.

The tools and modules are covered in full detail in this guide. In addition, manual pages are also provided in the default installation.

BIND 10 also provides libraries and programmer interfaces for C++ and Python for the message bus, configuration backend, and, of course, DNS. These include detailed developer documentation and code examples.

## Installation

### Building Requirements

Some operating systems have split their distribution packages into a run-time and a development package. You will need to install the development package versions, which include header files and libraries, to build BIND 10 from source code.

Building from source code requires the Boost build-time headers. At least Boost version 1.34 is required.

The Python Library and Python _sqlite3 module are required to enable the Xfrout and Xfrin support.

The Python related libraries and modules need to be built for Python 3.1.

Building BIND 10 also requires a C++ compiler and standard development headers, make, and pkg-config. BIND 10 builds have been tested with GCC g++ 3.4.3, 4.1.2, 4.1.3, 4.2.1, 4.3.2, and 4.4.1.

### Quick start

This quickly covers the standard steps for installing and deploying BIND 10 as an authoritative name server using its defaults. For troubleshooting, full customizations and further details, see the respective chapters in the BIND 10 guide.

The development prototype of the b10-auth server listens on 0.0.0.0 (all interfaces) port 5300. (This is not the standard domain service port.)

To quickly get started with BIND 10, follow these steps.

1. Install required build dependencies.

2. Download the BIND 10 source tar file from .

3. Extract the tar file:

       $ gzcat bind10-VERSION.tar.gz | tar -xvf -

4. Go into the source and run configure:

       $ cd bind10-VERSION
         $ ./configure

5. Build it:

       $ make

6. Install it (to default /usr/local):

       $ make install

7. Start the server:

       $ /usr/local/sbin/bind10

8. Test it; for example:

       $ dig @127.0.0.1 -p 5300 -c CH -t TXT authors.bind

9. Load desired zone file(s), for example:

       $ b10-loadzone your.zone.example.org

10. Test the new zone.

### Installation from source

BIND 10 is open source software written in C++ and Python. It is freely available in source code form from ISC via the Subversion code revision control system or as a downloadable tar file. It may also be available in pre-compiled ready-to-use packages from operating system vendors.

#### Download Tar File

Downloading a release tar file is the recommended method to obtain the source code.

The BIND 10 releases are available as tar file downloads from . Periodic development snapshots may also be available.

#### Retrieve from Subversion

Downloading this "bleeding edge" code is recommended only for developers or advanced users. Using development code in a production environment is not recommended.

When using source code retrieved via Subversion additional software will be required: automake (v1.11 or newer), libtoolize, and autoconf (2.59 or newer). These may need to be installed.

The latest development code, including temporary experiments and un-reviewed code, is available via the BIND 10 code revision control system. This is powered by Subversion and all the BIND 10 development is public. The leading development is done in the trunk.

The code can be checked out from `svn://bind10.isc.org/svn/bind10`; for example to check out the trunk:

    $ svn co svn://bind10.isc.org/svn/bind10/trunk

When checking out the code from the code version control system, it doesn't include the generated configure script, Makefile.in files, nor the related configure files. They can be created by running `autoreconf` with the `--install` switch. This will run `autoconf`, `aclocal`, `libtoolize`, `autoheader`, `automake`, and related commands.

#### Configure before the build

BIND 10 uses the GNU Build System to discover build environment details. To generate the makefiles using the defaults, simply run:

    $ ./configure

Run `./configure` with the `--help` switch to view the different options. The commonly-used options are:

--prefix

  Define the the installation location (the default is `/usr/local/`).

--with-boost-include

  Define the path to find the Boost headers.

--with-pythonpath

  Define the path to Python 3.1 if it is not in the standard execution path.

--with-gtest

  Enable building the C++ Unit Tests using the Google Tests framework. Optionally this can define the path to the gtest header files and library.

For example, the following configures it to find the Boost headers, find the Python interpreter, and sets the installation location:

    $ ./configure \
          --with-boost-include=/usr/pkg/include \
          --with-pythonpath=/usr/pkg/bin/python3.1 \
          --prefix=/opt/bind10

If the configure fails, it may be due to missing or old dependencies.

#### Build

After the configure step is complete, to build the executables from the C++ code and prepare the Python scripts, run:

    $ make

#### Install

To install the BIND 10 executables, support files, and documentation, run:

    $ make install

The install step may require superuser privileges.

#### Install Hierarchy

The following is the layout of the complete BIND 10 installation:

- `bin/` &mdash; general tools and diagnostic clients.

- `etc/bind10-devel/` &mdash; configuration files.

- `lib/` &mdash; libraries and python modules.

- `libexec/bind10-devel/` &mdash; executables that a user wouldn't normally run directly and are not run independently. These are the BIND 10 modules which are daemons started by the `bind10` tool.

- `sbin/` &mdash; commands used by the system administrator.

- `share/bind10-devel/` &mdash; configuration specifications.

- `share/man/` &mdash; manual pages (online documentation).

- `var/bind10-devel/` &mdash; data source and configuration databases.

## Starting BIND10 with `bind10`

BIND 10 provides the `bind10` command which starts up the required processes. `bind10` will also restart processes that exit unexpectedly. This is the only command needed to start the BIND 10 system.

After starting the `b10-msgq` communications channel, `bind10` connects to it, runs the configuration manager, and reads its own configuration. Then it starts the other modules.

The `b10-msgq` and `b10-cfgmgr` services make up the core. The `b10-msgq` daemon provides the communication channel between every part of the system. The `b10-cfgmgr` daemon is always needed by every module, if only to send information about themselves somewhere, but more importantly to ask about their own settings, and about other modules. The `bind10` master process will also start up `b10-cmdctl` for admins to communicate with the system, `b10-auth` for Authoritative DNS service, `b10-xfrin` for inbound DNS zone transfers, `b10-xfrout` for outbound DNS zone transfers, and `b10-zonemgr` for secondary service.

### Starting BIND 10

To start the BIND 10 service, simply run `bind10`. Run it with the `--verbose` switch to get additional debugging or diagnostic output.

## Command channel

The BIND 10 components use the `b10-msgq` message routing daemon to communicate with other BIND 10 components. The `b10-msgq` implements what is called the Command Channel. Processes intercommunicate by sending messages on the command channel. Example messages include shutdown, get configurations, and set configurations. This Command Channel is not used for DNS message passing. It is used only to control and monitor the BIND 10 system.

Administrators do not communicate directly with the `b10-msgq` daemon. By default, BIND 10 uses port 9912 for the `b10-msgq` service. It listens on 127.0.0.1.

## Configuration manager

The configuration manager, `b10-cfgmgr`, handles all BIND 10 system configuration. It provides persistent storage for configuration, and notifies running modules of configuration changes.

The `b10-auth` and `b10-xfrin` daemons and other components receive their configurations from the configuration manager over the `b10-msgq` command channel.

The administrator doesn't connect to it directly, but uses a user interface to communicate with the configuration manager via `b10-cmdctl`'s REST-ful interface. `b10-cmdctl` is covered in .

The development prototype release only provides the `bindctl` as a user interface to `b10-cmdctl`. Upcoming releases will provide another interactive command-line interface and a web-based interface.

The `b10-cfgmgr` daemon can send all specifications and all current settings to the `bindctl` client (via `b10-cmdctl`).

`b10-cfgmgr` relays configurations received from `b10-cmdctl` to the appropriate modules.

The stored configuration file is at `/usr/local/var/bind10-devel/b10-config.db`. (The full path is what was defined at build configure time for `--localstatedir`. The default is `/usr/local/var/`.) The format is loosely based on JSON and is directly parseable python, but this may change in a future version. This configuration data file is not manually edited by the administrator.

The configuration manager does not have any command line arguments. Normally it is not started manually, but is automatically started using the `bind10` master process (as covered in ).

## Remote control daemon

`b10-cmdctl` is the gateway between administrators and the BIND 10 system. It is a HTTPS server that uses standard HTTP Digest Authentication for username and password validation. It provides a REST-ful interface for accessing and controlling BIND 10.

When `b10-cmdctl` starts, it firsts asks `b10-cfgmgr` about what modules are running and what their configuration is (over the `b10-msgq` channel). Then it will start listening on HTTPS for clients &mdash; the user interface &mdash; such as `bindctl`.

`b10-cmdctl` directly sends commands (received from the user interface) to the specified component. Configuration changes are actually commands to `b10-cfgmgr` so are sent there.

The HTTPS server requires a private key, such as a RSA PRIVATE KEY. The default location is at `/usr/local/etc/bind10-devel/cmdctl-keyfile.pem`. (A sample key is at `/usr/local/share/bind10-devel/cmdctl-keyfile.pem`.) It also uses a certificate located at `/usr/local/etc/bind10-devel/cmdctl-certfile.pem`. (A sample certificate is at `/usr/local/share/bind10-devel/cmdctl-certfile.pem`.) This may be a self-signed certificate or purchased from a certification authority.

The HTTPS server doesn't support a certificate request from a client (at this time). The `b10-cmdctl` daemon does not provide a public service. If any client wants to control BIND 10, then a certificate needs to be first received from the BIND 10 administrator. The BIND 10 installation provides a sample PEM bundle that matches the sample key and certificate.

The `b10-cmdctl` daemon also requires the user account file located at `/usr/local/etc/bind10-devel/cmdctl-accounts.csv`. This comma-delimited file lists the accounts with a user name, hashed password, and salt. (A sample file is at `/usr/local/share/bind10-devel/cmdctl-accounts.csv`. It contains the user named root with the password bind10.)

The administrator may create a user account with the `b10-cmdctl-usermgr` tool.

By default the HTTPS server listens on the localhost port 8080. The port can be set by using the `--port` command line option. The address to listen on can be set using the `--address` command line argument. Each HTTPS connection is stateless and timesout in 1200 seconds by default. This can be redefined by using the `--idle-timeout` command line argument.

### Configuration specification for b10-cmdctl

The configuration items for `b10-cmdctl` are: key_file cert_file accounts_file

The control commands are: print_settings shutdown

## Control and configure user interface

For this development prototype release, `bindctl` is the only user interface. It is expected that upcoming releases will provide another interactive command-line interface and a web-based interface for controlling and configuring BIND 10.

The `bindctl` tool provides an interactive prompt for configuring, controlling, and querying the BIND 10 components. It communicates directly with a REST-ful interface over HTTPS provided by `b10-cmdctl`. It doesn't communicate to any other components directly.

Configuration changes are actually commands to `b10-cfgmgr`. So when `bindctl` sends a configuration, it is sent to `b10-cmdctl` (over a HTTPS connection); then `b10-cmdctl` sends the command (over a `b10-msgq` command channel) to `b10-cfgmgr` which then stores the details and relays (over a `b10-msgq` command channel) the configuration on to the specified module.

## Authoritative Server

The `b10-auth` is the authoritative DNS server. It supports EDNS0 and DNSSEC. It supports IPv6. Normally it is started by the `bind10` master process.

This development prototype release listens on all interfaces and the non-standard port 5300.

### Server Configurations

`b10-auth` is configured via the `b10-cfgmgr` configuration manager. The module name is Auth. The configuration data item is:

database_file

  This is an optional string to define the path to find the SQLite3 database file. Note: Later the DNS server will use various data source backends. This may be a temporary setting until then.

The configuration command is:

shutdown

  Stop the authoritative DNS server.

### Data Source Backends

For the development prototype release, `b10-auth` only supports the SQLite3 data source backend. Upcoming versions will be able to use multiple different data sources, such as MySQL, Berkeley DB, or in-memory DB.

By default, the SQLite3 backend uses the data file located at `/usr/local/var/bind10-devel/zone.sqlite3`. (The full path is what was defined at build configure time for `--localstatedir`. The default is `/usr/local/var/`.) This data file location may be changed by defining the database_file configuration.

### Loading Master Zones Files

RFC 1035 style DNS master zone files may imported into a BIND 10 data source by using the `b10-loadzone` utility.

`b10-loadzone` supports the following special directives (control entries):

$INCLUDE

  Loads an additional zone file. This may be recursive.

$ORIGIN

  Defines the relative domain name.

$TTL

  Defines the time-to-live value used for following records that don't include a TTL.

The `-o` argument may be used to define the default origin for loaded zone file records.

In the development prototype release, only the SQLite3 back end is used. By default, it stores the zone data in `/usr/local/var/bind10-devel/zone.sqlite3` unless the `-d` switch is used to set the database filename. Multiple zones are stored in a single SQLite3 zone database.

If you reload a zone already existing in the database, all records from that prior zone disappear and a whole new set appears.

## Incoming Zone Transfers

The `b10-xfrin` process is started by `bind10`. It can be manually triggered to request an AXFR zone transfer. When received, it is stored in the BIND 10 data store, and its records can be served by `b10-auth`. In combination with `b10-zonemgr` (for automated SOA checks), this allows the BIND 10 server to provide secondary service.

The current development release of BIND 10 only supports AXFR. (IXFR is not supported.)

To manually trigger a zone transfer to retrieve a remote zone, you may use the `bindctl` utility. For example, at the `bindctl` prompt run:

    > Xfrin retransfer zone_name="foo.example.org" master=192.0.2.99

## Outbound Zone Transfers

The `b10-xfrout` process is started by `bind10`. When the `b10-auth` authoritative DNS server receives an AXFR request, `b10-xfrout` sends the zone. This is used to provide master DNS service to share zones to secondary name servers. The `b10-xfrout` is also used to send NOTIFY messages to slaves.

The current development release of BIND 10 only supports AXFR. (IXFR is not supported.) Access control is not yet provided.

## Secondary Manager

The `b10-zonemgr` process is started by `bind10`. It keeps track of SOA refresh, retry, and expire timers and other details for BIND 10 to perform as a slave. When the `b10-auth` authoritative DNS server receives a NOTIFY message, `b10-zonemgr` may tell `b10-xfrin` to do a refresh to start an inbound zone transfer. The secondary manager resets its counters when a new zone is transferred in.

Access control (such as allowing notifies) is not yet provided. The primary/secondary service is not yet complete.