BIND 10 Guide

Administrator Reference for BIND 10

This is the reference guide for BIND 10 version - 20111129.

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. +BIND 10 Guide

BIND 10 Guide

Administrator Reference for BIND 10

This is the reference guide for BIND 10 version + 20111129.

Abstract

BIND 10 is a framework that features Domain Name System + (DNS) suite and Dynamic Host Configuration Protocol (DHCP) + servers managed by Internet Systems Consortium (ISC). It + includes DNS libraries, modular components for controlling + authoritative and recursive DNS servers, and experimental DHCPv4 + and DHCPv6 servers.

This is the reference guide for BIND 10 version 20111129. The most up-to-date version of this document (in PDF, HTML, and plain text formats), along with other documents for BIND 10, can be found at http://bind10.isc.org/docs. -

Table of Contents

1. Introduction

Supported Platforms
Required Software
Starting and Stopping the Server
Managing BIND 10

2. Installation

Building Requirements

Quick start

Installation from source

Download Tar File
Retrieve from Git
Configure before the build
Build
Install
Install Hierarchy

3. Starting BIND10 with bind10

Starting BIND 10
Configuration of started processes

4. Command channel

5. Configuration manager

6. Remote control daemon

Configuration specification for b10-cmdctl

7. Control and configure user interface

8. Authoritative Server

Server Configurations
Data Source Backends
Loading Master Zones Files

9. Incoming Zone Transfers

Configuration for Incoming Zone Transfers
Enabling IXFR
Secondary Manager
Trigger an Incoming Zone Transfer Manually

10. Outbound Zone Transfers

11. Recursive Name Server

Access Control
Forwarding

12. DHCPv4 Server

DHCPv4 Server Usage
DHCPv4 Server Configuration
Supported standards
DHCPv4 Server Limitations

13. DHCPv6 Server

DHCPv6 Server Usage
DHCPv6 Server Configuration
Supported DHCPv6 Standards
DHCPv6 Server Limitations

14. libdhcp++ library

Interface detection
DHCPv4/DHCPv6 packet handling

15. Statistics

16. Logging

Logging configuration

Loggers
Output Options
Example session

Logging Message Format

List of Tables

3.1.

Chapter 1. Introduction

Table of Contents

Supported Platforms
Required Software
Starting and Stopping the Server
Managing BIND 10

Table of Contents

1. Introduction

1.1. Supported Platforms
1.2. Required Software
1.3. Starting and Stopping the Server
1.4. Managing BIND 10

2. Installation

2.1. Building Requirements

2.2. Quick start

2.3. Installation from source

2.3.1. Download Tar File
2.3.2. Retrieve from Git
2.3.3. Configure before the build
2.3.4. Build
2.3.5. Install
2.3.6. Install Hierarchy

3. Starting BIND10 with bind10

3.1. Starting BIND 10
3.2. Configuration of started processes

4. Command channel

5. Configuration manager

6. Remote control daemon

6.1. Configuration specification for b10-cmdctl

7. Control and configure user interface

8. Authoritative Server

8.1. Server Configurations
8.2. Data Source Backends
8.3. Loading Master Zones Files

9. Incoming Zone Transfers

9.1. Configuration for Incoming Zone Transfers
9.2. Enabling IXFR
9.3. Secondary Manager
9.4. Trigger an Incoming Zone Transfer Manually

10. Outbound Zone Transfers

11. Recursive Name Server

11.1. Access Control
11.2. Forwarding

12. DHCPv4 Server

12.1. DHCPv4 Server Usage
12.2. DHCPv4 Server Configuration
12.3. Supported standards
12.4. DHCPv4 Server Limitations

13. DHCPv6 Server

13.1. DHCPv6 Server Usage
13.2. DHCPv6 Server Configuration
13.3. Supported DHCPv6 Standards
13.4. DHCPv6 Server Limitations

14. libdhcp++ library

14.1. Interface detection
14.2. DHCPv4/DHCPv6 packet handling

15. Statistics

16. Logging

16.1. Logging configuration

16.1.1. Loggers
16.1.2. Output Options
16.1.3. Example session

16.2. Logging Message Format

17. Acknowledgements

List of Tables

3.1.

Chapter 1. Introduction

Table of Contents

1.1. Supported Platforms
1.2. Required Software
1.3. Starting and Stopping the Server
1.4. Managing BIND 10

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 @@ -20,7 +22,7 @@ BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server and a caching recursive name server which also provides forwarding. -

Supported Platforms

1.1. Supported Platforms

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. @@ -30,7 +32,7 @@ It is planned for BIND 10 to build, install and run on Windows and standard Unix-type platforms. -

Required Software

1.2. Required Software

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

@@ -49,7 +51,7 @@ in their default installation nor standard packages collections. You may need to install them separately. -

Starting and Stopping the Server

1.3. 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 @@ -111,7 +113,7 @@

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

Managing BIND 10

1.4. Managing BIND 10

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

@@ -140,7 +142,7 @@ and, of course, DNS. These include detailed developer documentation and code examples. -

Chapter 2. Installation

Table of Contents

Building Requirements

Quick start

Installation from source

Download Tar File
Retrieve from Git
Configure before the build
Build
Install
Install Hierarchy

Building Requirements

Chapter 2. Installation

Table of Contents

2.1. Building Requirements

2.2. Quick start

2.3. Installation from source

2.3.1. Download Tar File
2.3.2. Retrieve from Git
2.3.3. Configure before the build
2.3.4. Build
2.3.5. Install
2.3.6. Install Hierarchy

2.1. Building Requirements

In addition to the run-time requirements, building BIND 10 from source code requires various development include headers.

Note

@@ -169,7 +171,7 @@ 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; Clang++ 2.8; and Sun C++ 5.10. -

Quick start

Note

2.2. Quick start

Note

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 @@ -198,20 +200,20 @@

$ b10-loadzone your.zone.example.org

Test the new zone. -

Installation from source

2.3. 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 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. -

Download Tar File

2.3.1. 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 ftp://ftp.isc.org/isc/bind10/. Periodic development snapshots may also be available. -

Retrieve from Git

2.3.2. Retrieve from Git

Downloading this "bleeding edge" code is recommended only for developers or advanced users. Using development code in a production environment is not recommended. @@ -245,7 +247,7 @@ autoheader, automake, and related commands. -

Configure before the build

2.3.3. 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: @@ -276,16 +278,16 @@

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

Build

2.3.4. Build

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

$ make

Install

2.3.5. Install

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

$ make install

Note

The install step may require superuser privileges.

Install Hierarchy

Note

The install step may require superuser privileges.

2.3.6. Install Hierarchy

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

bin/ — @@ -315,7 +317,7 @@ var/bind10-devel/ — data source and configuration databases.

Chapter 3. Starting BIND10 with bind10

Table of Contents

Starting BIND 10
Configuration of started processes

Chapter 3. Starting BIND10 with bind10

Table of Contents

3.1. Starting BIND 10
3.2. Configuration of started processes

BIND 10 provides the bind10 command which starts up the required processes. bind10 @@ -345,7 +347,7 @@ b10-xfrin for inbound DNS zone transfers, b10-xfrout for outbound DNS zone transfers, and b10-zonemgr for secondary service. -

Starting BIND 10

3.1. 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. @@ -354,7 +356,7 @@ the process names for the Python-based daemons will be renamed to better identify them instead of just “python”. This is not needed on some operating systems. -

Configuration of started processes

3.2. Configuration of started processes

The processes to be started can be configured, with the exception of the b10-sockcreator, b10-msgq and b10-cfgmgr. @@ -385,7 +387,7 @@ during startup or shutdown. Unless specified, the component is started in usual way. This is the list of components that need to be started in a special way, with the value of special used for them: -

Table 3.1.

Component	Special	Description
b10-auth	auth	Authoritative server
b10-resolver	resolver	The resolver
b10-cmdctl	cmdctl	The command control (remote control interface)
setuid	setuid	Virtual component, see below

Table 3.1.

Component	Special	Description
b10-auth	auth	Authoritative server
b10-resolver	resolver	The resolver
b10-cmdctl	cmdctl	The command control (remote control interface)
setuid	setuid	Virtual component, see below

The kind specifies how a failure of the component should be handled. If it is set to “dispensable” @@ -514,7 +516,7 @@ Normally it is not started manually, but is automatically started using the bind10 master process (as covered in Chapter 3, Starting BIND10 with bind10). -

Chapter 6. Remote control daemon

Table of Contents

Configuration specification for b10-cmdctl

Chapter 6. Remote control daemon

Table of Contents

6.1. Configuration specification for b10-cmdctl

b10-cmdctl is the gateway between administrators and the BIND 10 system. It is a HTTPS server that uses standard HTTP Digest @@ -576,7 +578,7 @@ 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

6.1. Configuration specification for b10-cmdctl

The configuration items for b10-cmdctl are: key_file cert_file @@ -610,12 +612,12 @@ shutdown the details and relays (over a b10-msgq command channel) the configuration on to the specified module.

Chapter 8. Authoritative Server

Table of Contents

Server Configurations
Data Source Backends
Loading Master Zones Files

Chapter 8. Authoritative Server

Table of Contents

8.1. Server Configurations
8.2. Data Source Backends
8.3. Loading Master Zones Files

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. -

Server Configurations

8.1. Server Configurations

b10-auth is configured via the b10-cfgmgr configuration manager. The module name is “Auth”. @@ -635,7 +637,7 @@ This may be a temporary setting until then.

shutdown: Stop the authoritative DNS server.

Data Source Backends

Note

8.2. Data Source Backends

Note

For the development prototype release, b10-auth supports a SQLite3 data source backend and in-memory data source backend. @@ -649,7 +651,7 @@ This may be a temporary setting until then. The default is /usr/local/var/.) This data file location may be changed by defining the “database_file” configuration. -

Loading Master Zones Files

8.3. 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. @@ -678,7 +680,7 @@ This may be a temporary setting until then. If you reload a zone already existing in the database, all records from that prior zone disappear and a whole new set appears. -

Chapter 9. Incoming Zone Transfers

Table of Contents

Configuration for Incoming Zone Transfers
Enabling IXFR
Secondary Manager
Trigger an Incoming Zone Transfer Manually

Chapter 9. Incoming Zone Transfers

Table of Contents

9.1. Configuration for Incoming Zone Transfers
9.2. Enabling IXFR
9.3. Secondary Manager
9.4. Trigger an Incoming Zone Transfer Manually

Incoming zones are transferred using the b10-xfrin process which is started by bind10. When received, the zone is stored in the corresponding BIND 10 @@ -696,7 +698,7 @@ This may be a temporary setting until then. In the current development release of BIND 10, incoming zone transfers are only available for SQLite3-based data sources, that is, they don't work for an in-memory data source. -

Configuration for Incoming Zone Transfers

9.1. Configuration for Incoming Zone Transfers

In practice, you need to specify a list of secondary zones to enable incoming zone transfers for these zones (you can still trigger a zone transfer manually, without a prior configuration @@ -712,7 +714,7 @@ This may be a temporary setting until then. > config commit

(We assume there has been no zone configuration before). -

Enabling IXFR

9.2. Enabling IXFR

As noted above, b10-xfrin uses AXFR for zone transfers by default. To enable IXFR for zone transfers for a particular zone, set the use_ixfr @@ -734,7 +736,7 @@ This may be a temporary setting until then. make this selection automatically. These features will be implemented in a near future version, at which point we will enable IXFR by default. -

Secondary Manager

9.3. Secondary Manager

The b10-zonemgr process is started by bind10. It keeps track of SOA refresh, retry, and expire timers @@ -764,7 +766,7 @@ This may be a temporary setting until then. (i.e. no SOA record for it), b10-zonemgr will automatically tell b10-xfrin to transfer the zone in. -

Trigger an Incoming Zone Transfer Manually

9.4. Trigger an Incoming Zone Transfer Manually

To manually trigger a zone transfer to retrieve a remote zone, you may use the bindctl utility. For example, at the bindctl prompt run: @@ -821,7 +823,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

use the system wide TSIG configuration. The way to specify zone specific configuration (ACLs, etc) is likely to be changed, too. -

Chapter 11. Recursive Name Server

Table of Contents

Access Control
Forwarding

Chapter 11. Recursive Name Server

Table of Contents

11.1. Access Control
11.2. Forwarding

The b10-resolver process is started by bind10. @@ -860,7 +862,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

(Replace the “2” as needed; run “config show - Resolver/listen_on” if needed.)

Access Control

+ Resolver/listen_on” if needed.)

11.1. Access Control

By default, the b10-resolver daemon only accepts DNS queries from the localhost (127.0.0.1 and ::1). The Resolver/query_acl configuration may @@ -893,7 +895,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

(Replace the “2” as needed; run “config show Resolver/query_acl” if needed.)

Note

This prototype access control configuration - syntax may be changed.

Forwarding

+ syntax may be changed.

11.2. Forwarding

To enable forwarding, the upstream address and port must be configured to forward queries to, such as: @@ -913,7 +915,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

> config set Resolver/forward_addresses [] > config commit

Chapter 12. DHCPv4 Server

Table of Contents

DHCPv4 Server Usage
DHCPv4 Server Configuration
Supported standards
DHCPv4 Server Limitations

Dynamic Host Configuration Protocol for IPv4 (DHCP or +

Chapter 12. DHCPv4 Server

Table of Contents

12.1. DHCPv4 Server Usage
12.2. DHCPv4 Server Configuration
12.3. Supported standards
12.4. DHCPv4 Server Limitations

Dynamic Host Configuration Protocol for IPv4 (DHCP or DHCPv4) and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are protocols that allow one node (server) to provision configuration parameters to many hosts and devices (clients). To @@ -933,13 +935,13 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

performing DHCP configuration, they are not fully functional yet. In particular, both do not have functional lease databases. This means that they will assign the same, fixed, - hardcoded addresses to any client that will ask. See the section called “DHCPv4 Server Limitations” and the section called “DHCPv6 Server Limitations” for + hardcoded addresses to any client that will ask. See Section 12.4, “DHCPv4 Server Limitations” and Section 13.4, “DHCPv6 Server Limitations” for detailed description. -

DHCPv4 Server Usage

BIND10 provides DHCPv4 server component since December +

12.1. DHCPv4 Server Usage

BIND10 provides DHCPv4 server component since December 2011. It is a skeleton server and can be described as an early prototype that is not fully functional yet. It is mature enough to conduct first tests in lab environment, but it has - significant limitations. See the section called “DHCPv4 Server Limitations” for + significant limitations. See Section 12.4, “DHCPv4 Server Limitations” for details.

DHCPv4 server is implemented as b10-dhcp4 @@ -973,7 +975,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

be started directly, but rather via bind10. Please be aware of this planned change. -

DHCPv4 Server Configuration

Chapter 16. Logging

Table of Contents

Logging configuration

Loggers
Output Options
Example session

Logging Message Format

Logging configuration

Chapter 16. Logging

Table of Contents

16.1. Logging configuration

16.1.1. Loggers
16.1.2. Output Options
16.1.3. Example session

16.2. Logging Message Format

16.1. Logging configuration

The logging system in BIND 10 is configured through the Logging module. All BIND 10 modules will look at the @@ -1209,7 +1211,7 @@ eth0 fe80::21e:8cff:fe9b:7349 -

Loggers

16.1.1. Loggers

Within BIND 10, a message is logged through a component called a "logger". Different parts of BIND 10 log messages @@ -1230,7 +1232,7 @@ eth0 fe80::21e:8cff:fe9b:7349 (what to log), and the output_options (where to log). -

name (string)

16.1.1.1. name (string)

Each logger in the system has a name, the name being that of the component using it to log messages. For instance, if you want to configure logging for the resolver module, @@ -1303,7 +1305,7 @@ eth0 fe80::21e:8cff:fe9b:7349 “Auth.cache” logger will appear in the output with a logger name of “b10-auth.cache”). -

severity (string)

16.1.1.2. severity (string)

This specifies the category of messages logged. Each message is logged with an associated severity which @@ -1319,7 +1321,7 @@ eth0 fe80::21e:8cff:fe9b:7349 -

output_options (list)

16.1.1.3. output_options (list)

Each logger can have zero or more output_options. These specify where log @@ -1329,7 +1331,7 @@ eth0 fe80::21e:8cff:fe9b:7349 The other options for a logger are: -

debuglevel (integer)

16.1.1.4. debuglevel (integer)

When a logger's severity is set to DEBUG, this value specifies what debug messages should be printed. It ranges @@ -1338,7 +1340,7 @@ eth0 fe80::21e:8cff:fe9b:7349 If severity for the logger is not DEBUG, this value is ignored. -

additive (true or false)

16.1.1.5. additive (true or false)

If this is true, the output_options from the parent will be used. For example, if there are two @@ -1352,18 +1354,18 @@ eth0 fe80::21e:8cff:fe9b:7349 -

Output Options

16.1.2. Output Options

The main settings for an output option are the destination and a value called output, the meaning of which depends on the destination that is set. -

destination (string)

16.1.2.1. destination (string)

The destination is the type of output. It can be one of: -

console
file
syslog

output (string)

console
file
syslog

16.1.2.2. output (string)

Depending on what is set as the output destination, this value is interpreted as follows: @@ -1385,12 +1387,12 @@ eth0 fe80::21e:8cff:fe9b:7349 The other options for output_options are: -

flush (true of false)

16.1.2.2.1. flush (true of false)

Flush buffers after each log message. Doing this will reduce performance but will ensure that if the program terminates abnormally, all messages up to the point of termination are output. -

maxsize (integer)

16.1.2.2.2. maxsize (integer)

Only relevant when destination is file, this is maximum file size of output files in bytes. When the maximum size is reached, the file is renamed and a new file opened. @@ -1399,11 +1401,11 @@ eth0 fe80::21e:8cff:fe9b:7349 etc.)

If this is 0, no maximum file size is used. -

maxver (integer)

16.1.2.2.3. maxver (integer)

Maximum number of old log files to keep around when rolling the output file. Only relevant when destination is “file”. -

Example session

16.1.3. Example session

In this example we want to set the global logging to write to the file /var/log/my_bind10.log, @@ -1564,7 +1566,7 @@ Logging/loggers[0]/output_options[0]/maxver 8 integer (modified) And every module will now be using the values from the logger named “*”. -

Logging Message Format

16.2. Logging Message Format

Each message written by BIND 10 to the configured logging destinations comprises a number of components that identify the origin of the message and, if the message indicates @@ -1610,4 +1612,5 @@ Logging/loggers[0]/output_options[0]/maxver 8 integer (modified) consulting your system's documentation to identify what error number 111 means.