BIND 10 Guide

8.2.1. In-memory Data Source
8.2.2. In-memory Data Source With SQLite3 Backend
8.2.3. Reloading an In-memory Data Source
8.2.4. Disabling In-memory Data Sources

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
9.5. Incoming Transfers with In-memory Datasource

10. Outbound Zone Transfers

11. Dynamic DNS Update

11.1. Enabling Dynamic Update
11.2. Access Control
11.3. Miscellaneous Operational Issues

12. Recursive Name Server

12.1. Access Control
12.2. Forwarding

13. DHCPv4 Server

13.1. DHCPv4 Server Usage
13.2. DHCPv4 Server Configuration
13.3. Supported standards
13.4. DHCPv4 Server Limitations

14. DHCPv6 Server

14.1. DHCPv6 Server Usage
14.2. DHCPv6 Server Configuration
14.3. Supported DHCPv6 Standards
14.4. DHCPv6 Server Limitations

15. libdhcp++ library

15.1. Interface detection
15.2. DHCPv4/DHCPv6 packet handling

16. Statistics

17. Logging

17.1.1. Loggers
17.1.2. Output Options
17.1.3. Example session

2.2. Install Hierarchy

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 at Run-time
1.3. Starting and Stopping the Server
1.4. Managing BIND 10

2. Installation

2.1. Packages

2.3. Building Requirements

2.4. Quick start

2.5. Installation from source

2.5.1. Download Tar File
2.5.2. Retrieve from Git
2.5.3. Configure before the build
2.5.4. Build
2.5.5. Install

3. Starting BIND10 with bind10

3.1. Starting BIND 10
3.2. Configuration to start 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.2.1. In-memory Data Source
8.2.2. In-memory Data Source with SQLite3 Backend
8.2.3. Reloading an In-memory Data Source
8.2.4. Disabling In-memory Data Sources

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
9.5. Incoming Transfers with In-memory Datasource

10. Outbound Zone Transfers

11. Dynamic DNS Update

11.1. Enabling Dynamic Update
11.2. Access Control
11.3. Miscellaneous Operational Issues

12. Recursive Name Server

12.1. Access Control
12.2. Forwarding

13. DHCPv4 Server

13.1. DHCPv4 Server Usage
13.2. DHCPv4 Server Configuration
13.3. Supported standards
13.4. DHCPv4 Server Limitations

14. DHCPv6 Server

14.1. DHCPv6 Server Usage
14.2. DHCPv6 Server Configuration
14.3. Supported DHCPv6 Standards
14.4. DHCPv6 Server Limitations

15. libdhcp++ library

15.1. Interface detection
15.2. DHCPv4/DHCPv6 packet handling

16. Statistics

17. Logging

17.1.1. Loggers
17.1.2. Output Options
17.1.3. Example session

2.1. Building Requirements

List of Tables

3.1. Special startup components

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 at Run-time
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 - and provides a modular environment for serving and maintaining DNS. + BIND 10 is a rewrite of BIND 9 and ISC DHCP. + BIND 10 is written in C++ and Python and provides a modular + environment for serving, maintaining, and developing DNS and DHCP. BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server and a caching recursive name server which also provides forwarding. + It also provides experimental DHCPv4 and DHCPv6 servers.

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

1.1. Supported Platforms

+ BIND 10 version 20120712. +

1.1. Supported Platforms

BIND 10 builds have been tested on (in no particular order) - Debian GNU/Linux 5 and unstable, Ubuntu 9.10, NetBSD 5, + Debian GNU/Linux 6 and unstable, Ubuntu 9.10, NetBSD 5, Solaris 10 and 11, FreeBSD 7 and 8, CentOS Linux 5.3, MacOS 10.6 and 10.7, and OpenBSD 5.1. @@ -34,10 +36,17 @@ It is planned for BIND 10 to build, install and run on Windows and standard Unix-type platforms. -

1.2. Required Software

1.2. Required Software at Run-time

+ Running BIND 10 uses various extra software which may + not be provided in some operating systems' default + installations nor standard packages collections. You may + need to install this required software separately. + (For the build requirements, also see + Section 2.3, “Building Requirements”.) +

BIND 10 requires at least Python 3.1 (http://www.python.org/). - It has also been tested with Python 3.2. + It also works with Python 3.2.

BIND 10 uses the Botan crypto library for C++ (http://botan.randombit.net/). @@ -46,6 +55,7 @@ BIND 10 uses the log4cplus C++ logging library (http://log4cplus.sourceforge.net/). It requires at least log4cplus version 1.0.3. +

The authoritative DNS server uses SQLite3 (http://www.sqlite.org/). @@ -56,15 +66,8 @@ b10-xfrout, and b10-zonemgr components require the libpython3 library and the Python _sqlite3.so module (which is included with Python). - The b10-stats-httpd component uses the - Python pyexpat.so module. - The Python modules need to be built for the corresponding Python 3. -

Note

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

1.3. Starting and Stopping the Server

+ Python modules need to be built for the corresponding Python 3. +

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 @@ -106,8 +109,8 @@

b10-resolver — Recursive name server. - This process handles incoming queries. - + This process handles incoming DNS queries and provides + answers from its cache or by recursively doing remote lookups.

b10-sockcreator — Socket creator daemon. @@ -130,34 +133,33 @@ b10-xfrout — 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. + send a local zone to a remote secondary server.

b10-zonemgr — - Secondary manager. + Secondary zone 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. + These are ran by bind10 + and do not need to be manually started independently.

1.4. Managing BIND 10

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

bindctl — - interactive administration interface. + Interactive administration interface. This is a low-level command-line tool which allows a developer or an experienced administrator to control BIND 10.
b10-loadzone — - zone file loader. + Zone file loader. This tool will load standard masterfile-format zone files into BIND 10.
b10-cmdctl-usermgr — - user access control. + User access control. This tool allows an administrator to authorize additional users to manage BIND 10.

@@ -171,9 +173,57 @@ and, of course, DNS. These include detailed developer documentation and code examples. -

Chapter 2. Installation

Table of Contents

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

Chapter 2. Installation

Table of Contents

2.1. Packages

2.2. Install Hierarchy

2.3. Building Requirements

2.4. Quick start

2.5. Installation from source

2.5.1. Download Tar File
2.5.2. Retrieve from Git
2.5.3. Configure before the build
2.5.4. Build
2.5.5. Install

2.1. Packages

+ Some operating systems or softare package vendors may + provide ready-to-use, pre-built software packages for + the BIND 10 suite. + Installing a pre-built package means you do not need to + install build-only prerequisites and do not need to + make the software. +

+ FreeBSD ports, NetBSD pkgsrc, and Debian + testing package collections provide + all the prerequisite packages. +

2.2. Install Hierarchy

+ The following is the standard, common 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/doc/bind10-devel/ — + this guide and other supplementary documentation. +
+ share/man/ — + manual pages (online documentation). +
+ var/bind10-devel/ — + data source and configuration databases. +

2.3. Building Requirements

+ In addition to the run-time requirements (listed in + Section 1.2, “Required Software at Run-time”), building BIND 10 + from source code requires various development include headers and + program development tools.

Note

Some operating systems have split their distribution packages into a run-time and a development package. You will need to install @@ -196,9 +246,9 @@ 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.

- Visit the wiki at http://bind10.isc.org/wiki/SystemSpecificNotes + Visit the user-contributed wiki at http://bind10.isc.org/wiki/SystemSpecificNotes for system-specific installation tips. -

2.2. Quick start

Note

2.4. 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 @@ -227,34 +277,35 @@

$ b10-loadzone your.zone.example.org

Test the new zone. -

2.3. Installation from source

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

2.3.1. Download Tar File

+ It is freely available in source code form from ISC as a + downloadable tar file or via BIND 10's Git code revision control + service. (It may also be available in pre-compiled ready-to-use + packages from operating system vendors.) +

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

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

Note

- When using source code retrieved via Git additional + 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 + The latest development code (and 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 leading development is done in the “master” + branch.

The code can be checked out from git://git.bind10.isc.org/bind10; @@ -264,8 +315,8 @@

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. + generated configure script, Makefile.in files, nor their + related build files. They can be created by running autoreconf with the --install switch. This will run autoconf, @@ -274,14 +325,14 @@ autoheader, automake, and related commands. -

2.3.3. Configure before the build

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

$ ./configure

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

--prefix

Define the installation location (the default is /usr/local/). @@ -305,46 +356,16 @@

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

2.3.4. Build

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

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

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

Chapter 3. Starting BIND10 with bind10

Table of Contents

3.1. Starting BIND 10
3.2. Configuration of started processes

Note

The install step may require superuser privileges.

Chapter 3. Starting BIND10 with bind10

Table of Contents

3.1. Starting BIND 10
3.2. Configuration to start processes

BIND 10 provides the bind10 command which starts up the required processes. bind10 @@ -363,8 +384,9 @@ 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 b10-sockcreator will - allocate sockets for the rest of the system. + about other modules. The b10-sockcreator daemon + helps allocate Internet addresses and ports as needed for BIND 10 + network services.

In its default configuration, the bind10 master process will also start up @@ -380,56 +402,62 @@ 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. -

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

3.2. Configuration to start processes

+ The processes to be used can be configured for + bind10 to start, with the exception + of the required b10-sockcreator, + b10-msgq and b10-cfgmgr + components. + The configuration is in the Boss/components + section. Each element represents one component, which is + an abstraction of a process.

- The configuration is in the Boss/components section. Each element - represents one component, which is an abstraction of a process - (currently there's also one component which doesn't represent - a process). -

- To add a process to the set, let's say the resolver (which not started - by default), you would do this: + To add a process to the set, let's say the resolver (which + is not started by default), you would do this:

> config add Boss/components b10-resolver
 > config set Boss/components/b10-resolver/special resolver
 > config set Boss/components/b10-resolver/kind needed
 > config set Boss/components/b10-resolver/priority 10
 > config commit

- Now, what it means. We add an entry called b10-resolver. It is both a - name used to reference this component in the configuration and the - name of the process to start. Then we set some parameters on how to - start it. + Now, what it means. We add an entry called + “b10-resolver”. It is both a name used to + reference this component in the configuration and the name + of the process to start. Then we set some parameters on + how to start it.

- The special one is for components that need some kind of special care - 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)

+ The special setting is for components + that need some kind of special care during startup or + shutdown. Unless specified, the component is started in a + 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. Special startup components

Component	Special	Description
b10-auth	auth	Authoritative DNS server
b10-resolver	resolver	DNS resolver
b10-cmdctl	cmdctl	Command control (remote control interface)

- The kind specifies how a failure of the component should - be handled. If it is set to “dispensable” - (the default unless you set something else), it will get - started again if it fails. If it is set to “needed” - and it fails at startup, the whole bind10 - shuts down and exits with error exit code. But if it fails - some time later, it is just started again. If you set it - to “core”, you indicate that the system is - not usable without the component and if such component - fails, the system shuts down no matter when the failure - happened. This is the behaviour of the core components - (the ones you can't turn off), but you can declare any - other components as core as well if you wish (but you can - turn these off, they just can't fail). + The kind specifies how a failure of the + component should be handled. If it is set to + “dispensable” (the default unless you set + something else), it will get started again if it fails. If + it is set to “needed” and it fails at startup, + the whole bind10 shuts down and exits + with an error exit code. But if it fails some time later, it + is just started again. If you set it to “core”, + you indicate that the system is not usable without the + component and if such component fails, the system shuts + down no matter when the failure happened. This is the + behaviour of the core components (the ones you can't turn + off), but you can declare any other components as core as + well if you wish (but you can turn these off, they just + can't fail).

- The priority defines order in which the components should start. - The ones with higher number are started sooner than the ones with - lower ones. If you don't set it, 0 (zero) is used as the priority. - Usually, leaving it at the default is enough. + The priority defines order in which the + components should start. The ones with higher numbers are + started sooner than the ones with lower ones. If you don't + set it, 0 (zero) is used as the priority. Usually, leaving + it at the default is enough.

There are other parameters we didn't use in our example. - One of them is “address”. It is the address + One of them is address. It is the address used by the component on the b10-msgq message bus. The special components already know their address, but the usual ones don't. The address is by @@ -438,16 +466,12 @@ would have “Stats” as its address).

- The last one is process. It is the name of the process to be started. - It defaults to the name of the component if not set, but you can use - this to override it. + The last one is process. It is the name + of the process to be started. It defaults to the name of + the component if not set, but you can use this to override + it. (The special components also already know their + executable name.)

Note

- This system allows you to start the same component multiple times - (by including it in the configuration with different names, but the - same process setting). However, the rest of the system doesn't expect - such a situation, so it would probably not do what you want. Such - support is yet to be implemented. -

Note

The configuration is quite powerful, but that includes a lot of space for mistakes. You could turn off the b10-cmdctl, but then you couldn't @@ -464,7 +488,7 @@ In short, you should think twice before disabling something here.

It is possible to start some components multiple times (currently - b10-auth and b10-resolzer). + b10-auth and b10-resolver). You might want to do that to gain more performance (each one uses only single core). Just put multiple entries under different names, like this, with the same config: @@ -478,6 +502,9 @@ server will keep its own copy of in-memory data and there could be problems with locking the sqlite database, if used. The configuration might be changed to something more convenient in future. + Other components don't expect such a situation, so it would + probably not do what you want. Such support is yet to be + implemented.

Chapter 4. Command channel

The BIND 10 components use the b10-msgq message routing daemon to communicate with other BIND 10 components. @@ -492,9 +519,9 @@

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. + By default, BIND 10 uses a UNIX domain socket file named + /usr/local/var/bind10-devel/msg_socket + for this interprocess communication.

Chapter 5. Configuration manager

The configuration manager, b10-cfgmgr, handles all BIND 10 system configuration. It provides @@ -520,13 +547,12 @@ 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 + (The directory 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 @@ -602,15 +628,16 @@ redefined by using the --idle-timeout command line argument.

6.1. 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 + accounts_file which defines the path to the + user accounts database (the default is + /usr/local/etc/bind10-devel/cmdctl-accounts.csv); + cert_file which defines the path to the + PEM certificate file (the default is + /usr/local/etc/bind10-devel/cmdctl-certfile.pem); + and + key_file which defines the path to the + PEM private key file (the default is + /usr/local/etc/bind10-devel/cmdctl-keyfile.pem).

Chapter 7. Control and configure user interface

Note

For this development prototype release, bindctl is the only user interface. It is expected that upcoming @@ -634,12 +661,13 @@ 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.2.1. In-memory Data Source
8.2.2. In-memory Data Source With SQLite3 Backend
8.2.3. Reloading an In-memory Data Source
8.2.4. Disabling In-memory Data Sources

Chapter 8. Authoritative Server

Table of Contents

8.2.1. In-memory Data Source
8.2.2. In-memory Data Source with SQLite3 Backend
8.2.3. Reloading an In-memory Data Source
8.2.4. Disabling In-memory Data Sources

The b10-auth is the authoritative DNS server. - It supports EDNS0 and DNSSEC. It supports IPv6. + It supports EDNS0, DNSSEC, IPv6, and SQLite3 and in-memory zone + data backends. Normally it is started by the bind10 master process. -

8.1. Server Configurations

b10-auth is configured via the b10-cfgmgr configuration manager. The module name is “Auth”. @@ -648,8 +676,8 @@ shutdown

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. +Note: This may be a temporary setting because the DNS server +can use various data source backends.
datasources: datasources configures data sources. The list items include: @@ -660,7 +688,9 @@ This may be a temporary setting until then. and zones to define the file path name, - the filetype (e.g., sqlite3), + the filetype (“sqlite3” to load + from a SQLite3 database file or “text” to + load from a master text file), and the origin (default domain). By default, this is empty. @@ -736,7 +766,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. @@ -767,8 +797,8 @@ This may be a temporary setting until then. > config commit

The authoritative server will begin serving it immediately - after it is loaded. -

8.2.2. In-memory Data Source With SQLite3 Backend

+ after the zone data is loaded from the master text file. +

8.2.2. In-memory Data Source with SQLite3 Backend

The following commands to bindctl provide an example of configuring an in-memory data @@ -786,7 +816,7 @@ This may be a temporary setting until then. > config commit

The authoritative server will begin serving it immediately - after it is loaded. + after the zone data is loaded from the database file.

8.2.3. Reloading an In-memory Data Source

Use the Auth loadzone command in bindctl to reload a changed master @@ -815,7 +845,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

RFC 1035 style DNS master zone files may imported into a BIND 10 SQLite3 data source by using the b10-loadzone utility. @@ -844,7 +874,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
9.5. Incoming Transfers with In-memory Datasource

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
9.5. Incoming Transfers with In-memory Datasource

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 @@ -852,13 +882,13 @@ This may be a temporary setting until then. b10-auth. In combination with b10-zonemgr (for automated SOA checks), this allows the BIND 10 server to - provide “secondary” service. + provide secondary service.

The b10-xfrin process supports both AXFR and IXFR. Due to some implementation limitations of the current development release, however, it only tries AXFR by default, and care should be taken to enable IXFR. -

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 @@ -874,7 +904,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 @@ -916,23 +946,20 @@ This may be a temporary setting until then.

> config add Zonemgr/secondary_zones
 > config set Zonemgr/secondary_zones[0]/name "example.com"
-> config set Zonemgr/secondary_zones[0]/class "IN"
 > config commit

- -

If the zone does not exist in the data source already (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:

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

9.5. Incoming Transfers with In-memory Datasource

In the case of an incoming zone transfer, the received zone is first stored in the corresponding BIND 10 datasource. In case the secondary zone is served by an in-memory datasource @@ -943,14 +970,14 @@ This may be a temporary setting until then. The administrator doesn't have to do anything for b10-auth to serve the new version of the zone, except for the configuration such as the one described in - Section 8.2.2, “In-memory Data Source With SQLite3 Backend”. + Section 8.2.2, “In-memory Data Source with SQLite3 Backend”.

Chapter 10. Outbound Zone Transfers

The b10-xfrout process is started by bind10. When the b10-auth authoritative DNS server receives an AXFR or IXFR request, b10-auth internally forwards the request to b10-xfrout, - which handles the rest of request processing. + which handles the rest of this request processing. This is used to provide primary DNS service to share zones to secondary name servers. The b10-xfrout is also used to send @@ -983,11 +1010,12 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

"key.example", you'll need to do this:

> config set tsig_keys/keys ["key.example:<base64-key>"]
 > config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}]
-> config commit

Both Xfrout and Auth will use the system wide keyring to check - TSIGs in the incoming messages and to sign responses.

Note

+> config commit

Both b10-xfrout and b10-auth + will use the system wide keyring to check + 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. Dynamic DNS Update

Table of Contents

11.1. Enabling Dynamic Update
11.2. Access Control
11.3. Miscellaneous Operational Issues

Chapter 11. Dynamic DNS Update

Table of Contents

11.1. Enabling Dynamic Update
11.2. Access Control
11.3. Miscellaneous Operational Issues

BIND 10 supports the server side of the Dynamic DNS Update (DDNS) protocol as defined in RFC 2136. This service is provided by the b10-ddns @@ -997,17 +1025,17 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

When the b10-auth authoritative DNS server receives an UPDATE request, it internally forwards the request to b10-ddns, which handles the rest of - request processing. - When the processing is completed b10-ddns - will send a response to the client with the RCODE set to the - value as specified in RFC 2136 (NOERROR for successful update, - REFUSED if rejected due to ACL check, etc). + this request processing. + When the processing is completed, b10-ddns + will send a response to the client as specified in RFC 2136 + (NOERROR for successful update, REFUSED if rejected due to + ACL check, etc). If the zone has been changed as a result, it will internally notify b10-xfrout so that other secondary - servers will be notified via the DNS notify protocol. + servers will be notified via the DNS NOTIFY protocol. In addition, if b10-auth serves the updated zone from its in-memory cache (as described in - Section 8.2.2, “In-memory Data Source With SQLite3 Backend”), + Section 8.2.2, “In-memory Data Source with SQLite3 Backend”), b10-ddns will also notify b10-auth so that b10-auth will re-cache the updated zone content. @@ -1026,15 +1054,15 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

As of this writing b10-ddns does not support update forwarding for secondary zones. If it receives an update request for a secondary zone, it will - immediately return a response with an RCODE of NOTIMP. + immediately return a “not implemented” response.

Note

- For feature completeness update forwarding should be - eventually supported. But right now it's considered a lower + For feature completeness, update forwarding should be + eventually supported. But currently it's considered a lower priority task and there is no specific plan of implementing this feature.

11.1. Enabling Dynamic Update

First off, it must be made sure that a few components on which b10-ddns depends are configured to run, which are b10-auth @@ -1052,9 +1080,9 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

underlying data source storing the zone data be writable. In the current implementation this means the zone must be stored in an SQLite3-based data source. - Also, right now, the b10-ddns component - configures itself with the data source referring to the - “database_file” configuration parameter of + Also, in this development version, the b10-ddns + component configures itself with the data source referring to the + database_file configuration parameter of b10-auth. So this information must be configured correctly before starting b10-ddns. @@ -1084,24 +1112,25 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

> config commit

Note

- In theory "kind" could be omitted because "dispensable" is its - default. But there's some peculiar behavior (which should - be a bug and should be fixed eventually; see Trac ticket - #2064) with bindctl and you'll still need to specify that explicitly. - Likewise, "address" may look unnecessary because - b10-ddns would start and work without - specifying it. But for it to shutdown gracefully this - parameter should also be specified. + In theory kind could be omitted because + "dispensable" is its default. + But there's some peculiar behavior (which should be a + bug and should be fixed eventually; see Trac ticket #2064) + with bindctl and you'll still need to + specify that explicitly. Likewise, address + may look unnecessary because b10-ddns + would start and work without specifying it. But for it + to shutdown gracefully this parameter should also be + specified.

11.2. Access Control

- By default b10-ddns rejects any update - requests from any clients by returning a response with an RCODE - of REFUSED. +

11.2. Access Control

+ By default, b10-ddns rejects any update + requests from any clients by returning a REFUSED response. To allow updates to take effect, an access control rule (called update ACL) with a policy allowing updates must explicitly be configured. Update ACL must be configured per zone basis in the - “zones” configuration parameter of + zones configuration parameter of b10-ddns. This is a list of per-zone configurations regarding DDNS. Each list element consists of the following parameters: @@ -1115,14 +1144,12 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)

In general, an update ACL rule that allows an update request should be configured with a TSIG key. This is an example update ACL that allows updates to the zone - named “example.org” of RR class “IN” + named “example.org” (of default RR class “IN”) from clients that send requests signed with a TSIG whose key name is "key.example.org" (and refuses all others):

 > config add DDNS/zones
 > config set DDNS/zones[0]/origin example.org
-> config set DDNS/zones[0]/class IN
-(Note: "class" can be omitted)
 > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}
 > config commit

@@ -1145,11 +1172,13 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. > config commit

(Note the "add" in the first line. Before this sequence, we - have had only entry in zones[0]/update_acl. The "add" command - with a value (rule) adds a new entry and sets it to the given rule. + have had only entry in zones[0]/update_acl. + The add command with a value (rule) adds + a new entry and sets it to the given rule. + Due to a limitation of the current implementation, it doesn't work if you first try to just add a new entry and then set it to - a given rule). + a given rule.)

Note

The b10-ddns component accepts an ACL rule that just allows updates from a specific IP address @@ -1192,10 +1221,10 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. arbitrary clients. There have been other troubles that could have been avoided if the ACL could be checked before the prerequisite check. -

11.3. Miscellaneous Operational Issues

Unlike BIND 9, BIND 10 currently does not support automatic - resigning of DNSSEC-signed zone when it's updated via DDNS. - It could be possible to resign the updated zone afterwards + re-signing of DNSSEC-signed zone when it's updated via DDNS. + It could be possible to re-sign the updated zone afterwards or make sure the update request also updates related DNSSEC records, but that will be pretty error-prone operation. In general, it's not advisable to allow DDNS for a signed zone @@ -1215,8 +1244,8 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. b10-zonemgr. Zones listed in “secondary_zones” will never be updated via DDNS regardless of the update ACL configuration; - b10-ddns will return a response with an - RCODE of NOTAUTH as specified in RFC 2136. + b10-ddns will return a NOTAUTH (server + not authoritative for the zone) response. If you have a "conceptual" secondary zone whose content is a copy of some external source but is not updated via the standard zone transfers and therefore not listed in @@ -1234,7 +1263,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. IXFR. This is done automatically; it does not require specific configuration to make this possible. -

Chapter 12. Recursive Name Server

Table of Contents

12.1. Access Control
12.2. Forwarding

Chapter 12. Recursive Name Server

Table of Contents

12.1. Access Control
12.2. Forwarding

The b10-resolver process is started by bind10. @@ -1268,7 +1297,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.

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

12.1. Access Control

+ Resolver/listen_on” if needed.)

12.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 @@ -1301,7 +1330,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.

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

Note

This prototype access control configuration - syntax may be changed.

12.2. Forwarding

+ syntax may be changed.

12.2. Forwarding

To enable forwarding, the upstream address and port must be configured to forward queries to, such as: @@ -1592,7 +1621,7 @@ const std::string HARDCODED_DNS_SERVER = "2001:db8:1::1";

} }

Chapter 17. Logging

Table of Contents

17.1.1. Loggers
17.1.2. Output Options
17.1.3. Example session

17.1. Logging configuration

Chapter 17. Logging

Table of Contents

17.1.1. Loggers
17.1.2. Output Options
17.1.3. Example session