                                 BIND 10 Guide

Administrator Reference for BIND 10

   This is the reference guide for BIND 10 version 20140313.

   Copyright © 2010-2013 Internet Systems Consortium, Inc.

   Abstract

   BIND 10 is a framework that features Domain Name System (DNS) suite and
   Dynamic Host Configuration Protocol (DHCP) servers with development
   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 (codenamed Kea).

   This is the reference guide for BIND 10 version 20140313. 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

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

                2.1. Quick start guide for authoritative DNS service

   3. Installation

                3.1. Packages

                3.2. Install Hierarchy

                3.3. Building Requirements

                3.4. Installation from source

                             3.4.1. Download Tar File

                             3.4.2. Retrieve from Git

                             3.4.3. Configure before the build

                             3.4.4. Build

                             3.4.5. Install

   4. Starting BIND 10 with bind10

                4.1. Starting BIND 10

   5. Command channel

   6. Configuration manager

   7. Remote control daemon

                7.1. Configuration specification for b10-cmdctl

   8. Control and configure user interface

                8.1. bindctl command-line options

                8.2. General syntax of bindctl commands

                8.3. Bindctl help

                8.4. Command arguments

                8.5. Module commands

                8.6. Configuration commands

                             8.6.1. List of configuration commands

                             8.6.2. Configuration data types

                8.7. The execute command

                             8.7.1. Execute directives

                             8.7.2. Notes on execute scripts

   9. Common configuration elements

                9.1. TSIG keys

                             9.1.1. Key anatomy and syntax

                             9.1.2. Key ring

                9.2. ACLs

                             9.2.1. Matching properties

                             9.2.2. More complicated matches

                             9.2.3. Examples

                             9.2.4. Interaction with bindctl

   10. bind10 Control and Configuration

                10.1. Stopping bind10

                10.2. Configuration to start processes

   11. Authoritative Server

                11.1. Server Configurations

                11.2. Data Source Backends

                             11.2.1. Data source types

                             11.2.2. Examples

                             11.2.3. Adding a static data source

                11.3. Loading Master Zones Files

   12. Incoming Zone Transfers

                12.1. Configuration for Incoming Zone Transfers

                12.2. TSIG

                12.3. Control the use of IXFR

                12.4. Secondary Manager

                12.5. Trigger an Incoming Zone Transfer Manually

                12.6. Incoming Transfers with In-memory Datasource

   13. Outbound Zone Transfers

   14. Dynamic DNS Update

                14.1. Enabling Dynamic Update

                14.2. Access Control

                14.3. Miscellaneous Operational Issues

   15. Recursive Name Server

                15.1. Access Control

                15.2. Forwarding

   16. DHCP

                16.1. DHCP Database Installation and Configuration

                             16.1.1. Install MySQL

                             16.1.2. Build and Install BIND 10

                             16.1.3. Create MySQL Database and BIND 10 User

   17. The DHCPv4 Server

                17.1. Starting and Stopping the DHCPv4 Server

                17.2. Configuring the DHCPv4 Server

                             17.2.1. Database Configuration

                             17.2.2. Interface selection

                             17.2.3. Configuration of IPv4 Address Pools

                             17.2.4. Standard DHCPv4 options

                             17.2.5. Custom DHCPv4 options

                             17.2.6. DHCPv4 vendor specific options

                             17.2.7. Nested DHCPv4 options (custom option
                             spaces)

                             17.2.8. Client Classification in DHCPv4

                             17.2.9. Limiting access to IPv4 subnet to
                             certain classes

                             17.2.10. Configuring DHCPv4 for DDNS

                17.3. Server Identifier in DHCPv4

                17.4. Next server (siaddr)

                17.5. Echoing client-id (RFC6842)

                17.6. How DHCPv4 server selects subnet for a client

                17.7. Using specific relay agent for a subnet

                17.8. Segregating IPv4 clients in a cable network

                17.9. Supported Standards

                17.10. DHCPv4 Server Limitations

   18. The DHCPv6 Server

                18.1. Starting and Stopping the DHCPv6 Server

                18.2. DHCPv6 Server Configuration

                             18.2.1. Database Configuration

                             18.2.2. Interface selection

                             18.2.3. Unicast traffic support

                             18.2.4. Subnet and Address Pool

                             18.2.5. Subnet and Prefix Delegation Pools

                             18.2.6. Standard DHCPv6 options

                             18.2.7. Custom DHCPv6 options

                             18.2.8. DHCPv6 vendor specific options

                             18.2.9. Nested DHCPv6 options (custom option
                             spaces)

                             18.2.10. IPv6 Subnet Selection

                             18.2.11. DHCPv6 Relays

                             18.2.12. Client Classification in DHCPv6

                             18.2.13. Limiting access to IPv6 subnet to
                             certain classes

                             18.2.14. Configuring DHCPv6 for DDNS

                18.3. Server Identifier in DHCPv6

                18.4. Using specific relay agent for a subnet

                18.5. Segregating IPv6 clients in a cable network

                18.6. Supported Standards

                18.7. DHCPv6 Server Limitations

   19. The DHCP-DDNS Server

                19.1. Starting and Stopping the DHCP-DDNS Server

                19.2. Configuring the DHCP-DDNS Server

                             19.2.1. General Server Parameters

                             19.2.2. TSIG Key List

                             19.2.3. Forward DDNS

                             19.2.4. Reverse DDNS

                             19.2.5. Example DHCP-DDNS Server Configuration

   20. libdhcp++ library

                20.1. Interface detection and Socket handling

   21. Statistics

   22. Logging

                22.1. Logging configuration

                             22.1.1. Loggers

                             22.1.2. Output Options

                             22.1.3. Example session

                22.2. Logging Message Format

   List of Tables

   10.1. Special startup components

   17.1. List of standard DHCPv4 options

   17.2. List of standard DHCPv4 options (continued)

   17.3. List of standard DHCP option types

   17.4. Default FQDN Flag Behavior

   18.1. List of standard DHCPv6 options

   18.2. Default FQDN Flag Behavior

   19.1. Our example network

   19.2. Forward DDNS Domains Needed

   19.3. Reverse DDNS Domains Needed

                                    Preface

   Table of Contents

   1. Acknowledgements

1. Acknowledgements

   BIND 10 is a sponsored development project, and would not be possible
   without the generous support of the sponsors.

   JPRS and CIRA are Patron Level sponsors.

   AFNIC, CNNIC, CZ.NIC, DENIC eG, Google, RIPE NCC, Registro.br, .nz
   Registry Services, and Technical Center of Internet are current sponsors.

   Afilias, IIS.SE, Nominet, and SIDN were founding sponsors of the project.

   Support for BIND 10 development of the DHCPv4 and DHCPv6 components is
   provided 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 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 BIND 10 version 20140313.

1.1. Supported Platforms

   BIND 10 builds have been tested on (in no particular order) 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.
   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.

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 3.3, “Building
   Requirements”.)

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

   BIND 10 uses the Botan crypto library for C++
   (http://botan.randombit.net/). It requires at least Botan version 1.8.

   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/). It
   needs at least SQLite version 3.3.9.

   The b10-ddns, b10-xfrin, b10-xfrout, and b10-zonemgr components require
   the libpython3 library and the Python _sqlite3.so module (which is
   included with Python). 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 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 by running a single command, bind10. This
   command starts a master process, b10-init, which will start other required
   processes and other processes when configured. The processes that may be
   started have names starting with "b10-", including:

     * b10-auth — Authoritative DNS server. This process serves DNS requests.
     * b10-cfgmgr — Configuration manager. This process maintains all of the
       configuration for BIND 10.
     * b10-cmdctl — Command and control service. This process allows external
       control of the BIND 10 system.
     * b10-ddns — Dynamic DNS update service. This process is used to handle
       incoming DNS update requests to allow granted clients to update zones
       for which BIND 10 is serving as a primary server.
     * b10-msgq — Message bus daemon. This process coordinates communication
       between all of the other BIND 10 processes.
     * b10-resolver — Recursive name server. This process handles incoming
       DNS queries and provides answers from its cache or by recursively
       doing remote lookups. (This is an experimental proof of concept.)
     * b10-sockcreator — Socket creator daemon. This process creates sockets
       used by network-listening BIND 10 processes.
     * b10-stats — Statistics collection daemon. This process collects and
       reports statistics data.
     * b10-stats-httpd — HTTP server for statistics reporting. This process
       reports statistics data in XML format over HTTP.
     * b10-xfrin — Incoming zone transfer service. This process is used to
       transfer a new copy of a zone into BIND 10, when acting as a secondary
       server.
     * b10-xfrout — Outgoing zone transfer service. This process is used to
       handle transfer requests to send a local zone to a remote secondary
       server.
     * b10-zonemgr — Secondary zone manager. This process keeps track of
       timers and other necessary information for BIND 10 to act as a slave
       server.

   These 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. 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. This tool will load standard
       masterfile-format zone files into BIND 10.
     * b10-cmdctl-usermgr — User access control. This tool allows an
       administrator to authorize additional users to manage BIND 10.

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

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

                             Chapter 2. Quick start

   Table of Contents

   2.1. Quick start guide for authoritative DNS service

   This quickly covers the standard steps for installing and deploying BIND
   10. For further details, full customizations, and troubleshooting, see the
   respective chapters in the BIND 10 guide.

2.1. Quick start guide for authoritative DNS service

    1. Install required run-time and build dependencies.
    2. Download the BIND 10 source tar file from
       ftp://ftp.isc.org/isc/bind10/.
    3. Extract the tar file:

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

    4. Go into the source and run configure:

 $ cd bind10-VERSION
 $ ./configure

    5. Build it:

 $ make

    6. Install it as root (by default to prefix /usr/local/):

 $ make install

    7. Change directory to the install prefix (by default /usr/local/):

 $ cd /usr/local/

    8. Create a user for yourself:

 $ sbin/b10-cmdctl-usermgr add root

       and enter a newly chosen password when prompted.

    9. Start the server (as root):

 $ sbin/bind10

   10. DNS and DHCP components are not started in the default configuration.
       In another console, enable the authoritative DNS service (by using the
       bindctl utility to configure the b10-auth component to run):

 $ bin/bindctl

       (Login with the username and password you used above to create a
       user.)

 > config add Init/components b10-auth
 > config set Init/components/b10-auth/special auth
 > config set Init/components/b10-auth/kind needed
 > config commit
 > quit


   11. Test it; for example:

 $ dig @127.0.0.1 -c CH -t TXT version.bind

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

 $ bin/b10-loadzone -c '{"database_file": "/usr/local/var/bind10/zone.sqlite3"}' your.zone.example.org your.zone.file

       (If you use the sqlite3 data source with the default DB file, you can
       omit the -c option).
   13. Test the new zone.

                            Chapter 3. Installation

   Table of Contents

   3.1. Packages

   3.2. Install Hierarchy

   3.3. Building Requirements

   3.4. Installation from source

                3.4.1. Download Tar File

                3.4.2. Retrieve from Git

                3.4.3. Configure before the build

                3.4.4. Build

                3.4.5. Install

3.1. Packages

   Some operating systems or software 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.

3.2. Install Hierarchy

   The following is the standard, common layout of the complete BIND 10
   installation:

     * bin/ — general tools and diagnostic clients.
     * etc/bind10/ — configuration files.
     * lib/ — libraries and python modules.
     * libexec/bind10/ — 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 b10-init master process.
     * sbin/ — commands used by the system administrator.
     * share/bind10/ — configuration specifications.
     * share/doc/bind10/ — this guide and other supplementary documentation.
     * share/man/ — manual pages (online documentation).
     * var/bind10/ — data source and configuration databases.

3.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 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
   (http://www.boost.org/). At least Boost version 1.35 is required.

   To build BIND 10, also install the Botan (at least version 1.8) and the
   log4cplus (at least version 1.0.3) development include headers.

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

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

3.4. Installation from source

   BIND 10 is open source software written in C++ and Python. 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.)

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

  3.4.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 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 (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” branch.

   The code can be checked out from git://git.bind10.isc.org/bind10; for
   example:

 $ git clone git://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
   their related build files. They can be created by running autoreconf with
   the --install switch. This will run autoconf, aclocal, libtoolize,
   autoheader, automake, and related commands.

  3.4.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. Some
   commonly-used options are:

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

   --with-boost-include
           Define the path to find the Boost headers.

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

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

   --without-werror
           Disable the default use of the -Werror compiler flag so that
           compiler warnings aren't build failures.

  Note

   For additional instructions concerning the building and installation of
   BIND 10 DHCP, see Section 16.1, “DHCP Database Installation and
   Configuration”.

   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.

  3.4.4. Build

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

 $ make

  3.4.5. Install

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

 $ make install

   Please don't use any form of parallel or job server options (such as GNU
   make's -j option) when performing this step. Doing so may cause errors.

  Note

   The install step may require superuser privileges.

   If required, run ldconfig as root with /usr/local/lib (or with
   ${prefix}/lib if configured with --prefix) in /etc/ld.so.conf (or the
   relevant linker cache configuration file for your OS):

 $ ldconfig

  Note

   If you do not run ldconfig where it is required, you may see errors like
   the following:

               program: error while loading shared libraries: libb10-something.so.1:
               cannot open shared object file: No such file or directory


                    Chapter 4. Starting BIND 10 with bind10

   Table of Contents

   4.1. Starting BIND 10

   BIND 10 is started with the bind10 command. It runs the b10-init daemon
   which starts up the required processes, and will also restart some
   processes that exit unexpectedly. bind10 is the only command needed to
   start the BIND 10 system.

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

   The b10-sockcreator, 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
   b10-sockcreator daemon helps allocate Internet addresses and ports as
   needed for BIND 10 network services.

   In its default configuration, the b10-init master process will also start
   up b10-cmdctl for administration tools to communicate with the system, and
   b10-stats for statistics collection. The DNS and DHCP servers are not
   started by default. The configuration of components to start is covered in
   Section 10.2, “Configuration to start processes”.

4.1. Starting BIND 10

   To start the BIND 10 service, simply run bind10 as root. It will run in
   the foreground and your shell prompt will not be available. It will output
   various log messages as it starts up and is used. Run it with the
   --verbose switch to get additional debugging or diagnostic output.

  Note

   If the setproctitle Python module is detected at start up, 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.

                           Chapter 5. Command channel

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

   Administrators do not communicate directly with the b10-msgq daemon. By
   default, BIND 10 uses a UNIX domain socket file named
   /usr/local/var/bind10/msg_socket for this interprocess communication.

                        Chapter 6. Configuration manager

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

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

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

  Note

   The current release only provides 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/b10-config.db.
   (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 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 b10-init master process (as covered in Chapter 4, Starting BIND 10
   with bind10).

                        Chapter 7. Remote control daemon

   Table of Contents

   7.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 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/cmdctl-keyfile.pem. (A sample
   key is at /usr/local/share/bind10/cmdctl-keyfile.pem.) It also uses a
   certificate located at /usr/local/etc/bind10/cmdctl-certfile.pem. (A
   sample certificate is at /usr/local/share/bind10/cmdctl-certfile.pem.)
   This may be a self-signed certificate or purchased from a certification
   authority.

  Note

   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/cmdctl-accounts.csv. This comma-delimited file lists
   the accounts with a user name, hashed password, and salt.

   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 times out in 1200 seconds by default. This can
   be redefined by using the --idle-timeout command line argument.

7.1. Configuration specification for b10-cmdctl

   The configuration items for b10-cmdctl are: accounts_file which defines
   the path to the user accounts database (the default is
   /usr/local/etc/bind10/cmdctl-accounts.csv); cert_file which defines the
   path to the PEM certificate file (the default is
   /usr/local/etc/bind10/cmdctl-certfile.pem); and key_file which defines the
   path to the PEM private key file (the default is
   /usr/local/etc/bind10/cmdctl-keyfile.pem).

                Chapter 8. Control and configure user interface

   Table of Contents

   8.1. bindctl command-line options

   8.2. General syntax of bindctl commands

   8.3. Bindctl help

   8.4. Command arguments

   8.5. Module commands

   8.6. Configuration commands

                8.6.1. List of configuration commands

                8.6.2. Configuration data types

   8.7. The execute command

                8.7.1. Execute directives

                8.7.2. Notes on execute scripts

  Note

   For the current 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.

  Note

   bindctl has an internal command history, as well as tab-completion for
   most of the commands and arguments. However, these are only enabled if the
   python readline module is available on the system. If not, neither of
   these features will be supported.

   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.

8.1. bindctl command-line options

   -a <address>, --address=<address>
           IP address that BIND 10's b10-cmdctl module is listening on. By
           default, this is 127.0.0.1.

   -c <certificate file>, --certificate-chain=<certificate file>
           PEM-formatted server certificate file. When this option is given,
           bindctl will verify the server certificate using the given file as
           the root of the certificate chain. If not specified, bindctl does
           not validate the certificate.

   --csv-file-dir=<csv file>
           bindctl stores the username and password for logging in in a file
           called default_user.csv; this option specifies the directory where
           this file is stored and read from. When not specified, ~/.bind10/
           is used.

  Note

           Currently, this file contains an unencrypted password.

   -h, --help
           Shows a short overview of the command-line options of bindctl, and
           exits.

   --version
           Shows the version of bindctl, and exits.

   -p <port number>, --port=<port number>
           Port number that BIND 10's b10-cmdctl module is listening on. By
           default, this is port 8080.

8.2. General syntax of bindctl commands

   The bindctl tool is an interactive command-line tool, with dynamic
   commands depending on the BIND 10 modules that are running. There are a
   number of fixed commands that have no module and that are always
   available. The general syntax of a command is

 <module> <command> [argument(s)]

   For example, the Init module has a 'shutdown' command to shut down BIND
   10, with an optional argument 'help':

 > Init shutdown help
 Command  shutdown       (Shut down BIND 10)
                 help (Get help for command)
 This command has no parameters


   There are no mandatory arguments, only the optional 'help'.

8.3. Bindctl help

   help is both a command and an option that is available to all other
   commands. When run as a command directly, it shows the available modules.

 > help
 usage: <module name> <command name> [param1 = value1 [, param2 = value2]]
 Type Tab character to get the hint of module/command/parameters.
 Type "help(? h)" for help on bindctl.
 Type "<module_name> help" for help on the specific module.
 Type "<module_name> <command_name> help" for help on the specific command.

 Available module names:
 (list of modules)


   When 'help' is used as a command to a module, it shows the supported
   commands for the module; for example:

 > Init help
 Module  Init    Master process
 Available commands:
     help        Get help for module.
     shutdown    Shut down BIND 10
     ping        Ping the Init process
     show_processes
             List the running BIND 10 processes


   And when added to a module command, it shows the description and
   parameters of that specific command; for example:

 > Auth loadzone help
 Command  loadzone       ((Re)load a specified zone)
                 help (Get help for command)
 Parameters:
     class (string, optional)
     origin (string, mandatory)


8.4. Command arguments

   Commands can have arguments, which can be either optional or mandatory.
   They can be specified by name (e.g. <command> <argument name>=<argument
   value>), or positionally, (e.g. <command> <argument value 1> <argument
   value 2>).

   <command> help shows the arguments a command supports and which of those
   are mandatory, and in which order the arguments are expected if positional
   arguments are used.

   For example, the loadzone command of the Auth module, as shown in the last
   example of the previous section, has two arguments, one of which is
   optional. The positional arguments in this case are class first and origin
   second; for example:

 > Auth loadzone IN example.com.

   But since the class is optional (defaulting to IN), leaving it out works
   as well:

 > Auth loadzone example.com.

   The arguments can also be provided with their names, in which case the
   order does not matter:

 > Auth loadzone origin="example.com." class="IN"

8.5. Module commands

   Each module has its own set of commands (if any), which will only be
   available if the module is running. For instance, the Auth module has a
   loadzone command. The commands a module provides are documented in this
   guide in the section of that module or in the module's corresponding
   manual page.

8.6. Configuration commands

   Configuration commands are used to view and change the configuration of
   BIND 10 and its modules. Module configuration is only shown if that module
   is running, but similar to commands, there are a number of top-level
   configuration items that are always available (for instance tsig_keys and
   data_sources). Configuration changes (set, unset, add and remove) are done
   locally first, and have no immediate effect. The changes can be viewed
   with config diff, and either reverted (config revert), or committed
   (config commit). In the latter case, all local changes are submitted to
   the configuration manager, which verifies them, and if they are accepted,
   applied and saved in persistent storage. When identifying items in
   configuration commands, the format is

 Module/example/item

   Sub-elements of names, lists and sets (see Section 8.6.2, “Configuration
   data types”) are separated with the '/' character, and list indices are
   identified with [<index>]; for example:

 Module/example/list[2]/foo

  8.6.1. List of configuration commands

   The following configuration commands are available:

   show [all] [item name]
           Shows the current configuration of the given item. If 'all' is
           given, it will recurse through the entire set, and show every
           nested value.

   show_json [item name]
           Shows the full configuration of the given item in JSON format.

   add <item name> [value]
           Add an entry to configuration list or a named set (see
           Section 8.6.2, “Configuration data types”). When adding to a list,
           the command has one optional argument, a value to add to the list.
           The value must be in correct JSON and complete. When adding to a
           named set, it has one mandatory parameter (the name to add), and
           an optional parameter value, similar to when adding to a list. In
           either case, when no value is given, an entry will be constructed
           with default values.

   remove
           Remove an item from a configuration list or a named set. When
           removing an item for a list, either the index needs to be
           specified, or the complete value of the element to remove must be
           specified (in JSON format).

   set <item name> <value>
           Directly set the value of the given item to the given value.

   unset <item name>
           Remove any user-specified value for the given item.

   diff
           Show all current local changes that have not been committed yet.

   revert
           Revert all local changes without committing them.

   commit
           Send all local changes to the configuration manager, which will
           validate them, and apply them if validation succeeds.

   go
           Go to a specific configuration part, similar to the 'cd' command
           in a shell.

  Note

           There are a number of problems with the current implementation of
           go within bindctl, and we recommend not using it for general
           cases.

  8.6.2. Configuration data types

   Configuration data can be of different types, which can be modified in
   ways that depend on the types. There are a few syntax restrictions on
   these types, but only basic ones. Modules may impose additional
   restrictions on the values of elements.

   integer
           A basic integer; can be set directly with config set, to any
           integer value. The value must not be quoted, or else, it will be
           parsed as a string.

   real
           A basic floating point number; can be set directly with config
           set, to any floating point value. The value must not be quoted, or
           else, it will be parsed as a string.

   boolean
           A basic boolean value; can be set directly with config set, to
           either true or false. The value must not be quoted, or else, it
           will be parsed as a string. Integer values are not allowed.

   string
           A basic string value; can be set directly with config set to any
           string. Double quotation marks are optional.

   null
           This is a special type representing 'no value at all'; usable in
           compound structures that have optional elements that are not set.

   maps

           Maps are (pre-defined) compound collections of other elements of
           any other type. They are not usually modified directly, but their
           elements are. Every top-level element for a module is a map
           containing the configuration values for that map, which can
           themselves be maps again. For instance, the Auth module
           configuration is a map containing the elements 'listen_on' (list)
           and 'tcp_recv_timeout' (integer). When changing one of its values,
           they can be modified directly with config set
           Auth/tcp_recv_timeout 3000.

           Some map entries are optional. If they are, and currently have a
           value, the value can be unset by using either config unset <item
           name> or config set <item name> null.

           Maps can be modified as a whole, but using the full JSON
           representation of the entire map to set. Since this involves a lot
           of text, this is usually not recommended.

           Another example is the Logging virtual module, which is, like any
           module, a map, but it only contains one element: a list of
           loggers. Normally, an administrator would only modify that list
           (or its elements) directly, but it is possible to set the entire
           map in one command; for example: config set Logging { "loggers":
           [] }

   list

           A list is a compound list of other elements of the same type.
           Elements can be added with config add <list name> [value], and
           removed with config remove <list name> [value] or config remove
           <list name><index>. The index is of the form square bracket,
           number, square bracket (e.g. [0]), and it immediately follows the
           list name (there is no separator or space between them). List
           indices start with 0 for the first element.

           For addition, if the value is omitted, an entry with default
           values will be added. For removal, either the index or the full
           value (in JSON format) needs to be specified.

           Lists can also be used with config set, but like maps, only by
           specifying the entire list value in JSON format.

           For example, this command shows the port number used for the
           second element of the list listen_on in the Auth module: config
           show Auth/listen_on[1]/port

   named set

           Named sets are similar to lists, in that they are sets of elements
           of the same type, but they are not indexed by numbers, but by
           strings.

           Values can be added with config add <item name> <string> [value]
           where 'string' is the name of the element. If 'value' is ommitted,
           default values will be used. Elements can be removed with config
           remove <item name> <string>

           Elements in a named set can be addressed similarly to maps.

           For example, the Init/components elements is a named set; adding,
           showing, and then removing an element can be done with the
           following three commands (note the '/'-character versus the space
           before 'example_module'):

           config add Init/components example_module

           config show Init/components/example_module

           config remove Init/components example_module

   any
           The 'any' type is a special type that can have any form. Apart
           from that, it must consist of elements as described in this
           chapter, there is no restriction on which element types are used.
           This type is used in places where different data formats could be
           used. Element modification commands depend on the actual type of
           the value. For instance, if the value of an 'any' element is a
           list, config add and config remove work as for other lists.

8.7. The execute command

   The execute command executes a set of commands, either from a file or from
   a pre-defined set. Currently, the only predefined set is
   init_authoritative_server, which adds b10-auth, b10-xfrin, and b10-xfrout
   to the set of components to be started by BIND 10. This pre-defined set
   does not commit the changes, so these modules do not show up for commands
   or configuration until the user enters config commit after execute
   init_authoritative_server. For example:

 > execute init_authoritative_server

 > execute file /tmp/example_commands

   The optional argument show displays the exact set of commands that would
   be executed; for example:

 > execute init_authoritative_server show
 !echo adding Authoritative server component
 config add /Init/components b10-auth
 config set /Init/components/b10-auth/kind needed
 config set /Init/components/b10-auth/special auth
 !echo adding Xfrin component
 config add /Init/components b10-xfrin
 config set /Init/components/b10-xfrin/address Xfrin
 config set /Init/components/b10-xfrin/kind dispensable
 !echo adding Xfrout component
 config add /Init/components b10-xfrout
 config set /Init/components/b10-xfrout/address Xfrout
 config set /Init/components/b10-xfrout/kind dispensable
 !echo adding Zone Manager component
 config add /Init/components b10-zonemgr
 config set /Init/components/b10-zonemgr/address Zonemgr
 config set /Init/components/b10-zonemgr/kind dispensable
 !echo Components added. Please enter "config commit" to
 !echo finalize initial setup and run the components.


   The optional show argument may also be used when executing a script from a
   file; for example:

 > execute file /tmp/example_commands show

  8.7.1. Execute directives

   Within sets of commands to be run with the execute command, a number of
   directives are supported:

   !echo <string>
           Prints the given string to bindctl's output.

   !verbose on
           Enables verbose mode; all following commands that are to be
           executed are also printed.

   !verbose off
           Disables verbose mode; following commands that are to be executed
           are no longer printed.

  8.7.2. Notes on execute scripts

   Within scripts, you can add or remove modules with the normal
   configuration commands for Init/components. However, as module
   configuration and commands do not show up until the module is running, it
   is currently not possible to add a module and set its configuration in one
   script. This will be addressed in the future, but for now the only option
   is to add and configure modules in separate commands and execute scripts.

                    Chapter 9. Common configuration elements

   Table of Contents

   9.1. TSIG keys

                9.1.1. Key anatomy and syntax

                9.1.2. Key ring

   9.2. ACLs

                9.2.1. Matching properties

                9.2.2. More complicated matches

                9.2.3. Examples

                9.2.4. Interaction with bindctl

   Some things are configured in the same or similar manner across many
   modules. So we show them here in one place.

9.1. TSIG keys

   TSIG is a way to sign requests and responses in DNS. It is defined in RFC
   2845 and uses symmetric cryptography to sign the DNS messages. If you want
   to make any use of TSIG (to authenticate transfers or DDNS, for example),
   you need to set up shared secrets between the endpoints.

   BIND 10 uses a global key ring for the secrets. It doesn't currently mean
   they would be stored differently, they are just in one place of the
   configuration.

  9.1.1. Key anatomy and syntax

   Each key has three attributes. One is a name by which it is referred both
   in DNS packets and the rest of the configuration. Another is the algorithm
   used to compute the signature. And the last part is a base64 encoded
   secret, which might be any blob of data.

   The parts are written into a string, concatenated together by colons. So
   if you wanted to have a key called "example.key", used as a HMAC-MD5 key
   with secret "secret", you'd write it as:

 "example.key.:c2VjcmV0:hmac-md5"

   The HMAC-MD5 algorithm is the default, so you can omit it. You could write
   the same key as:

 "example.key.:c2VjcmV0"

   You can also use these algorithms (which may not be omitted from the key
   definition if used):

     * hmac-sha1
     * hmac-sha224
     * hmac-sha256
     * hmac-sha384
     * hmac-sha512

   The name of the key must be a valid DNS name.

  9.1.2. Key ring

   The key ring lives in the configuration in "tsig_keys/keys". Most of the
   system uses the keys from there — ACLs, authoritative server to sign
   responses to signed queries, and b10-xfrin and b10-xfrout to sign
   transfers.

   The key ring is just a list of strings, each describing one key. So, to
   add a new key, you can do this:

 > config add tsig_keys/keys "example.key.:c2VjcmV0"
 > config show tsig_keys/keys
 tsig_keys/keys[0]   "example.key.:c2VjcmV0" string  (modified)
 > config commit

   You can keep as many keys as you want in the key ring, but each must have
   a different name.

9.2. ACLs

   An ACL, or Access Control List, is a way to describe if a request is
   allowed or disallowed. The principle is, there's a list of rules. Each
   rule is a name-value mapping (a dictionary, in the JSON terminology). Each
   rule must contain exactly one mapping called "action", which describes
   what should happen if the rule applies. There may be more mappings, called
   matches, which describe the conditions under which the rule applies.

   When there's a query, the first rule is examined. If it matches, the
   action in it is taken. If not, next rule is examined. If there are no more
   rules to examine, a default action is taken.

   There are three possible "action" values. The "ACCEPT" value means the
   query is handled. If it is "REJECT", the query is not answered, but a
   polite error message is sent back (if that makes sense in the context).
   The "DROP" action acts like a black hole. The query is not answered and no
   error message is sent.

   If there are multiple matching conditions inside the rule, all of them
   must be satisfied for the rule to apply. This can be used, for example, to
   require the query to be signed by a TSIG key and originate from given
   address.

   This is encoded in form of JSON. Semi-formal description could look
   something like this. It is described in more details below.

 ACL := [ RULE, RULE, ... ]
 RULE := { "action": "ACCEPT"|"REJECT"|"DROP", MATCH, MATCH, ... }
 RULE_RAW := { MATCH, MATCH, ... }
 MATCH := FROM_MATCH|KEY_MATCH|NOT_MATCH|OR_MATCH|AND_MATCH|...
 FROM_MATCH := "from": [RANGE, RANGE, RANGE, ...] | RANGE
 RANGE := "<ip range>"
 KEY_MATCH := "key": [KEY, KEY, KEY, ...] | KEY
 KEY := "<key name>"
 NOT_MATCH := "NOT": RULE_RAW
 OR_MATCH := "ANY": [ RULE_RAW, RULE_RAW, ... ]
 AND_MATCH := "ALL": [ RULE_RAW, RULE_RAW, ... ]

  9.2.1. Matching properties

   The first thing you can check against is the source address of request.
   The name is from and the value is a string containing either a single IPv4
   or IPv6 address, or a range in the usual slash notation (eg.
   "192.0.2.0/24").

   The other is TSIG key by which the message was signed. The ACL contains
   only the name (under the name "key"), the key itself must be stored in the
   global key ring (see Section 9.1.2, “Key ring”). This property is
   applicable only to the DNS context.

   More properties to match are planned — the destination address, ports,
   matches against the packet content.

  9.2.2. More complicated matches

   From time to time, you need to express something more complex than just a
   single address or key.

   You can specify a list of values instead of single value. Then the
   property needs to match at least one of the values listed — so you can say
   “"from": ["192.0.2.0/24", "2001:db8::/32"]” to match any address in the
   ranges set aside for documentation. The keys or any future properties will
   work in a similar way.

   If that is not enough, you can compose the matching conditions to logical
   expressions. They are called "ANY", "ALL" and "NOT". The "ANY" and "ALL"
   ones contain lists of subexpressions — each subexpression is a similar
   dictionary, just not containing the "action" element. The "NOT" contains
   single subexpression. Their function should be obvious — "NOT" matches if
   and only if the subexpression does not match. The "ALL" matches exactly
   when each of the subexpressions matches and "ANY" when at least one
   matches.

  9.2.3. Examples

   All the examples here is just the JSON representing the ACL, nicely
   formatted and split across lines. They are out of any surrounding context.
   This is similar to what you'd get from config show_json called on the
   entry containing the ACL.

   In the first example, the ACL accepts queries from two known hosts. Each
   host has an IP addresses (both IPv4 and IPv6) and a TSIG key. Other
   queries are politely rejected. The last entry in the list has no
   conditions — making it match any query.

 [
   {
     "from": ["192.0.2.1", "2001:db8::1"],
     "key": "first.key",
     "action": "ACCEPT"
   },
   {
     "from": ["192.0.2.2", "2001:db8::2"],
     "key": "second.key",
     "action": "ACCEPT"
   },
   {
     "action": "REJECT"
   }
 ]

   Now we show two ways to accept only the queries from private ranges. This
   is the same as rejecting anything that is outside.

 [
   {
     "from": [
       "10.0.0.0/8",
       "172.16.0.0/12",
       "192.168.0.0/16",
       "fc00::/7"
     ],
     "action": "ACCEPT"
   },
   {
     "action": "REJECT"
   }
 ]

 [
   {
     "NOT": {
        "ANY": [
          {"from": "10.0.0.0/8"},
          {"from": "172.16.0.0/12"},
          {"from": "192.168.0.0/16"},
          {"from": "fc00::/7"}
        ]
     },
     "action": "REJECT"
   },
   {
     "action": "ACCEPT"
   }
 ]

  9.2.4. Interaction with bindctl

   Currently, bindctl has hard time coping with the variable nature of the
   ACL syntax. This technical limitation makes it impossible to edit parts of
   the entries. You need to set the whole entry at once, providing the whole
   JSON value.

   This limitation is planned to be solved soon at least partially.

   You'd do something like this to create the second example. Note that the
   whole JSON must be on a single line.

 > config add somewhere/acl
 > config set somewhere/acl[0] { "from": [ "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "fc00::/7" ], "action": "ACCEPT" }
 > config add somewhere/acl
 > config set somewhere/acl[1] { "action": "REJECT" }
 > config commit

                  Chapter 10. bind10 Control and Configuration

   Table of Contents

   10.1. Stopping bind10

   10.2. Configuration to start processes

   This chapter explains how to control and configure the b10-init parent.
   The startup of this resident process that runs the BIND 10 daemons is
   covered in Chapter 4, Starting BIND 10 with bind10.

10.1. Stopping bind10

   The BIND 10 suite may be shut down by stopping the parent b10-init
   process. This may be done by running the Init shutdown command at the
   bindctl prompt.

10.2. Configuration to start processes

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

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

 > config add Init/components b10-resolver
 > config set Init/components/b10-resolver/special resolver
 > config set Init/components/b10-resolver/kind needed
 > config set Init/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.

   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 10.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 b10-init 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 behavior 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 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 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 convention the thing after b10-, with the first
   letter capitalized (eg. b10-stats 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 special components also already know their executable
   name.)

  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 change
   it back the usual way, as it would require it to be running (you would
   have to find and edit the configuration directly). Also, some modules
   might have dependencies: b10-stats-httpd needs b10-stats, b10-xfrout needs
   b10-auth to be running, etc.

   In short, you should think twice before disabling something here.

   It is possible to start some components multiple times (currently 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:

 > config add Init/components b10-resolver-2
 > config set Init/components/b10-resolver-2/special resolver
 > config set Init/components/b10-resolver-2/kind needed
 > config commit

   However, this is work in progress and the support is not yet complete. For
   example, each resolver will have its own cache, each authoritative 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.

   The running processes started by b10-init may be listed by running Init
   show_processes using bindctl.

                        Chapter 11. Authoritative Server

   Table of Contents

   11.1. Server Configurations

   11.2. Data Source Backends

                11.2.1. Data source types

                11.2.2. Examples

                11.2.3. Adding a static data source

   11.3. Loading Master Zones Files

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

11.1. Server Configurations

   b10-auth is configured via the b10-cfgmgr configuration manager. The
   module name is “Auth”. The configuration data items are:

   database_file
           This is an optional string to define the path to find the SQLite3
           database file. 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: type
           to define the required data source type (such as “memory”); class
           to optionally select the class (it defaults to “IN”); and zones to
           define the file path name, 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.

  Note

           Currently this is only used for the memory data source. Only the
           IN class is supported at this time. By default, the memory data
           source is disabled. Also, currently the zone file must be
           canonical such as generated by named-compilezone -D, or must be an
           SQLite3 database.

   listen_on
           listen_on is a list of addresses and ports for b10-auth to listen
           on. The list items are the address string and port number. By
           default, b10-auth listens on port 53 on the IPv6 (::) and IPv4
           (0.0.0.0) wildcard addresses.

  Note

           The default configuration is currently not appropriate for a
           multi-homed host. In case you have multiple public IP addresses,
           it is possible the query UDP packet comes through one interface
           and the answer goes out through another. The answer will probably
           be dropped by the client, as it has a different source address
           than the one it sent the query to. The client would fallback on
           TCP after several attempts, which works well in this situation,
           but is clearly not ideal.

           There are plans to solve the problem such that the server handles
           it by itself. But until it is actually implemented, it is
           recommended to alter the configuration — remove the wildcard
           addresses and list all addresses explicitly. Then the server will
           answer on the same interface the request came on, preserving the
           correct address.

   tcp_recv_timeout
           tcp_recv_timeout is the timeout used on incoming TCP connections,
           in milliseconds. If the query is not sent within this time, the
           connection is closed. Setting this to 0 will disable TCP timeouts
           completely.

   The configuration commands are:

   loadzone
           loadzone tells b10-auth to load or reload a zone file. The
           arguments include: class which optionally defines the class (it
           defaults to “IN”); origin is the domain name of the zone; and
           datasrc optionally defines the type of datasource (it defaults to
           “memory”).

  Note

           Currently this only supports the IN class and the memory data
           source.

   getstats
           getstats requests b10-auth to send its statistics data to
           b10-stats(8) as a response of the command.

   shutdown
           Stop the authoritative DNS server. This has an optional pid
           argument to select the process ID to stop. (Note that the BIND 10
           init process may restart this service if configured.)

11.2. Data Source Backends

   Bind 10 has the concept of data sources. A data source is a place where
   authoritative zone data reside and where they can be served from. This can
   be a master file, a database or something completely different.

   Once a query arrives, b10-auth goes through a configured list of data
   sources and finds the one containing a best matching zone. From the
   equally good ones, the first one is taken. This data source is then used
   to answer the query.

  Note

   In the current release, b10-auth can serve data from a SQLite3 data source
   backend and from master files. Upcoming versions will be able to use
   multiple different data sources, such as MySQL and Berkeley DB.

   The configuration is located in data_sources/classes. Each item there
   represents one RR class and a list used to answer queries for that class.
   The default contains two classes. The CH class contains a built-in data
   source — one that serves things like “AUTHORS.BIND.”. The IN class
   contains single SQLite3 data source with database file located at
   /usr/local/var/bind10/zone.sqlite3.

   Each data source has several options. The first one is type, which
   specifies the type of data source to use. Valid types include the ones
   listed below, but BIND 10 uses dynamically loaded modules for them, so
   there may be more in your case. This option is mandatory.

   Another option is params. This option is type specific; it holds different
   data depending on the type above. Also, depending on the type, it could be
   possible to omit it.

   There are two options related to the so-called cache. If you enable cache,
   zone data from the data source are loaded into memory. Then, when
   answering a query, b10-auth looks into the memory only instead of the data
   source, which speeds answering up. The first option is cache-enable, a
   boolean value turning the cache on and off (off is the default). The
   second one, cache-zones, is a list of zone origins to load into in-memory.

  11.2.1. Data source types

   As mentioned, the type used by default is “sqlite3”. It has single
   configuration option inside params — database_file, which contains the
   path to the SQLite3 file containing the data.

   Another type is called “MasterFiles”. This one is slightly special. The
   data are stored in RFC1034 master files. Because answering directly from
   them would be impractical, this type mandates the cache to be enabled.
   Also, the list of zones (cache-zones) should be omitted. The params is a
   dictionary mapping from zone origins to the files they reside in.

  11.2.2. Examples

   As this is one of the more complex configurations of BIND 10, we show some
   examples. They all assume they start with default configuration.

   First, let's disable the built-in data source (“VERSION.BIND” and
   friends). As it is the only data source in the CH class, we can remove the
   whole class.

 > config remove data_sources/classes CH
 > config commit

   Another one, let's say our default data source contains zones
   “example.org.” and “example.net.”. We want them to be served from memory
   to make the answering faster.

 > config set data_sources/classes/IN[0]/cache-enable true
 > config add data_sources/classes/IN[0]/cache-zones example.org.
 > config add data_sources/classes/IN[0]/cache-zones example.net.
 > config commit

   Now every time the zone in the data source is changed by the operator, the
   authoritative server needs to be told to reload it, by

 > Auth loadzone example.org

   You don't need to do this when the zone is modified by b10-xfrin; it does
   so automatically.

   Now, the last example is when there are master files we want to serve in
   addition to whatever is inside the SQLite3 database.

 > config add data_sources/classes/IN
 > config set data_sources/classes/IN[1]/type MasterFiles
 > config set data_sources/classes/IN[1]/cache-enable true
 > config set data_sources/classes/IN[1]/params { "example.org": "/path/to/example.org", "example.com": "/path/to/example.com" }
 > config commit

   Unfortunately, due to current technical limitations, the params must be
   set as one JSON blob. To reload a zone, use the same Auth loadzone command
   as above.

   Initially, a map value has to be set, but this value may be an empty map.
   After that, key/value pairs can be added with config add and keys can be
   removed with config remove. The initial value may be an empty map, but it
   has to be set before zones are added or removed.

 > config set data_sources/classes/IN[1]/params {}
 > config add data_sources/classes/IN[1]/params another.example.org /path/to/another.example.org
 > config add data_sources/classes/IN[1]/params another.example.com /path/to/another.example.com
 > config remove data_sources/classes/IN[1]/params another.example.org
 > config commit

  Note

   There's also Auth/database_file configuration variable, pointing to a
   SQLite3 database file. This is no longer used by b10-auth, but it is left
   in place for now, since other modules use it. Once b10-zonemgr, b10-xfrout
   and b10-ddns are ported to the new configuration, this will disappear. But
   for now, make sure that if you use any of these modules, the new and old
   configuration correspond. The defaults are consistent, so unless you
   tweaked either the new or the old configuration, you're good.

  11.2.3. Adding a static data source

   BIND 10 includes a zone file named static.zone in the CH (Chaos) class for
   providing information about the server via the AUTHORS.BIND and
   VERSION.BIND TXT records. By default, this BIND zone is configured and its
   records are served.

   If you have removed this zone from the configuration (e.g., by using the
   commands in the previous section to disable the "built-in data source"),
   here is how you can add it back to serve the zones in the static.zone
   file.

   First, add the CH class if it doesn't exist:

 > config add data_sources/classes CH
 > config commit

   Then, add a data source of type MasterFiles in the CH class to serve the
   zones in static.zone:

 > config add data_sources/classes/CH
 > config set data_sources/classes/CH[0]/type MasterFiles
 > config set data_sources/classes/CH[0]/cache-enable true
 > config set data_sources/classes/CH[0]/params {"BIND": "/usr/local/bind10/share/bind10/static.zone"}
 > config commit

   Then, lookup the static data from static.zone to test it (assuming your
   authoritative server is running on localhost):

 > dig @localhost -c CH -t TXT version.bind
 > dig @localhost -c CH -t TXT authors.bind

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

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

   $INCLUDE
           Loads an additional zone file. This may be recursive.

   $ORIGIN
           Defines the relative domain name.

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

  Note

   In the current release, only the SQLite3 back end is used by b10-loadzone.
   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.

                      Chapter 12. Incoming Zone Transfers

   Table of Contents

   12.1. Configuration for Incoming Zone Transfers

   12.2. TSIG

   12.3. Control the use of IXFR

   12.4. Secondary Manager

   12.5. Trigger an Incoming Zone Transfer Manually

   12.6. Incoming Transfers with In-memory Datasource

   Incoming zones are transferred using the b10-xfrin process which is
   started by b10-init. When received, the zone is stored in the
   corresponding BIND 10 data source, 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 b10-xfrin process supports both AXFR and IXFR.

12.1. Configuration for Incoming Zone Transfers

   In order to enable incoming zone transfers for a secondary zone, you will
   first need to make the zone "exist" in some data source. One easy way to
   do this is to create an empty zone using the b10-loadzone utility. For
   example, this makes an empty zone (or empties any existing content of the
   zone) "example.com" in the default data source for b10-loadzone (which is
   SQLite3-based data source):

 $ b10-loadzone -e example.com

   Next, you need to specify a list of secondary zones to enable incoming
   zone transfers for these zones in most practical cases (you can still
   trigger a zone transfer manually, without a prior configuration (see
   below)).

   For example, to enable zone transfers for a zone named "example.com"
   (whose master address is assumed to be 2001:db8::53 here), run the
   following at the bindctl prompt:

 > config add Xfrin/zones
 > config set Xfrin/zones[0]/name "example.com"
 > config set Xfrin/zones[0]/master_addr "2001:db8::53"
 > config commit

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

  Note

   There is a plan to revise overall zone management configuration (which are
   primary and secondary zones, which data source they are stored, etc) so it
   can be configured more consistently and in a unified way among various
   BIND 10 modules. When it's done, part or all of the initial configuration
   setup described in this section may be deprecated.

12.2. TSIG

   If you want to use TSIG for incoming transfers, a system wide TSIG key
   ring must be configured (see Section 9.1.2, “Key ring”). To specify a key
   to use, set tsig_key value to the name of the key to use from the key
   ring. > config set Xfrin/zones[0]/tsig_key "example.key"

12.3. Control the use of IXFR

   By default, b10-xfrin uses IXFR for transferring zones specified in the
   Xfrin/zones list of the configuration, unless it doesn't know the current
   SOA serial of the zone (including the case where the zone has never
   transferred or locally loaded), in which case it automatically uses AXFR.
   If the attempt of IXFR fails, b10-xfrin automatically retries the transfer
   using AXFR. In general, this works for any master server implementations
   including those that don't support IXFR and in any local state of the
   zone. So there should normally be no need to configure on whether to use
   IXFR.

   In some cases, however, it may be desirable to specify how and whether to
   use IXFR and AXFR. The request_ixfr configuration item under Xfrin/zones
   can be used to control such policies. It can take the following values.

   yes
           This is the default behavior as described above.

   no
           Only use AXFR. Note that this value normally shouldn't be needed
           thanks to the automatic fallback from IXFR to IXFR. A possible
           case where this value needs to be used is that the master server
           has a bug and crashes if it receives an IXFR request.

   only
           Only use IXFR except when the current SOA serial is not known.
           This value has a severe drawback, that is, if the master server
           does not support IXFR zone transfers never succeed (except for the
           very first one, which will use AXFR), and the zone will eventually
           expire. Therefore it should not be used in general. Still, in some
           special cases the use of this value may make sense. For example,
           if the operator is sure that the master server supports IXFR and
           the zone is very large, they may want to avoid falling back to
           AXFR as it can be more expensive.

  Note

   There used to be a boolean configuration item named use_ixfr. It was
   deprecated for the finer control described above. The request_ixfr item
   should be used instead.

12.4. Secondary Manager

   The b10-zonemgr process is started by b10-init. 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.

  Note

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

   The following example shows using bindctl to configure the server to be a
   secondary for the example zone:

 > config add Zonemgr/secondary_zones
 > config set Zonemgr/secondary_zones[0]/name "example.com"
 > 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.

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

   The retransfer command always uses AXFR. To use IXFR for a zone that has
   already been transferred once, use the refresh command. It honors the
   Xfrin/zones/request_ixfr configuration item (see Section 12.3, “Control
   the use of IXFR”.), and if it's configured to use IXFR, it will be used.

   Both the retransfer and refresh commands can be used for an initial
   transfer before setting up secondary configurations. In this case AXFR
   will be used for the obvious reason.

12.6. 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 with an SQLite3 backend, b10-auth is
   automatically sent a loadzone command to reload the corresponding zone
   into memory from the backend.

   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 11.2, “Data Source Backends”.

                      Chapter 13. Outbound Zone Transfers

   The b10-xfrout process is started by b10-init. 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
   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
   NOTIFY messages to secondary servers.

   A global or per zone transfer_acl configuration can be used to control
   accessibility of the outbound zone transfer service. By default,
   b10-xfrout allows any clients to perform zone transfers for any zones.

 > config show Xfrout/transfer_acl
 Xfrout/transfer_acl[0]  {"action": "ACCEPT"}    any     (default)

   If you want to require TSIG in access control, a system wide TSIG key ring
   must be configured (see Section 9.1.2, “Key ring”). In this example, we
   allow client matching both the IP address and key.

 > 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 b10-xfrout and b10-auth will use the system wide key ring to check
   TSIGs in the incoming messages and to sign responses.

   For further details on ACL configuration, see Section 9.2, “ACLs”.

  Note

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

                         Chapter 14. Dynamic DNS Update

   Table of Contents

   14.1. Enabling Dynamic Update

   14.2. Access Control

   14.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
   component, which is started by the b10-init process if configured so.

   When the b10-auth authoritative DNS server receives an UPDATE request, it
   internally forwards the request to b10-ddns, which handles the rest of
   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. In
   addition, if b10-auth serves the updated zone (as described in
   Section 11.2, “Data Source Backends”), b10-ddns will also notify b10-auth
   so that b10-auth will re-cache the updated zone content if necessary.

   The b10-ddns component supports requests over both UDP and TCP, and both
   IPv6 and IPv4; for TCP requests, however, it terminates the TCP connection
   immediately after each single request has been processed. Clients cannot
   reuse the same TCP connection for multiple requests. (This is a current
   implementation limitation of b10-ddns. While RFC 2136 doesn't specify
   anything about such reuse of TCP connection, there is no reason for
   disallowing it as RFC 1035 generally allows multiple requests sent over a
   single TCP connection. BIND 9 supports such reuse.)

   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 “not implemented” response.

  Note

   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.

14.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 and b10-zonemgr. In
   addition, b10-xfrout should also be configured to run; otherwise the
   notification after an update (see above) will fail with a timeout,
   suspending the DDNS service while b10-ddns waits for the response (see the
   description of the DDNS_UPDATE_NOTIFY_FAIL log message for further
   details). If BIND 10 is already configured to provide authoritative DNS
   service they should normally be configured to run already.

   Second, for the obvious reason dynamic update requires that the 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, in this current 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.

  Note

   The way to configure data sources is now being revised. Configuration on
   the data source for DDNS will be very likely to be changed in a backward
   incompatible manner in a near future version.

   In general, if something goes wrong regarding the dependency described
   above, b10-ddns will log the related event at the warning or error level.
   It's advisable to check the log message when you first enable DDNS or if
   it doesn't work as you expect to see if there's any warning or error log
   message.

   Next, to enable the DDNS service, b10-ddns needs to be explicitly
   configured to run. It can be done by using the bindctl utility. For
   example:

 > config add Init/components b10-ddns
 > config set Init/components/b10-ddns/address DDNS
 > config set Init/components/b10-ddns/kind dispensable
 > 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.

14.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 b10-ddns. This is a list of per-zone
   configurations regarding DDNS. Each list element consists of the following
   parameters:

   origin
           The zone's origin name

   class
           The RR class of the zone (normally “IN”, and in that case can be
           omitted in configuration)

   update_acl
           List of access control rules (ACL) for the zone

   The syntax of the ACL is the same as ACLs for other components. Specific
   examples are given below.

   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 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 add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}
 > config commit

   The TSIG key must be configured system wide (see Section 9.1, “TSIG
   keys”).

   The full description of ACLs can be found in Section 9.2, “ACLs”.

  Note

   The b10-ddns component accepts an ACL rule that just allows updates from a
   specific IP address (i.e., without requiring TSIG), but this is highly
   discouraged (remember that requests can be made over UDP and spoofing the
   source address of a UDP packet is often pretty easy). Unless you know what
   you are doing and that you can accept its consequence, any update ACL rule
   that allows updates should have a TSIG key in its constraints.

   Currently update ACL can only control updates per zone basis; it's not
   possible to specify access control with higher granularity such as for
   particular domain names or specific types of RRs.

  Note

   Contrary to what RFC 2136 (literally) specifies, b10-ddns checks the
   update ACL before checking the prerequisites of the update request. This
   is a deliberate implementation decision. This counter intuitive
   specification has been repeatedly discussed among implementers and in the
   IETF, and it is now widely agreed that it does not make sense to strictly
   follow that part of RFC. One known specific bad result of following the
   RFC is that it could leak information about which name or record exists or
   does not exist in the zone as a result of prerequisite checks even if a
   zone is somehow configured to reject normal queries from arbitrary
   clients. There have been other troubles that could have been avoided if
   the ACL could be checked before the prerequisite check.

14.3. Miscellaneous Operational Issues

   Unlike BIND 9, BIND 10 currently does not support automatic 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
   at this moment.

   Also unlike BIND 9, it's currently not possible to “freeze” a zone
   temporarily in order to suspend DDNS while you manually update the zone.
   If you need to make manual updates to a dynamic zone, you'll need to
   temporarily reject any updates to the zone via the update ACLs.

   Dynamic updates are only applicable to primary zones. In order to avoid
   updating secondary zones via DDNS requests, b10-ddns refers to the
   “secondary_zones” configuration of b10-zonemgr. Zones listed in
   “secondary_zones” will never be updated via DDNS regardless of the update
   ACL configuration; 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
   “secondary_zones”, be careful not to allow DDNS for the zone; it would be
   quite likely to lead to inconsistent state between different servers.
   Normally this should not be a problem because the default update ACL
   rejects any update requests, but you may want to take an extra care about
   the configuration if you have such type of secondary zones.

   The difference of two versions of a zone, before and after a DDNS
   transaction, is automatically recorded in the underlying data source, and
   can be retrieved in the form of outbound IXFR. This is done automatically;
   it does not require specific configuration to make this possible.

                       Chapter 15. Recursive Name Server

   Table of Contents

   15.1. Access Control

   15.2. Forwarding

  Note

   The b10-resolver is an experimental proof of concept.

   The b10-resolver daemon provides an iterative caching and forwarding DNS
   server. The process is started by b10-init.

   The main b10-init process can be configured to select to run either the
   authoritative or resolver or both. By default, it doesn't start either
   one. You may change this using bindctl, for example:

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

   The master b10-init process will stop and start the desired services.

   By default, the resolver listens on port 53 for 127.0.0.1 and ::1. The
   following example shows how it can be configured to listen on an
   additional address (and port):

 > config add Resolver/listen_on
 > config set Resolver/listen_on[2]/address "192.168.1.1"
 > config set Resolver/listen_on[2]/port 53
 > config commit

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

15.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 be
   used to reject, drop, or allow specific IPs or networks. See Section 9.2,
   “ACLs”.

   The following session is an example of extending the ACL to also allow
   queries from 192.0.2.0/24:

 > config show Resolver/query_acl
 Resolver/query_acl[0]   {"action": "ACCEPT", "from": "127.0.0.1"}   any (default)
 Resolver/query_acl[1]   {"action": "ACCEPT", "from": "::1"} any (default)
 > config add Resolver/query_acl
 > config set Resolver/query_acl[2] {"action": "ACCEPT", "from": "192.0.2.0/24"}
 > config add Resolver/query_acl
 > config show Resolver/query_acl
 Resolver/query_acl[0]   {"action": "ACCEPT", "from": "127.0.0.1"}   any (modified)
 Resolver/query_acl[1]   {"action": "ACCEPT", "from": "::1"} any (modified)
 Resolver/query_acl[2]   {"action": "ACCEPT", "from": "192.0.2.0/24"}  any (modified)
 Resolver/query_acl[3]   {"action": "REJECT"}    any (modified)
 > config commit

   Note that we didn't set the value of the last final rule (query_acl[3]) --
   in the case of resolver, rejecting all queries is the default value of a
   new rule. In fact, this rule can even be omitted completely, as the
   default, when a query falls off the list, is rejection.

15.2. Forwarding

   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

                                Chapter 16. DHCP

   Table of Contents

   16.1. DHCP Database Installation and Configuration

                16.1.1. Install MySQL

                16.1.2. Build and Install BIND 10

                16.1.3. Create MySQL Database and BIND 10 User

   The 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 ease deployment in larger networks,
   additional nodes (relays) may be deployed that facilitate communication
   between servers and clients. Even though principles of both DHCPv4 and
   DHCPv6 are somewhat similar, these are two radically different protocols.
   BIND 10 offers two server implementations, one for DHCPv4 and one for
   DHCPv6. The DHCP part of the BIND 10 project is codenamed Kea. The DHCPv4
   component is colloquially referred to as Kea4 and its DHCPv6 counterpart
   is called Kea6.

   In addition to providing lease management services, both Kea4 and Kea6 can
   provide dynamic DNS (DDNS) updates driven by the lease changes they make.
   These updates are carried out with the assistance of the DHCP-DDNS server,
   colloquially referred to as D2. When configured to do so, Kea servers will
   notify D2 of lease changes. D2 will match them to the appropriate DNS
   servers and instruct those severs to add or delete the requisite DNS
   entries.

   This chapter covers those parts of BIND 10 that are common to both
   servers. DHCPv4-specific details are covered in Chapter 17, The DHCPv4
   Server, while those details specific to DHCPv6 are described in
   Chapter 18, The DHCPv6 Server. The DHCP-DDNS server details are covered in
   Chapter 19, The DHCP-DDNS Server

  Note

   In this release of BIND 10, the DHCPv4 and DHCPv6 servers must be
   considered experimental.

16.1. DHCP Database Installation and Configuration

   BIND 10 DHCP stores its leases in a lease database. The software has been
   written in a way that makes it possible to choose which database product
   should be used to store the lease information. At present, only support
   for MySQL is provided, and that support must be explicitly included when
   BIND 10 is built. This section covers the building of BIND 10 with MySQL
   and the creation of the lease database.

  16.1.1. Install MySQL

   Install MySQL according to the instructions for your system. The client
   development libraries must be installed.

  16.1.2. Build and Install BIND 10

   Build and install BIND 10 as described in Chapter 3, Installation, with
   the following modification: to enable the MySQL database code, at the
   "configure" step (see Section 3.4.3, “Configure before the build”),
   specify the location of the MySQL configuration program "mysql_config"
   with the "--with-dhcp-mysql" switch, i.e.

 ./configure [other-options] --with-dhcp-mysql

   ...if MySQL was installed in the default location, or:

 ./configure [other-options] --with-dhcp-mysql=path-to-mysql_config

   ...if not.

  16.1.3. Create MySQL Database and BIND 10 User

   The next task is to create both the lease database and the user under
   which the servers will access it. A number of steps are required:

   1. Log into MySQL as "root":

 $ mysql -u root -p
 Enter password:
    :
 mysql>

   2. Create the database:

 mysql> CREATE DATABASE database-name;

   ... database-name is the name you have chosen for the database.

   3. Create the database tables:

 mysql> CONNECT database-name;
 mysql> SOURCE path-to-bind10/share/bind10/dhcpdb_create.mysql

   4. Create the user under which BIND 10 will access the database (and give
   it a password), then grant it access to the database tables:

 mysql> CREATE USER 'user-name'@'localhost' IDENTIFIED BY 'password';
 mysql> GRANT ALL ON database-name.* TO 'user-name'@'localhost';

   5. Exit MySQL:

 mysql> quit
 Bye
 $

                         Chapter 17. The DHCPv4 Server

   Table of Contents

   17.1. Starting and Stopping the DHCPv4 Server

   17.2. Configuring the DHCPv4 Server

                17.2.1. Database Configuration

                17.2.2. Interface selection

                17.2.3. Configuration of IPv4 Address Pools

                17.2.4. Standard DHCPv4 options

                17.2.5. Custom DHCPv4 options

                17.2.6. DHCPv4 vendor specific options

                17.2.7. Nested DHCPv4 options (custom option spaces)

                17.2.8. Client Classification in DHCPv4

                17.2.9. Limiting access to IPv4 subnet to certain classes

                17.2.10. Configuring DHCPv4 for DDNS

   17.3. Server Identifier in DHCPv4

   17.4. Next server (siaddr)

   17.5. Echoing client-id (RFC6842)

   17.6. How DHCPv4 server selects subnet for a client

   17.7. Using specific relay agent for a subnet

   17.8. Segregating IPv4 clients in a cable network

   17.9. Supported Standards

   17.10. DHCPv4 Server Limitations

17.1. Starting and Stopping the DHCPv4 Server

   b10-dhcp4 is the BIND 10 DHCPv4 server and, like other parts of BIND 10,
   is configured through the bindctl program.

   After starting BIND 10 and entering bindctl, the first step in configuring
   the server is to add it to the list of running BIND 10 services.

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

   To remove b10-dhcp4 from the set of running services, the b10-dhcp4 is
   removed from list of Init components:

 > config remove Init/components b10-dhcp4
 > config commit

   Note that the server was only removed from the list, so BIND10 will not
   restart it, but the server itself is still running. Hence it is usually
   desired to stop it:

 > Dhcp4 shutdown

   On start-up, 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 assigned. The server will then listen
   to incoming traffic. Currently supported client messages are DISCOVER and
   REQUEST. The server will respond to them with OFFER and ACK, respectively.
   Since the DHCPv4 server opens privileged ports, it requires root access.
   Make sure you run this daemon as root.

17.2. Configuring the DHCPv4 Server

   Once the server is started, it can be configured. To view the current
   configuration, use the following command in bindctl:

 > config show Dhcp4

   When starting the DHCPv4 daemon for the first time, the default
   configuration will be available. It will look similar to this:

 > config show Dhcp4
 Dhcp4/hooks-libraries   []      list    (default)
 Dhcp4/interfaces/       list
 Dhcp4/renew-timer       1800    integer
 Dhcp4/rebind-timer      2000    integer (default)
 Dhcp4/valid-lifetime    4000    integer (default)
 Dhcp4/next-server       ""      string  (default)
 Dhcp4/echo-client-id    true    boolean (default)
 Dhcp4/option-def        []      list    (default)
 Dhcp4/option-data       []      list    (default)
 Dhcp4/lease-database/type       ""      string  (default)
 Dhcp4/lease-database/name       ""      string  (default)
 Dhcp4/lease-database/user       ""      string  (default)
 Dhcp4/lease-database/host       ""      string  (default)
 Dhcp4/lease-database/password   ""      string  (default)
 Dhcp4/subnet4/  list
 Dhcp4/dhcp-ddns/enable-updates  true    boolean
 Dhcp4/dhcp-ddns/server-ip       "127.0.0.1"     string
 Dhcp4/dhcp-ddns/server-port     53001   integer
 Dhcp4/dhcp-ddns/ncr-protocol    "UDP"   string
 Dhcp4/dhcp-ddns/ncr-format      "JSON"  string
 Dhcp4/dhcp-ddns/override-no-update      false   boolean
 Dhcp4/dhcp-ddns/override-client-update  false   boolean
 Dhcp4/dhcp-ddns/replace-client-name     false   boolean
 Dhcp4/dhcp-ddns/generated-prefix        "myhost"        string
 Dhcp4/dhcp-ddns/qualifying-suffix       "example.com"   string

   To change one of the parameters, simply follow the usual bindctl
   procedure. For example, to make the leases longer, change their
   valid-lifetime parameter:

 > config set Dhcp4/valid-lifetime 7200
 > config commit

   Please note that most Dhcp4 parameters are of global scope and apply to
   all defined subnets, unless they are overridden on a per-subnet basis.

  17.2.1. Database Configuration

   All leases issued by the server are stored in the lease database.
   Currently, the only supported database is MySQL ^[1], and so the server
   must be configured to access the correct database with the appropriate
   credentials.

  Note

   Database access information must be configured for the DHCPv4 server, even
   if it has already been configured for the DHCPv6 server. The servers store
   their information independently, so each server can use a separate
   database or both servers can use the same database.

   Database configuration is controlled through the Dhcp4/lease-database
   parameters. The type of the database must be set to MySQL (although the
   string entered is "mysql"):

 > config set Dhcp4/lease-database/type "mysql"

   Next, the name of the database is to hold the leases must be set: this is
   the name used when the lease database was created (see Section 16.1.3,
   “Create MySQL Database and BIND 10 User”).

 > config set Dhcp4/lease-database/name "database-name"

   If the database is located on a different system to the DHCPv4 server, the
   database host name must also be specified (although note that this
   configuration may have a severe impact on server performance):

 > config set Dhcp4/lease-database/host "remote-host-name"

   The usual state of affairs will be to have the database on the same
   machine as the DHCPv4 server. In this case, set the value to the empty
   string (this is the default):

 > config set Dhcp4/lease-database/host ""

   Finally, the credentials of the account under which the server will access
   the database should be set:

 > config set Dhcp4/lease-database/user "user-name"
 > config set Dhcp4/lease-database/password "password"

   If there is no password to the account, set the password to the empty
   string "". (This is also the default.)

  Note

   The password is echoed when entered and is stored in clear text in the
   BIND 10 configuration database. Improved password security will be added
   in a future version of BIND 10 DHCP

  17.2.2. Interface selection

   When DHCPv4 server starts up, by default it will listen to the DHCP
   traffic and respond to it on all interfaces detected during startup.
   However, in many cases it is desired to configure the server to listen and
   respond on selected interfaces only. The sample commands in this section
   show how to make interface selection using bindctl.

   The default configuration can be presented with the following command:

 > config show Dhcp4/interfaces
 Dhcp4/interfaces[0] "*" string

   An asterisk sign plays a role of the wildcard and means "listen on all
   interfaces".

   In order to override the default configuration, the existing entry can be
   replaced with the actual interface name:

 > config set Dhcp4/interfaces[0] eth1
 > config commit

   Other interface names can be added on one-by-one basis:

 > config add Dhcp4/interfaces eth2
 > config commit

   Configuration will now contain two interfaces which can be presented as
   follows:

 > config show Dhcp4/interfaces
 Dhcp4/interfaces[0]     "eth1"  string
 Dhcp4/interfaces[1]     "eth2"  string

   When configuration gets committed, the server will start to listen on eth1
   and eth2 interfaces only.

   It is possible to use wildcard interface name (asterisk) concurrently with
   explicit interface names:

 > config add Dhcp4/interfaces *
 > config commit

   This will result in the following configuration:

 > config show Dhcp4/interfaces
 Dhcp4/interfaces[0]     "eth1"  string
 Dhcp4/interfaces[1]     "eth2"  string
 Dhcp4/interfaces[2]     "*"     string

   The presence of the wildcard name implies that server will listen on all
   interfaces. In order to fall back to the previous configuration when
   server listens on eth1 and eth2:

 > config remove Dhcp4/interfaces[2]
 > config commit

  17.2.3. Configuration of IPv4 Address Pools

   The essential role of DHCPv4 server is address assignment. The server has
   to be configured with at least one subnet and one pool of dynamic
   addresses to be managed. For example, assume that the server is connected
   to a network segment that uses the 192.0.2.0/24 prefix. The Administrator
   of that network has decided that addresses from range 192.0.2.10 to
   192.0.2.20 are going to be managed by the Dhcp4 server. Such a
   configuration can be achieved in the following way:

 > config add Dhcp4/subnet4
 > config set Dhcp4/subnet4[0]/subnet "192.0.2.0/24"
 > config set Dhcp4/subnet4[0]/pool [ "192.0.2.10 - 192.0.2.20" ]
 > config commit

   Note that subnet is defined as a simple string, but the pool parameter is
   actually a list of pools: for this reason, the pool definition is enclosed
   in square brackets, even though only one range of addresses is specified.

   It is possible to define more than one pool in a subnet: continuing the
   previous example, further assume that 192.0.2.64/26 should be also be
   managed by the server. It could be written as 192.0.2.64 to 192.0.2.127.
   Alternatively, it can be expressed more simply as 192.0.2.64/26. Both
   formats are supported by Dhcp4 and can be mixed in the pool list. For
   example, one could define the following pools:

 > config set Dhcp4/subnet4[0]/pool [ "192.0.2.10-192.0.2.20", "192.0.2.64/26" ]
 > config commit

   The number of pools is not limited, but for performance reasons it is
   recommended to use as few as possible. Space and tabulations in pool
   definitions are ignored, so spaces before and after hyphen are optional.
   They can be used to improve readability.

   The server may be configured to serve more than one subnet. To add a
   second subnet, use a command similar to the following:

 > config add Dhcp4/subnet4
 > config set Dhcp4/subnet4[1]/subnet "192.0.3.0/24"
 > config set Dhcp4/subnet4[1]/pool [ "192.0.3.0/24" ]
 > config commit

   Arrays are counted from 0. subnet[0] refers to the subnet defined in the
   previous example. The config add Dhcp4/subnet4 command adds another
   (second) subnet. It can be referred to as Dhcp4/subnet4[1]. In this
   example, we allow server to dynamically assign all addresses available in
   the whole subnet.

   When configuring a DHCPv4 server using prefix/length notation, please pay
   attention to the boundary values. When specifying that the server should
   use a given pool, it will be able to allocate also first (typically
   network address) and the last (typically broadcast address) address from
   that pool. In the aforementioned example of pool 192.0.3.0/24, both
   192.0.3.0 and 192.0.3.255 addresses may be assigned as well. This may be
   invalid in some network configurations. If you want to avoid this, please
   use the "min-max" notation.

  17.2.4. Standard DHCPv4 options

   One of the major features of DHCPv4 server is to provide configuration
   options to clients. Although there are several options that require
   special behavior, most options are sent by the server only if the client
   explicitly requested them. The following example shows how to configure
   DNS servers, which is one of the most frequently used options. Options
   specified in this way are considered global and apply to all configured
   subnets.

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[0]/name "domain-name-servers"
 > config set Dhcp4/option-data[0]/code 6
 > config set Dhcp4/option-data[0]/space "dhcp4"
 > config set Dhcp4/option-data[0]/csv-format true
 > config set Dhcp4/option-data[0]/data "192.0.3.1, 192.0.3.2"
 > config commit

   The first line creates new entry in option-data table. It contains
   information on all global options that the server is supposed to configure
   in all subnets. The second line specifies option name. For a complete list
   of currently supported names, see Table 17.1, “List of standard DHCPv4
   options” below. The third line specifies option code, which must match one
   of the values from that list. Line 4 specifies option space, which must
   always be set to "dhcp4" as these are standard DHCPv4 options. For other
   option spaces, including custom option spaces, see Section 17.2.7, “Nested
   DHCPv4 options (custom option spaces)”. The fifth line specifies the
   format in which the data will be entered: use of CSV (comma separated
   values) is recommended. The sixth line gives the actual value to be sent
   to clients. Data is specified as a normal text, with values separated by
   commas if more than one value is allowed.

   Options can also be configured as hexadecimal values. If csv-format is set
   to false, option data must be specified as a hex string. The following
   commands configure the domain-name-servers option for all subnets with the
   following addresses: 192.0.3.1 and 192.0.3.2. Note that csv-format is set
   to false.

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[0]/name "domain-name-servers"
 > config set Dhcp4/option-data[0]/code 6
 > config set Dhcp4/option-data[0]/space "dhcp4"
 > config set Dhcp4/option-data[0]/csv-format false
 > config set Dhcp4/option-data[0]/data "C0 00 03 01 C0 00 03 02"
 > config commit


   It is possible to override options on a per-subnet basis. If clients
   connected to most of your subnets are expected to get the same values of a
   given option, you should use global options: you can then override
   specific values for a small number of subnets. On the other hand, if you
   use different values in each subnet, it does not make sense to specify
   global option values (Dhcp4/option-data), rather you should set only
   subnet-specific values (Dhcp4/subnet[X]/option-data[Y]).

   The following commands override the global DNS servers option for a
   particular subnet, setting a single DNS server with address 192.0.2.3.

 > config add Dhcp4/subnet4[0]/option-data
 > config set Dhcp4/subnet4[0]/option-data[0]/name "domain-name-servers"
 > config set Dhcp4/subnet4[0]/option-data[0]/code 6
 > config set Dhcp4/subnet4[0]/option-data[0]/space "dhcp4"
 > config set Dhcp4/subnet4[0]/option-data[0]/csv-format true
 > config set Dhcp4/subnet4[0]/option-data[0]/data "192.0.2.3"
 > config commit

  Note

   In a future version of Kea, it will not be necessary to specify the option
   code, space and csv-format fields as they will be set automatically.

   The currently supported standard DHCPv4 options are listed in Table 17.1,
   “List of standard DHCPv4 options” and Table 17.2, “List of standard DHCPv4
   options (continued)”. The "Name" and "Code" are the values that should be
   used as a name in the option-data structures. "Type" designates the format
   of the data: the meanings of the various types is given in Table 17.3,
   “List of standard DHCP option types”.

   Some options are designated as arrays, which means that more than one
   value is allowed in such an option. For example the option time-servers
   allows the specification of more than one IPv4 address, so allowing
   clients to obtain the the addresses of multiple NTP servers.

   The Section 17.2.5, “Custom DHCPv4 options” describes the configuration
   syntax to create custom option definitions (formats). It is generally not
   allowed to create custom definitions for standard options, even if the
   definition being created matches the actual option format defined in the
   RFCs. There is an exception from this rule for standard options for which
   Kea does not provide a definition yet. In order to use such options, a
   server administrator must create a definition as described in
   Section 17.2.5, “Custom DHCPv4 options” in the 'dhcp4' option space. This
   definition should match the option format described in the relevant RFC
   but configuration mechanism would allow any option format as it has no
   means to validate it at the moment.

   Table 17.1. List of standard DHCPv4 options

   +------------------------------------------------------------+
   |            Name             | Code |     Type     | Array? |
   |-----------------------------+------+--------------+--------|
   | subnet-mask                 | 1    | ipv4-address | false  |
   |-----------------------------+------+--------------+--------|
   | time-offset                 | 2    | int32        | false  |
   |-----------------------------+------+--------------+--------|
   | routers                     | 3    | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | time-servers                | 4    | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | name-servers                | 5    | ipv4-address | false  |
   |-----------------------------+------+--------------+--------|
   | domain-name-servers         | 6    | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | log-servers                 | 7    | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | cookie-servers              | 8    | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | lpr-servers                 | 9    | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | impress-servers             | 10   | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | resource-location-servers   | 11   | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | host-name                   | 12   | string       | false  |
   |-----------------------------+------+--------------+--------|
   | boot-size                   | 13   | uint16       | false  |
   |-----------------------------+------+--------------+--------|
   | merit-dump                  | 14   | string       | false  |
   |-----------------------------+------+--------------+--------|
   | domain-name                 | 15   | fqdn         | false  |
   |-----------------------------+------+--------------+--------|
   | swap-server                 | 16   | ipv4-address | false  |
   |-----------------------------+------+--------------+--------|
   | root-path                   | 17   | string       | false  |
   |-----------------------------+------+--------------+--------|
   | extensions-path             | 18   | string       | false  |
   |-----------------------------+------+--------------+--------|
   | ip-forwarding               | 19   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | non-local-source-routing    | 20   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | policy-filter               | 21   | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | max-dgram-reassembly        | 22   | uint16       | false  |
   |-----------------------------+------+--------------+--------|
   | default-ip-ttl              | 23   | uint8        | false  |
   |-----------------------------+------+--------------+--------|
   | path-mtu-aging-timeout      | 24   | uint32       | false  |
   |-----------------------------+------+--------------+--------|
   | path-mtu-plateau-table      | 25   | uint16       | true   |
   |-----------------------------+------+--------------+--------|
   | interface-mtu               | 26   | uint16       | false  |
   |-----------------------------+------+--------------+--------|
   | all-subnets-local           | 27   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | broadcast-address           | 28   | ipv4-address | false  |
   |-----------------------------+------+--------------+--------|
   | perform-mask-discovery      | 29   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | mask-supplier               | 30   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | router-discovery            | 31   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | router-solicitation-address | 32   | ipv4-address | false  |
   |-----------------------------+------+--------------+--------|
   | static-routes               | 33   | ipv4-address | true   |
   |-----------------------------+------+--------------+--------|
   | trailer-encapsulation       | 34   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | arp-cache-timeout           | 35   | uint32       | false  |
   |-----------------------------+------+--------------+--------|
   | ieee802-3-encapsulation     | 36   | boolean      | false  |
   |-----------------------------+------+--------------+--------|
   | default-tcp-ttl             | 37   | uint8        | false  |
   |-----------------------------+------+--------------+--------|
   | tcp-keepalive-internal      | 38   | uint32       | false  |
   |-----------------------------+------+--------------+--------|
   | tcp-keepalive-garbage       | 39   | boolean      | false  |
   +------------------------------------------------------------+

   Table 17.2. List of standard DHCPv4 options (continued)

   +-------------------------------------------------------------+
   |             Name             | Code |     Type     | Array? |
   |------------------------------+------+--------------+--------|
   | nis-domain                   | 40   | string       | false  |
   |------------------------------+------+--------------+--------|
   | nis-servers                  | 41   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | ntp-servers                  | 42   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | vendor-encapsulated-options  | 43   | empty        | false  |
   |------------------------------+------+--------------+--------|
   | netbios-name-servers         | 44   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | netbios-dd-server            | 45   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | netbios-node-type            | 46   | uint8        | false  |
   |------------------------------+------+--------------+--------|
   | netbios-scope                | 47   | string       | false  |
   |------------------------------+------+--------------+--------|
   | font-servers                 | 48   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | x-display-manager            | 49   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | dhcp-requested-address       | 50   | ipv4-address | false  |
   |------------------------------+------+--------------+--------|
   | dhcp-option-overload         | 52   | uint8        | false  |
   |------------------------------+------+--------------+--------|
   | dhcp-message                 | 56   | string       | false  |
   |------------------------------+------+--------------+--------|
   | dhcp-max-message-size        | 57   | uint16       | false  |
   |------------------------------+------+--------------+--------|
   | vendor-class-identifier      | 60   | binary       | false  |
   |------------------------------+------+--------------+--------|
   | nwip-domain-name             | 62   | string       | false  |
   |------------------------------+------+--------------+--------|
   | nwip-suboptions              | 63   | binary       | false  |
   |------------------------------+------+--------------+--------|
   | tftp-server-name             | 66   | string       | false  |
   |------------------------------+------+--------------+--------|
   | boot-file-name               | 67   | string       | false  |
   |------------------------------+------+--------------+--------|
   | user-class                   | 77   | binary       | false  |
   |------------------------------+------+--------------+--------|
   | fqdn                         | 81   | record       | false  |
   |------------------------------+------+--------------+--------|
   | dhcp-agent-options           | 82   | empty        | false  |
   |------------------------------+------+--------------+--------|
   | authenticate                 | 90   | binary       | false  |
   |------------------------------+------+--------------+--------|
   | client-last-transaction-time | 91   | uint32       | false  |
   |------------------------------+------+--------------+--------|
   | associated-ip                | 92   | ipv4-address | true   |
   |------------------------------+------+--------------+--------|
   | subnet-selection             | 118  | ipv4-address | false  |
   |------------------------------+------+--------------+--------|
   | domain-search                | 119  | binary       | false  |
   |------------------------------+------+--------------+--------|
   | vivco-suboptions             | 124  | binary       | false  |
   |------------------------------+------+--------------+--------|
   | vivso-suboptions             | 125  | binary       | false  |
   +-------------------------------------------------------------+

   Table 17.3. List of standard DHCP option types

   +------------------------------------------------------------------------+
   |     Name     |                         Meaning                         |
   |--------------+---------------------------------------------------------|
   | binary       | An arbitrary string of bytes, specified as a set of     |
   |              | hexadecimal digits.                                     |
   |--------------+---------------------------------------------------------|
   | boolean      | Boolean value with allowed values true or false         |
   |--------------+---------------------------------------------------------|
   | empty        | No value, data is carried in suboptions                 |
   |--------------+---------------------------------------------------------|
   | fqdn         | Fully qualified domain name (e.g. www.example.com)      |
   |--------------+---------------------------------------------------------|
   | ipv4-address | IPv4 address in the usual dotted-decimal notation (e.g. |
   |              | 192.0.2.1)                                              |
   |--------------+---------------------------------------------------------|
   | ipv6-address | IPv6 address in the usual colon notation (e.g.          |
   |              | 2001:db8::1)                                            |
   |--------------+---------------------------------------------------------|
   | record       | Structured data that may comprise any types (except     |
   |              | "record" and "empty")                                   |
   |--------------+---------------------------------------------------------|
   | string       | Any text                                                |
   |--------------+---------------------------------------------------------|
   | uint8        | 8 bit unsigned integer with allowed values 0 to 255     |
   |--------------+---------------------------------------------------------|
   | uint16       | 16 bit unsinged integer with allowed values 0 to 65535  |
   |--------------+---------------------------------------------------------|
   | uint32       | 32 bit unsigned integer with allowed values 0 to        |
   |              | 4294967295                                              |
   +------------------------------------------------------------------------+

  17.2.5. Custom DHCPv4 options

   It is also possible to define options other than the standard ones. Assume
   that we want to define a new DHCPv4 option called "foo" which will have
   code 222 and will convey a single unsigned 32 bit integer value. We can
   define such an option by using the following commands:

 > config add Dhcp4/option-def
 > config set Dhcp4/option-def[0]/name "foo"
 > config set Dhcp4/option-def[0]/code 222
 > config set Dhcp4/option-def[0]/type "uint32"
 > config set Dhcp4/option-def[0]/array false
 > config set Dhcp4/option-def[0]/record-types ""
 > config set Dhcp4/option-def[0]/space "dhcp4"
 > config set Dhcp4/option-def[0]/encapsulate ""
 > config commit

   The "false" value of the "array" parameter determines that the option does
   NOT comprise an array of "uint32" values but rather a single value. Two
   other parameters have been left blank: "record-types" and "encapsulate".
   The former specifies the comma separated list of option data fields if the
   option comprises a record of data fields. The "record-fields" value should
   be non-empty if the "type" is set to "record". Otherwise it must be left
   blank. The latter parameter specifies the name of the option space being
   encapsulated by the particular option. If the particular option does not
   encapsulate any option space it should be left blank. Note that the above
   set of comments define the format of the new option and do not set its
   values.

  Note

   In the current release the default values are not propagated to the parser
   when the new configuration is being set. Therefore, all parameters must be
   specified at all times, even if their values are left blank.

   Once the new option format is defined, its value is set in the same way as
   for a standard option. For example the following commands set a global
   value that applies to all subnets.

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[0]/name "foo"
 > config set Dhcp4/option-data[0]/code 222
 > config set Dhcp4/option-data[0]/space "dhcp4"
 > config set Dhcp4/option-data[0]/csv-format true
 > config set Dhcp4/option-data[0]/data "12345"
 > config commit

   New options can take more complex forms than simple use of primitives
   (uint8, string, ipv4-address etc): it is possible to define an option
   comprising a number of existing primitives.

   Assume we want to define a new option that will consist of an IPv4
   address, followed by unsigned 16 bit integer, followed by a boolean value,
   followed by a text string. Such an option could be defined in the
   following way:

 > config add Dhcp4/option-def
 > config set Dhcp4/option-def[0]/name "bar"
 > config set Dhcp4/option-def[0]/code 223
 > config set Dhcp4/option-def[0]/space "dhcp4"
 > config set Dhcp4/option-def[0]/type "record"
 > config set Dhcp4/option-def[0]/array false
 > config set Dhcp4/option-def[0]/record-types "ipv4-address, uint16, boolean, string"
 > config set Dhcp4/option-def[0]/encapsulate ""

   The "type" is set to "record" to indicate that the option contains
   multiple values of different types. These types are given as a
   comma-separated list in the "record-types" field and should be those
   listed in Table 17.3, “List of standard DHCP option types”.

   The values of the option are set as follows:

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[0]/name "bar"
 > config set Dhcp4/option-data[0]/space "dhcp4"
 > config set Dhcp4/option-data[0]/code 223
 > config set Dhcp4/option-data[0]/csv-format true
 > config set Dhcp4/option-data[0]/data "192.0.2.100, 123, true, Hello World"
 > config commit

   "csv-format" is set "true" to indicate that the "data" field comprises a
   command-separated list of values. The values in the "data" must correspond
   to the types set in the "record-types" field of the option definition.

  Note

   It is recommended that boolean values are specified using "true" and
   "false" strings. This helps to prevent errors when typing multiple comma
   separated values, as it make it easier to identify the type of the value
   being typed, and compare it with the order of data fields. Nevetheless, it
   is possible to use integer values: "1" and "0", instead of "true" and
   "false" accordingly. If other integer value is specified, the
   configuration is rejected.

  17.2.6. DHCPv4 vendor specific options

   Currently there are three option spaces defined: dhcp4 (to be used in
   DHCPv4 daemon) and dhcp6 (for the DHCPv6 daemon); there is also
   vendor-encapsulated-options-space, which is empty by default, but options
   can be defined in it. Those options are called vendor-specific information
   options. The following examples show how to define an option "foo" with
   code 1 that consists of an IPv4 address, an unsigned 16 bit integer and a
   string. The "foo" option is conveyed in a vendor specific information
   option.

   The first step is to define the format of the option:

 > config add Dhcp4/option-def
 > config set Dhcp4/option-def[0]/name "foo"
 > config set Dhcp4/option-def[0]/code 1
 > config set Dhcp4/option-def[0]/space "vendor-encapsulated-options-space"
 > config set Dhcp4/option-def[0]/type "record"
 > config set Dhcp4/option-def[0]/array false
 > config set Dhcp4/option-def[0]/record-types "ipv4-address, uint16, string"
 > config set Dhcp4/option-def[0]/encapsulates ""
 > config commit

   (Note that the option space is set to
   "vendor-encapsulated-options-space".) Once the option format is defined,
   the next step is to define actual values for that option:

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[0]/name "foo"
 > config set Dhcp4/option-data[0]/space "vendor-encapsulated-options-space"
 > config set Dhcp4/option-data[0]/code 1
 > config set Dhcp4/option-data[0]/csv-format true
 > config set Dhcp4/option-data[0]/data "192.0.2.3, 123, Hello World"
 > config commit

   We also set up a dummy value for vendor-opts, the option that conveys our
   sub-option "foo". This is required else the option will not be included in
   messages sent to the client.

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[1]/name "vendor-encapsulated-options"
 > config set Dhcp4/option-data[1]/space "dhcp4"
 > config set Dhcp4/option-data[1]/code 43
 > config set Dhcp4/option-data[1]/csv-format false
 > config set Dhcp4/option-data[1]/data ""
 > config commit

  Note

   With this version of BIND 10, the "vendor-encapsulated-options" option
   must be specified in the configuration although it has no configurable
   parameters. If it is not specified, the server will assume that it is not
   configured and will not send it to a client. In the future there will be
   no need to include this option in the configuration.

  17.2.7. Nested DHCPv4 options (custom option spaces)

   It is sometimes useful to define completely new option space. This is the
   case when user creates new option in the standard option space ("dhcp4 or
   "dhcp6") and wants this option to convey sub-options. Thanks to being in
   the separate space, sub-option codes will have a separate numbering scheme
   and may overlap with codes of standard options.

   Note that creation of a new option space when defining sub-options for a
   standard option is not required, because it is created by default if the
   standard option is meant to convey any sub-options (see Section 17.2.6,
   “DHCPv4 vendor specific options”).

   Assume that we want to have a DHCPv4 option called "container" with code
   222 that conveys two sub-options with codes 1 and 2. First we need to
   define the new sub-options:

 > config add Dhcp4/option-def
 > config set Dhcp4/option-def[0]/name "subopt1"
 > config set Dhcp4/option-def[0]/code 1
 > config set Dhcp4/option-def[0]/space "isc"
 > config set Dhcp4/option-def[0]/type "ipv4-address"
 > config set Dhcp4/option-def[0]/record-types ""
 > config set Dhcp4/option-def[0]/array false
 > config set Dhcp4/option-def[0]/encapsulate ""
 > config commit

 > config add Dhcp4/option-def
 > config set Dhcp4/option-def[1]/name "subopt2"
 > config set Dhcp4/option-def[1]/code 2
 > config set Dhcp4/option-def[1]/space "isc"
 > config set Dhcp4/option-def[1]/type "string"
 > config set Dhcp4/option-def[1]/record-types ""
 > config set Dhcp4/option-def[1]/array false
 > config set Dhcp4/option-def[1]/encapsulate ""
 > config commit

   Note that we have defined the options to belong to a new option space (in
   this case, "isc").

   The next step is to define a regular DHCPv4 option with our desired code
   and specify that it should include options from the new option space:

 > add Dhcp4/option-def
 > set Dhcp4/option-def[2]/name "container"
 > set Dhcp4/option-def[2]/code 222
 > set Dhcp4/option-def[2]/space "dhcp4"
 > set Dhcp4/option-def[2]/type "empty"
 > set Dhcp4/option-def[2]/array false
 > set Dhcp4/option-def[2]/record-types ""
 > set Dhcp4/option-def[2]/encapsulate "isc"
 > commit

   The name of the option space in which the sub-options are defined is set
   in the "encapsulate" field. The "type" field is set to "empty" to indicate
   that this option does not carry any data other than sub-options.

   Finally, we can set values for the new options:

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[0]/name "subopt1"
 > config set Dhcp4/option-data[0]/space "isc"
 > config set Dhcp4/option-data[0]/code 1
 > config set Dhcp4/option-data[0]/csv-format true
 > config set Dhcp4/option-data[0]/data "192.0.2.3"
 > config commit

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[1]/name "subopt2"
 > config set Dhcp4/option-data[1]/space "isc"
 > config set Dhcp4/option-data[1]/code 2
 > config set Dhcp4/option-data[1]/csv-format true
 > config set Dhcp4/option-data[1]/data "Hello world"
 > config commit

 > config add Dhcp4/option-data
 > config set Dhcp4/option-data[2]/name "container"
 > config set Dhcp4/option-data[2]/space "dhcp4"
 > config set Dhcp4/option-data[2]/code 222
 > config set Dhcp4/option-data[2]/csv-format true
 > config set Dhcp4/option-data[2]/data ""
 > config commit

   Even though the "container" option does not carry any data except
   sub-options, the "data" field must be explicitly set to an empty value.
   This is required because in the current version of BIND 10 DHCP, the
   default configuration values are not propagated to the configuration
   parsers: if the "data" is not set the parser will assume that this
   parameter is not specified and an error will be reported.

   Note that it is possible to create an option which carries some data in
   addition to the sub-options defined in the encapsulated option space. For
   example, if the "container" option from the previous example was required
   to carry an uint16 value as well as the sub-options, the "type" value
   would have to be set to "uint16" in the option definition. (Such an option
   would then have the following data structure: DHCP header, uint16 value,
   sub-options.) The value specified with the "data" parameter - which should
   be a valid integer enclosed in quotes, e.g. "123" - would then be assigned
   to the uint16 field in the "container" option.

  17.2.8. Client Classification in DHCPv4

  Note

   DHCPv4 server has been extended to support limited client classification.
   Although the current capability is modest, it is expected to be expanded
   in the future. It is envisaged that the majority of client classification
   extensions will be using hooks extensions.

   In certain cases it is useful to differentiate between different types of
   clients and treat them differently. The process of doing classification is
   conducted in two steps. The first step is to assess incoming packet and
   assign it to zero or more classes. This classification is currently
   simple, but is expected to grow in capability soon. Currently the server
   checks whether incoming packet has vendor class identifier option (60). If
   it has, content of that option is prepended with "VENDOR_CLASS_" then is
   interpreted as a class. For example, modern cable modems will send this
   option with value "docsis3.0" and as a result the packet will belong to
   class "VENDOR_CLASS_docsis3.0".

   It is envisaged that the client classification will be used for changing
   behavior of almost any part of the DHCP message processing, including
   assigning leases from different pools, assigning different option (or
   different values of the same options) etc. For now, there are only two
   mechanisms that are taking advantage of client classification: specific
   processing for cable modems and subnet selection.

   For clients that belong to the VENDOR_CLASS_docsis3.0 class, the siaddr
   field is set to the value of next-server (if specified in a subnet). If
   there is boot-file-name option specified, its value is also set in the
   file field in the DHCPv4 packet. For eRouter1.0 class, the siaddr is
   always set to 0.0.0.0. That capability is expected to be moved to external
   hook library that will be dedicated to cable modems.

   Kea can be instructed to limit access to given subnets based on class
   information. This is particularly useful for cases where two types of
   devices share the same link and are expected to be served from two
   different subnets. The primary use case for such a scenario is cable
   networks. There are two classes of devices: cable modem itself, which
   should be handled a lease from subnet A and all other devices behind
   modems that should get a lease from subnet B. That segregation is
   essential to prevent overly curious users from playing with their cable
   modems. For details on how to set up class restrictions on subnets, see
   Section 17.2.9, “Limiting access to IPv4 subnet to certain classes”.

  17.2.9. Limiting access to IPv4 subnet to certain classes

   In certain cases it beneficial to restrict access to certain subnets only
   to clients that belong to a given subnet. For details on client classes,
   see Section 17.2.8, “Client Classification in DHCPv4”. This is an
   extension of a previous example from Section 17.2.3, “Configuration of
   IPv4 Address Pools”. Let's assume that the server is connected to a
   network segment that uses the 192.0.2.0/24 prefix. The Administrator of
   that network has decided that addresses from range 192.0.2.10 to
   192.0.2.20 are going to be managed by the Dhcp4 server. Only clients
   belonging to client class VENDOR_CLASS_docsis3.0 are allowed to use this
   subnet. Such a configuration can be achieved in the following way:

 > config add Dhcp4/subnet4
 > config set Dhcp4/subnet4[0]/subnet "192.0.2.0/24"
 > config set Dhcp4/subnet4[0]/pool [ "192.0.2.10 - 192.0.2.20" ]
 > config set Dhcp4/subnet4[0]/client-class "VENDOR_CLASS_docsis3.0"
 > config commit

   Care should be taken with client classification as it is easy to prevent
   clients that do not meet class criteria to be denied any service
   altogether.

  17.2.10. Configuring DHCPv4 for DDNS

   As mentioned earlier, DHCPv4 can be configured to generate requests to the
   DHCP-DDNS server to update DNS entries. These requests are known as
   NameChangeRequests or NCRs. Each NCR contains the following information:

    1. Whether it is a request to add (update) or remove DNS entries

    2. Whether the change requests forward DNS updates (A records), reverse
       DNS updates (PTR records), or both.

    3. The FQDN, lease address, and DHCID

   The paramaters for controlling the generation of NCRs for submission to D2
   are contained in the "dhcp-ddns" section of the DHCPv4 server
   configuration. The default values for this section appears as follows:

 > config show Dhcp4/dhcp-ddns
 Dhcp4/dhcp-ddns/enable-updates  true    boolean
 Dhcp4/dhcp-ddns/server-ip       "127.0.0.1"     string
 Dhcp4/dhcp-ddns/server-port     53001   integer
 Dhcp4/dhcp-ddns/ncr-protocol    "UDP"   string
 Dhcp4/dhcp-ddns/ncr-format      "JSON"  string
 Dhcp4/dhcp-ddns/override-no-update      false   boolean
 Dhcp4/dhcp-ddns/override-client-update  false   boolean
 Dhcp4/dhcp-ddns/replace-client-name     false   boolean
 Dhcp4/dhcp-ddns/generated-prefix        "myhost"        string
 Dhcp4/dhcp-ddns/qualifying-suffix       "example.com"   string

   The "enable-updates" parameter determines whether or not DHCPv4 will
   generate NCRs. By default, this value is false hence DDNS updates are
   disabled. To enable DDNS updates set this value to true:

 > config set Dhcp4/dhcp-ddns/enable-updates true
 > config commit

    17.2.10.1. DHCP-DDNS Server Connectivty

   In order for NCRs to reach the D2 server, DHCPv4 must be able to
   communicate with it and so the relevant parameters must be set
   appropriately. The parameters, "server-ip" and "server-port", specify the
   address of the D2 server. By default, D2 is assumed to running on the same
   machine as DHCPv4, and the default values for these two parameters should
   be sufficient. However, if D2 has been configured to listen on a different
   address or port, these values must altered accordingly. For example, if D2
   has been configured to listen on 198.162.1.10 port 900, the following
   commands would be required:

 > config set Dhcp4/dhcp-ddns/server-ip "198.162.1.10"
 > config set Dhcp4/dhcp-ddns/server-port 900
 > config commit

   D2 can be configured to listen over IPv4 or IPv6, therefore server-ip may
   be either an IPv4 or IPv6 address.

   The socket protocol that DHCPv4 should use to communicate with D2 is
   specified with the "ncr-protocol" parameter. Currently only UDP is
   supported.

   The internal format for DDNS update requests sent by DHCPv4 is specified
   with the "ncr-format" parameter. Currently only JSON is supported.

    17.2.10.2. When does the DHCPv4 server generate DDNS requests?

   DHCPv4 follows the behavior prescribed for DHCP servers in RFC 4702. It is
   important to keep in mind that DHCPv4 provides the initial decision making
   of when and what to update and forwards that information to D2 in the form
   of NCRs. Carrying out the actual DNS updates and dealing with such things
   as conflict resolution are the purvue of D2 (Chapter 19, The DHCP-DDNS
   Server).

   This section describes when DHCPv4 will generate NCRs and the
   configuration parameters that can be used to influence this decision. It
   assumes that the "enable-updates" paramater is true.

   In general, DHCPv4 will generate DDNS udpate requests when:

    1. A new lease is granted in response to a DHCP REQUEST

    2. An existing lease is renewed but the FQDN associated with it has
       changed.

    3. An existing lease is released in response to a DHCP RELEASE

   In the second case, lease renewal, two DDNS requests will be issued: one
   request to remove entries for the previous FQDN and a second request to
   add entries for the new FQDN. In the last case, a lease release, a single
   DDNS request to remove its entries will be made. The decision making
   involved when granting a new lease (the first case) is more involved and
   is discussed next.

   When a new lease is granted, the DHCPv4 server will generate a DDNS update
   request if the DHCP REQUEST contains either the FQDN option (code 81) or
   the Host Name option (code 12). If both are present, the server will use
   the FQDN option. By default the DHCPv4 server will respect the FQDN N and
   S flags specified by the client as shown in the following table:

   Table 17.4. Default FQDN Flag Behavior

   +------------------------------------------------------------------------+
   | Client    | Client Intent           | Server Response    | Server      |
   | Flags:N-S |                         |                    | Flags:N-S-O |
   |-----------+-------------------------+--------------------+-------------|
   |           | Client wants to do      | Server generates   |             |
   | 0-0       | forward updates, server | reverse-only       | 1-0-0       |
   |           | should do reverse       | request            |             |
   |           | updates                 |                    |             |
   |-----------+-------------------------+--------------------+-------------|
   |           | Server should do both   | Server generates   |             |
   | 0-1       | forward and reverse     | request to update  | 0-1-0       |
   |           | updates                 | both directions    |             |
   |-----------+-------------------------+--------------------+-------------|
   | 1-0       | Client wants no updates | Server does not    | 1-0-0       |
   |           | done                    | generate a request |             |
   +------------------------------------------------------------------------+

   The first row in the table above represents "client delegation". Here the
   DHCP client states that it intends to do the forward DNS updates and the
   server should do the reverese updates. By default, DHCPv4 will honor the
   client's wishes and generate a DDNS request to D2 to update only reverse
   DNS data. The parameter, "override-client-update", can be used to instruct
   the server to override client delegation requests. When this parameter is
   true, DHCPv4 will disregard requests for client delegation and generate a
   DDNS request to update both forward and reverse DNS data. In this case,
   the N-S-O flags in the server's response to the client will be 0-1-1
   respectively.

   (Note that the flag combination N=1, S=1 is prohibited according to RFC
   4702. If such a combination is received from the client, the packet will
   be dropped by the DHCPv4 server.)

   To override client delegation, issue the following commands:

 > config set Dhcp4/dhcp-ddns/override-client-update true
 > config commit

   The third row in the table above describes the case in which the client
   requests that no DNS updates be done. The parameter, "override-no-update",
   can be used to instruct the server to disregard the client's wishes. When
   this parameter is true, DHCPv4 will generate DDNS udpate request to D2
   even if the client requests no updates be done. The N-S-O flags in the
   server's response to the client will be 0-1-1.

   To override client delegation, issue the following commands:

 > config set Dhcp4/dhcp-ddns/override-no-update true
 > config commit

   DHCPv4 will always generate DDNS update requests if the client request
   only contains the Host Name option. In addition it will include an FQDN
   option in the response to the client with the FQDN N-S-O flags set to
   0-1-0 respectively. The domain name portion of the FQDN option will be the
   name submitted to D2 in the DDNS update request.

    17.2.10.3. DHCPv4 name generation for DDNS update requests

   Each NameChangeRequest must of course include the fully qualified domain
   name whose DNS entries are to be affected. DHCPv4 can be configured to
   supply a portion or all of that name based upon what it receives from the
   client in the DHCP REQUEST.

   The rules for determining the FQDN option are as follows:

    1. If configured to do, so ignore the REQUEST contents and generate a
       FQDN using a configurable prefix and suffix.

    2. If the REQUEST contains the client FQDN option, the candidate name is
       taken from there, otherwise it is taken from the Host Name option. The
       candiate name may then be modified:

         a. If the candidate name is a fully qualified domain name, use it.

         b. If the candidate name is a partial (i.e. unqualified) name then
            add a configurable suffix to the name and use the result as the
            FQDN.

         c. If the candidate name is a empty, generate a FQDN using a
            configurable prefix and suffix.

   To instruct DHCPv4 to always generate the FQDN for a client, set the
   parameter "replace-client-name" to true as follows:

 > config set Dhcp4/dhcp-ddns/replace-client-name true
 > config commit

   The prefix used in the generation of a FQDN is specified by the
   "generated-prefix" parameter. The default value is "myhost". To alter its
   value simply set it to the desired string:

 > config set Dhcp4/dhcp-ddns/generated-prefix "another.host"
 > config commit

   The suffix used when generating a FQDN or when qualifying a partial name
   is specified by the "qualifying-suffix" parameter. The default value is
   "example.com". To alter its value simply set it to the desired string:

 > config set Dhcp4/dhcp-ddns/generated-prefix "our.net"
 > config commit

   When generating a name, DHCPv4 will construct name of the format:

   [generated-prefix]-[address-text].[qualifying-suffix].

   where address-text is simply the lease IP address converted to a
   hyphenated string. For example, if lease address is 172.16.1.10 and
   assuming default values for generated-prefix and qualifying-suffix, the
   generated FQDN would be:

   myhost-172-16-1-10.example.com.

17.3. Server Identifier in DHCPv4

   The DHCPv4 protocol uses a "server identifier" for clients to be able to
   discriminate between several servers present on the same link: this value
   is an IPv4 address of the server. The server chooses the IPv4 address of
   the interface on which the message from the client (or relay) has been
   received. A single server instance will use multiple server identifiers if
   it is receiving queries on multiple interfaces.

   Currently there is no mechanism to override the default server identifiers
   by an administrator. In the future, the configuration mechanism will be
   used to specify the custom server identifier.

17.4. Next server (siaddr)

   In some cases, clients want to obtain configuration from the TFTP server.
   Although there is a dedicated option for it, some devices may use siaddr
   field in the DHCPv4 packet for that purpose. That specific field can be
   configured using next-server directive. It is possible to define it in
   global scope or for a given subnet only. If both are defined, subnet value
   takes precedence. The value in subnet can be set to 0.0.0.0, which means
   that next-server should not be sent. It may also be set to empty string,
   which means the same as if it was not defined at all - use global value.

 > config add Dhcp4/next-server
 > config set Dhcp4/next-server "192.0.2.123"
 > config commit

 > config add Dhcp4/subnet[0]/next-server
 > config set Dhcp4/subnet[0]/next-server "192.0.2.234"
 > config commit

17.5. Echoing client-id (RFC6842)

   Original DHCPv4 spec (RFC2131) states that the DHCPv4 server must not send
   back client-id options when responding to clients. However, in some cases
   that confused clients that did not have MAC address or client-id. See
   RFC6842 for details. That behavior has changed with the publication of
   RFC6842 which updated RFC2131. That update now states that the server must
   send client-id if client sent it. That is the default behaviour that Kea
   offers. However, in some cases older devices that do not support RFC6842
   may refuse to accept responses that include client-id option. To enable
   backward compatibility, an optional configuration parameter has been
   introduced. To configure it, use the following commands:

 > config add Dhcp4/echo-client-id
 > config set Dhcp4/echo-client-id False
 > config commit

17.6. How DHCPv4 server selects subnet for a client

   The DHCPv4 server differentiates between the directly connected clients,
   clients trying to renew leases and clients sending their messages through
   relays. For the directly connected clients the server will check the
   configuration of the interface on which the message has been received, and
   if the server configuration doesn't match any configured subnet the
   message is discarded.

   Assuming that the server's interface is configured with the 192.0.2.3 IPv4
   address, the server will only process messages received through this
   interface from the directly connected client, if there is a subnet
   configured, to which this IPv4 address belongs, e.g. 192.0.2.0/24. The
   server will use this subnet to assign IPv4 address for the client.

   The rule above does not apply when the client unicasts its message, i.e.
   is trying to renew its lease. Such message is accepted through any
   interface. The renewing client sets ciaddr to the currently used IPv4
   address. The server uses this address to select the subnet for the client
   (in particular, to extend the lease using this address).

   If the message is relayed it is accepted through any interface. The giaddr
   set by the relay agent is used to select the subnet for the client.

   It is also possible to specify a relay IPv4 address for a given subnet. It
   can be used to match incoming packets into a subnet in uncommon
   configurations, e.g. shared subnets. See Section 17.7, “Using specific
   relay agent for a subnet” for details.

  Note

   The subnet selection mechanism described in this section is based on the
   assumption that client classification is not used. The classification
   mechanism alters the way in which subnet is selected for the client,
   depending on the clasess that the client belongs to.

17.7. Using specific relay agent for a subnet

   The relay has to have an interface connected to the link on which the
   clients are being configured. Typically the relay has an IPv4 address
   configured on that interface that belongs to the subnet that the server
   will assign addresses from. In such typical case, the server is able to
   use IPv4 address inserted by the relay (in GIADDR field of the DHCPv4
   packet) to select appropriate subnet.

   However, that is not always the case. In certain uncommon, but valid
   deployments, the relay address may not match the subnet. This usually
   means that there is more than one subnet allocated for a given link. Two
   most common examples where this is the case are long lasting network
   renumbering (where both old and new address space is still being used) and
   a cable network. In a cable network both cable modems and the devices
   behind them are physically connected to the same link, yet they use
   distinct addressing. In such case, the DHCPv4 server needs additional
   information (IPv4 address of the relay) to properly select an appropriate
   subnet.

   The following example assumes that there is a subnet 192.0.2.0/24 that is
   accessible via relay that uses 10.0.0.1 as its IPv4 address. The server
   will be able to select this subnet for any incoming packets that came from
   a relay that has an address in 192.0.2.0/24 subnet. It will also select
   that subnet for a relay with address 10.0.0.1.

 > config add Dhcp4/subnet4
 > config set Dhcp4/subnet4[0]/subnet "192.0.2.0/24"
 > config set Dhcp4/subnet4[0]/pool [ "192.0.2.10 - 192.0.2.20" ]
 > config set Dhcp4/subnet4[0]/relay/ip-address "10.0.0.1"
 > config commit

17.8. Segregating IPv4 clients in a cable network

   In certain cases, it is useful to mix relay address information,
   introduced in Section 17.7, “Using specific relay agent for a subnet” with
   client classification, explained in Section 17.2.9, “Limiting access to
   IPv4 subnet to certain classes”. One specific example is cable network,
   where typically modems get addresses from a different subnet than all
   devices connected behind them.

   Let's assume that there is one CMTS (Cable Modem Termination System) with
   one CM MAC (a physical link that modems are connected to). We want the
   modems to get addresses from the 10.1.1.0/24 subnet, while everything
   connected behind modems should get addresses from another subnet
   (192.0.2.0/24). The CMTS that acts as a relay an uses address 10.1.1.1.
   The following configuration can serve that configuration:

 > config add Dhcp4/subnet4
 > config set Dhcp4/subnet4[0]/subnet "10.1.1.0/24"
 > config set Dhcp4/subnet4[0]/pool [ "10.1.1.2 - 10.1.1.20" ]
 > config set Dhcp4/subnet4[0]/client-class "docsis3.0"
 > config set Dhcp4/subnet4[0]/relay/ip-address "10.1.1.1"
 > config add Dhcp4/subnet4
 > config set Dhcp4/subnet4[1]/subnet "192.0.2.0/24"
 > config set Dhcp4/subnet4[1]/pool [ "192.0.2.10 - 192.0.2.20" ]
 > config set Dhcp4/subnet4[1]/relay/ip-address "10.1.1.1"
 > config commit

17.9. Supported Standards

   The following standards and draft standards are currently supported:

     * RFC 2131: Supported messages are DISCOVER, OFFER, REQUEST, RELEASE,
       ACK, and NAK.
     * RFC 2132: Supported options are: PAD (0), END(255), Message Type(53),
       DHCP Server Identifier (54), Domain Name (15), DNS Servers (6), IP
       Address Lease Time (51), Subnet mask (1), and Routers (3).
     * RFC 3046: Relay Agent Information option is supported.
     * RFC 6842: Server by default sends back client-id option. That
       capability may be disabled. See Section 17.5, “Echoing client-id
       (RFC6842)” for details.

17.10. DHCPv4 Server Limitations

   These are the current limitations of the DHCPv4 server software. Most of
   them are reflections of the current stage of development and should be
   treated as “not implemented yet”, rather than actual limitations.

     * On-line configuration has some limitations. Adding new subnets or
       modifying existing ones work, as is removing the last subnet from the
       list. However, removing non-last (e.g. removing subnet 1,2 or 3 if
       there are 4 subnets configured) will cause issues. The problem is
       caused by simplistic subnet-id assignment. The subnets are always
       numbered, starting from 1. That subnet-id is then used in leases that
       are stored in the lease database. Removing non-last subnet will cause
       the configuration information to mismatch data in the lease database.
       It is possible to manually update subnet-id fields in MySQL database,
       but it is awkward and error prone process. A better reconfiguration
       support is planned.

     * On startup, the DHCPv4 server does not get the full configuration from
       BIND 10. To remedy this, after starting BIND 10, modify any parameter
       and commit the changes, e.g.

 > config show Dhcp4/renew-timer
 Dhcp4/renew-timer       1000    integer (default)
 > config set Dhcp4/renew-timer 1001
 > config commit

     * The DHCPv4 server does not support BOOTP. That is a design choice and
       the limitation is permanent. If you have legacy nodes that can't use
       DHCP and require BOOTP support, please use the latest version of ISC
       DHCP, available from http://www.isc.org/software/dhcp.
     * Raw sockets operation is working on Linux only. See Section 20.1,
       “Interface detection and Socket handling” for details.
     * The DHCPv4 server does not verify that assigned address is unused.
       According to RFC 2131, the allocating server should verify that
       address is not used by sending ICMP echo request.
     * Address rebinding (REBIND) and duplication report (DECLINE) are not
       supported yet.
     * DNS Update is not yet supported.

   --------------------------------------------------------------------------

   ^[1] The server comes with an in-memory database ("memfile") configured as
   the default database. This is used for internal testing and is not
   supported. In addition, it does not store lease information on disk: lease
   information will be lost if the server is restarted.

                         Chapter 18. The DHCPv6 Server

   Table of Contents

   18.1. Starting and Stopping the DHCPv6 Server

   18.2. DHCPv6 Server Configuration

                18.2.1. Database Configuration

                18.2.2. Interface selection

                18.2.3. Unicast traffic support

                18.2.4. Subnet and Address Pool

                18.2.5. Subnet and Prefix Delegation Pools

                18.2.6. Standard DHCPv6 options

                18.2.7. Custom DHCPv6 options

                18.2.8. DHCPv6 vendor specific options

                18.2.9. Nested DHCPv6 options (custom option spaces)

                18.2.10. IPv6 Subnet Selection

                18.2.11. DHCPv6 Relays

                18.2.12. Client Classification in DHCPv6

                18.2.13. Limiting access to IPv6 subnet to certain classes

                18.2.14. Configuring DHCPv6 for DDNS

   18.3. Server Identifier in DHCPv6

   18.4. Using specific relay agent for a subnet

   18.5. Segregating IPv6 clients in a cable network

   18.6. Supported Standards

   18.7. DHCPv6 Server Limitations

18.1. Starting and Stopping the DHCPv6 Server

   b10-dhcp6 is the BIND 10 DHCPv6 server and, like other parts of BIND 10,
   is configured through the bindctl program.

   After starting BIND 10 and starting bindctl, the first step in configuring
   the server is to add b10-dhcp6 to the list of running BIND 10 services.

 > config add Init/components b10-dhcp6
 > config set Init/components/b10-dhcp6/kind dispensable
 > config commit

   To remove b10-dhcp6 from the set of running services, the b10-dhcp6 is
   removed from list of Init components:

 > config remove Init/components b10-dhcp6
 > config commit

   Note that the server was only removed from the list, so BIND10 will not
   restart it, but the server itself is still running. Hence it is usually
   desired to stop it:

 > Dhcp6 shutdown

   During start-up the server will detect available network interfaces and
   will attempt to open UDP sockets on all interfaces that are up, running,
   are not loopback, are multicast-capable, and have IPv6 address assigned.
   It will then listen to incoming traffic.

18.2. DHCPv6 Server Configuration

   Once the server has been started, it can be configured. To view the
   current configuration, use the following command in bindctl:

 > config show Dhcp6

   When starting the Dhcp6 daemon for the first time, the default
   configuration will be available. It will look similar to this:

 > config show Dhcp6
 Dhcp6/hooks-libraries   []  list    (default)
 Dhcp6/interfaces/   list    (default)
 Dhcp6/renew-timer   1000    integer (default)
 Dhcp6/rebind-timer  2000    integer (default)
 Dhcp6/preferred-lifetime    3000    integer (default)
 Dhcp6/valid-lifetime    4000    integer (default)
 Dhcp6/option-def    []  list    (default)
 Dhcp6/option-data   []  list    (default)
 Dhcp6/lease-database/type   ""  string  (default)
 Dhcp6/lease-database/name   ""  string  (default)
 Dhcp6/lease-database/user   ""  string  (default)
 Dhcp6/lease-database/host   ""  string  (default)
 Dhcp6/lease-database/password   ""  string  (default)
 Dhcp6/subnet6/  list
 Dhcp6/dhcp-ddns/enable-updates  true    boolean
 Dhcp6/dhcp-ddns/server-ip   "127.0.0.1" string
 Dhcp6/dhcp-ddns/server-port 53001   integer
 Dhcp6/dhcp-ddns/ncr-protocol    "UDP"   string
 Dhcp6/dhcp-ddns/ncr-format  "JSON"  string
 Dhcp6/dhcp-ddns/always-include-fqdn false   boolean
 Dhcp6/dhcp-ddns/override-no-update  false   boolean
 Dhcp6/dhcp-ddns/override-client-update  false   boolean
 Dhcp6/dhcp-ddns/replace-client-name false   boolean
 Dhcp6/dhcp-ddns/generated-prefix    "myhost"    string
 Dhcp6/dhcp-ddns/qualifying-suffix   "example.com"   string

   To change one of the parameters, simply follow the usual bindctl
   procedure. For example, to make the leases longer, change their
   valid-lifetime parameter:

 > config set Dhcp6/valid-lifetime 7200
 > config commit

   Most Dhcp6 parameters are of global scope and apply to all defined
   subnets, unless they are overridden on a per-subnet basis.

  Note

   With this version of BIND 10, there are a number of known limitations and
   problems in the DHCPv6 server. See Section 18.7, “DHCPv6 Server
   Limitations”.

  18.2.1. Database Configuration

   All leases issued by the server are stored in the lease database.
   Currently, the only supported database is MySQL ^[2], and so the server
   must be configured to access the correct database with the appropriate
   credentials.

  Note

   Database access information must be configured for the DHCPv6 server, even
   if it has already been configured for the DHCPv4 server. The servers store
   their information independently, so each server can use a separate
   database or both servers can use the same database.

   Database configuration is controlled through the Dhcp6/lease-database
   parameters. The type of the database must be set to MySQL (although the
   string entered is "mysql"):

 > config set Dhcp6/lease-database/type "mysql"

   Next, the name of the database is to hold the leases must be set: this is
   the name used when the lease database was created (see Section 16.1.3,
   “Create MySQL Database and BIND 10 User”).

 > config set Dhcp6/lease-database/name "database-name"

   If the database is located on a different system to the DHCPv6 server, the
   database host name must also be specified (although note that this
   configuration may have a severe impact on server performance):

 > config set Dhcp6/lease-database/host "remote-host-name"

   The usual state of affairs will be to have the database on the same
   machine as the DHCPv6 server. In this case, set the value to the empty
   string (this is the default):

 > config set Dhcp6/lease-database/host ""

   Finally, the credentials of the account under which the server will access
   the database should be set:

 > config set Dhcp6/lease-database/user "user-name"
 > config set Dhcp6/lease-database/password "password"

   If there is no password to the account, set the password to the empty
   string "". (This is also the default.)

  Note

   The password is echoed when entered and is stored in clear text in the
   BIND 10 configuration database. Improved password security will be added
   in a future version of BIND 10 DHCP

  18.2.2. Interface selection

   When DHCPv6 server starts up, by default it will listen to the DHCP
   traffic and respond to it on all interfaces detected during startup.
   However, in many cases it is desired to configure the server to listen and
   respond on selected interfaces only. The sample commands in this section
   show how to make interface selection using bindctl.

   The default configuration can be presented with the following command:

 > config show Dhcp6/interfaces
 Dhcp6/interfaces[0] "*" string

   An asterisk sign plays a role of the wildcard and means "listen on all
   interfaces".

   In order to override the default configuration, the existing entry can be
   replaced with the actual interface name:

 > config set Dhcp6/interfaces[0] eth1
 > config commit

   Other interface names can be added on one-by-one basis:

 > config add Dhcp6/interfaces eth2
 > config commit

   Configuration will now contain two interfaces which can be presented as
   follows:

 > config show Dhcp6/interfaces
 Dhcp6/interfaces[0]     "eth1"  string
 Dhcp6/interfaces[1]     "eth2"  string

   When configuration gets committed, the server will start to listen on eth1
   and eth2 interfaces only.

   It is possible to use wildcard interface name (asterisk) concurrently with
   explicit interface names:

 > config add Dhcp6/interfaces *
 > config commit

   This will result in the following configuration:

 > config show Dhcp6/interfaces
 Dhcp6/interfaces[0]     "eth1"  string
 Dhcp6/interfaces[1]     "eth2"  string
 Dhcp6/interfaces[2]     "*"     string

   The presence of the wildcard name implies that server will listen on all
   interfaces. In order to fall back to the previous configuration when
   server listens on eth1 and eth2:

 > config remove Dhcp6/interfaces[2]
 > config commit

  18.2.3. Unicast traffic support

   When DHCPv6 server starts up, by default it listens to the DHCP traffic
   sent to multicast address ff02::1:2 on each interface that it is
   configured to listen on (see Section 18.2.2, “Interface selection”). In
   some cases it is useful to configure a server to handle incoming traffic
   sent to the global unicast addresses as well. The most common reason for
   that is to have relays send their traffic to the server directly. To
   configure server to listen on specific unicast address, a notation to
   specify interfaces has been extended. Interface name can be optionally
   followed by a slash, followed by global unicast address that server should
   listen on. That will be done in addition to normal link-local binding +
   listening on ff02::1:2 address. The sample commands listed below show how
   to listen on 2001:db8::1 (a global address) configured on the eth1
   interface.

 > config set Dhcp6/interfaces[0] eth1/2001:db8::1
 > config commit

   When configuration gets committed, the server will start to listen on eth1
   on link-local address, mutlicast group (ff02::1:2) and 2001:db8::1.

   It is possible to mix interface names, wildcards and interface
   name/addresses on the Dhcp6/interface list. It is not possible to specify
   more than one unicast address on a given interface.

   Care should be taken to specify proper unicast addresses. The server will
   attempt to bind to those addresses specified, without any additional
   checks. That approach is selected on purpose, so in the software can be
   used to communicate over uncommon addresses if the administrator desires
   so.

  18.2.4. Subnet and Address Pool

   The essential role of a DHCPv6 server is address assignment. For this, the
   server has to be configured with at least one subnet and one pool of
   dynamic addresses to be managed. For example, assume that the server is
   connected to a network segment that uses the 2001:db8:1::/64 prefix. The
   Administrator of that network has decided that addresses from range
   2001:db8:1::1 to 2001:db8:1::ffff are going to be managed by the Dhcp6
   server. Such a configuration can be achieved in the following way:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[0]/subnet "2001:db8:1::/64"
 > config set Dhcp6/subnet6[0]/pool [ "2001:db8:1::0 - 2001:db8:1::ffff" ]
 > config commit

   Note that subnet is defined as a simple string, but the pool parameter is
   actually a list of pools: for this reason, the pool definition is enclosed
   in square brackets, even though only one range of addresses is specified.

   It is possible to define more than one pool in a subnet: continuing the
   previous example, further assume that 2001:db8:1:0:5::/80 should be also
   be managed by the server. It could be written as 2001:db8:1:0:5:: to
   2001:db8:1::5:ffff:ffff:ffff, but typing so many 'f's is cumbersome. It
   can be expressed more simply as 2001:db8:1:0:5::/80. Both formats are
   supported by Dhcp6 and can be mixed in the pool list. For example, one
   could define the following pools:

 > config set Dhcp6/subnet6[0]/pool [ "2001:db8:1::1 - 2001:db8:1::ffff", "2001:db8:1:0:5::/80" ]
 > config commit

   The number of pools is not limited, but for performance reasons it is
   recommended to use as few as possible.

   The server may be configured to serve more than one subnet. To add a
   second subnet, use a command similar to the following:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[1]/subnet "2001:db8:beef::/48"
 > config set Dhcp6/subnet6[1]/pool [ "2001:db8:beef::/48" ]
 > config commit

   Arrays are counted from 0. subnet[0] refers to the subnet defined in the
   previous example. The config add Dhcp6/subnet6 command adds another
   (second) subnet. It can be referred to as Dhcp6/subnet6[1]. In this
   example, we allow server to dynamically assign all addresses available in
   the whole subnet. Although very wasteful, it is certainly a valid
   configuration to dedicate the whole /48 subnet for that purpose.

   When configuring a DHCPv6 server using prefix/length notation, please pay
   attention to the boundary values. When specifying that the server should
   use a given pool, it will be able to allocate also first (typically
   network address) address from that pool. For example for pool
   2001:db8::/64 the 2001:db8:: address may be assigned as well. If you want
   to avoid this, please use the "min-max" notation.

  18.2.5. Subnet and Prefix Delegation Pools

   Subnets may also be configured to delegate address prefixes.... A subnet
   may have one or more prefix delegation pools. Each pool has a prefixed
   address, which is specified as a prefix and a prefix length, as well as a
   delegated prefix length. A sample configuration is shown below:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[0]/subnet "2001:db8:1::/64"
 > config show Dhcp6/subnet6[0]
 > config add Dhcp6/subnet6[0]/pd-pools
 > config set Dhcp6/subnet6[0]/pd-pools[0]/prefix "2001:db8:1::"
 > config set Dhcp6/subnet6[0]/pd-pools[0]/prefix-len 64
 > config set Dhcp6/subnet6[0]/pd-pools[0]/delegated-len 96
 > config commit

  18.2.6. Standard DHCPv6 options

   One of the major features of DHCPv6 server is to provide configuration
   options to clients. Although there are several options that require
   special behavior, most options are sent by the server only if the client
   explicitly requested them. The following example shows how to configure
   DNS servers, which is one of the most frequently used options. Numbers in
   the first column are added for easier reference and will not appear on
   screen. Options specified in this way are considered global and apply to
   all configured subnets.

 1. > config add Dhcp6/option-data
 2. > config set Dhcp6/option-data[0]/name "dns-servers"
 3. > config set Dhcp6/option-data[0]/code 23
 4. > config set Dhcp6/option-data[0]/space "dhcp6"
 5. > config set Dhcp6/option-data[0]/csv-format true
 6. > config set Dhcp6/option-data[0]/data "2001:db8::cafe, 2001:db8::babe"
 7. > config commit

   The first line creates new entry in option-data table. It contains
   information on all global options that the server is supposed to configure
   in all subnets. The second line specifies option name. For a complete list
   of currently supported names, see Table 18.1, “List of standard DHCPv6
   options”. The third line specifies option code, which must match one of
   the values from that list. Line 4 specifies option space, which must
   always be set to "dhcp6" as these are standard DHCPv6 options. For other
   name spaces, including custom option spaces, see Section 18.2.9, “Nested
   DHCPv6 options (custom option spaces)”. The fifth line specifies the
   format in which the data will be entered: use of CSV (comma separated
   values) is recommended. The sixth line gives the actual value to be sent
   to clients. Data is specified as a normal text, with values separated by
   commas if more than one value is allowed.

   Options can also be configured as hexadecimal values. If csv-format is set
   to false, the option data must be specified as a string of hexadecimal
   numbers. The following commands configure the DNS-SERVERS option for all
   subnets with the following addresses: 2001:db8:1::cafe and
   2001:db8:1::babe.

 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[0]/name "dns-servers"
 > config set Dhcp6/option-data[0]/code 23
 > config set Dhcp6/option-data[0]/space "dhcp6"
 > config set Dhcp6/option-data[0]/csv-format false
 > config set Dhcp6/option-data[0]/data "2001 0DB8 0001 0000 0000 0000
         0000 CAFE 2001 0DB8 0001 0000 0000 0000 0000 BABE"
 > config commit


   (The value for the setting of the "data" element is split across two lines
   in this document for clarity: when entering the command, the whole string
   should be entered on the same line.)

   It is possible to override options on a per-subnet basis. If clients
   connected to most of your subnets are expected to get the same values of a
   given option, you should use global options: you can then override
   specific values for a small number of subnets. On the other hand, if you
   use different values in each subnet, it does not make sense to specify
   global option values (Dhcp6/option-data), rather you should set only
   subnet-specific values (Dhcp6/subnet[X]/option-data[Y]).

   The following commands override the global DNS servers option for a
   particular subnet, setting a single DNS server with address 2001:db8:1::3.

 > config add Dhcp6/subnet6[0]/option-data
 > config set Dhcp6/subnet6[0]/option-data[0]/name "dns-servers"
 > config set Dhcp6/subnet6[0]/option-data[0]/code 23
 > config set Dhcp6/subnet6[0]/option-data[0]/space "dhcp6"
 > config set Dhcp6/subnet6[0]/option-data[0]/csv-format true
 > config set Dhcp6/subnet6[0]/option-data[0]/data "2001:db8:1::3"
 > config commit

  Note

   In future versions of BIND 10 DHCP, it will not be necessary to specify
   option code, space and csv-format fields, as those fields will be set
   automatically.

   The currently supported standard DHCPv6 options are listed in Table 18.1,
   “List of standard DHCPv6 options”. The "Name" and "Code" are the values
   that should be used as a name in the option-data structures. "Type"
   designates the format of the data: the meanings of the various types is
   given in Table 17.3, “List of standard DHCP option types”.

   Some options are designated as arrays, which means that more than one
   value is allowed in such an option. For example the option dns-servers
   allows the specification of more than one IPv6 address, so allowing
   clients to obtain the the addresses of multiple DNS servers.

   The Section 18.2.7, “Custom DHCPv6 options” describes the configuration
   syntax to create custom option definitions (formats). It is generally not
   allowed to create custom definitions for standard options, even if the
   definition being created matches the actual option format defined in the
   RFCs. There is an exception from this rule for standard options for which
   Kea does not provide a definition yet. In order to use such options, a
   server administrator must create a definition as described in
   Section 18.2.7, “Custom DHCPv6 options” in the 'dhcp6' option space. This
   definition should match the option format described in the relevant RFC
   but configuration mechanism would allow any option format as it has no
   means to validate it at the moment.

   Table 18.1. List of standard DHCPv6 options

   +---------------------------------------------------------+
   |           Name           | Code |     Type     | Array? |
   |--------------------------+------+--------------+--------|
   | preference               | 7    | uint8        | false  |
   |--------------------------+------+--------------+--------|
   | sip-server-dns           | 21   | fqdn         | true   |
   |--------------------------+------+--------------+--------|
   | sip-server-addr          | 22   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | dns-servers              | 23   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | domain-search            | 24   | fqdn         | true   |
   |--------------------------+------+--------------+--------|
   | nis-servers              | 27   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | nisp-servers             | 28   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | nis-domain-name          | 29   | fqdn         | true   |
   |--------------------------+------+--------------+--------|
   | nisp-domain-name         | 30   | fqdn         | true   |
   |--------------------------+------+--------------+--------|
   | sntp-servers             | 31   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | information-refresh-time | 32   | uint32       | false  |
   |--------------------------+------+--------------+--------|
   | bcmcs-server-dns         | 33   | fqdn         | true   |
   |--------------------------+------+--------------+--------|
   | bcmcs-server-addr        | 34   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | geoconf-civic            | 36   | record       | false  |
   |--------------------------+------+--------------+--------|
   | remote-id                | 37   | record       | false  |
   |--------------------------+------+--------------+--------|
   | subscriber-id            | 38   | binary       | false  |
   |--------------------------+------+--------------+--------|
   | client-fqdn              | 39   | record       | false  |
   |--------------------------+------+--------------+--------|
   | pana-agent               | 40   | ipv6-address | true   |
   |--------------------------+------+--------------+--------|
   | new-posix-timezone       | 41   | string       | false  |
   |--------------------------+------+--------------+--------|
   | new-tzdb-timezone        | 42   | string       | false  |
   |--------------------------+------+--------------+--------|
   | ero                      | 43   | uint16       | true   |
   |--------------------------+------+--------------+--------|
   | lq-query                 | 44   | record       | false  |
   |--------------------------+------+--------------+--------|
   | client-data              | 45   | empty        | false  |
   |--------------------------+------+--------------+--------|
   | clt-time                 | 46   | uint32       | false  |
   |--------------------------+------+--------------+--------|
   | lq-relay-data            | 47   | record       | false  |
   |--------------------------+------+--------------+--------|
   | lq-client-link           | 48   | ipv6-address | true   |
   +---------------------------------------------------------+

  18.2.7. Custom DHCPv6 options

   It is also possible to define options other than the standard ones. Assume
   that we want to define a new DHCPv6 option called "foo" which will have
   code 100 and will convey a single unsigned 32 bit integer value. We can
   define such an option by using the following commands:

 > config add Dhcp6/option-def
 > config set Dhcp6/option-def[0]/name "foo"
 > config set Dhcp6/option-def[0]/code 100
 > config set Dhcp6/option-def[0]/type "uint32"
 > config set Dhcp6/option-def[0]/array false
 > config set Dhcp6/option-def[0]/record-types ""
 > config set Dhcp6/option-def[0]/space "dhcp6"
 > config set Dhcp6/option-def[0]/encapsulate ""
 > config commit

   The "false" value of the "array" parameter determines that the option does
   NOT comprise an array of "uint32" values but rather a single value. Two
   other parameters have been left blank: "record-types" and "encapsulate".
   The former specifies the comma separated list of option data fields if the
   option comprises a record of data fields. The "record-fields" value should
   be non-empty if the "type" is set to "record". Otherwise it must be left
   blank. The latter parameter specifies the name of the option space being
   encapsulated by the particular option. If the particular option does not
   encapsulate any option space it should be left blank. Note that the above
   set of comments define the format of the new option and do not set its
   values.

   Once the new option format is defined, its value is set in the same way as
   for a standard option. For example the following commands set a global
   value that applies to all subnets.

 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[0]/name "foo"
 > config set Dhcp6/option-data[0]/code 100
 > config set Dhcp6/option-data[0]/space "dhcp6"
 > config set Dhcp6/option-data[0]/csv-format true
 > config set Dhcp6/option-data[0]/data "12345"
 > config commit

   New options can take more complex forms than simple use of primitives
   (uint8, string, ipv6-address etc): it is possible to define an option
   comprising a number of existing primitives.

   Assume we want to define a new option that will consist of an IPv6
   address, followed by an unsigned 16 bit integer, followed by a boolean
   value, followed by a text string. Such an option could be defined in the
   following way:

 > config add Dhcp6/option-def
 > config set Dhcp6/option-def[0]/name "bar"
 > config set Dhcp6/option-def[0]/code 101
 > config set Dhcp6/option-def[0]/space "dhcp6"
 > config set Dhcp6/option-def[0]/type "record"
 > config set Dhcp6/option-def[0]/array false
 > config set Dhcp6/option-def[0]/record-types "ipv6-address, uint16, boolean, string"
 > config set Dhcp6/option-def[0]/encapsulate ""

   The "type" is set to "record" to indicate that the option contains
   multiple values of different types. These types are given as a
   comma-separated list in the "record-types" field and should be those
   listed in Table 17.3, “List of standard DHCP option types”.

   The values of the option are set as follows:

 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[0]/name "bar"
 > config set Dhcp6/option-data[0]/space "dhcp6"
 > config set Dhcp6/option-data[0]/code 101
 > config set Dhcp6/option-data[0]/csv-format true
 > config set Dhcp6/option-data[0]/data "2001:db8:1::10, 123, false, Hello World"
 > config commit

   "csv-format" is set "true" to indicate that the "data" field comprises a
   command-separated list of values. The values in the "data" must correspond
   to the types set in the "record-types" field of the option definition.

  Note

   It is recommended that boolean values are specified using "true" and
   "false" strings. This helps to prevent errors when typing multiple comma
   separated values, as it make it easier to identify the type of the value
   being typed, and compare it with the order of data fields. Nevetheless, it
   is possible to use integer values: "1" and "0", instead of "true" and
   "false" accordingly. If other integer value is specified, the
   configuration is rejected.

  18.2.8. DHCPv6 vendor specific options

   Currently there are three option spaces defined: dhcp4 (to be used in
   DHCPv4 daemon) and dhcp6 (for the DHCPv6 daemon); there is also
   vendor-opts-space, which is empty by default, but options can be defined
   in it. Those options are called vendor-specific information options. The
   following examples show how to define an option "foo" with code 1 that
   consists of an IPv6 address, an unsigned 16 bit integer and a string. The
   "foo" option is conveyed in a vendor specific information option. This
   option comprises a single uint32 value that is set to "12345". The
   sub-option "foo" follows the data field holding this value.

 > config add Dhcp6/option-def
 > config set Dhcp6/option-def[0]/name "foo"
 > config set Dhcp6/option-def[0]/code 1
 > config set Dhcp6/option-def[0]/space "vendor-opts-space"
 > config set Dhcp6/option-def[0]/type "record"
 > config set Dhcp6/option-def[0]/array false
 > config set Dhcp6/option-def[0]/record-types "ipv6-address, uint16, string"
 > config set Dhcp6/option-def[0]/encapsulates ""
 > config commit

   (Note that the option space is set to "vendor-opts-space".) Once the
   option format is defined, the next step is to define actual values for
   that option:

 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[0]/name "foo"
 > config set Dhcp6/option-data[0]/space "vendor-opts-space"
 > config set Dhcp6/option-data[0]/code 1
 > config set Dhcp6/option-data[0]/csv-format true
 > config set Dhcp6/option-data[0]/data "2001:db8:1::10, 123, Hello World"
 > config commit

   We should also define values for the vendor-opts, that will convey our
   option foo.

 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[1]/name "vendor-opts"
 > config set Dhcp6/option-data[1]/space "dhcp6"
 > config set Dhcp6/option-data[1]/code 17
 > config set Dhcp6/option-data[1]/csv-format true
 > config set Dhcp6/option-data[1]/data "12345"
 > config commit

  18.2.9. Nested DHCPv6 options (custom option spaces)

   It is sometimes useful to define completely new option spaces. This is
   useful if the user wants his new option to convey sub-options that use
   separate numbering scheme, for example sub-options with codes 1 and 2.
   Those option codes conflict with standard DHCPv6 options, so a separate
   option space must be defined.

   Note that it is not required to create new option space when defining
   sub-options for a standard option because it is by default created if the
   standard option is meant to convey any sub-options (see Section 18.2.8,
   “DHCPv6 vendor specific options”).

   Assume that we want to have a DHCPv6 option called "container" with code
   102 that conveys two sub-options with codes 1 and 2. First we need to
   define the new sub-options:

 > config add Dhcp6/option-def
 > config set Dhcp6/option-def[0]/name "subopt1"
 > config set Dhcp6/option-def[0]/code 1
 > config set Dhcp6/option-def[0]/space "isc"
 > config set Dhcp6/option-def[0]/type "ipv6-address"
 > config set Dhcp6/option-def[0]/record-types ""
 > config set Dhcp6/option-def[0]/array false
 > config set Dhcp6/option-def[0]/encapsulate ""
 > config commit
 >
 > config add Dhcp6/option-def
 > config set Dhcp6/option-def[1]/name "subopt2"
 > config set Dhcp6/option-def[1]/code 2
 > config set Dhcp6/option-def[1]/space "isc"
 > config set Dhcp6/option-def[1]/type "string"
 > config set Dhcp6/option-def[1]/record-types ""
 > config set Dhcp6/option-def[1]/array false
 > config set Dhcp6/option-def[1]/encapsulate ""
 > config commit

   Note that we have defined the options to belong to a new option space (in
   this case, "isc").

   The next step is to define a regular DHCPv6 option and specify that it
   should include options from the isc option space:

 > config add Dhcp6/option-def
 > config set Dhcp6/option-def[2]/name "container"
 > config set Dhcp6/option-def[2]/code 102
 > config set Dhcp6/option-def[2]/space "dhcp6"
 > config set Dhcp6/option-def[2]/type "empty"
 > config set Dhcp6/option-def[2]/array false
 > config set Dhcp6/option-def[2]/record-types ""
 > config set Dhcp6/option-def[2]/encapsulate "isc"
 > config commit

   The name of the option space in which the sub-options are defined is set
   in the "encapsulate" field. The "type" field is set to "empty" which
   imposes that this option does not carry any data other than sub-options.

   Finally, we can set values for the new options:

 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[0]/name "subopt1"
 > config set Dhcp6/option-data[0]/space "isc"
 > config set Dhcp6/option-data[0]/code 1
 > config set Dhcp6/option-data[0]/csv-format true
 > config set Dhcp6/option-data[0]/data "2001:db8::abcd"
 > config commit
 >
 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[1]/name "subopt2"
 > config set Dhcp6/option-data[1]/space "isc"
 > config set Dhcp6/option-data[1]/code 2
 > config set Dhcp6/option-data[1]/csv-format true
 > config set Dhcp6/option-data[1]/data "Hello world"
 > config commit
 >
 > config add Dhcp6/option-data
 > config set Dhcp6/option-data[2]/name "container"
 > config set Dhcp6/option-data[2]/space "dhcp6"
 > config set Dhcp6/option-data[2]/code 102
 > config set Dhcp6/option-data[2]/csv-format true
 > config set Dhcp6/option-data[2]/data ""
 > config commit

   Even though the "container" option does not carry any data except
   sub-options, the "data" field must be explicitly set to an empty value.
   This is required because in the current version of BIND 10 DHCP, the
   default configuration values are not propagated to the configuration
   parsers: if the "data" is not set the parser will assume that this
   parameter is not specified and an error will be reported.

   Note that it is possible to create an option which carries some data in
   addition to the sub-options defined in the encapsulated option space. For
   example, if the "container" option from the previous example was required
   to carry an uint16 value as well as the sub-options, the "type" value
   would have to be set to "uint16" in the option definition. (Such an option
   would then have the following data structure: DHCP header, uint16 value,
   sub-options.) The value specified with the "data" parameter - which should
   be a valid integer enclosed in quotes, e.g. "123" - would then be assigned
   to the uint16 field in the "container" option.

  18.2.10. IPv6 Subnet Selection

   The DHCPv6 server may receive requests from local (connected to the same
   subnet as the server) and remote (connecting via relays) clients. As
   server may have many subnet configurations defined, it must select
   appropriate subnet for a given request.

   The server can not assume which of configured subnets are local. It is
   possible in IPv4, where there is reasonable expectation that the server
   will have a (global) IPv4 address configured on the interface, and can use
   that information to detect whether a subnet is local or not. That
   assumption is not true in IPv6, as the DHCPv6 must be able to operate with
   having link-local addresses only. Therefore an optional "interface"
   parameter is available within a subnet definition to designate that a
   given subnet is local, i.e. reachable directly over specified interface.
   For example the server that is intended to serve a local subnet over eth0
   may be configured as follows:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[1]/subnet "2001:db8:beef::/48"
 > config set Dhcp6/subnet6[1]/pool [ "2001:db8:beef::/48" ]
 > config set Dhcp6/subnet6[1]/interface "eth0"
 > config commit

  18.2.11. DHCPv6 Relays

   A DHCPv6 server with multiple subnets defined must select the appropriate
   subnet when it receives a request from client. For clients connected via
   relays, two mechanisms are used:

   The first uses the linkaddr field in the RELAY_FORW message. The name of
   this field is somewhat misleading in that it does not contain a link-layer
   address: instead, it holds an address (typically a global address) that is
   used to identify a link. The DHCPv6 server checks if the address belongs
   to a defined subnet and, if it does, that subnet is selected for the
   client's request.

   The second mechanism is based on interface-id options. While forwarding a
   client's message, relays may insert an interface-id option into the
   message that identifies the interface on the relay that received the
   message. (Some relays allow configuration of that parameter, but it is
   sometimes hardcoded and may range from the very simple (e.g. "vlan100") to
   the very cryptic: one example seen on real hardware was
   "ISAM144|299|ipv6|nt:vp:1:110"). The server can use this information to
   select the appropriate subnet. The information is also returned to the
   relay which then knows the interface to use to transmit the response to
   the client. In order for this to work successfully, the relay interface
   IDs must be unique within the network and the server configuration must
   match those values.

   When configuring the DHCPv6 server, it should be noted that two
   similarly-named parameters can be configured for a subnet:

     * "interface" defines which local network interface can be used to
       access a given subnet.
     * "interface-id" specifies the content of the interface-id option used
       by relays to identify the interface on the relay to which the response
       packet is sent.

   The two are mutually exclusive: a subnet cannot be both reachable locally
   (direct traffic) and via relays (remote traffic). Specifying both is a
   configuration error and the DHCPv6 server will refuse such a
   configuration.

   To specify interface-id with value "vlan123", the following commands can
   be used:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[0]/subnet "2001:db8:beef::/48"
 > config set Dhcp6/subnet6[0]/pool [ "2001:db8:beef::/48" ]
 > config set Dhcp6/subnet6[0]/interface-id "vland123"
 > config commit

  18.2.12. Client Classification in DHCPv6

  Note

   DHCPv6 server has been extended to support limited client classification.
   Although the current capability is modest, it is expected to be expanded
   in the future. It is envisaged that the majority of client classification
   extensions will be using hooks extensions.

   In certain cases it is useful to differentiate between different types of
   clients and treat them differently. The process of doing classification is
   conducted in two steps. The first step is to assess incoming packet and
   assign it to zero or more classes. This classification is currently
   simple, but is expected to grow in capability soon. Currently the server
   checks whether incoming packet has vendor class option (16). If it has,
   content of that option is prepended with "VENDOR_CLASS_" interpreted as a
   class. For example, modern cable modems will send this option with value
   "docsis3.0" and as a result the packet will belong to class
   "VENDOR_CLASS_docsis3.0".

   It is envisaged that the client classification will be used for changing
   behavior of almost any part of the DHCP engine processing, including
   assigning leases from different pools, assigning different option (or
   different values of the same options) etc. For now, there is only one
   mechanism that is taking advantage of client classification: subnet
   selection.

   Kea can be instructed to limit access to given subnets based on class
   information. This is particularly useful for cases where two types of
   devices share the same link and are expected to be served from two
   different subnets. The primary use case for such a scenario are cable
   networks. There are two classes of devices: cable modem itself, which
   should be handled a lease from subnet A and all other devices behind
   modems that should get a lease from subnet B. That segregation is
   essential to prevent overly curious users from playing with their cable
   modems. For details on how to set up class restrictions on subnets, see
   Section 18.2.13, “Limiting access to IPv6 subnet to certain classes”.

  18.2.13. Limiting access to IPv6 subnet to certain classes

   In certain cases it beneficial to restrict access to certains subnets only
   to clients that belong to a given subnet. For details on client classes,
   see Section 18.2.12, “Client Classification in DHCPv6”. This is an
   extension of a previous example from Section 18.2.4, “Subnet and Address
   Pool”. Let's assume that the server is connected to a network segment that
   uses the 2001:db8:1::/64 prefix. The Administrator of that network has
   decided that addresses from range 2001:db8:1::1 to 2001:db8:1::ffff are
   going to be managed by the Dhcp6 server. Only clients belonging to the
   eRouter1.0 client class are allowed to use that pool. Such a configuration
   can be achieved in the following way:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[0]/subnet "2001:db8:1::/64"
 > config set Dhcp6/subnet6[0]/pool [ "2001:db8:1::0 - 2001:db8:1::ffff" ]
 > config set Dhcp6/subnet6[0]/client-class "eRouter1.0"
 > config commit

   Care should be taken with client classification as it is easy to prevent
   clients that do not meet class criteria to be denied any service
   altogether.

  18.2.14. Configuring DHCPv6 for DDNS

   As mentioned earlier, DHCPv6 can be configured to generate requests to the
   DHCP-DDNS server (referred to here as the "D2" server) to update DNS
   entries. These requests are known as NameChangeRequests or NCRs. Each NCR
   contains the following information:

    1. Whether it is a request to add (update) or remove DNS entries

    2. Whether the change requests forward DNS updates (AAAA records),
       reverse DNS updates (PTR records), or both.

    3. The FQDN, lease address, and DHCID

   The parameters controlling the generation of NCRs for submission to D2 are
   contained in the "dhcp-ddns" section of the DHCPv6 server configuration.
   The default values for this section appears as follows:

 > config show Dhcp6/dhcp-ddns
 Dhcp6/dhcp-ddns/enable-updates  true    boolean
 Dhcp6/dhcp-ddns/server-ip       "127.0.0.1"     string
 Dhcp6/dhcp-ddns/server-port     53001   integer
 Dhcp6/dhcp-ddns/ncr-protocol    "UDP"   string
 Dhcp6/dhcp-ddns/ncr-format      "JSON"  string
 Dhcp6/dhcp-ddns/override-no-update      false   boolean
 Dhcp6/dhcp-ddns/override-client-update  false   boolean
 Dhcp6/dhcp-ddns/replace-client-name     false   boolean
 Dhcp6/dhcp-ddns/generated-prefix        "myhost"        string
 Dhcp6/dhcp-ddns/qualifying-suffix       "example.com"   string

   The "enable-updates" parameter determines whether or not DHCPv6 will
   generate NCRs. By default, this value is false hence DDNS updates are
   disabled. To enable DDNS updates set this value to true as follows:

 > config set Dhcp6/dhcp-ddns/enable-updates true
 > config commit

    18.2.14.1. DHCP-DDNS Server Connectivty

   In order for NCRs to reach D2, DHCPv6 must be able to communicate with it.
   The following parameters are used to establish connectivty between DHCPv6
   and D2.

   The parameters, "server-ip" and "server-port", specify the address of the
   D2 server. By default, D2 is assumed to running on the same machine as
   DHCPv6, and the default values for these two parameters should be
   sufficient. However, if D2 has been configured to listen on a different
   address or port, these values must altered accordingly. For example, if D2
   has been configured to listen on 198.162.1.10 port 900, the following
   commands would be required:

 > config set Dhcp6/dhcp-ddns/server-ip "198.162.1.10"
 > config set Dhcp6/dhcp-ddns/server-port 900
 > config commit

   D2 can be configured to listen over IPv4 or IPv6, therefore server-ip may
   be either an IPv4 or IPv6 address.

   The socket protocol that DHCPv6 should use to communicate with D2 is
   specified with the "ncr-protocol" parameter. Currently only UDP is
   supported.

   The internal format for DDNS update requests sent by DHCPv6 is specified
   with the "ncr-format" parameter. Currently only JSON is supported.

    18.2.14.2. When does DHCPv6 generates DDNS request

   DHCPv6 follows the behavior prescribed for DHCP servers in RFC 4704. It is
   important to keep in mind that DHCPv6 provides the initial decision making
   of when and what to update and forwards that information to D2 in the form
   of NCRs. Carrying out the actual DNS updates and dealing with such things
   as conflict resolution are the purvue of D2 (Chapter 19, The DHCP-DDNS
   Server).

   This section describes when DHCPv6 will generate NCRs and the
   configuration parameters that can be used to influence this decision. It
   assumes that the "enable-updates" paramater is true.

  Note

   Currently the interface between DHCPv6 and D2 only supports requests which
   update DNS entries for a single IP address. If a lease grants more than
   one address, DHCPv6 will create the DDNS update request for only the first
   of these addresses. Support for multiple address mappings may be provided
   in a future release.

   In general, DHCPv6 will generate DDNS udpate requests when:

    1. A new lease is granted in response to a DHCP REQUEST

    2. An existing lease is renewed but the FQDN associated with it has
       changed.

    3. An existing lease is released in response to a DHCP RELEASE

   In the second case, lease renewal, two DDNS requests will be issued: one
   request to remove entries for the previous FQDN and a second request to
   add entries for the new FQDN. In the last case, a lease release, a single
   DDNS request to remove its entries will be made. The decision making
   involved when granting a new lease is more involved and is discussed next.

   DHCPv6 will generate a DDNS update request only if the DHCP REQUEST
   contains the FQDN option (code 39). By default the DHCPv6 server will
   respect the FQDN N and S flags specified by the client as shown in the
   following table:

   Table 18.2. Default FQDN Flag Behavior

   +------------------------------------------------------------------------+
   | Client    | Client Intent           | Server Response    | Server      |
   | Flags:N-S |                         |                    | Flags:N-S-O |
   |-----------+-------------------------+--------------------+-------------|
   |           | Client wants to do      | Server generates   |             |
   | 0-0       | forward updates, server | reverse-only       | 1-0-0       |
   |           | should do reverse       | request            |             |
   |           | updates                 |                    |             |
   |-----------+-------------------------+--------------------+-------------|
   |           | Server should do both   | Server generates   |             |
   | 0-1       | forward and reverse     | request to update  | 0-1-0       |
   |           | updates                 | both directions    |             |
   |-----------+-------------------------+--------------------+-------------|
   | 1-0       | Client wants no updates | Server does not    | 1-0-0       |
   |           | done                    | generate a request |             |
   +------------------------------------------------------------------------+

   The first row in the table above represents "client delegation". Here the
   DHCP client states that it intends to do the forward DNS updates and the
   server should do the reverese updates. By default, DHCPv6 will honor the
   client's wishes and generate a DDNS request to D2 to update only reverse
   DNS data. The parameter, "override-client-update", can be used to instruct
   the server to override client delegation requests. When this parameter is
   true, DHCPv6 will disregard requests for client delegation and generate a
   DDNS request to update both forward and reverse DNS data. In this case,
   the N-S-O flags in the server's response to the client will be 0-1-1
   respectively.

   (Note that the flag combination N=1, S=1 is prohibited according to RFC
   4702. If such a combination is received from the client, the packet will
   be dropped by the DHCPv6 server.)

   To override client delegation, issue the following commands:

 > config set Dhcp6/dhcp-ddns/override-client-update true
 > config commit

   The third row in the table above describes the case in which the client
   requests that no DNS updates be done. The parameter, "override-no-update",
   can be used to instruct the server to disregard the client's wishes. When
   this parameter is true, DHCPv6 will generate DDNS udpate request to D2
   even if the client requests no updates be done. The N-S-O flags in the
   server's response to the client will be 0-1-1.

   To override client delegation, issue the following commands:

 > config set Dhcp6/dhcp-ddns/override-no-update true
 > config commit

    18.2.14.3. DHCPv6 name generation for DDNS update requests

   Each NameChangeRequest must of course include the fully qualified domain
   name whose DNS entries are to be affected. DHCPv6 can be configured to
   supply a portion or all of that name based upon what it receives from the
   client in the DHCP REQUEST.

   The rules for determining the FQDN option are as follows:

    1. If configured to do so ignore the REQUEST contents and generate a FQDN
       using a configurable prefix and suffix.

    2. Otherwise, using is the domain name value from the client FQDN option
       as the candidate name:

         a. If the candidate name is a fully qualified domain name then use
            it.

         b. If the candidate name is a partial (i.e. unqualified) name then
            add a configurable suffix to the name and use the result as the
            FQDN.

         c. If the candidate name is a empty then generate a FQDN using a
            configurable prefix and suffix.

   To instruct DHCPv6 to always generate a FQDN, set the parameter
   "replace-client-name" to true:

 > config set Dhcp6/dhcp-ddns/replace-client-name true
 > config commit

   The prefix used when generating a FQDN is specified by the
   "generated-prefix" parameter. The default value is "myhost". To alter its
   value, simply set it to the desired string:

 > config set Dhcp6/dhcp-ddns/generated-prefix "another.host"
 > config commit

   The suffix used when generating a FQDN or when qualifying a partial name
   is specified by the "qualifying-suffix" parameter. The default value is
   "example.com". To alter its value simply set it to the desired string:

 > config set Dhcp6/dhcp-ddns/generated-prefix "our.net"
 > config commit

   When qualifying a partial name, DHCPv6 will construct a name with the
   format:

   [candidate-name].[qualifying-suffix].

   where candidate-name is the partial name supplied in the REQUEST. For
   example, if FQDN domain name value was "some-computer" and assuming the
   default value for qualifying-suffix, the generated FQDN would be:

   some-computer.example.com.

   When generating a the entire name, DHCPv6 will construct name of the
   format:

   [generated-prefix]-[address-text].[qualifying-suffix].

   where address-text is simply the lease IP address converted to a
   hyphenated string. For example, if lease address is 3001:1::70E and
   assuming default values for generated-prefix and qualifying-suffix, the
   generated FQDN would be:

   myhost-3001-1--70E.example.com.

18.3. Server Identifier in DHCPv6

   The DHCPv6 protocol uses a "server identifier" (also known as a DUID) for
   clients to be able to discriminate between several servers present on the
   same link. There are several types of DUIDs defined, but RFC 3315
   instructs servers to use DUID-LLT if possible. This format consists of a
   link-layer (MAC) address and a timestamp. When started for the first time,
   the DHCPv6 server will automatically generate such a DUID and store the
   chosen value to a file. That file is read by the server and the contained
   value used whenever the server is subsequently started.

   It is unlikely that this parameter should ever need to be changed.
   However, if such a need arises, stop the server, edit the file and restart
   the server. (The file is named b10-dhcp6-serverid and by default is stored
   in the "var" subdirectory of the directory in which BIND 10 is installed.
   This can be changed when BIND 10 is built by using "--localstatedir" on
   the "configure" command line.) The file is a text file that contains
   double digit hexadecimal values separated by colons. This format is
   similar to typical MAC address format. Spaces are ignored. No extra
   characters are allowed in this file.

18.4. Using specific relay agent for a subnet

   The relay has to have an interface connected to the link on which the
   clients are being configured. Typically the relay has a global IPv6
   address configured on that interface that belongs to the subnet that the
   server will assign addresses from. In such typical case, the server is
   able to use IPv6 address inserted by the relay (in link-addr field in
   RELAY-FORW message) to select appropriate subnet.

   However, that is not always the case. The relay address may not match the
   subnet in certain deployments. This usually means that there is more than
   one subnet allocated for a given link. Two most common examples where this
   is the case are long lasting network renumbering (where both old and new
   address space is still being used) and a cable network. In a cable network
   both cable modems and the devices behind them are physically connected to
   the same link, yet they use distinct addressing. In such case, the DHCPv6
   server needs additional information (like the value of interface-id option
   or IPv6 address inserted in the link-addr field in RELAY-FORW message) to
   properly select an appropriate subnet.

   The following example assumes that there is a subnet 2001:db8:1::/64 that
   is accessible via relay that uses 3000::1 as its IPv6 address. The server
   will be able to select this subnet for any incoming packets that came from
   a relay that has an address in 2001:db8:1::/64 subnet. It will also select
   that subnet for a relay with address 3000::1.

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[0]/subnet "2001:db8:1::/64"
 > config set Dhcp6/subnet6[0]/pool [ "2001:db8:1::2 - 2001:db8:1::ffff" ]
 > config set Dhcp6/subnet6[0]/relay/ip-address "3000::1"
 > config commit

18.5. Segregating IPv6 clients in a cable network

   In certain cases, it is useful to mix relay address information,
   introduced in Section 18.4, “Using specific relay agent for a subnet” with
   client classification, explained in Section 18.2.13, “Limiting access to
   IPv6 subnet to certain classes”. One specific example is cable network,
   where typically modems get addresses from a different subnet than all
   devices connected behind them.

   Let's assume that there is one CMTS (Cable Modem Termination System) with
   one CM MAC (a physical link that modems are connected to). We want the
   modems to get addresses from the 3000::/64 subnet, while everything
   connected behind modems should get addresses from another subnet
   (2001:db8:1::/64). The CMTS that acts as a relay an uses address 3000::1.
   The following configuration can serve that configuration:

 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[0]/subnet "3000::/64"
 > config set Dhcp6/subnet6[0]/pool [ "3000::2 - 3000::ffff" ]
 > config set Dhcp6/subnet6[0]/client-class "docsis3.0"
 > config set Dhcp6/subnet6[0]/relay/ip-address "3000::1"
 > config add Dhcp6/subnet6
 > config set Dhcp6/subnet6[1]/subnet "2001:db8:1::/64"
 > config set Dhcp6/subnet6[1]/pool [ "2001:db8:1::1 - 2001:db8:1::ffff" ]
 > config set Dhcp6/subnet6[1]/relay/ip-address "3000::1"
 > config commit

18.6. Supported Standards

   The following standards and draft standards are currently supported:

     * RFC 3315: Supported messages are SOLICIT, ADVERTISE, REQUEST, RELEASE,
       RENEW, and REPLY.
     * RFC 3646: Supported option is DNS_SERVERS.
     * RFC 4704: Supported option is CLIENT_FQDN.

18.7. DHCPv6 Server Limitations

   These are the current limitations and known problems with the DHCPv6
   server software. Most of them are reflections of the early stage of
   development and should be treated as “not implemented yet”, rather than
   actual limitations.

     * On-line configuration has some limitations. Adding new subnets or
       modifying existing ones work, as is removing the last subnet from the
       list. However, removing non-last (e.g. removing subnet 1,2 or 3 if
       there are 4 subnets configured) will cause issues. The problem is
       caused by simplistic subnet-id assignment. The subnets are always
       numbered, starting from 1. That subnet-id is then used in leases that
       are stored in the lease database. Removing non-last subnet will cause
       the configuration information to mismatch data in the lease database.
       It is possible to manually update subnet-id fields in MySQL database,
       but it is awkward and error prone process. A better reconfiguration
       support is planned.

     * On startup, the DHCPv6 server does not get the full configuration from
       BIND 10. To remedy this, after starting BIND 10, modify any parameter
       and commit the changes, e.g.

 > config show Dhcp6/renew-timer
 Dhcp6/renew-timer       1000    integer (default)
 > config set Dhcp6/renew-timer 1001
 > config commit

     * Temporary addresses are not supported.
     * Prefix delegation is not supported.
     * Confirmation (CONFIRM), and duplication report (DECLINE) are not yet
       supported.
     * DNS Update is not supported.

   --------------------------------------------------------------------------

   ^[2] The server comes with an in-memory database ("memfile") configured as
   the default database. This is used for internal testing and is not
   supported. In addition, it does not store lease information on disk: lease
   information will be lost if the server is restarted.

                        Chapter 19. The DHCP-DDNS Server

   Table of Contents

   19.1. Starting and Stopping the DHCP-DDNS Server

   19.2. Configuring the DHCP-DDNS Server

                19.2.1. General Server Parameters

                19.2.2. TSIG Key List

                19.2.3. Forward DDNS

                19.2.4. Reverse DDNS

                19.2.5. Example DHCP-DDNS Server Configuration

   The DHCP-DDNS Server (known informally as D2) conducts the client side of
   the DDNS protocol (defined in RFC 2136) on behalf of the DHCPv4 and DHCPv6
   servers. The DHCP servers construct DDNS update requests, known as
   NameChangeRequests (NCRs), based upon DHCP lease change events and then
   post these to D2. D2 attempts to match each such request to the
   appropriate DNS server(s) and carry out the necessary conversation with
   those servers to update the DNS data.

   In order to match a request to appropriate DNS servers, D2 must have a
   catalog of servers from which to select. In fact, D2 has two such
   catalogs, one for forward DNS and one for reverse DNS; these catalogs are
   referred to as DDNS Domain Lists. Each list consists of one or more named
   DDNS Domains. Further, each DDNS Domain has a list of of one or more DNS
   servers that publish the DNS data for that domain.

   When conducting forward domain matching, D2 will compare the FQDN in the
   request against the name of each forward DDNS Domain. The domain whose
   name matches the longest portion of the FQDN is considered the best match.
   For example, if the FQDN is "myhost.sample.example.com.", and there are
   two forward domains in the catalog: "sample.example.com." and
   "example.com.", the former is regarded as the best match. In some cases,
   it may not be possible to find a suitable match. Given the same two
   forward domains there would be no match for the FQDN, "bogus.net", so the
   request would be rejected. Finally, if there are no forward DDNS Domains
   defined, D2 will simply disregard the forward update portion of requests.

   When conducting reverse domain matching, D2 constructs a reverse FQDN from
   the lease address in the request and compare that against the name of each
   reverse DDNS Domain. Again, the domain whose name matches the longest
   portion of the FQDN is considered the best match. For instance, if the
   lease address is "172.16.1.40" and there are two reverse domains in the
   catalog: "1.16.172.in-addr.arpa." and "16.172.in-addr.arpa", the former is
   the best match. As with forward matching, it is possible to not find a
   suitable match. Given the same two domains, there would be no match for
   the lease address, "192.168.1.50", and the request would be rejected.
   Finally, if there are no reverse DDNS Domains defined, D2 will simply
   disregard the reverse update portion of requests.

19.1. Starting and Stopping the DHCP-DDNS Server

   b10-dhcp-ddns is the BIND 10 DHCP-DDNS server and, like other parts of
   BIND 10, is configured through the bindctl program.

   After starting BIND 10 and entering bindctl, the first step in configuring
   the server is to add it to the list of running BIND 10 services.

 > config add Init/components b10-dhcp-ddns
 > config set Init/components/b10-dhcp-ddns/kind dispensable
 > config commit

   To remove b10-dhcp-ddns from the set of running services, the
   b10-dhcp-ddns is removed from list of Init components:

 > config remove Init/components b10-dhcp-ddns
 > config commit

   Note that the server was only removed from the list, so BIND10 will not
   restart it, but the server itself is still running. Hence it is usually
   desired to stop it:

 > DhcpDdns shutdown

   Upon start up the module will load its configuration and begin listening
   for NCRs based on that configuration.

19.2. Configuring the DHCP-DDNS Server

   Once the server is started, it can be configured. To view the current
   configuration, use the following command in bindctl:

 > config show DhcpDdns

   When starting b10-dhcp-ddns module for the first time, the default
   configuration will be available. It will look similar to this:

 > config show DhcpDdns
 DhcpDdns/interface  "eth0"  string  (default)
 DhcpDdns/ip_address "127.0.0.1" string  (default)
 DhcpDdns/port   53001   integer (default)
 DhcpDdns/tsig_keys  []  list    (default)
 DhcpDdns/forward_ddns/ddns_domains  []  list    (default)
 DhcpDdns/reverse_ddns/ddns_domains  []  list    (default)

   (While displayed, the parameter "interface" is not implemented, and will
   be removed in the near future.)

   The configuration can be divided as follows, each of which is described in
   its own section:

     * General Server Parameters — values which control connectivity and
       global server behavior
     * TSIG Key Info — defines the TSIG keys used for secure traffic with DNS
       servers
     * Forward DDNS — defines the catalog of Forward DDNS Domains
     * Reverse DDNS — defines the catalog of Forward DDNS Domains

  19.2.1. General Server Parameters

   The DHCP-DDNS server must listen for requests on a known address and port.
   By default, it will listen at 127.0.0.1 on port 53001. This is governed by
   the parameters, "ip-address" and "port". Either value may be changed using
   config set/commit. For example to change the server to listen at
   192.168.1.10 port 900:

 > config set DhcpDdns/ip_address "192.168.1.10"
 > config set DhcpDdns/port 900
 > config commit

   The server may be configured to listen over IPv4 or IPv6, therefore
   ip-address may an IPv4 or IPv6 address.

  Note

   If the ip_address and port are changed, it will be necessary to change the
   corresponding values in the DHCP servers' "dhcp-ddns" configuration
   section.

  19.2.2. TSIG Key List

  Note

   While this section may be displayed and edited using bindctl, the use of
   TSIG in actual communications between D2 and DNS servers is not yet
   implemented.

   DDNS protocol can be conducted with or without TSIG as defined in RFC
   2845. This configuration section allows the administrator to define the
   dictionary of TSIG keys to may be used. To use TSIG when working with a
   specific DDNS Domain that key must be defined in the TSIG Key List and
   referenced by name in that domain's entry in the DDNS catalog.

   As one might gather from its name, this section is a list of TSIG keys.
   Each key has three parameters:

     * name — is a unique text label used to idenfity the this key within the
       list. It is this value that is used to specify which key (if any)
       should be used with a specific DNS server. So long as it is unique,
       its content is arbitrary. It cannot be blank.
     * algorithm — specifies which hashing algorithm should be used with this
       key. This value is not currently used.
     * secret — is used to specify the shared secret key code for this key.
       This value is not currently used.

   By default, the TSIG Key list is empty:

 > config show DhcpDdns/tsig_keys
 DhcpDdns/tsig_keys  []  list  (default)

   To create a new key in the list, one must first add a new key element:

 > config add DhcpDdns/tsig_keys

   Displaying the new element, reveals this:

 > config show DhcpDdns/tsig_keys[0]
 DhcpDdns/tsig_keys[0]/name  ""  string  (default)
 DhcpDdns/tsig_keys[0]/algorithm "hmac_md5"  string  (modified)
 DhcpDdns/tsig_keys[0]/secret  ""  string  (default)

   Populating the key name and secret, while accepting the default value for
   alogorithm:

 > config set DhcpDdns/tsig_keys[0]/name "key1.example.com"
 > config set DhcpDdns/tsig_keys[0]/secret "123456789"
 > config commit

  19.2.3. Forward DDNS

   The Forward DDNS section is used to configure D2's forward update
   behavior. Currently it contains a single parameter, the catalog of forward
   DDNS Domains:

 > config show DhcpDdns/forward_ddns/
 DhcpDdns/forward_ddns/ddns_domains  [] list  (default)

   By default, this list is empty, which will cause the server to ignore the
   forward update portions of requests.

    19.2.3.1. Adding Forward DDNS Domains

   A forward DDNS Domain maps a forward DNS zone to a set of DNS servers
   which maintain the forward DNS data for that zone. You will need one
   forward DDNS Domain for each zone you wish to service. It may very well be
   that some or all of your zones are maintained by the same servers. You
   will still need one DDNS Domain per zone. Remember that matching a request
   to the appropriate server(s) is done by zone and a DDNS Domain only
   defines a single zone.

   The section describes how to add Forward DDNS Domains. Repeat these steps
   for each Forward DDNS Domain desired. Each Forward DDNS Domain has the
   following parameters:

     * name — The fully qualified domain name (or zone) that this DDNS Domain
       can update. This is value used to compare against the request FQDN
       during forward matching. It must be unique within the catalog.
     * key_name — If TSIG is used with this domain's servers, this value
       should be the name of the key from within the TSIG Key List to use. If
       the value is blank (the default), TSIG will not be used in DDNS
       converations with this domain's servers. Currently TSIG has not been
       implemented, so this value is ignored.
     * dns_servers — A list of one or more DNS servers which can conduct the
       server side of the DDNS protocol for this domain. The servers are used
       in a first to last preference. In other words, when D2 begins to
       process a request for this domain it will pick the first server in
       this list and attempt to communicate with it. If that attempt fails,
       it will move to next one in the list and so on until the it achieves
       success or the list is exhausted.

   To create a new forward DDNS Domain, one must first add a new domain
   element:

 > config add DhcpDdns/forward_ddns/ddns_domains

   Displaying the DDNS Domain reveals this:

 > config show DhcpDdns/forward_ddns/ddns_domains[0]
 DhcpDdns/forward_ddns/ddns_domains[0]/name  ""  string  (default)
 DhcpDdns/forward_ddns/ddns_domains[0]/key_name  ""  string  (default)
 DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers   []  list    (default)

   To set the domain's name to "other.example.com":

 > config set DhcpDdns/forward_ddns/ddns_domains[1]/name "other.example.com"
 > config commit

   It is permissable to add a domain without any servers. If that domain
   should be matched to a request, however, the request will fail. In order
   to make the domain useful though, we must add at least one DNS server to
   it.

      19.2.3.1.1. Adding Forward DNS Servers

   The section describes how to add DNS servers to a Forward DDNS Domain.
   Repeat them for as many servers as desired for a each domain.

   Forward DNS Server entries represent actual DNS servers which support the
   server side of the DDNS protocol. Each Forward DNS Server has the
   following parameters:

     * hostname — The resolvable host name of the DNS server. This value is
       not yet implemented.
     * ip_address — The IP address at which the server listens for DDNS
       requests. This may be either an IPv4 or an IPv6 address.
     * port — The port on which the server listens for DDNS requests. It
       defaults to the standard DNS service port of 53.

   To create a new forward DNS Server, one must first add a new server
   element to the domain:

 > config add DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers

   Displaying the DNS Server element should appear as follows:

 > config show DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]
 DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/hostname   ""  string  (default)
 DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/ip_address ""  string  (default)
 DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/port   53  integer(default)

   As stated earlier, "hostname" is not yet supported so, the parameter
   "ip_address" must be set to the address of the DNS server. If for example
   the service is running at "172.88.99.10", then set it as follows:

 > config set DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.88.99.10"
 > config commit

  19.2.4. Reverse DDNS

   The Reverse DDNS section is used to configure D2's reverse update
   behavior, and the concepts are the same as for the forward DDNS section.
   Currently it contains a single parameter, the catalog of reverse DDNS
   Domains:

 > config show DhcpDdns/reverse_ddns/
 DhcpDdns/reverse_ddns/ddns_domains  [] list  (default)

   By default, this list is empty, which will cause the server to ignore the
   reverse update portions of requests.

    19.2.4.1. Adding Reverse DDNS Domains

   A reverse DDNS Domain maps a reverse DNS zone to a set of DNS servers
   which maintain the reverse DNS data for that zone. You will need one
   reverse DDNS Domain for each zone you wish to service. It may very well be
   that some or all of your zones are maintained by the same servers; even
   then, you will still need one DDNS Domain entry for each zone. Remember
   that matching a request to the appropriate server(s) is done by zone and a
   DDNS Domain only defines a single zone.

   The section describes how to add Reverse DDNS Domains. Repeat these steps
   for each Reverse DDNS Domain desired. Each Reverse DDNS Domain has the
   following parameters:

     * name — The fully qualified reverse zone that this DDNS Domain can
       update. This is the value used during reverse matching which will
       compare it with a reversed version of the request's lease address. The
       zone name should follow the appropriate standards: for example, to to
       support the IPv4 subnet 172.16.1, the name should be.
       "1.16.172.in-addr.arpa.". Similarly, to support an IPv6 subent of
       2001:db8:1, the name should be "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
       Whatever the name, it must be unique within the catalog.
     * key_name — If TSIG should be used with this domain's servers, then
       this value should be the name of the key from within the TSIG Key List
       to use. If the value is blank (the default), TSIG will not be used in
       DDNS converations with this domain's servers. Currently this value is
       not used as TSIG has not been implemented.
     * dns_servers — a list of one or more DNS servers which can conduct the
       server side of the DDNS protocol for this domain. Currently the
       servers are used in a first to last preference. In other words, when
       D2 begins to process a request for this domain it will pick the first
       server in this list and attempt to communicate with it. If that
       attempt fails, it will move to next one in the list and so on until
       the it achieves success or the list is exhausted.

   To create a new reverse DDNS Domain, one must first add a new domain
   element:

 > config add DhcpDdns/reverse_ddns/ddns_domains

   Displaying the DDNS Domain reveals this:

 > config show DhcpDdns/reverse_ddns/ddns_domains[0]
 DhcpDdns/reverse_ddns/ddns_domains[0]/name  ""  string  (default)
 DhcpDdns/reverse_ddns/ddns_domains[0]/key_name  ""  string  (default)
 DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers   []  list    (default)

   For domain supporting the subnet 2001:db8:1::, we would set the domain's
   name as follows:

 > config set DhcpDdns/reverse_ddns/ddns_domains[1]/name "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
 > config commit

   It is permissable to add a domain without any servers. If that domain
   should be matched to a request, however, the request will fail. In order
   to make the domain useful though, we must add at least one DNS server to
   it.

      19.2.4.1.1. Adding Reverse DNS Servers

   The section describes how to add DNS servers to a Reverse DDNS Domain.
   Repeat them for as many servers as desired for a each domain.

   Reverse DNS Server entries represents a actual DNS servers which support
   the server side of the DDNS protocol. Each Reverse DNS Server has the
   following parameters:

     * hostname — The resolvable host name of the DNS server. This value is
       currently ignored.
     * ip_address — The IP address at which the server listens for DDNS
       requests.
     * port — The port on which the server listens for DDNS requests. It
       defaults to the standard DNS service port of 53.

   To create a new reverse DNS Server, one must first add a new server
   element to the domain:

 > config add DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers

   Displaying the DNS Server element should appear as follows:

 > config show DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]
 DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/hostname   ""  string  (default)
 DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/ip_address ""  string  (default)
 DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/port   53  integer(default)

   As stated earlier, "hostname" is not yet supported so, the parameter
   "ip_address" must be set to the address of the DNS server. If for example
   the service is running at "172.88.99.10", then set it as follows:

 > config set DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.88.99.10"
 > config commit

  19.2.5. Example DHCP-DDNS Server Configuration

   This section provides an example DHCP-DDNS server configuration based on a
   small example network. Let's suppose our example network has three
   domains, each with their own subnet.

   Table 19.1. Our example network

   +------------------------------------------------------------------------+
   | Domain           | Subnet          | Forward DNS Servers | Reverse DNS |
   |                  |                 |                     | Servers     |
   |------------------+-----------------+---------------------+-------------|
   | four.example.com | 192.0.2.0/24    | 172.16.1.5,         | 172.16.1.5, |
   |                  |                 | 172.16.2.5          | 172.16.2.5  |
   |------------------+-----------------+---------------------+-------------|
   | six.example.com  | 2001:db8:1::/64 | 3001:1::50          | 3001:1::51  |
   |------------------+-----------------+---------------------+-------------|
   | example.com      | 192.0.0.0/16    | 172.16.2.5          | 172.16.2.5  |
   +------------------------------------------------------------------------+

   We need to construct three forward DDNS Domains:

   Table 19.2. Forward DDNS Domains Needed

   +-------------------------------------------------+
   | #  | DDNS Domain Name  | DNS Servers            |
   |----+-------------------+------------------------|
   | 1. | four.example.com. | 172.16.1.5, 172.16.2.5 |
   |----+-------------------+------------------------|
   | 2. | six.example.com.  | 3001:1::50             |
   |----+-------------------+------------------------|
   | 3. | example.com.      | 172.16.2.5             |
   +-------------------------------------------------+

   As discussed earlier, FQDN to domain matching is based on the longest
   match. The FQDN, "myhost.four.example.com.", will match the first domain
   ("four.example.com") while "admin.example.com." will match the third
   domain ("example.com"). The FQDN, "other.example.net." will fail to match
   any domain and would be rejected.

   The following series of commands in bindctl will create the Forward DDNS
   Domains.


 > config add DhcpDdns/forward_ddns/ddns_domains
 > config set DhcpDdns/forward_ddns/ddns_domains[0]/name "four.example.com."
 > config add DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers
 > config set DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.16.1.5"
 > config add DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers
 > config set DhcpDdns/forward_ddns/ddns_domains[0]/dns_servers[1]/ip_address "172.16.2.5"
 >
 > config add DhcpDdns/forward_ddns/ddns_domains
 > config set DhcpDdns/forward_ddns/ddns_domains[1]/name "six.example.com."
 > config add DhcpDdns/forward_ddns/ddns_domains[1]/dns_servers
 > config set DhcpDdns/forward_ddns/ddns_domains[1]/dns_servers[0]/ip_address "3001:1::50:"
 >
 > config add DhcpDdns/forward_ddns/ddns_domains
 > config set DhcpDdns/forward_ddns/ddns_domains[2]/name "example.com."
 > config add DhcpDdns/forward_ddns/ddns_domains[2]/dns_servers
 > config set DhcpDdns/forward_ddns/ddns_domains[2]/dns_servers[0]/ip_address "172.16.2.5"
 >
 > config commit


   Similarly, we need to construct the three reverse DDNS Domains:

   Table 19.3. Reverse DDNS Domains Needed

   +-----------------------------------------------------------------+
   | #  | DDNS Domain Name                  | DNS Servers            |
   |----+-----------------------------------+------------------------|
   | 1. | 2.0.192.in-addr.arpa.             | 172.16.1.5, 172.16.2.5 |
   |----+-----------------------------------+------------------------|
   | 2. | 1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa. | 3001:1::50             |
   |----+-----------------------------------+------------------------|
   | 3. | 0.182.in-addr.arpa.               | 172.16.2.5             |
   +-----------------------------------------------------------------+

   An address of "192.0.2.150" will match the first domain, "2001:db8:1::10"
   will match the second domain, and "192.0.50.77" the third domain.

   The following series of commands in bindctl will create our Reverse DDNS
   Domains.


 > config add DhcpDdns/reverse_ddns/ddns_domains
 > config set DhcpDdns/reverse_ddns/ddns_domains[0]/name "2.0.192.in-addr.arpa."
 > config add DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers
 > config set DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[0]/ip_address "172.16.1.5"
 > config add DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers
 > config set DhcpDdns/reverse_ddns/ddns_domains[0]/dns_servers[1]/ip_address "172.16.2.5"
 >
 > config add DhcpDdns/reverse_ddns/ddns_domains
 > config set DhcpDdns/reverse_ddns/ddns_domains[1]/name "1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa."
 > config add DhcpDdns/reverse_ddns/ddns_domains[1]/dns_servers
 > config set DhcpDdns/reverse_ddns/ddns_domains[1]/dns_servers[0]/ip_address "3001:1::50:"
 >
 > config add DhcpDdns/reverse_ddns/ddns_domains
 > config set DhcpDdns/reverse_ddns/ddns_domains[2]/name "0.192.in-addr.arpa."
 > config add DhcpDdns/reverse_ddns/ddns_domains[2]/dns_servers
 > config set DhcpDdns/reverse_ddns/ddns_domains[2]/dns_servers[0]/ip_address "172.16.2.5"
 >
 > config commit


                         Chapter 20. libdhcp++ library

   Table of Contents

   20.1. Interface detection and Socket handling

   libdhcp++ is a common library written in C++ that handles many
   DHCP-related tasks, including:

     * DHCPv4 and DHCPv6 packets parsing, manipulation and assembly
     * Option parsing, manipulation and assembly
     * Network interface detection
     * Socket operations such as creation, data transmission and reception
       and socket closing.

   While this library is currently used by BIND 10 DHCP, it is designed to be
   a portable, universal library, useful for any kind of DHCP-related
   software.

20.1. Interface detection and Socket handling

   Both the DHCPv4 and DHCPv6 components share network interface detection
   routines. Interface detection is currently supported on Linux, all BSD
   family (FreeBSD, NetBSD, OpenBSD), Mac OS X and Solaris 11 systems.

   DHCPv4 requires special raw socket processing to send and receive packets
   from hosts that do not have IPv4 address assigned yet. Support for this
   operation is implemented on Linux only, so it is likely that DHCPv4
   component will not work in certain cases on systems other than Linux.

                             Chapter 21. Statistics

   The b10-stats process is started by b10-init. 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, and show specified or all statistics
   data schema. For example, using bindctl:

 > Stats show
 {
     "Auth": {
         "opcode.iquery": 0,
         "opcode.notify": 10,
         "opcode.query": 869617,
         ...
         "queries.tcp": 1749,
         "queries.udp": 867868
     },
     "Init": {
         "boot_time": "2011-01-20T16:59:03Z"
     },
     "Stats": {
         "boot_time": "2011-01-20T16:59:05Z",
         "last_update_time": "2011-01-20T17:04:05Z",
         "lname": "4d3869d9_a@jreed.example.net",
         "report_time": "2011-01-20T17:04:06Z",
         "timestamp": 1295543046.823504
     }
 }


                              Chapter 22. Logging

   Table of Contents

   22.1. Logging configuration

                22.1.1. Loggers

                22.1.2. Output Options

                22.1.3. Example session

   22.2. Logging Message Format

22.1. Logging configuration

   The logging system in BIND 10 is configured through the Logging module.
   All BIND 10 modules will look at the configuration in Logging to see what
   should be logged and to where.

  22.1.1. Loggers

   Within BIND 10, a message is logged through a component called a "logger".
   Different parts of BIND 10 log messages through different loggers, and
   each logger can be configured independently of one another.

   In the Logging module, you can specify the configuration for zero or more
   loggers; any that are not specified will take appropriate default values.

   The three most important elements of a logger configuration are the name
   (the component that is generating the messages), the severity (what to
   log), and the output_options (where to log).

    22.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, you add an entry for a logger named “Resolver”.
   This configuration will then be used by the loggers in the Resolver
   module, and all the libraries used by it.

   If you want to specify logging for one specific library within the module,
   you set the name to module.library. For example, the logger used by the
   nameserver address store component has the full name of “Resolver.nsas”.
   If there is no entry in Logging for a particular library, it will use the
   configuration given for the module.

   To illustrate this, suppose you want the cache library to log messages of
   severity DEBUG, and the rest of the resolver code to log messages of
   severity INFO. To achieve this you specify two loggers, one with the name
   “Resolver” and severity INFO, and one with the name “Resolver.cache” with
   severity DEBUG. As there are no entries for other libraries (e.g. the
   nsas), they will use the configuration for the module (“Resolver”), so
   giving the desired behavior.

   One special case is that of a module name of “*” (asterisks), which is
   interpreted as any module. You can set global logging options by using
   this, including setting the logging configuration for a library that is
   used by multiple modules (e.g. “*.config” specifies the configuration
   library code in whatever module is using it).

   If there are multiple logger specifications in the configuration that
   might match a particular logger, the specification with the more specific
   logger name takes precedence. For example, if there are entries for both
   “*” and “Resolver”, the resolver module — and all libraries it uses — will
   log messages according to the configuration in the second entry
   (“Resolver”). All other modules will use the configuration of the first
   entry (“*”). If there was also a configuration entry for “Resolver.cache”,
   the cache library within the resolver would use that in preference to the
   entry for “Resolver”.

   One final note about the naming. When specifying the module name within a
   logger, use the name of the module as specified in bindctl, e.g.
   “Resolver” for the resolver module, “Xfrout” for the xfrout module, etc.
   When the message is logged, the message will include the name of the
   logger generating the message, but with the module name replaced by the
   name of the process implementing the module (so for example, a message
   generated by the “Auth.cache” logger will appear in the output with a
   logger name of “b10-auth.cache”).

    22.1.1.2. severity (string)

   This specifies the category of messages logged. Each message is logged
   with an associated severity which may be one of the following (in
   descending order of severity):

     * FATAL
     * ERROR
     * WARN
     * INFO
     * DEBUG

   When the severity of a logger is set to one of these values, it will only
   log messages of that severity, and the severities above it. The severity
   may also be set to NONE, in which case all messages from that logger are
   inhibited.

    22.1.1.3. output_options (list)

   Each logger can have zero or more output_options. These specify where log
   messages are sent to. These are explained in detail below.

   The other options for a logger are:

    22.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 from 0 (least verbose) to 99 (most
   verbose).

   If severity for the logger is not DEBUG, this value is ignored.

    22.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 loggers configured; “Resolver” and
   “Resolver.cache”, and additive is true in the second, it will write the
   log messages not only to the destinations specified for “Resolver.cache”,
   but also to the destinations as specified in the output_options in the
   logger named “Resolver”.

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

    22.1.2.1. destination (string)

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

     * console
     * file
     * syslog

    22.1.2.2. output (string)

   Depending on what is set as the output destination, this value is
   interpreted as follows:

   destination is “console”

           The value of output must be one of “stdout” (messages printed to
           standard output) or “stderr” (messages printed to standard error).

           Note: if output is set to “stderr” and a lot of messages are
           produced in a short time (e.g. if the logging level is set to
           DEBUG), you may occasionally see some messages jumbled up
           together. This is due to a combination of the way that messages
           are written to the screen and the unbuffered nature of the
           standard error stream. If this occurs, it is recommended that
           output be set to “stdout”.

   destination is “file”

           The value of output is interpreted as a file name; log messages
           will be appended to this file.

   destination is “syslog”

           The value of output is interpreted as the syslog facility (e.g.
           local0) that should be used for log messages.

   The other options for output_options are:

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

      22.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. (For example, a ".1" is appended to the
   name — if a ".1" file exists, it is renamed ".2", etc.)

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

  Note

   Due to a limitation of the underlying logging library (log4cplus), rolling
   over the log files (from ".1" to ".2", etc) may show odd results: There
   can be multiple small files at the timing of roll over. This can happen
   when multiple BIND 10 processes try to roll over the files simultaneously.
   Version 1.1.0 of log4cplus solved this problem, so if this or higher
   version of log4cplus is used to build BIND 10, it shouldn't happen. Even
   for older versions it is normally expected to happen rarely unless the log
   messages are produced very frequently by multiple different processes.

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

  22.1.3. Example session

   In this example we want to set the global logging to write to the file
   /var/log/my_bind10.log, at severity WARN. We want the authoritative server
   to log at DEBUG with debuglevel 40, to a different file
   (/tmp/debug_messages).

   Start bindctl.

 ["login success "]
 > config show Logging
 Logging/loggers []      list

   By default, no specific loggers are configured, in which case the severity
   defaults to INFO and the output is written to stderr.

   Let's first add a default logger:

 > config add Logging/loggers
 > config show Logging
 Logging/loggers/        list    (modified)

   The loggers value line changed to indicate that it is no longer an empty
   list:

 > config show Logging/loggers
 Logging/loggers[0]/name ""      string  (default)
 Logging/loggers[0]/severity     "INFO"  string  (default)
 Logging/loggers[0]/debuglevel   0       integer (default)
 Logging/loggers[0]/additive     false   boolean (default)
 Logging/loggers[0]/output_options       []      list    (default)

   The name is mandatory, so we must set it. We will also change the severity
   as well. Let's start with the global logger.

 > config set Logging/loggers[0]/name *
 > config set Logging/loggers[0]/severity WARN
 > config show Logging/loggers
 Logging/loggers[0]/name "*"     string  (modified)
 Logging/loggers[0]/severity     "WARN"  string  (modified)
 Logging/loggers[0]/debuglevel   0       integer (default)
 Logging/loggers[0]/additive     false   boolean (default)
 Logging/loggers[0]/output_options       []      list    (default)

   Of course, we need to specify where we want the log messages to go, so we
   add an entry for an output option.

 >  config add Logging/loggers[0]/output_options
 >  config show Logging/loggers[0]/output_options
 Logging/loggers[0]/output_options[0]/destination        "console"       string  (default)
 Logging/loggers[0]/output_options[0]/output     "stdout"        string  (default)
 Logging/loggers[0]/output_options[0]/flush      false   boolean (default)
 Logging/loggers[0]/output_options[0]/maxsize    0       integer (default)
 Logging/loggers[0]/output_options[0]/maxver     0       integer (default)

   These aren't the values we are looking for.

 >  config set Logging/loggers[0]/output_options[0]/destination file
 >  config set Logging/loggers[0]/output_options[0]/output /var/log/bind10.log
 >  config set Logging/loggers[0]/output_options[0]/maxsize 204800
 >  config set Logging/loggers[0]/output_options[0]/maxver 8

   Which would make the entire configuration for this logger look like:

 >  config show all Logging/loggers
 Logging/loggers[0]/name "*"     string  (modified)
 Logging/loggers[0]/severity     "WARN"  string  (modified)
 Logging/loggers[0]/debuglevel   0       integer (default)
 Logging/loggers[0]/additive     false   boolean (default)
 Logging/loggers[0]/output_options[0]/destination        "file"  string  (modified)
 Logging/loggers[0]/output_options[0]/output     "/var/log/bind10.log"   string  (modified)
 Logging/loggers[0]/output_options[0]/flush      false   boolean (default)
 Logging/loggers[0]/output_options[0]/maxsize    204800  integer (modified)
 Logging/loggers[0]/output_options[0]/maxver     8       integer (modified)

   That looks OK, so let's commit it before we add the configuration for the
   authoritative server's logger.

 >  config commit

   Now that we have set it, and checked each value along the way, adding a
   second entry is quite similar.

 >  config add Logging/loggers
 >  config set Logging/loggers[1]/name Auth
 >  config set Logging/loggers[1]/severity DEBUG
 >  config set Logging/loggers[1]/debuglevel 40
 >  config add Logging/loggers[1]/output_options
 >  config set Logging/loggers[1]/output_options[0]/destination file
 >  config set Logging/loggers[1]/output_options[0]/output /tmp/auth_debug.log
 >  config commit

   And that's it. Once we have found whatever it was we needed the debug
   messages for, we can simply remove the second logger to let the
   authoritative server use the same settings as the rest.

 >  config remove Logging/loggers[1]
 >  config commit

   And every module will now be using the values from the logger named “*”.

22.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 a problem, information about the problem
   that may be useful in fixing it.

   Consider the message below logged to a file:

 2011-06-15 13:48:22.034 ERROR [b10-resolver.asiolink]
     ASIODNS_OPENSOCK error 111 opening TCP socket to 127.0.0.1(53)

   Note: the layout of messages written to the system logging file (syslog)
   may be slightly different. This message has been split across two lines
   here for display reasons; in the logging file, it will appear on one
   line.)

   The log message comprises a number of components:

   2011-06-15 13:48:22.034

           The date and time at which the message was generated.

   ERROR

           The severity of the message.

   [b10-resolver.asiolink]

           The source of the message. This comprises two components: the BIND
           10 process generating the message (in this case, b10-resolver) and
           the module within the program from which the message originated
           (which in the example is the asynchronous I/O link module,
           asiolink).

   ASIODNS_OPENSOCK

           The message identification. Every message in BIND 10 has a unique
           identification, which can be used as an index into the BIND 10
           Messages Manual (http://bind10.isc.org/docs/bind10-messages.html)
           from which more information can be obtained.

   error 111 opening TCP socket to 127.0.0.1(53)

           A brief description of the cause of the problem. Within this text,
           information relating to the condition that caused the message to
           be logged will be included. In this example, error number 111 (an
           operating system-specific error number) was encountered when
           trying to open a TCP connection to port 53 on the local system
           (address 127.0.0.1). The next step would be to find out the reason
           for the failure by consulting your system's documentation to
           identify what error number 111 means.
