This is the reference guide for BIND 10 version 20110322.
Copyright © 2010 Internet Systems Consortium, Inc.
Abstract
BIND 10 is a Domain Name System (DNS) suite managed by Internet Systems Consortium (ISC). It includes DNS libraries and modular components for controlling authoritative and recursive DNS servers.
This is the reference guide for BIND 10 version 20110322. The most up-to-date version of this document, along with other documents for BIND 10, can be found at http://bind10.isc.org/docs.
Table of Contents
Table of Contents
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 of BIND 10 version 20110322.
BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server and a caching recursive name server which also provides forwarding.
BIND 10 builds have been tested on Debian GNU/Linux 5, Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, 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.
BIND 10 requires Python 3.1. Later versions may work, but Python 3.1 is the minimum version which will work.
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.
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:
These are ran automatically by bind10 and do not need to be run manually.
Once BIND 10 is running, a few commands are used to interact directly with the system:
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.
Table of Contents
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.35 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.
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.
To quickly get started with BIND 10, follow these steps.
Extract the tar file:
$ gzcat bind10-VERSION.tar.gz | tar -xvf -
Go into the source and run configure:
$cd bind10-$VERSION./configure
Build it:
$ make
Install it (to default /usr/local):
$ make install
Start the server:
$ /usr/local/sbin/bind10
Test it; for example:
$ dig @127.0.0.1 -c CH -t TXT authors.bind
Load desired zone file(s), for example:
$ b10-loadzone your.zone.example.org
BIND 10 is open source software written in C++ and Python. It is freely available in source code form from ISC via the Git 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.
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 ftp://ftp.isc.org/isc/bind10/. Periodic development snapshots may also be available.
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 Git 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 Git and all the BIND 10 development is public. The leading development is done in the “master”.
The code can be checked out from
git://bind10.isc.org/bind10;
for example:
$ git clone git://bind10.isc.org/bind10
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.
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:
/usr/local/).
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.
After the configure step is complete, to build the executables from the C++ code and prepare the Python scripts, run:
$ make
To install the BIND 10 executables, support files, and documentation, run:
$ make install
The install step may require superuser privileges.
The following is the layout of the complete BIND 10 installation:
bin/ —
general tools and diagnostic clients.
etc/bind10-devel/ —
configuration files.
lib/ —
libraries and python modules.
libexec/bind10-devel/ —
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/ —
commands used by the system administrator.
share/bind10-devel/ —
configuration specifications.
share/man/ —
manual pages (online documentation).
var/bind10-devel/ —
data source and configuration databases.
Table of Contents
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 or b10-resolver for recursive name service, b10-stats for statistics collection, b10-xfrin for inbound DNS zone transfers, b10-xfrout for outbound DNS zone transfers, and b10-zonemgr for secondary service.
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.
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 Chapter 6, Remote control daemon.
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 Chapter 3, Starting BIND10 with bind10).
Table of Contents
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 — the user interface — 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.
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.
Table of Contents
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.
b10-auth is configured via the b10-cfgmgr configuration manager. The module name is “Auth”. The configuration data item is:
The configuration command is:
For the development prototype release, b10-auth supports a SQLite3 data source backend and in-memory data source backend. Upcoming versions will be able to use multiple different data sources, such as MySQL and Berkeley 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.
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):
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 zones are transferred using the b10-xfrin process which is started by bind10. When received, the zone 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
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.
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.
Table of Contents
The b10-resolver process is started by bind10.
The main bind10 process can be configured to select to run either the authoritative or resolver. By default, it starts the authoritative service. You may change this using bindctl, for example:
>config set Boss/start_auth false>config set Boss/start_resolver true>config commit
The master bind10 will stop and start the desired services.
The resolver also needs to be configured to listen on an address and port:
>config set Resolver/listen_on [{ "address": "127.0.0.1", "port": 53 }]>config commit
To enable forwarding, the upstream address and port must be configured to forward queries to, such as:
>config set Resolver/forward_addresses [{ "address": ">192.168.1.1", "port": 53 }]config commit
(Replace 192.168.1.1 to point to your
full resolver.)
Normal iterative name service can be re-enabled by clearing the forwarding address(es); for example:
>config set Resolver/forward_addresses []>config commit
The b10-stats process is started by bind10. It periodically collects statistics data from various modules and aggregates it.
This stats daemon provides commands to identify if it is running, show specified or all statistics data, set values, remove data, and reset data. For example, using bindctl:
> Stats show
{
"auth.queries.tcp": 1749,
"auth.queries.udp": 867868,
"bind10.boot_time": "2011-01-20T16:59:03Z",
"report_time": "2011-01-20T17:04:06Z",
"stats.boot_time": "2011-01-20T16:59:05Z",
"stats.last_update_time": "2011-01-20T17:04:05Z",
"stats.lname": "4d3869d9_a@jreed.example.net",
"stats.start_time": "2011-01-20T16:59:05Z",
"stats.timestamp": 1295543046.823504
}