BIND 10 Guide

3. Starting BIND10 with bind10

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.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.2.1. In-memory Data Source

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.1. Loggers
16.1.2. Output Options
16.1.3. Example session

List of Tables

3.1.

Preface

Table of Contents

1. Acknowledgements

1. Acknowledgements

ISC would like to acknowledge generous support for +

Table of Contents

Preface

1. Acknowledgements

1. Introduction

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

2. Installation

3. Starting BIND10 with bind10

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.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.2.1. In-memory Data Source

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.1. Loggers
16.1.2. Output Options
16.1.3. Example session

List of Tables

3.1.

Preface

Table of Contents

1. Acknowledgements

1. Acknowledgements

ISC would like to acknowledge generous support for BIND 10 development of DHCPv4 and DHCPv6 components provided - by Comcast.

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

+ by Comcast.

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 @@ -23,7 +23,7 @@

This guide covers the experimental prototype of BIND 10 version 20120405. -

1.1. Supported Platforms

BIND 10 builds have been tested on Debian GNU/Linux 5 and unstable, Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, CentOS Linux 5.3, and MacOS 10.6. @@ -162,7 +162,7 @@ and, of course, DNS. These include detailed developer documentation and code examples. -

Chapter 2. Installation

Table of Contents

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

Chapter 2. Installation

Table of Contents

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

@@ -224,14 +224,14 @@ 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. -

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

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. @@ -265,7 +265,7 @@ autoheader, automake, and related commands. -

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: @@ -296,16 +296,16 @@

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

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

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.

2.3.6. 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/ — @@ -360,9 +360,8 @@ In its default configuration, the bind10 master process will also start up b10-cmdctl for administration tools to - communicate with the system, - b10-stats for statistics collection, and - b10-stats-httpd for statistics reporting. + communicate with the system, and + b10-stats for statistics collection.
3.1. Starting BIND 10
To start the BIND 10 service, simply run bind10. Run it with the --verbose switch to @@ -398,7 +397,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)

+
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)

The kind specifies how a failure of the component should be handled. If it is set to “dispensable” @@ -626,12 +625,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
8.1. Server Configurations
8.2. Data Source Backends
8.2.1. In-memory Data Source
8.3. Loading Master Zones Files
+
Chapter 8. Authoritative Server
Table of Contents
8.1. Server Configurations
8.2. Data Source Backends
8.2.1. In-memory Data Source
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. -
8.1. Server Configurations
+
8.1. Server Configurations
b10-auth is configured via the b10-cfgmgr configuration manager. The module name is “Auth”. @@ -711,7 +710,7 @@ This may be a temporary setting until then. if configured.)
-
8.2. 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. @@ -771,7 +770,7 @@ This may be a temporary setting until then. and/or zones[0] for the relevant zone as needed.) -
8.3. Loading Master Zones Files
+
8.3. Loading Master Zones Files
RFC 1035 style DNS master zone files may imported into a BIND 10 SQLite3 data source by using the b10-loadzone utility. @@ -800,7 +799,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
9.1. Configuration for Incoming Zone Transfers
9.2. Enabling IXFR
9.3. Secondary Manager
9.4. Trigger an Incoming Zone Transfer Manually
+

Component	Special	Description
b10-auth	auth	Authoritative server
b10-resolver	resolver	The resolver
b10-cmdctl	cmdctl	The command control (remote control interface)

Component	Special	Description
b10-auth	auth	Authoritative server
b10-resolver	resolver	The resolver
b10-cmdctl	cmdctl	The command control (remote control interface)

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 @@ -818,7 +817,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. -

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 @@ -834,7 +833,7 @@ This may be a temporary setting until then. > config commit

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

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 @@ -886,7 +885,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. -

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: @@ -935,7 +934,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

TSIGs in the incoming messages and to sign responses.

Note

The way to specify zone specific configuration (ACLs, etc) is likely to be changed. -

Chapter 11. Recursive Name Server

Table of Contents

11.1. Access Control
11.2. Forwarding

Chapter 11. Recursive Name Server

Table of Contents

11.1. Access Control
11.2. Forwarding

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

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

11.1. 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 @@ -1002,7 +1001,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.

11.2. 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: @@ -1051,21 +1050,18 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

significant limitations. See Section 12.4, “DHCPv4 Server Limitations” for details.

- The DHCPv4 server is implemented as b10-dhcp4 - daemon. As it is not configurable yet, it is fully autonomous, - that is it does not interact with b10-cfgmgr. - To start DHCPv4 server, simply input: - -

-#cd src/bin/dhcp4
-#./b10-dhcp4
-

- - Depending on your installation, b10-dhcp4 - binary may reside in src/bin/dhcp4 in your source code - directory, in /usr/local/bin/b10-dhcp4 or other directory - you specified during compilation. - + b10-dhcp4 is a BIND10 component and is being + run under BIND10 framework. To add a DHCPv4 process to the set of running + BIND10 services, you can use following commands in bindctl: +

> config add Boss/components b10-dhcp4
+> config set Boss/components/b10-dhcp4/kind dispensable
+> config commit

+ To shutdown running b10-dhcp4, please use the + following command: +

> Dhcp4 shutdown

+ or +

> config remove Boss/components b10-dhcp4
+> config commit

At start, the server will detect available network interfaces and will attempt to open UDP sockets on all interfaces that are up, running, are not loopback, and have IPv4 address @@ -1125,13 +1121,7 @@ const std::string HARDCODED_SERVER_ID = "192.0.2.1";

currently hardcoded. The only way to tweak configuration is to directly modify source code. See see Section 12.2, “DHCPv4 Server Configuration” for details.

Upon start, the server will open sockets on all interfaces that are not loopback, are up and running and - have IPv4 address. Support for multiple interfaces is not - coded in reception routines yet, so if you are running - this code on a machine that has many interfaces and - b10-dhcp4 happens to listen on wrong - interface, the easiest way to work around this problem is - to turn down other interfaces. This limitation will be - fixed shortly.

PRL (Parameter Request List, a list of options + have IPv4 address.

PRL (Parameter Request List, a list of options requested by a client) is currently ignored and server assigns DNS SERVER and DOMAIN NAME options.

b10-dhcp4 does not support BOOTP. That is a design choice. This limitation is @@ -1261,22 +1251,10 @@ const std::string HARDCODED_DNS_SERVER = "2001:db8:1::1";

14.1. Interface detection

Both DHCPv4 and DHCPv6 components share network interface detection routines. Interface detection is currently only supported on Linux systems.

For non-Linux systems, there is currently stub - implementation provided. As DHCP servers need to know available - addresses, there is a simple mechanism implemented to provide - that information. User is expected to create interfaces.txt - file. Format of this file is simple. It contains list of - interfaces along with available address on each interface. This - mechanism is temporary and is going to be removed as soon as - interface detection becomes available on non-Linux - systems. Here is an example of the interfaces.txt file: -

-# For DHCPv6, please specify link-local address (starts with fe80::)
-# If in doubt, check output of 'ifconfig -a' command.
-eth0 fe80::21e:8cff:fe9b:7349
-
-# For DHCPv4, please use following format:
-#eth0 192.0.2.5

14.2. DHCPv4/DHCPv6 packet handling

TODO: Describe packet handling here, with pointers to wiki

Chapter 15. Statistics

+ implementation provided. Interface manager detects loopback + interfaces only as their name (lo or lo0) can be easily predicted. + Please contact BIND10 development team if you are interested + in running DHCP components on systems other than Linux.

14.2. DHCPv4/DHCPv6 packet handling

TODO: Describe packet handling here, with pointers to wiki

Chapter 15. Statistics

The b10-stats process is started by bind10. It periodically collects statistics data from various modules @@ -1314,7 +1292,7 @@ eth0 fe80::21e:8cff:fe9b:7349 } }

Chapter 16. Logging

Table of Contents

16.1.1. Loggers
16.1.2. Output Options
16.1.3. Example session

16.1. Logging configuration

Chapter 16. Logging

Table of Contents

16.1.1. Loggers
16.1.2. Output Options
16.1.3. Example session