BIND 10 trac1687, updated. 7a48a76d208b0c687074850837e99989700af160 [trac1687] remove generated roff man pages
BIND 10 source code commits
bind10-changes at lists.isc.org
Thu Feb 16 20:03:27 UTC 2012
The branch, trac1687 has been updated
via 7a48a76d208b0c687074850837e99989700af160 (commit)
via 878bed3207150a3a006eecba1c30292fbf22cda6 (commit)
from c8739afa54bafeffac2cad157020242b8acb3b28 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 7a48a76d208b0c687074850837e99989700af160
Author: Jeremy C. Reed <jreed at ISC.org>
Date: Thu Feb 16 10:41:17 2012 -0600
[trac1687] remove generated roff man pages
Later steps will make sure these are generated for "make dist"
to be included in tarball.
commit 878bed3207150a3a006eecba1c30292fbf22cda6
Author: Jeremy C. Reed <jreed at ISC.org>
Date: Thu Feb 16 10:39:01 2012 -0600
[trac1687] remove generated guide and message documentation files
Later steps will make sure these are generated for "make dist"
to be included in tarball.
-----------------------------------------------------------------------
Summary of changes:
doc/guide/bind10-guide.html | 1631 ----------
doc/guide/bind10-guide.txt | 1726 ----------
doc/guide/bind10-messages.html | 2628 ---------------
doc/guide/bind10-messages.xml | 5896 ----------------------------------
src/bin/auth/b10-auth.8 | 202 --
src/bin/bind10/bind10.8 | 343 --
src/bin/bindctl/bindctl.1 | 149 -
src/bin/cfgmgr/b10-cfgmgr.8 | 81 -
src/bin/cmdctl/b10-cmdctl.8 | 97 -
src/bin/ddns/b10-ddns.8 | 102 -
src/bin/dhcp4/b10-dhcp4.8 | 60 -
src/bin/dhcp6/b10-dhcp6.8 | 51 -
src/bin/host/b10-host.1 | 118 -
src/bin/loadzone/b10-loadzone.8 | 80 -
src/bin/msgq/b10-msgq.8 | 127 -
src/bin/resolver/b10-resolver.8 | 138 -
src/bin/stats/b10-stats-httpd.8 | 132 -
src/bin/stats/b10-stats.8 | 154 -
src/bin/usermgr/b10-cmdctl-usermgr.8 | 74 -
src/bin/xfrin/b10-xfrin.8 | 161 -
src/bin/xfrout/b10-xfrout.8 | 158 -
src/bin/zonemgr/b10-zonemgr.8 | 132 -
22 files changed, 0 insertions(+), 14240 deletions(-)
delete mode 100644 doc/guide/bind10-guide.html
delete mode 100644 doc/guide/bind10-guide.txt
delete mode 100644 doc/guide/bind10-messages.html
delete mode 100644 doc/guide/bind10-messages.xml
delete mode 100644 src/bin/auth/b10-auth.8
delete mode 100644 src/bin/bind10/bind10.8
delete mode 100644 src/bin/bindctl/bindctl.1
delete mode 100644 src/bin/cfgmgr/b10-cfgmgr.8
delete mode 100644 src/bin/cmdctl/b10-cmdctl.8
delete mode 100644 src/bin/ddns/b10-ddns.8
delete mode 100644 src/bin/dhcp4/b10-dhcp4.8
delete mode 100644 src/bin/dhcp6/b10-dhcp6.8
delete mode 100644 src/bin/host/b10-host.1
delete mode 100644 src/bin/loadzone/b10-loadzone.8
delete mode 100644 src/bin/msgq/b10-msgq.8
delete mode 100644 src/bin/resolver/b10-resolver.8
delete mode 100644 src/bin/stats/b10-stats-httpd.8
delete mode 100644 src/bin/stats/b10-stats.8
delete mode 100644 src/bin/usermgr/b10-cmdctl-usermgr.8
delete mode 100644 src/bin/xfrin/b10-xfrin.8
delete mode 100644 src/bin/xfrout/b10-xfrout.8
delete mode 100644 src/bin/zonemgr/b10-zonemgr.8
-----------------------------------------------------------------------
diff --git a/doc/guide/bind10-guide.html b/doc/guide/bind10-guide.html
deleted file mode 100644
index 4ae31f5..0000000
--- a/doc/guide/bind10-guide.html
+++ /dev/null
@@ -1,1631 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>BIND 10 Guide</title><link rel="stylesheet" type="text/css" href="./bind10-guide.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><meta name="description" content="BIND 10 is a framework that features Domain Name System (DNS) suite and Dynamic Host Configuration Protocol (DHCP) servers managed by Internet Systems Consortium (ISC). It includes DNS libraries, modular components for controlling authoritative and recursive DNS servers, and experimental DHCPv4 and DHCPv6 servers. This is the reference guide for BIND 10 version 20120127. 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 ."></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="BIND 10 Guide"><div class="titlepage"><div><div><h1 class="title"><a name="idm148
92896"></a>BIND 10 Guide</h1></div><div><h2 class="subtitle">Administrator Reference for BIND 10</h2></div><div><p class="releaseinfo">This is the reference guide for BIND 10 version
- 20120127.</p></div><div><p class="copyright">Copyright © 2010-2012 Internet Systems Consortium, Inc.</p></div><div><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>BIND 10 is a framework that features Domain Name System
- (DNS) suite and Dynamic Host Configuration Protocol (DHCP)
- servers managed by Internet Systems Consortium (ISC). It
- includes DNS libraries, modular components for controlling
- authoritative and recursive DNS servers, and experimental DHCPv4
- and DHCPv6 servers.
- </p><p>
- This is the reference guide for BIND 10 version 20120127.
- 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 <a class="ulink" href="http://bind10.isc.org/docs" target="_top">http://bind10.isc.org/docs</a>.
- </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#idp61424">Preface</a></span></dt><dd><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></dd><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#idp64344">1.1. Supported Platforms</a></span></dt><dt><span class="section"><a href="#required-software">1.2. Required Software</a></span></dt><dt><span class="section"><a href="#starting_stopping">1.3. Starting and Stopping the Server</a></span></dt><dt><span class="section"><a href="#managing_once_running">1.4. Managing BIND 10</a></span></dt></dl></dd><dt><span class="chapter"><a href="#installation">2. Installation</a></span></dt><dd><dl><dt><span class="section"><a href="#build-requirements">2.1. Building Requirements</a></span></dt><dt><span class="section"><a href="#quickstart">2.2. Quick
start</a></span></dt><dt><span class="section"><a href="#install">2.3. Installation from source</a></span></dt><dd><dl><dt><span class="section"><a href="#idp113000">2.3.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#idp114472">2.3.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#idp119504">2.3.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#idp126792">2.3.4. Build</a></span></dt><dt><span class="section"><a href="#idp127848">2.3.5. Install</a></span></dt><dt><span class="section"><a href="#idp129504">2.3.6. Install Hierarchy</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#bind10">3. Starting BIND10 with <span class="command"><strong>bind10</strong></span></a></span></dt><dd><dl><dt><span class="section"><a href="#start">3.1. Starting BIND 10</a></span></dt><dt><span class="section"><a href="#bind10.config">3.2. Configuration of started processes</a></span></dt></dl></dd><
dt><span class="chapter"><a href="#msgq">4. Command channel</a></span></dt><dt><span class="chapter"><a href="#cfgmgr">5. Configuration manager</a></span></dt><dt><span class="chapter"><a href="#cmdctl">6. Remote control daemon</a></span></dt><dd><dl><dt><span class="section"><a href="#cmdctl.spec">6.1. Configuration specification for b10-cmdctl</a></span></dt></dl></dd><dt><span class="chapter"><a href="#bindctl">7. Control and configure user interface</a></span></dt><dt><span class="chapter"><a href="#authserver">8. Authoritative Server</a></span></dt><dd><dl><dt><span class="section"><a href="#idp200360">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#idp205096">8.2. Data Source Backends</a></span></dt><dt><span class="section"><a href="#idp207592">8.3. Loading Master Zones Files</a></span></dt></dl></dd><dt><span class="chapter"><a href="#xfrin">9. Incoming Zone Transfers</a></span></dt><dd><dl><dt><span class="section"><a href="#idp217864">
9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#idp220904">9.2. Enabling IXFR</a></span></dt><dt><span class="section"><a href="#zonemgr">9.3. Secondary Manager</a></span></dt><dt><span class="section"><a href="#idp11976">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt></dl></dd><dt><span class="chapter"><a href="#xfrout">10. Outbound Zone Transfers</a></span></dt><dt><span class="chapter"><a href="#resolverserver">11. Recursive Name Server</a></span></dt><dd><dl><dt><span class="section"><a href="#idp259896">11.1. Access Control</a></span></dt><dt><span class="section"><a href="#idp269088">11.2. Forwarding</a></span></dt></dl></dd><dt><span class="chapter"><a href="#dhcp4">12. DHCPv4 Server</a></span></dt><dd><dl><dt><span class="section"><a href="#dhcp4-usage">12.1. DHCPv4 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp4-config">12.2. DHCPv4 Server Configuration</a></span></dt><dt><span c
lass="section"><a href="#dhcp4-std">12.3. Supported standards</a></span></dt><dt><span class="section"><a href="#dhcp4-limit">12.4. DHCPv4 Server Limitations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#dhcp6">13. DHCPv6 Server</a></span></dt><dd><dl><dt><span class="section"><a href="#dhcp6-usage">13.1. DHCPv6 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp6-config">13.2. DHCPv6 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp6-std">13.3. Supported DHCPv6 Standards</a></span></dt><dt><span class="section"><a href="#dhcp6-limit">13.4. DHCPv6 Server Limitations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#libdhcp">14. libdhcp++ library</a></span></dt><dd><dl><dt><span class="section"><a href="#iface-detect">14.1. Interface detection</a></span></dt><dt><span class="section"><a href="#packet-handling">14.2. DHCPv4/DHCPv6 packet handling</a></span></dt></dl></dd><dt><span class="chapter"><a href="#s
tatistics">15. Statistics</a></span></dt><dt><span class="chapter"><a href="#logging">16. Logging</a></span></dt><dd><dl><dt><span class="section"><a href="#idp327280">16.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp328272">16.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#idp349480">16.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#idp362088">16.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#idp379592">16.2. Logging Message Format</a></span></dt></dl></dd></dl></div><div class="list-of-tables"><p><b>List of Tables</b></p><dl><dt>3.1. <a href="#idp150584"></a></dt></dl></div><div class="preface" title="Preface"><div class="titlepage"><div><div><h2 class="title"><a name="idp61424"></a>Preface</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></
div><div class="section" title="1. Acknowledgements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="acknowledgements"></a>1. Acknowledgements</h2></div></div></div><p>ISC would like to acknowledge generous support for
- BIND 10 development of DHCPv4 and DHCPv6 components provided
- by <a class="ulink" href="http://www.comcast.com/" target="_top">Comcast</a>.</p></div></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a name="intro"></a>Chapter 1. Introduction</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#idp64344">1.1. Supported Platforms</a></span></dt><dt><span class="section"><a href="#required-software">1.2. Required Software</a></span></dt><dt><span class="section"><a href="#starting_stopping">1.3. Starting and Stopping the Server</a></span></dt><dt><span class="section"><a href="#managing_once_running">1.4. Managing BIND 10</a></span></dt></dl></div><p>
- BIND is the popular implementation of a DNS server, developer
- interfaces, and DNS tools.
- BIND 10 is a rewrite of BIND 9. BIND 10 is written in C++ and Python
- and provides a modular environment for serving and maintaining DNS.
- BIND 10 provides a EDNS0- and DNSSEC-capable authoritative
- DNS server and a caching recursive name server which also
- provides forwarding.
- </p><p>
- This guide covers the experimental prototype of
- BIND 10 version 20120127.
- </p><div class="section" title="1.1. Supported Platforms"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp64344"></a>1.1. Supported Platforms</h2></div></div></div><p>
- BIND 10 builds have been tested on Debian GNU/Linux 5 and unstable,
- Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, CentOS
- Linux 5.3, and MacOS 10.6.
-
- 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.
- </p></div><div class="section" title="1.2. Required Software"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="required-software"></a>1.2. Required Software</h2></div></div></div><p>
- BIND 10 requires at least Python 3.1
- (<a class="ulink" href="http://www.python.org/" target="_top">http://www.python.org/</a>).
- It has also been tested with Python 3.2.
- </p><p>
- BIND 10 uses the Botan crypto library for C++
- (<a class="ulink" href="http://botan.randombit.net/" target="_top">http://botan.randombit.net/</a>).
- It requires at least Botan version 1.8.
- </p><p>
- BIND 10 uses the log4cplus C++ logging library
- (<a class="ulink" href="http://log4cplus.sourceforge.net/" target="_top">http://log4cplus.sourceforge.net/</a>).
- It requires at least log4cplus version 1.0.3.
- </p><p>
- The authoritative DNS server uses SQLite3
- (<a class="ulink" href="http://www.sqlite.org/" target="_top">http://www.sqlite.org/</a>).
-
- It needs at least SQLite version 3.3.9.
- </p><p>
- The <span class="command"><strong>b10-xfrin</strong></span>, <span class="command"><strong>b10-xfrout</strong></span>,
- and <span class="command"><strong>b10-zonemgr</strong></span> components require the
- libpython3 library and the Python _sqlite3.so module
- (which is included with Python).
- The Python module needs to be built for the corresponding Python 3.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- Some operating systems do not provide these dependencies
- in their default installation nor standard packages
- collections.
- You may need to install them separately.
- </p></div></div><div class="section" title="1.3. Starting and Stopping the Server"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="starting_stopping"></a>1.3. Starting and Stopping the Server</h2></div></div></div><p>
- 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.
- </p><p>
- At first, running many different processes may seem confusing.
- However, these processes are started, stopped, and maintained
- by a single command, <span class="command"><strong>bind10</strong></span>.
- This command starts a master process which will start other
- processes as needed.
- The processes started by the <span class="command"><strong>bind10</strong></span>
- command have names starting with "b10-", including:
- </p><p>
-
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
- <span class="command"><strong>b10-msgq</strong></span> —
- Message bus daemon.
- This process coordinates communication between all of the other
- BIND 10 processes.
- </li><li class="listitem">
- <span class="command"><strong>b10-auth</strong></span> —
- Authoritative DNS server.
- This process serves DNS requests.
- </li><li class="listitem">
- <span class="command"><strong>b10-cfgmgr</strong></span> —
- Configuration manager.
- This process maintains all of the configuration for BIND 10.
- </li><li class="listitem">
- <span class="command"><strong>b10-cmdctl</strong></span> —
- Command and control service.
- This process allows external control of the BIND 10 system.
- </li><li class="listitem">
- <span class="command"><strong>b10-resolver</strong></span> —
- Recursive name server.
- This process handles incoming queries.
-
- </li><li class="listitem">
- <span class="command"><strong>b10-stats</strong></span> —
- Statistics collection daemon.
- This process collects and reports statistics data.
- </li><li class="listitem">
- <span class="command"><strong>b10-xfrin</strong></span> —
- 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.
- </li><li class="listitem">
- <span class="command"><strong>b10-xfrout</strong></span> —
- Outgoing zone transfer service.
- This process is used to handle transfer requests to
- send a local zone to a remote secondary server,
- when acting as a master server.
- </li><li class="listitem">
- <span class="command"><strong>b10-zonemgr</strong></span> —
- Secondary manager.
- This process keeps track of timers and other
- necessary information for BIND 10 to act as a slave server.
- </li></ul></div><p>
- </p><p>
- These are ran automatically by <span class="command"><strong>bind10</strong></span>
- and do not need to be run manually.
- </p></div><div class="section" title="1.4. Managing BIND 10"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="managing_once_running"></a>1.4. Managing BIND 10</h2></div></div></div><p>
- Once BIND 10 is running, a few commands are used to interact
- directly with the system:
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
- <span class="command"><strong>bindctl</strong></span> —
- interactive administration interface.
- This is a command-line tool which allows an administrator
- to control BIND 10.
- </li><li class="listitem">
- <span class="command"><strong>b10-loadzone</strong></span> —
- zone file loader.
- This tool will load standard masterfile-format zone files into
- BIND 10.
- </li><li class="listitem">
- <span class="command"><strong>b10-cmdctl-usermgr</strong></span> —
- user access control.
- This tool allows an administrator to authorize additional users
- to manage BIND 10.
- </li></ul></div><p>
- </p></div><p>
- The tools and modules are covered in full detail in this guide.
-
- In addition, manual pages are also provided in the default installation.
- </p><p>
- 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.
-
- </p></div><div class="chapter" title="Chapter 2. Installation"><div class="titlepage"><div><div><h2 class="title"><a name="installation"></a>Chapter 2. Installation</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#build-requirements">2.1. Building Requirements</a></span></dt><dt><span class="section"><a href="#quickstart">2.2. Quick start</a></span></dt><dt><span class="section"><a href="#install">2.3. Installation from source</a></span></dt><dd><dl><dt><span class="section"><a href="#idp113000">2.3.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#idp114472">2.3.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#idp119504">2.3.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#idp126792">2.3.4. Build</a></span></dt><dt><span class="section"><a href="#idp127848">2.3.5. Install</a></span></dt><dt><span class="section"><a href="#idp129504">2
.3.6. Install Hierarchy</a></span></dt></dl></dd></dl></div><div class="section" title="2.1. Building Requirements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="build-requirements"></a>2.1. Building Requirements</h2></div></div></div><p>
- In addition to the run-time requirements, building BIND 10
- from source code requires various development include headers.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- 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.
- </p></div><p>
- Building from source code requires the Boost
- build-time headers
- (<a class="ulink" href="http://www.boost.org/" target="_top">http://www.boost.org/</a>).
- At least Boost version 1.35 is required.
-
-
- </p><p>
- 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.
- </p><p>
- 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.
- </p><p>
- Visit the wiki at <a class="ulink" href="http://bind10.isc.org/wiki/SystemSpecificNotes" target="_top">http://bind10.isc.org/wiki/SystemSpecificNotes</a>
- for system-specific installation tips.
- </p></div><div class="section" title="2.2. Quick start"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="quickstart"></a>2.2. Quick start</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- This quickly covers the standard steps for installing
- and deploying BIND 10 as an authoritative name server using
- its defaults. For troubleshooting, full customizations and further
- details, see the respective chapters in the BIND 10 guide.
- </p></div><p>
- To quickly get started with BIND 10, follow these steps.
- </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">
- Install required run-time and build dependencies.
- </li><li class="listitem">
- Download the BIND 10 source tar file from
- <a class="ulink" href="ftp://ftp.isc.org/isc/bind10/" target="_top">ftp://ftp.isc.org/isc/bind10/</a>.
- </li><li class="listitem"><p>Extract the tar file:
- </p><pre class="screen">$ <strong class="userinput"><code>gzcat bind10-<em class="replaceable"><code>VERSION</code></em>.tar.gz | tar -xvf -</code></strong></pre><p>
- </p></li><li class="listitem"><p>Go into the source and run configure:
- </p><pre class="screen">$ <strong class="userinput"><code>cd bind10-<em class="replaceable"><code>VERSION</code></em></code></strong>
- $ <strong class="userinput"><code>./configure</code></strong></pre><p>
- </p></li><li class="listitem"><p>Build it:
- </p><pre class="screen">$ <strong class="userinput"><code>make</code></strong></pre><p>
- </p></li><li class="listitem"><p>Install it (to default /usr/local):
- </p><pre class="screen">$ <strong class="userinput"><code>make install</code></strong></pre><p>
- </p></li><li class="listitem"><p>Start the server:
- </p><pre class="screen">$ <strong class="userinput"><code>/usr/local/sbin/bind10</code></strong></pre><p>
- </p></li><li class="listitem"><p>Test it; for example:
- </p><pre class="screen">$ <strong class="userinput"><code>dig @127.0.0.1 -c CH -t TXT authors.bind</code></strong></pre><p>
- </p></li><li class="listitem"><p>Load desired zone file(s), for example:
- </p><pre class="screen">$ <strong class="userinput"><code>b10-loadzone <em class="replaceable"><code>your.zone.example.org</code></em></code></strong></pre><p>
- </p></li><li class="listitem">
- Test the new zone.
- </li></ol></div></div><div class="section" title="2.3. Installation from source"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="install"></a>2.3. Installation from source</h2></div></div></div><p>
- BIND 10 is open source software written in C++ and Python.
- It is freely available in source code form from ISC via
- the Git code revision control system or as a downloadable
- tar file. It may also be available in pre-compiled ready-to-use
- packages from operating system vendors.
- </p><div class="section" title="2.3.1. Download Tar File"><div class="titlepage"><div><div><h3 class="title"><a name="idp113000"></a>2.3.1. Download Tar File</h3></div></div></div><p>
- Downloading a release tar file is the recommended method to
- obtain the source code.
- </p><p>
- The BIND 10 releases are available as tar file downloads from
- <a class="ulink" href="ftp://ftp.isc.org/isc/bind10/" target="_top">ftp://ftp.isc.org/isc/bind10/</a>.
- Periodic development snapshots may also be available.
- </p></div><div class="section" title="2.3.2. Retrieve from Git"><div class="titlepage"><div><div><h3 class="title"><a name="idp114472"></a>2.3.2. Retrieve from Git</h3></div></div></div><p>
- Downloading this "bleeding edge" code is recommended only for
- developers or advanced users. Using development code in a production
- environment is not recommended.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- 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.
- </p></div><p>
- The latest development code, including temporary experiments
- and un-reviewed code, is available via the BIND 10 code revision
- control system. This is powered by Git and all the BIND 10
- development is public.
- The leading development is done in the <span class="quote">“<span class="quote">master</span>”</span>.
- </p><p>
- The code can be checked out from
- <code class="filename">git://git.bind10.isc.org/bind10</code>;
- for example:
-
- </p><pre class="screen">$ <strong class="userinput"><code>git clone git://git.bind10.isc.org/bind10</code></strong></pre><p>
- </p><p>
- When checking out the code from
- the code version control system, it doesn't include the
- generated configure script, Makefile.in files, nor the
- related configure files.
- They can be created by running <span class="command"><strong>autoreconf</strong></span>
- with the <code class="option">--install</code> switch.
- This will run <span class="command"><strong>autoconf</strong></span>,
- <span class="command"><strong>aclocal</strong></span>,
- <span class="command"><strong>libtoolize</strong></span>,
- <span class="command"><strong>autoheader</strong></span>,
- <span class="command"><strong>automake</strong></span>,
- and related commands.
- </p></div><div class="section" title="2.3.3. Configure before the build"><div class="titlepage"><div><div><h3 class="title"><a name="idp119504"></a>2.3.3. Configure before the build</h3></div></div></div><p>
- BIND 10 uses the GNU Build System to discover build environment
- details.
- To generate the makefiles using the defaults, simply run:
- </p><pre class="screen">$ <strong class="userinput"><code>./configure</code></strong></pre><p>
- </p><p>
- Run <span class="command"><strong>./configure</strong></span> with the <code class="option">--help</code>
- switch to view the different options. The commonly-used options are:
-
- </p><div class="variablelist"><dl><dt><span class="term">--prefix</span></dt><dd>Define the installation location (the
- default is <code class="filename">/usr/local/</code>).
- </dd><dt><span class="term">--with-boost-include</span></dt><dd>Define the path to find the Boost headers.
- </dd><dt><span class="term">--with-pythonpath</span></dt><dd>Define the path to Python 3.1 if it is not in the
- standard execution path.
- </dd><dt><span class="term">--with-gtest</span></dt><dd>Enable building the C++ Unit Tests using the
- Google Tests framework. Optionally this can define the
- path to the gtest header files and library.
- </dd></dl></div><p>
-
- </p><p>
- For example, the following configures it to
- find the Boost headers, find the
- Python interpreter, and sets the installation location:
-
- </p><pre class="screen">$ <strong class="userinput"><code>./configure \
- --with-boost-include=/usr/pkg/include \
- --with-pythonpath=/usr/pkg/bin/python3.1 \
- --prefix=/opt/bind10</code></strong></pre><p>
- </p><p>
- If the configure fails, it may be due to missing or old
- dependencies.
- </p></div><div class="section" title="2.3.4. Build"><div class="titlepage"><div><div><h3 class="title"><a name="idp126792"></a>2.3.4. Build</h3></div></div></div><p>
- After the configure step is complete, to build the executables
- from the C++ code and prepare the Python scripts, run:
-
- </p><pre class="screen">$ <strong class="userinput"><code>make</code></strong></pre><p>
- </p></div><div class="section" title="2.3.5. Install"><div class="titlepage"><div><div><h3 class="title"><a name="idp127848"></a>2.3.5. Install</h3></div></div></div><p>
- To install the BIND 10 executables, support files,
- and documentation, run:
- </p><pre class="screen">$ <strong class="userinput"><code>make install</code></strong></pre><p>
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The install step may require superuser privileges.</p></div></div><div class="section" title="2.3.6. Install Hierarchy"><div class="titlepage"><div><div><h3 class="title"><a name="idp129504"></a>2.3.6. Install Hierarchy</h3></div></div></div><p>
- The following is the layout of the complete BIND 10 installation:
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
- <code class="filename">bin/</code> —
- general tools and diagnostic clients.
- </li><li class="listitem">
- <code class="filename">etc/bind10-devel/</code> —
- configuration files.
- </li><li class="listitem">
- <code class="filename">lib/</code> —
- libraries and python modules.
- </li><li class="listitem">
- <code class="filename">libexec/bind10-devel/</code> —
- 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 <span class="command"><strong>bind10</strong></span> tool.
- </li><li class="listitem">
- <code class="filename">sbin/</code> —
- commands used by the system administrator.
- </li><li class="listitem">
- <code class="filename">share/bind10-devel/</code> —
- configuration specifications.
- </li><li class="listitem">
- <code class="filename">share/man/</code> —
- manual pages (online documentation).
- </li><li class="listitem">
- <code class="filename">var/bind10-devel/</code> —
- data source and configuration databases.
- </li></ul></div><p>
- </p></div></div></div><div class="chapter" title="Chapter 3. Starting BIND10 with bind10"><div class="titlepage"><div><div><h2 class="title"><a name="bind10"></a>Chapter 3. Starting BIND10 with <span class="command"><strong>bind10</strong></span></h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#start">3.1. Starting BIND 10</a></span></dt><dt><span class="section"><a href="#bind10.config">3.2. Configuration of started processes</a></span></dt></dl></div><p>
- BIND 10 provides the <span class="command"><strong>bind10</strong></span> command which
- starts up the required processes.
- <span class="command"><strong>bind10</strong></span>
- will also restart some processes that exit unexpectedly.
- This is the only command needed to start the BIND 10 system.
- </p><p>
- After starting the <span class="command"><strong>b10-msgq</strong></span> communications channel,
- <span class="command"><strong>bind10</strong></span> connects to it,
- runs the configuration manager, and reads its own configuration.
- Then it starts the other modules.
- </p><p>
- The <span class="command"><strong>b10-sockcreator</strong></span>, <span class="command"><strong>b10-msgq</strong></span> and
- <span class="command"><strong>b10-cfgmgr</strong></span>
- services make up the core. The <span class="command"><strong>b10-msgq</strong></span> daemon
- provides the communication channel between every part of the system.
- The <span class="command"><strong>b10-cfgmgr</strong></span> 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 <span class="command"><strong>b10-sockcreator</strong></span> will
- allocate sockets for the rest of the system.
- </p><p>
- In its default configuration, the <span class="command"><strong>bind10</strong></span>
- master process will also start up
- <span class="command"><strong>b10-cmdctl</strong></span> for admins to communicate with the
- system, <span class="command"><strong>b10-auth</strong></span> for authoritative DNS service,
- <span class="command"><strong>b10-stats</strong></span> for statistics collection,
- <span class="command"><strong>b10-xfrin</strong></span> for inbound DNS zone transfers,
- <span class="command"><strong>b10-xfrout</strong></span> for outbound DNS zone transfers,
- and <span class="command"><strong>b10-zonemgr</strong></span> for secondary service.
- </p><div class="section" title="3.1. Starting BIND 10"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="start"></a>3.1. Starting BIND 10</h2></div></div></div><p>
- To start the BIND 10 service, simply run <span class="command"><strong>bind10</strong></span>.
- Run it with the <code class="option">--verbose</code> switch to
- get additional debugging or diagnostic output.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- 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 <span class="quote">“<span class="quote">python</span>”</span>.
- This is not needed on some operating systems.
- </p></div></div><div class="section" title="3.2. Configuration of started processes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="bind10.config"></a>3.2. Configuration of started processes</h2></div></div></div><p>
- The processes to be started can be configured, with the exception
- of the <span class="command"><strong>b10-sockcreator</strong></span>, <span class="command"><strong>b10-msgq</strong></span>
- and <span class="command"><strong>b10-cfgmgr</strong></span>.
- </p><p>
- The configuration is in the Boss/components section. Each element
- represents one component, which is an abstraction of a process
- (currently there's also one component which doesn't represent
- a process). If you didn't want to transfer out at all (your server
- is a slave only), you would just remove the corresponding component
- from the set, like this and the process would be stopped immediately
- (and not started on the next startup):
- </p><pre class="screen">> <strong class="userinput"><code>config remove Boss/components b10-xfrout</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
- </p><p>
- To add a process to the set, let's say the resolver (which not started
- by default), you would do this:
- </p><pre class="screen">> <strong class="userinput"><code>config add Boss/components b10-resolver</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver/special resolver</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver/kind needed</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver/priority 10</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
- 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.
- </p><p>
- The special one is for components that need some kind of special care
- during startup or shutdown. Unless specified, the component is started
- in usual way. This is the list of components that need to be started
- in a special way, with the value of special used for them:
- </p><div class="table"><a name="idp150584"></a><p class="title"><b>Table 3.1. </b></p><div class="table-contents"><table border="1"><colgroup><col align="left" class="component"><col align="left" class="special"><col align="left" class="description"></colgroup><thead><tr><th align="left">Component</th><th align="left">Special</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left">b10-auth</td><td align="left">auth</td><td align="left">Authoritative server</td></tr><tr><td align="left">b10-resolver</td><td align="left">resolver</td><td align="left">The resolver</td></tr><tr><td align="left">b10-cmdctl</td><td align="left">cmdctl</td><td align="left">The command control (remote control interface)</td></tr></tbody></table></div></div><p><br class="table-break">
- </p><p>
- The kind specifies how a failure of the component should
- be handled. If it is set to <span class="quote">“<span class="quote">dispensable</span>”</span>
- (the default unless you set something else), it will get
- started again if it fails. If it is set to <span class="quote">“<span class="quote">needed</span>”</span>
- and it fails at startup, the whole <span class="command"><strong>bind10</strong></span>
- shuts down and exits with error exit code. But if it fails
- some time later, it is just started again. If you set it
- to <span class="quote">“<span class="quote">core</span>”</span>, you indicate that the system is
- not usable without the component and if such component
- fails, the system shuts down no matter when the failure
- happened. This is the behaviour of the core components
- (the ones you can't turn off), but you can declare any
- other components as core as well if you wish (but you can
- turn these off, they just can't fail).
- </p><p>
- The priority defines order in which the components should start.
- The ones with higher number are started sooner than the ones with
- lower ones. If you don't set it, 0 (zero) is used as the priority.
- Usually, leaving it at the default is enough.
- </p><p>
- There are other parameters we didn't use in our example.
- One of them is <span class="quote">“<span class="quote">address</span>”</span>. It is the address
- used by the component on the <span class="command"><strong>b10-msgq</strong></span>
- message bus. The special components already know their
- address, but the usual ones don't. The address is by
- convention the thing after <span class="emphasis"><em>b10-</em></span>, with
- the first letter capital (eg. <span class="command"><strong>b10-stats</strong></span>
- would have <span class="quote">“<span class="quote">Stats</span>”</span> as its address).
-
- </p><p>
- 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.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- This system allows you to start the same component multiple times
- (by including it in the configuration with different names, but the
- same process setting). However, the rest of the system doesn't expect
- such situation, so it would probably not do what you want. Such
- support is yet to be implemented.
- </p></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- The configuration is quite powerful, but that includes
- a lot of space for mistakes. You could turn off the
- <span class="command"><strong>b10-cmdctl</strong></span>, 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
- -- <span class="command"><strong>b10-stats-httpd</strong></span> need
- <span class="command"><strong>b10-stats</strong></span>, <span class="command"><strong>b10-xfrout</strong></span>
- needs the <span class="command"><strong>b10-auth</strong></span> to be running, etc.
-
-
-
- </p><p>
- In short, you should think twice before disabling something here.
- </p></div><p>
- It is possible to start some components multiple times (currently
- <span class="command"><strong>b10-auth</strong></span> and <span class="command"><strong>b10-resolzer</strong></span>).
- 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:
- </p><pre class="screen">> <strong class="userinput"><code>config add Boss/components b10-resolver-2</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver-2/special resolver</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver-2/kind needed</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
- </p><p>
- 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.
- </p></div></div><div class="chapter" title="Chapter 4. Command channel"><div class="titlepage"><div><div><h2 class="title"><a name="msgq"></a>Chapter 4. Command channel</h2></div></div></div><p>
- The BIND 10 components use the <span class="command"><strong>b10-msgq</strong></span>
- message routing daemon to communicate with other BIND 10 components.
- The <span class="command"><strong>b10-msgq</strong></span> implements what is called the
- <span class="quote">“<span class="quote">Command Channel</span>”</span>.
- 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.
- </p><p>
- Administrators do not communicate directly with the
- <span class="command"><strong>b10-msgq</strong></span> daemon.
- By default, BIND 10 uses port 9912 for the
- <span class="command"><strong>b10-msgq</strong></span> service.
- It listens on 127.0.0.1.
- </p></div><div class="chapter" title="Chapter 5. Configuration manager"><div class="titlepage"><div><div><h2 class="title"><a name="cfgmgr"></a>Chapter 5. Configuration manager</h2></div></div></div><p>
- The configuration manager, <span class="command"><strong>b10-cfgmgr</strong></span>,
- handles all BIND 10 system configuration. It provides
- persistent storage for configuration, and notifies running
- modules of configuration changes.
- </p><p>
- The <span class="command"><strong>b10-auth</strong></span> and <span class="command"><strong>b10-xfrin</strong></span>
- daemons and other components receive their configurations
- from the configuration manager over the <span class="command"><strong>b10-msgq</strong></span>
- command channel.
- </p><p>The administrator doesn't connect to it directly, but
- uses a user interface to communicate with the configuration
- manager via <span class="command"><strong>b10-cmdctl</strong></span>'s REST-ful interface.
- <span class="command"><strong>b10-cmdctl</strong></span> is covered in <a class="xref" href="#cmdctl" title="Chapter 6. Remote control daemon">Chapter 6, <i>Remote control daemon</i></a>.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- The development prototype release only provides the
- <span class="command"><strong>bindctl</strong></span> as a user interface to
- <span class="command"><strong>b10-cmdctl</strong></span>.
- Upcoming releases will provide another interactive command-line
- interface and a web-based interface.
- </p></div><p>
- The <span class="command"><strong>b10-cfgmgr</strong></span> daemon can send all
- specifications and all current settings to the
- <span class="command"><strong>bindctl</strong></span> client (via
- <span class="command"><strong>b10-cmdctl</strong></span>).
- </p><p>
- <span class="command"><strong>b10-cfgmgr</strong></span> relays configurations received
- from <span class="command"><strong>b10-cmdctl</strong></span> to the appropriate modules.
- </p><p>
- The stored configuration file is at
- <code class="filename">/usr/local/var/bind10-devel/b10-config.db</code>.
- (The full path is what was defined at build configure time for
- <code class="option">--localstatedir</code>.
- The default is <code class="filename">/usr/local/var/</code>.)
- 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.
- </p><p>
- The configuration manager does not have any command line arguments.
- Normally it is not started manually, but is automatically
- started using the <span class="command"><strong>bind10</strong></span> master process
- (as covered in <a class="xref" href="#bind10" title="Chapter 3. Starting BIND10 with bind10">Chapter 3, <i>Starting BIND10 with <span class="command"><strong>bind10</strong></span></i></a>).
- </p></div><div class="chapter" title="Chapter 6. Remote control daemon"><div class="titlepage"><div><div><h2 class="title"><a name="cmdctl"></a>Chapter 6. Remote control daemon</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#cmdctl.spec">6.1. Configuration specification for b10-cmdctl</a></span></dt></dl></div><p>
- <span class="command"><strong>b10-cmdctl</strong></span> 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.
- </p><p>
- When <span class="command"><strong>b10-cmdctl</strong></span> starts, it firsts
- asks <span class="command"><strong>b10-cfgmgr</strong></span> about what modules are
- running and what their configuration is (over the
- <span class="command"><strong>b10-msgq</strong></span> channel). Then it will start listening
- on HTTPS for clients — the user interface — such
- as <span class="command"><strong>bindctl</strong></span>.
- </p><p>
- <span class="command"><strong>b10-cmdctl</strong></span> directly sends commands
- (received from the user interface) to the specified component.
- Configuration changes are actually commands to
- <span class="command"><strong>b10-cfgmgr</strong></span> so are sent there.
- </p><p>The HTTPS server requires a private key,
- such as a RSA PRIVATE KEY.
- The default location is at
- <code class="filename">/usr/local/etc/bind10-devel/cmdctl-keyfile.pem</code>.
- (A sample key is at
- <code class="filename">/usr/local/share/bind10-devel/cmdctl-keyfile.pem</code>.)
- It also uses a certificate located at
- <code class="filename">/usr/local/etc/bind10-devel/cmdctl-certfile.pem</code>.
- (A sample certificate is at
- <code class="filename">/usr/local/share/bind10-devel/cmdctl-certfile.pem</code>.)
- This may be a self-signed certificate or purchased from a
- certification authority.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- The HTTPS server doesn't support a certificate request from a
- client (at this time).
-
- The <span class="command"><strong>b10-cmdctl</strong></span> 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.
- </p></div><p>
- The <span class="command"><strong>b10-cmdctl</strong></span> daemon also requires
- the user account file located at
- <code class="filename">/usr/local/etc/bind10-devel/cmdctl-accounts.csv</code>.
- This comma-delimited file lists the accounts with a user name,
- hashed password, and salt.
- (A sample file is at
- <code class="filename">/usr/local/share/bind10-devel/cmdctl-accounts.csv</code>.
- It contains the user named <span class="quote">“<span class="quote">root</span>”</span> with the password
- <span class="quote">“<span class="quote">bind10</span>”</span>.)
- </p><p>
- The administrator may create a user account with the
- <span class="command"><strong>b10-cmdctl-usermgr</strong></span> tool.
- </p><p>
- By default the HTTPS server listens on the localhost port 8080.
- The port can be set by using the <code class="option">--port</code> command line option.
- The address to listen on can be set using the <code class="option">--address</code> command
- line argument.
- Each HTTPS connection is stateless and timesout in 1200 seconds
- by default. This can be
- redefined by using the <code class="option">--idle-timeout</code> command line argument.
- </p><div class="section" title="6.1. Configuration specification for b10-cmdctl"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="cmdctl.spec"></a>6.1. Configuration specification for b10-cmdctl</h2></div></div></div><p>
- The configuration items for <span class="command"><strong>b10-cmdctl</strong></span> are:
-key_file
-cert_file
-accounts_file
- </p><p>
- The control commands are:
-print_settings
-
-
-shutdown
- </p></div></div><div class="chapter" title="Chapter 7. Control and configure user interface"><div class="titlepage"><div><div><h2 class="title"><a name="bindctl"></a>Chapter 7. Control and configure user interface</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- For this development prototype release, <span class="command"><strong>bindctl</strong></span>
- 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.
- </p></div><p>
- The <span class="command"><strong>bindctl</strong></span> 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 <span class="command"><strong>b10-cmdctl</strong></span>. It doesn't
- communicate to any other components directly.
- </p><p>
- Configuration changes are actually commands to
- <span class="command"><strong>b10-cfgmgr</strong></span>. So when <span class="command"><strong>bindctl</strong></span>
- sends a configuration, it is sent to <span class="command"><strong>b10-cmdctl</strong></span>
- (over a HTTPS connection); then <span class="command"><strong>b10-cmdctl</strong></span>
- sends the command (over a <span class="command"><strong>b10-msgq</strong></span> command
- channel) to <span class="command"><strong>b10-cfgmgr</strong></span> which then stores
- the details and relays (over a <span class="command"><strong>b10-msgq</strong></span> command
- channel) the configuration on to the specified module.
- </p><p>
- </p></div><div class="chapter" title="Chapter 8. Authoritative Server"><div class="titlepage"><div><div><h2 class="title"><a name="authserver"></a>Chapter 8. Authoritative Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#idp200360">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#idp205096">8.2. Data Source Backends</a></span></dt><dt><span class="section"><a href="#idp207592">8.3. Loading Master Zones Files</a></span></dt></dl></div><p>
- The <span class="command"><strong>b10-auth</strong></span> is the authoritative DNS server.
- It supports EDNS0 and DNSSEC. It supports IPv6.
- Normally it is started by the <span class="command"><strong>bind10</strong></span> master
- process.
- </p><div class="section" title="8.1. Server Configurations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp200360"></a>8.1. Server Configurations</h2></div></div></div><p>
- <span class="command"><strong>b10-auth</strong></span> is configured via the
- <span class="command"><strong>b10-cfgmgr</strong></span> configuration manager.
- The module name is <span class="quote">“<span class="quote">Auth</span>”</span>.
- The configuration data item is:
-
- </p><div class="variablelist"><dl><dt><span class="term">database_file</span></dt><dd>This is an optional string to define the path to find
- the SQLite3 database file.
-
-Note: Later the DNS server will use various data source backends.
-This may be a temporary setting until then.
- </dd></dl></div><p>
-
- </p><p>
-
- The configuration command is:
-
- </p><div class="variablelist"><dl><dt><span class="term">shutdown</span></dt><dd>Stop the authoritative DNS server.
- </dd></dl></div><p>
-
- </p></div><div class="section" title="8.2. Data Source Backends"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp205096"></a>8.2. Data Source Backends</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- For the development prototype release, <span class="command"><strong>b10-auth</strong></span>
- supports a SQLite3 data source backend and in-memory data source
- backend.
- Upcoming versions will be able to use multiple different
- data sources, such as MySQL and Berkeley DB.
- </p></div><p>
- By default, the SQLite3 backend uses the data file located at
- <code class="filename">/usr/local/var/bind10-devel/zone.sqlite3</code>.
- (The full path is what was defined at build configure time for
- <code class="option">--localstatedir</code>.
- The default is <code class="filename">/usr/local/var/</code>.)
- This data file location may be changed by defining the
- <span class="quote">“<span class="quote">database_file</span>”</span> configuration.
- </p></div><div class="section" title="8.3. Loading Master Zones Files"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp207592"></a>8.3. Loading Master Zones Files</h2></div></div></div><p>
- RFC 1035 style DNS master zone files may imported
- into a BIND 10 data source by using the
- <span class="command"><strong>b10-loadzone</strong></span> utility.
- </p><p>
- <span class="command"><strong>b10-loadzone</strong></span> supports the following
- special directives (control entries):
-
- </p><div class="variablelist"><dl><dt><span class="term">$INCLUDE</span></dt><dd>Loads an additional zone file. This may be recursive.
- </dd><dt><span class="term">$ORIGIN</span></dt><dd>Defines the relative domain name.
- </dd><dt><span class="term">$TTL</span></dt><dd>Defines the time-to-live value used for following
- records that don't include a TTL.
- </dd></dl></div><p>
-
- </p><p>
- The <code class="option">-o</code> argument may be used to define the
- default origin for loaded zone file records.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- In the development prototype release, only the SQLite3 back
- end is used.
- By default, it stores the zone data in
- <code class="filename">/usr/local/var/bind10-devel/zone.sqlite3</code>
- unless the <code class="option">-d</code> switch is used to set the
- database filename.
- Multiple zones are stored in a single SQLite3 zone database.
- </p></div><p>
- If you reload a zone already existing in the database,
- all records from that prior zone disappear and a whole new set
- appears.
- </p></div></div><div class="chapter" title="Chapter 9. Incoming Zone Transfers"><div class="titlepage"><div><div><h2 class="title"><a name="xfrin"></a>Chapter 9. Incoming Zone Transfers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#idp217864">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#idp220904">9.2. Enabling IXFR</a></span></dt><dt><span class="section"><a href="#zonemgr">9.3. Secondary Manager</a></span></dt><dt><span class="section"><a href="#idp11976">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt></dl></div><p>
- Incoming zones are transferred using the <span class="command"><strong>b10-xfrin</strong></span>
- process which is started by <span class="command"><strong>bind10</strong></span>.
- When received, the zone is stored in the corresponding BIND 10
- data source, and its records can be served by
- <span class="command"><strong>b10-auth</strong></span>.
- In combination with <span class="command"><strong>b10-zonemgr</strong></span> (for
- automated SOA checks), this allows the BIND 10 server to
- provide <span class="quote">“<span class="quote">secondary</span>”</span> service.
- </p><p>
- The <span class="command"><strong>b10-xfrin</strong></span> process supports both AXFR and
- IXFR. Due to some implementation limitations of the current
- development release, however, it only tries AXFR by default,
- and care should be taken to enable IXFR.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- In the current development release of BIND 10, incoming zone
- transfers are only available for SQLite3-based data sources,
- that is, they don't work for an in-memory data source.
- </p></div><div class="section" title="9.1. Configuration for Incoming Zone Transfers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp217864"></a>9.1. Configuration for Incoming Zone Transfers</h2></div></div></div><p>
- In practice, you need to specify a list of secondary zones to
- enable incoming zone transfers for these zones (you can still
- trigger a zone transfer manually, without a prior configuration
- (see below)).
- </p><p>
- 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 <span class="command"><strong>bindctl</strong></span> prompt:
-
- </p><pre class="screen">> <strong class="userinput"><code>config add Xfrin/zones</code></strong>
-> <strong class="userinput"><code>config set Xfrin/zones[0]/name "<code class="option">example.com</code>"</code></strong>
-> <strong class="userinput"><code>config set Xfrin/zones[0]/master_addr "<code class="option">2001:db8::53</code>"</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
-
- (We assume there has been no zone configuration before).
- </p></div><div class="section" title="9.2. Enabling IXFR"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp220904"></a>9.2. Enabling IXFR</h2></div></div></div><p>
- As noted above, <span class="command"><strong>b10-xfrin</strong></span> uses AXFR for
- zone transfers by default. To enable IXFR for zone transfers
- for a particular zone, set the <strong class="userinput"><code>use_ixfr</code></strong>
- configuration parameter to <strong class="userinput"><code>true</code></strong>.
- In the above example of configuration sequence, you'll need
- to add the following before performing <strong class="userinput"><code>commit</code></strong>:
- </p><pre class="screen">> <strong class="userinput"><code>config set Xfrin/zones[0]/use_ixfr true</code></strong></pre><p>
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- One reason why IXFR is disabled by default in the current
- release is because it does not support automatic fallback from IXFR to
- AXFR when it encounters a primary server that doesn't support
- outbound IXFR (and, not many existing implementations support
- it). Another, related reason is that it does not use AXFR even
- if it has no knowledge about the zone (like at the very first
- time the secondary server is set up). IXFR requires the
- "current version" of the zone, so obviously it doesn't work
- in this situation and AXFR is the only workable choice.
- The current release of <span class="command"><strong>b10-xfrin</strong></span> does not
- make this selection automatically.
- These features will be implemented in a near future
- version, at which point we will enable IXFR by default.
- </p></div></div><div class="section" title="9.3. Secondary Manager"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="zonemgr"></a>9.3. Secondary Manager</h2></div></div></div><p>
- The <span class="command"><strong>b10-zonemgr</strong></span> process is started by
- <span class="command"><strong>bind10</strong></span>.
- It keeps track of SOA refresh, retry, and expire timers
- and other details for BIND 10 to perform as a slave.
- When the <span class="command"><strong>b10-auth</strong></span> authoritative DNS server
- receives a NOTIFY message, <span class="command"><strong>b10-zonemgr</strong></span>
- may tell <span class="command"><strong>b10-xfrin</strong></span> to do a refresh
- to start an inbound zone transfer.
- The secondary manager resets its counters when a new zone is
- transferred in.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- Access control (such as allowing notifies) is not yet provided.
- The primary/secondary service is not yet complete.
- </p></div><p>
- The following example shows using <span class="command"><strong>bindctl</strong></span>
- to configure the server to be a secondary for the example zone:
-
- </p><pre class="screen">> <strong class="userinput"><code>config add Zonemgr/secondary_zones</code></strong>
-> <strong class="userinput"><code>config set Zonemgr/secondary_zones[0]/name "<code class="option">example.com</code>"</code></strong>
-> <strong class="userinput"><code>config set Zonemgr/secondary_zones[0]/class "<code class="option">IN</code>"</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
-
-
-
- </p><p>
- If the zone does not exist in the data source already
- (i.e. no SOA record for it), <span class="command"><strong>b10-zonemgr</strong></span>
- will automatically tell <span class="command"><strong>b10-xfrin</strong></span>
- to transfer the zone in.
- </p></div><div class="section" title="9.4. Trigger an Incoming Zone Transfer Manually"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp11976"></a>9.4. Trigger an Incoming Zone Transfer Manually</h2></div></div></div><p>
- To manually trigger a zone transfer to retrieve a remote zone,
- you may use the <span class="command"><strong>bindctl</strong></span> utility.
- For example, at the <span class="command"><strong>bindctl</strong></span> prompt run:
-
- </p><pre class="screen">> <strong class="userinput"><code>Xfrin retransfer zone_name="<code class="option">foo.example.org</code>" master=<code class="option">192.0.2.99</code></code></strong></pre><p>
- </p></div></div><div class="chapter" title="Chapter 10. Outbound Zone Transfers"><div class="titlepage"><div><div><h2 class="title"><a name="xfrout"></a>Chapter 10. Outbound Zone Transfers</h2></div></div></div><p>
- The <span class="command"><strong>b10-xfrout</strong></span> process is started by
- <span class="command"><strong>bind10</strong></span>.
- When the <span class="command"><strong>b10-auth</strong></span> authoritative DNS server
- receives an AXFR or IXFR request, <span class="command"><strong>b10-auth</strong></span>
- internally forwards the request to <span class="command"><strong>b10-xfrout</strong></span>,
- which handles the rest of request processing.
- This is used to provide primary DNS service to share zones
- to secondary name servers.
- The <span class="command"><strong>b10-xfrout</strong></span> is also used to send
- NOTIFY messages to secondary servers.
- </p><p>
- A global or per zone <code class="option">transfer_acl</code> configuration
- can be used to control accessibility of the outbound zone
- transfer service.
- By default, <span class="command"><strong>b10-xfrout</strong></span> allows any clients to
- perform zone transfers for any zones:
- </p><pre class="screen">> <strong class="userinput"><code>config show Xfrout/transfer_acl</code></strong>
-Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)</pre><p>
- You can change this to, for example, rejecting all transfer
- requests by default while allowing requests for the transfer
- of zone "example.com" from 192.0.2.1 and 2001:db8::1 as follows:
- </p><pre class="screen">> <strong class="userinput"><code>config set Xfrout/transfer_acl[0] {"action": "REJECT"}</code></strong>
-> <strong class="userinput"><code>config add Xfrout/zone_config</code></strong>
-> <strong class="userinput"><code>config set Xfrout/zone_config[0]/origin "example.com"</code></strong>
-> <strong class="userinput"><code>config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1"},</code></strong>
-<strong class="userinput"><code> {"action": "ACCEPT", "from": "2001:db8::1"}]</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- In the above example the lines
- for <code class="option">transfer_acl</code> were divided for
- readability. In the actual input it must be in a single line.
- </p></div><p>
- If you want to require TSIG in access control, a separate TSIG
- "key ring" must be configured specifically
- for <span class="command"><strong>b10-xfrout</strong></span> as well as a system wide
- key ring, both containing a consistent set of keys.
- For example, to change the previous example to allowing requests
- from 192.0.2.1 signed by a TSIG with a key name of
- "key.example", you'll need to do this:
- </p><pre class="screen">> <strong class="userinput"><code>config set tsig_keys/keys ["key.example:<base64-key>"]</code></strong>
-> <strong class="userinput"><code>config set Xfrout/tsig_keys/keys ["key.example:<base64-key>"]</code></strong>
-> <strong class="userinput"><code>config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}]</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
- The first line of configuration defines a system wide key ring.
- This is necessary because the <span class="command"><strong>b10-auth</strong></span> server
- also checks TSIGs and it uses the system wide configuration.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- In a future version, <span class="command"><strong>b10-xfrout</strong></span> will also
- use the system wide TSIG configuration.
- The way to specify zone specific configuration (ACLs, etc) is
- likely to be changed, too.
- </p></div></div><div class="chapter" title="Chapter 11. Recursive Name Server"><div class="titlepage"><div><div><h2 class="title"><a name="resolverserver"></a>Chapter 11. Recursive Name Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#idp259896">11.1. Access Control</a></span></dt><dt><span class="section"><a href="#idp269088">11.2. Forwarding</a></span></dt></dl></div><p>
- The <span class="command"><strong>b10-resolver</strong></span> process is started by
- <span class="command"><strong>bind10</strong></span>.
-
- </p><p>
- The main <span class="command"><strong>bind10</strong></span> process can be configured
- to select to run either the authoritative or resolver or both.
- By default, it starts the authoritative service.
-
-
- You may change this using <span class="command"><strong>bindctl</strong></span>, for example:
-
- </p><pre class="screen">
-> <strong class="userinput"><code>config remove Boss/components b10-xfrout</code></strong>
-> <strong class="userinput"><code>config remove Boss/components b10-xfrin</code></strong>
-> <strong class="userinput"><code>config remove Boss/components b10-auth</code></strong>
-> <strong class="userinput"><code>config add Boss/components b10-resolver</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver/special resolver</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver/kind needed</code></strong>
-> <strong class="userinput"><code>config set Boss/components/b10-resolver/priority 10</code></strong>
-> <strong class="userinput"><code>config commit</code></strong>
-</pre><p>
-
- </p><p>
- The master <span class="command"><strong>bind10</strong></span> will stop and start
- the desired services.
- </p><p>
- 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):
-
- </p><pre class="screen">
-> <strong class="userinput"><code>config add Resolver/listen_on</code></strong>
-> <strong class="userinput"><code>config set Resolver/listen_on[<em class="replaceable"><code>2</code></em>]/address "192.168.1.1"</code></strong>
-> <strong class="userinput"><code>config set Resolver/listen_on[<em class="replaceable"><code>2</code></em>]/port 53</code></strong>
-> <strong class="userinput"><code>config commit</code></strong>
-</pre><p>
- </p><p>(Replace the <span class="quote">“<span class="quote"><em class="replaceable"><code>2</code></em></span>”</span>
- as needed; run <span class="quote">“<span class="quote"><strong class="userinput"><code>config show
- Resolver/listen_on</code></strong></span>”</span> if needed.)</p><div class="section" title="11.1. Access Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp259896"></a>11.1. Access Control</h2></div></div></div><p>
- By default, the <span class="command"><strong>b10-resolver</strong></span> daemon only accepts
- DNS queries from the localhost (127.0.0.1 and ::1).
- The <code class="option">Resolver/query_acl</code> configuration may
- be used to reject, drop, or allow specific IPs or networks.
- This configuration list is first match.
- </p><p>
- The configuration's <code class="option">action</code> item may be
- set to <span class="quote">“<span class="quote">ACCEPT</span>”</span> to allow the incoming query,
- <span class="quote">“<span class="quote">REJECT</span>”</span> to respond with a DNS REFUSED return
- code, or <span class="quote">“<span class="quote">DROP</span>”</span> to ignore the query without
- any response (such as a blackhole). For more information,
- see the respective debugging messages: <a class="ulink" href="bind10-messages.html#RESOLVER_QUERY_ACCEPTED" target="_top">RESOLVER_QUERY_ACCEPTED</a>,
- <a class="ulink" href="bind10-messages.html#RESOLVER_QUERY_REJECTED" target="_top">RESOLVER_QUERY_REJECTED</a>,
- and <a class="ulink" href="bind10-messages.html#RESOLVER_QUERY_DROPPED" target="_top">RESOLVER_QUERY_DROPPED</a>.
- </p><p>
- The required configuration's <code class="option">from</code> item is set
- to an IPv4 or IPv6 address, addresses with an network mask, or to
- the special lowercase keywords <span class="quote">“<span class="quote">any6</span>”</span> (for
- any IPv6 address) or <span class="quote">“<span class="quote">any4</span>”</span> (for any IPv4
- address).
- </p><p>
- For example to allow the <em class="replaceable"><code>192.168.1.0/24</code></em>
- network to use your recursive name server, at the
- <span class="command"><strong>bindctl</strong></span> prompt run:
- </p><pre class="screen">
-> <strong class="userinput"><code>config add Resolver/query_acl</code></strong>
-> <strong class="userinput"><code>config set Resolver/query_acl[<em class="replaceable"><code>2</code></em>]/action "ACCEPT"</code></strong>
-> <strong class="userinput"><code>config set Resolver/query_acl[<em class="replaceable"><code>2</code></em>]/from "<em class="replaceable"><code>192.168.1.0/24</code></em>"</code></strong>
-> <strong class="userinput"><code>config commit</code></strong>
-</pre><p>(Replace the <span class="quote">“<span class="quote"><em class="replaceable"><code>2</code></em></span>”</span>
- as needed; run <span class="quote">“<span class="quote"><strong class="userinput"><code>config show
- Resolver/query_acl</code></strong></span>”</span> if needed.)</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This prototype access control configuration
- syntax may be changed.</p></div></div><div class="section" title="11.2. Forwarding"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp269088"></a>11.2. Forwarding</h2></div></div></div><p>
-
- To enable forwarding, the upstream address and port must be
- configured to forward queries to, such as:
-
- </p><pre class="screen">
-> <strong class="userinput"><code>config set Resolver/forward_addresses [{ "address": "<em class="replaceable"><code>192.168.1.1</code></em>", "port": 53 }]</code></strong>
-> <strong class="userinput"><code>config commit</code></strong>
-</pre><p>
-
- (Replace <em class="replaceable"><code>192.168.1.1</code></em> to point to your
- full resolver.)
- </p><p>
- Normal iterative name service can be re-enabled by clearing the
- forwarding address(es); for example:
-
- </p><pre class="screen">
-> <strong class="userinput"><code>config set Resolver/forward_addresses []</code></strong>
-> <strong class="userinput"><code>config commit</code></strong>
-</pre><p>
- </p></div></div><div class="chapter" title="Chapter 12. DHCPv4 Server"><div class="titlepage"><div><div><h2 class="title"><a name="dhcp4"></a>Chapter 12. DHCPv4 Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#dhcp4-usage">12.1. DHCPv4 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp4-config">12.2. DHCPv4 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp4-std">12.3. Supported standards</a></span></dt><dt><span class="section"><a href="#dhcp4-limit">12.4. DHCPv4 Server Limitations</a></span></dt></dl></div><p>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. BIND10 offers server implementations for both DHCPv4
- and DHCPv6. This chapter is about DHCP for IPv4. For a description
- of the DHCPv6 server, see <a class="xref" href="#dhcp6" title="Chapter 13. DHCPv6 Server">Chapter 13, <i>DHCPv6 Server</i></a>.</p><p>The DHCPv4 server component is currently under intense
- development. You may want to check out <a class="ulink" href="http://bind10.isc.org/wiki/Kea" target="_top">BIND10 DHCP (Kea) wiki</a>
- and recent posts on <a class="ulink" href="https://lists.isc.org/mailman/listinfo/bind10-dev" target="_top">BIND10
- developers mailing list</a>.</p><p>The DHCPv4 and DHCPv6 components in BIND10 architecture are
- internally code named <span class="quote">“<span class="quote">Kea</span>”</span>.</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- As of December 2011, both DHCPv4 and DHCPv6 components are
- skeleton servers. That means that while they are capable of
- performing DHCP configuration, they are not fully functional
- yet. In particular, neither has functional lease
- databases. This means that they will assign the same, fixed,
- hardcoded addresses to any client that will ask. See <a class="xref" href="#dhcp4-limit" title="12.4. DHCPv4 Server Limitations">Section 12.4, “DHCPv4 Server Limitations”</a> and <a class="xref" href="#dhcp6-limit" title="13.4. DHCPv6 Server Limitations">Section 13.4, “DHCPv6 Server Limitations”</a> for
- detailed description.
- </p></div><div class="section" title="12.1. DHCPv4 Server Usage"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp4-usage"></a>12.1. DHCPv4 Server Usage</h2></div></div></div><p>BIND10 provides the DHCPv4 server component since December
- 2011. It is a skeleton server and can be described as an early
- prototype that is not fully functional yet. It is mature enough
- to conduct first tests in lab environment, but it has
- significant limitations. See <a class="xref" href="#dhcp4-limit" title="12.4. DHCPv4 Server Limitations">Section 12.4, “DHCPv4 Server Limitations”</a> for
- details.
- </p><p>
- The DHCPv4 server is implemented as <span class="command"><strong>b10-dhcp4</strong></span>
- daemon. As it is not configurable yet, it is fully autonomous,
- that is it does not interact with <span class="command"><strong>b10-cfgmgr</strong></span>.
- To start DHCPv4 server, simply input:
-
- </p><pre class="screen">
-#<strong class="userinput"><code>cd src/bin/dhcp4</code></strong>
-#<strong class="userinput"><code>./b10-dhcp4</code></strong>
-</pre><p>
-
- Depending on your installation, <span class="command"><strong>b10-dhcp4</strong></span>
- binary may reside in src/bin/dhcp4 in your source code
- directory, in /usr/local/bin/b10-dhcp4 or other directory
- you specified during compilation.
-
- At start, the server will detect available network interfaces
- and will attempt to open UDP sockets on all interfaces that
- are up, running, are not loopback, and have IPv4 address
- 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.</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- Integration with <span class="command"><strong>bind10</strong></span> is
- planned. Ultimately, <span class="command"><strong>b10-dhcp4</strong></span> will not
- be started directly, but rather via
- <span class="command"><strong>bind10</strong></span>. Please be aware of this planned
- change.
- </p></div></div><div class="section" title="12.2. DHCPv4 Server Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp4-config"></a>12.2. DHCPv4 Server Configuration</h2></div></div></div><p>
- The DHCPv4 server does not have a lease database implemented yet
- nor any support for configuration, so every time the same set
- of configuration options (including the same fixed address)
- will be assigned every time.
- </p><p>
- At this stage of development, the only way to alter the server
- configuration is to tweak its source code. To do so, please
- edit src/bin/dhcp4/dhcp4_srv.cc file and modify following
- parameters and recompile:
- </p><pre class="screen">
-const std::string HARDCODED_LEASE = "192.0.2.222"; // assigned lease
-const std::string HARDCODED_NETMASK = "255.255.255.0";
-const uint32_t HARDCODED_LEASE_TIME = 60; // in seconds
-const std::string HARDCODED_GATEWAY = "192.0.2.1";
-const std::string HARDCODED_DNS_SERVER = "192.0.2.2";
-const std::string HARDCODED_DOMAIN_NAME = "isc.example.com";
-const std::string HARDCODED_SERVER_ID = "192.0.2.1";</pre><p>
-
- Lease database and configuration support is planned for 2012.
- </p></div><div class="section" title="12.3. Supported standards"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp4-std"></a>12.3. Supported standards</h2></div></div></div><p>The following standards and draft standards are currently
- supported:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">RFC2131: Supported messages are DISCOVER, OFFER,
- REQUEST, and ACK.</li><li class="listitem">RFC2132: 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).</li></ul></div></div><div class="section" title="12.4. DHCPv4 Server Limitations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp4-limit"></a>12.4. DHCPv4 Server Limitations</h2></div></div></div><p>These are the current limitations of the DHCPv4 server
- software. Most of them are reflections of the early stage of
- development and should be treated as <span class="quote">“<span class="quote">not implemented
- yet</span>”</span>, rather than actual limitations.</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">During initial IPv4 node configuration, the
- server is expected to send packets to a node that does not
- have IPv4 address assigned yet. The server requires
- certain tricks (or hacks) to transmit such packets. This
- is not implemented yet, therefore DHCPv4 server supports
- relayed traffic only (that is, normal point to point
- communication).</li><li class="listitem"><span class="command"><strong>b10-dhcp4</strong></span> provides a single,
- fixed, hardcoded lease to any client that asks. There is
- no lease manager implemented. If two clients request
- addresses, they will both get the same fixed
- address.</li><li class="listitem"><span class="command"><strong>b10-dhcp4</strong></span> does not support any
- configuration mechanisms yet. The whole configuration is
- currently hardcoded. The only way to tweak configuration
- is to directly modify source code. See see <a class="xref" href="#dhcp4-config" title="12.2. DHCPv4 Server Configuration">Section 12.2, “DHCPv4 Server Configuration”</a> for details.</li><li class="listitem">Upon start, the server will open sockets on all
- interfaces that are not loopback, are up and running and
- have IPv4 address. Support for multiple interfaces is not
- coded in reception routines yet, so if you are running
- this code on a machine that has many interfaces and
- <span class="command"><strong>b10-dhcp4</strong></span> happens to listen on wrong
- interface, the easiest way to work around this problem is
- to turn down other interfaces. This limitation will be
- fixed shortly.</li><li class="listitem">PRL (Parameter Request List, a list of options
- requested by a client) is currently ignored and server
- assigns DNS SERVER and DOMAIN NAME options.</li><li class="listitem"><span class="command"><strong>b10-dhcp4</strong></span> does not support
- BOOTP. That is a design choice. This limitation is
- permanent. If you have legacy nodes that can't use DHCP and
- require BOOTP support, please use latest version of ISC DHCP
- <a class="ulink" href="http://www.isc.org/software/dhcp" target="_top">http://www.isc.org/software/dhcp</a>.</li><li class="listitem">Interface detection is currently working on Linux
- only. See <a class="xref" href="#iface-detect" title="14.1. Interface detection">Section 14.1, “Interface detection”</a> for details.</li><li class="listitem"><span class="command"><strong>b10-dhcp4</strong></span> does not verify that
- assigned address is unused. According to RFC2131, the
- allocating server should verify that address is no used by
- sending ICMP echo request.</li><li class="listitem">Address renewal (RENEW), rebinding (REBIND),
- confirmation (CONFIRM), duplication report (DECLINE) and
- release (RELEASE) are not supported yet.</li><li class="listitem">DNS Update is not supported yet.</li><li class="listitem">-v (verbose) command line option is currently
- the default, and cannot be disabled.</li></ul></div></div></div><div class="chapter" title="Chapter 13. DHCPv6 Server"><div class="titlepage"><div><div><h2 class="title"><a name="dhcp6"></a>Chapter 13. DHCPv6 Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#dhcp6-usage">13.1. DHCPv6 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp6-config">13.2. DHCPv6 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp6-std">13.3. Supported DHCPv6 Standards</a></span></dt><dt><span class="section"><a href="#dhcp6-limit">13.4. DHCPv6 Server Limitations</a></span></dt></dl></div><p>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is
- specified in RFC3315. BIND10 provides DHCPv6 server implementation
- that is described in this chapter. For a description of the DHCPv4
- server implementation, see <a class="xref" href="#dhcp4" title="Chapter 12. DHCPv4 Server">Chapter 12, <i>DHCPv4 Server</i></a>.
- </p><p>The DHCPv6 server component is currently under intense
- development. You may want to check out <a class="ulink" href="http://bind10.isc.org/wiki/Kea" target="_top">BIND10 DHCP (Kea) wiki</a>
- and recent posts on <a class="ulink" href="https://lists.isc.org/mailman/listinfo/bind10-dev" target="_top">BIND10
- developers mailing list</a>.</p><p>The DHCPv4 and DHCPv6 components in BIND10 architecture are
- internally code named <span class="quote">“<span class="quote">Kea</span>”</span>.</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- As of December 2011, both DHCPv4 and DHCPv6 components are
- skeleton servers. That means that while they are capable of
- performing DHCP configuration, they are not fully functional
- yet. In particular, neither has functional lease
- databases. This means that they will assign the same, fixed,
- hardcoded addresses to any client that will ask. See <a class="xref" href="#dhcp4-limit" title="12.4. DHCPv4 Server Limitations">Section 12.4, “DHCPv4 Server Limitations”</a> and <a class="xref" href="#dhcp6-limit" title="13.4. DHCPv6 Server Limitations">Section 13.4, “DHCPv6 Server Limitations”</a> for
- detailed description.
- </p></div><div class="section" title="13.1. DHCPv6 Server Usage"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp6-usage"></a>13.1. DHCPv6 Server Usage</h2></div></div></div><p>
- BIND10 provides the DHCPv6 server component since September
- 2011. It is a skeleton server and can be described as an early
- prototype that is not fully functional yet. It is mature
- enough to conduct first tests in lab environment, but it has
- significant limitations. See <a class="xref" href="#dhcp6-limit" title="13.4. DHCPv6 Server Limitations">Section 13.4, “DHCPv6 Server Limitations”</a> for
- details.
- </p><p>
- The DHCPv6 server is implemented as <span class="command"><strong>b10-dhcp6</strong></span>
- daemon. As it is not configurable yet, it is fully autonomous,
- that is it does not interact with <span class="command"><strong>b10-cfgmgr</strong></span>.
- To start DHCPv6 server, simply input:
-
- </p><pre class="screen">
-#<strong class="userinput"><code>cd src/bin/dhcp6</code></strong>
-#<strong class="userinput"><code>./b10-dhcp6</code></strong>
-</pre><p>
-
- Depending on your installation, <span class="command"><strong>b10-dhcp6</strong></span>
- binary may reside in src/bin/dhcp6 in your source code
- directory, in /usr/local/bin/b10-dhcp6 or other directory
- you specified during compilation.
-
- At start, 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.
-
- The server will then listen to incoming traffic. Currently
- supported client messages are SOLICIT and REQUEST. The server
- will respond to them with ADVERTISE and REPLY, respectively.
-
- Since the DHCPv6 server opens privileged ports, it requires root
- access. Make sure you run this daemon as root.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- Integration with <span class="command"><strong>bind10</strong></span> is
- planned. Ultimately, <span class="command"><strong>b10-dhcp6</strong></span> will not
- be started directly, but rather via
- <span class="command"><strong>bind10</strong></span>. Please be aware of this planned
- change.
- </p></div></div><div class="section" title="13.2. DHCPv6 Server Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp6-config"></a>13.2. DHCPv6 Server Configuration</h2></div></div></div><p>
- The DHCPv6 server does not have lease database implemented yet
- or any support for configuration, so every time the same set
- of configuration options (including the same fixed address)
- will be assigned every time.
- </p><p>
- At this stage of development, the only way to alter server
- configuration is to tweak its source code. To do so, please
- edit src/bin/dhcp6/dhcp6_srv.cc file and modify following
- parameters and recompile:
- </p><pre class="screen">
-const std::string HARDCODED_LEASE = "2001:db8:1::1234:abcd";
-const uint32_t HARDCODED_T1 = 1500; // in seconds
-const uint32_t HARDCODED_T2 = 2600; // in seconds
-const uint32_t HARDCODED_PREFERRED_LIFETIME = 3600; // in seconds
-const uint32_t HARDCODED_VALID_LIFETIME = 7200; // in seconds
-const std::string HARDCODED_DNS_SERVER = "2001:db8:1::1";</pre><p>
-
- Lease database and configuration support is planned for 2012.
- </p></div><div class="section" title="13.3. Supported DHCPv6 Standards"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp6-std"></a>13.3. Supported DHCPv6 Standards</h2></div></div></div><p>The following standards and draft standards are currently
- supported:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">RFC3315: Supported messages are SOLICIT,
- ADVERTISE, REQUEST, and REPLY. Supported options are
- SERVER_ID, CLIENT_ID, IA_NA, and IAADDRESS.</li><li class="listitem">RFC3646: Supported option is DNS_SERVERS.</li></ul></div></div><div class="section" title="13.4. DHCPv6 Server Limitations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dhcp6-limit"></a>13.4. DHCPv6 Server Limitations</h2></div></div></div><p> These are the current limitations of the DHCPv6 server
- software. Most of them are reflections of the early stage of
- development and should be treated as <span class="quote">“<span class="quote">not implemented
- yet</span>”</span>, rather than actual limitations.</p><p>
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Relayed traffic is not supported.</li><li class="listitem"><span class="command"><strong>b10-dhcp6</strong></span> provides a single,
- fixed, hardcoded lease to any client that asks. There is no
- lease manager implemented. If two clients request addresses,
- they will both get the same fixed address.</li><li class="listitem"><span class="command"><strong>b10-dhcp6</strong></span> does not support any
- configuration mechanisms yet. The whole configuration is
- currently hardcoded. The only way to tweak configuration
- is to directly modify source code. See see <a class="xref" href="#dhcp6-config" title="13.2. DHCPv6 Server Configuration">Section 13.2, “DHCPv6 Server Configuration”</a> for details.</li><li class="listitem">Upon start, the server will open sockets on all
- interfaces that are not loopback, are up, running and are
- multicast capable and have IPv6 address. Support for
- multiple interfaces is not coded in reception routines yet,
- so if you are running this code on a machine that has many
- interfaces and <span class="command"><strong>b10-dhcp6</strong></span> happens to
- listen on wrong interface, the easiest way to work around
- this problem is to turn down other interfaces. This
- limitation will be fixed shortly.</li><li class="listitem">ORO (Option Request Option, a list of options
- requested by a client) is currently ignored and server
- assigns DNS SERVER option.</li><li class="listitem">Temporary addresses are not supported yet.</li><li class="listitem">Prefix delegation is not supported yet.</li><li class="listitem">Address renewal (RENEW), rebinding (REBIND),
- confirmation (CONFIRM), duplication report (DECLINE) and
- release (RELEASE) are not supported yet.</li><li class="listitem">DNS Update is not supported yet.</li><li class="listitem">Interface detection is currently working on Linux
- only. See <a class="xref" href="#iface-detect" title="14.1. Interface detection">Section 14.1, “Interface detection”</a> for details.</li><li class="listitem">-v (verbose) command line option is currently the
- default, and cannot be disabled.</li></ul></div><p>
- </p></div></div><div class="chapter" title="Chapter 14. libdhcp++ library"><div class="titlepage"><div><div><h2 class="title"><a name="libdhcp"></a>Chapter 14. libdhcp++ library</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#iface-detect">14.1. Interface detection</a></span></dt><dt><span class="section"><a href="#packet-handling">14.2. DHCPv4/DHCPv6 packet handling</a></span></dt></dl></div><p>libdhcp++ is a common library written in C++ that handles
- many DHCP-related tasks, like DHCPv4 and DHCPv6 packets parsing,
- manipulation and assembly, option parsing, manipulation and
- assembly, network interface detection and socket operations, like
- socket creations, data transmission and reception and socket
- closing.
- </p><p>
- While this library is currently used by
- <span class="command"><strong>b10-dhcp4</strong></span> and <span class="command"><strong>b10-dhcp6</strong></span>
- only, it is designed to be portable, universal library useful for
- any kind of DHCP-related software.
- </p><div class="section" title="14.1. Interface detection"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="iface-detect"></a>14.1. Interface detection</h2></div></div></div><p>Both DHCPv4 and DHCPv6 components share network
- interface detection routines. Interface detection is
- currently only supported on Linux systems.</p><p>For non-Linux systems, there is currently stub
- implementation provided. As DHCP servers need to know available
- addresses, there is a simple mechanism implemented to provide
- that information. User is expected to create interfaces.txt
- file. Format of this file is simple. It contains list of
- interfaces along with available address on each interface. This
- mechanism is temporary and is going to be removed as soon as
- interface detection becomes available on non-Linux
- systems. Here is an example of the interfaces.txt file:
- </p><pre class="screen">
-# For DHCPv6, please specify link-local address (starts with fe80::)
-# If in doubt, check output of 'ifconfig -a' command.
-eth0 fe80::21e:8cff:fe9b:7349
-
-# For DHCPv4, please use following format:
-#eth0 192.0.2.5</pre><p>
- </p></div><div class="section" title="14.2. DHCPv4/DHCPv6 packet handling"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="packet-handling"></a>14.2. DHCPv4/DHCPv6 packet handling</h2></div></div></div><p>TODO: Describe packet handling here, with pointers to wiki</p></div></div><div class="chapter" title="Chapter 15. Statistics"><div class="titlepage"><div><div><h2 class="title"><a name="statistics"></a>Chapter 15. Statistics</h2></div></div></div><p>
- The <span class="command"><strong>b10-stats</strong></span> process is started by
- <span class="command"><strong>bind10</strong></span>.
- It periodically collects statistics data from various modules
- and aggregates it.
-
- </p><p>
-
- This stats daemon provides commands to identify if it is
- running, show specified or all statistics data, show specified
- or all statistics data schema, and set specified statistics
- data.
-
- For example, using <span class="command"><strong>bindctl</strong></span>:
-
- </p><pre class="screen">
-> <strong class="userinput"><code>Stats show</code></strong>
-{
- "Auth": {
- "opcode.iquery": 0,
- "opcode.notify": 10,
- "opcode.query": 869617,
- ...
- "queries.tcp": 1749,
- "queries.udp": 867868
- },
- "Boss": {
- "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 at jreed.example.net",
- "report_time": "2011-01-20T17:04:06Z",
- "timestamp": 1295543046.823504
- }
-}
- </pre><p>
- </p></div><div class="chapter" title="Chapter 16. Logging"><div class="titlepage"><div><div><h2 class="title"><a name="logging"></a>Chapter 16. Logging</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#idp327280">16.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp328272">16.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#idp349480">16.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#idp362088">16.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#idp379592">16.2. Logging Message Format</a></span></dt></dl></div><div class="section" title="16.1. Logging configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp327280"></a>16.1. Logging configuration</h2></div></div></div><p>
-
- 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.
-
-
-
- </p><div class="section" title="16.1.1. Loggers"><div class="titlepage"><div><div><h3 class="title"><a name="idp328272"></a>16.1.1. Loggers</h3></div></div></div><p>
-
- 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.
-
- </p><p>
-
- In the Logging module, you can specify the configuration
- for zero or more loggers; any that are not specified will
- take appropriate default values..
-
- </p><p>
-
- The three most important elements of a logger configuration
- are the <code class="option">name</code> (the component that is
- generating the messages), the <code class="option">severity</code>
- (what to log), and the <code class="option">output_options</code>
- (where to log).
-
- </p><div class="section" title="16.1.1.1. name (string)"><div class="titlepage"><div><div><h4 class="title"><a name="idp330520"></a>16.1.1.1. name (string)</h4></div></div></div><p>
- 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 <span class="quote">“<span class="quote">Resolver</span>”</span>. This
- configuration will then be used by the loggers in the
- Resolver module, and all the libraries used by it.
- </p><p>
-
- If you want to specify logging for one specific library
- within the module, you set the name to
- <em class="replaceable"><code>module.library</code></em>. For example, the
- logger used by the nameserver address store component
- has the full name of <span class="quote">“<span class="quote">Resolver.nsas</span>”</span>. If
- there is no entry in Logging for a particular library,
- it will use the configuration given for the module.
-
-
-
- </p><p>
-
-
-
- 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
- <span class="quote">“<span class="quote">Resolver</span>”</span> and severity INFO, and one with
- the name <span class="quote">“<span class="quote">Resolver.cache</span>”</span> with severity
- DEBUG. As there are no entries for other libraries (e.g.
- the nsas), they will use the configuration for the module
- (<span class="quote">“<span class="quote">Resolver</span>”</span>), so giving the desired behavior.
-
- </p><p>
-
- One special case is that of a module name of <span class="quote">“<span class="quote">*</span>”</span>
- (asterisks), which is interpreted as <span class="emphasis"><em>any</em></span>
- 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. <span class="quote">“<span class="quote">*.config</span>”</span>
- specifies the configuration library code in whatever
- module is using it).
-
- </p><p>
-
- 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 for
- both <span class="quote">“<span class="quote">*</span>”</span> and <span class="quote">“<span class="quote">Resolver</span>”</span>, the
- resolver module — and all libraries it uses —
- will log messages according to the configuration in the
- second entry (<span class="quote">“<span class="quote">Resolver</span>”</span>). All other modules
- will use the configuration of the first entry
- (<span class="quote">“<span class="quote">*</span>”</span>). If there was also a configuration
- entry for <span class="quote">“<span class="quote">Resolver.cache</span>”</span>, the cache library
- within the resolver would use that in preference to the
- entry for <span class="quote">“<span class="quote">Resolver</span>”</span>.
-
- </p><p>
-
- One final note about the naming. When specifying the
- module name within a logger, use the name of the module
- as specified in <span class="command"><strong>bindctl</strong></span>, e.g.
- <span class="quote">“<span class="quote">Resolver</span>”</span> for the resolver module,
- <span class="quote">“<span class="quote">Xfrout</span>”</span> 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
- <span class="quote">“<span class="quote">Auth.cache</span>”</span> logger will appear in the output
- with a logger name of <span class="quote">“<span class="quote">b10-auth.cache</span>”</span>).
-
- </p></div><div class="section" title="16.1.1.2. severity (string)"><div class="titlepage"><div><div><h4 class="title"><a name="idp340304"></a>16.1.1.2. severity (string)</h4></div></div></div><p>
-
- 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):
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> FATAL </li><li class="listitem"> ERROR </li><li class="listitem"> WARN </li><li class="listitem"> INFO </li><li class="listitem"> DEBUG </li></ul></div><p>
-
- 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.
-
-
-
- </p></div><div class="section" title="16.1.1.3. output_options (list)"><div class="titlepage"><div><div><h4 class="title"><a name="idp344096"></a>16.1.1.3. output_options (list)</h4></div></div></div><p>
-
- Each logger can have zero or more
- <code class="option">output_options</code>. These specify where log
- messages are sent to. These are explained in detail below.
-
- </p><p>
-
- The other options for a logger are:
-
- </p></div><div class="section" title="16.1.1.4. debuglevel (integer)"><div class="titlepage"><div><div><h4 class="title"><a name="idp345320"></a>16.1.1.4. debuglevel (integer)</h4></div></div></div><p>
-
- 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).
- </p><p>
-
- If severity for the logger is not DEBUG, this value is ignored.
-
- </p></div><div class="section" title="16.1.1.5. additive (true or false)"><div class="titlepage"><div><div><h4 class="title"><a name="idp346760"></a>16.1.1.5. additive (true or false)</h4></div></div></div><p>
-
- If this is true, the <code class="option">output_options</code> from
- the parent will be used. For example, if there are two
- loggers configured; <span class="quote">“<span class="quote">Resolver</span>”</span> and
- <span class="quote">“<span class="quote">Resolver.cache</span>”</span>, and <code class="option">additive</code>
- is true in the second, it will write the log messages
- not only to the destinations specified for
- <span class="quote">“<span class="quote">Resolver.cache</span>”</span>, but also to the destinations
- as specified in the <code class="option">output_options</code> in
- the logger named <span class="quote">“<span class="quote">Resolver</span>”</span>.
-
-
-
- </p></div></div><div class="section" title="16.1.2. Output Options"><div class="titlepage"><div><div><h3 class="title"><a name="idp349480"></a>16.1.2. Output Options</h3></div></div></div><p>
-
- The main settings for an output option are the
- <code class="option">destination</code> and a value called
- <code class="option">output</code>, the meaning of which depends on
- the destination that is set.
-
- </p><div class="section" title="16.1.2.1. destination (string)"><div class="titlepage"><div><div><h4 class="title"><a name="idp350616"></a>16.1.2.1. destination (string)</h4></div></div></div><p>
-
- The destination is the type of output. It can be one of:
-
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> console </li><li class="listitem"> file </li><li class="listitem"> syslog </li></ul></div></div><div class="section" title="16.1.2.2. output (string)"><div class="titlepage"><div><div><h4 class="title"><a name="idp352704"></a>16.1.2.2. output (string)</h4></div></div></div><p>
-
- Depending on what is set as the output destination, this
- value is interpreted as follows:
-
- </p><div class="variablelist"><dl><dt><span class="term"><code class="option">destination</code> is <span class="quote">“<span class="quote">console</span>”</span></span></dt><dd>
- The value of output must be one of <span class="quote">“<span class="quote">stdout</span>”</span>
- (messages printed to standard output) or
- <span class="quote">“<span class="quote">stderr</span>”</span> (messages printed to standard
- error).
- </dd><dt><span class="term"><code class="option">destination</code> is <span class="quote">“<span class="quote">file</span>”</span></span></dt><dd>
- The value of output is interpreted as a file name;
- log messages will be appended to this file.
- </dd><dt><span class="term"><code class="option">destination</code> is <span class="quote">“<span class="quote">syslog</span>”</span></span></dt><dd>
- The value of output is interpreted as the
- <span class="command"><strong>syslog</strong></span> facility (e.g.
- <span class="emphasis"><em>local0</em></span>) that should be used
- for log messages.
- </dd></dl></div><p>
-
- The other options for <code class="option">output_options</code> are:
-
- </p><div class="section" title="16.1.2.2.1. flush (true of false)"><div class="titlepage"><div><div><h5 class="title"><a name="idp358664"></a>16.1.2.2.1. flush (true of false)</h5></div></div></div><p>
- 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.
- </p></div><div class="section" title="16.1.2.2.2. maxsize (integer)"><div class="titlepage"><div><div><h5 class="title"><a name="idp359528"></a>16.1.2.2.2. maxsize (integer)</h5></div></div></div><p>
- 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.)
- </p><p>
- If this is 0, no maximum file size is used.
- </p></div><div class="section" title="16.1.2.2.3. maxver (integer)"><div class="titlepage"><div><div><h5 class="title"><a name="idp360776"></a>16.1.2.2.3. maxver (integer)</h5></div></div></div><p>
- Maximum number of old log files to keep around when
- rolling the output file. Only relevant when
- <code class="option">destination</code> is <span class="quote">“<span class="quote">file</span>”</span>.
- </p></div></div></div><div class="section" title="16.1.3. Example session"><div class="titlepage"><div><div><h3 class="title"><a name="idp362088"></a>16.1.3. Example session</h3></div></div></div><p>
-
- In this example we want to set the global logging to
- write to the file <code class="filename">/var/log/my_bind10.log</code>,
- at severity WARN. We want the authoritative server to
- log at DEBUG with debuglevel 40, to a different file
- (<code class="filename">/tmp/debug_messages</code>).
-
- </p><p>
-
- Start <span class="command"><strong>bindctl</strong></span>.
-
- </p><p>
-
- </p><pre class="screen">["login success "]
-> <strong class="userinput"><code>config show Logging</code></strong>
-Logging/loggers [] list
-</pre><p>
-
- </p><p>
-
- By default, no specific loggers are configured, in which
- case the severity defaults to INFO and the output is
- written to stderr.
-
- </p><p>
-
- Let's first add a default logger:
-
- </p><p>
-
- </p><pre class="screen"><strong class="userinput"><code>> config add Logging/loggers</code></strong>
-> <strong class="userinput"><code>config show Logging</code></strong>
-Logging/loggers/ list (modified)
-</pre><p>
-
- </p><p>
-
- The loggers value line changed to indicate that it is no
- longer an empty list:
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code>config show Logging/loggers</code></strong>
-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)
-</pre><p>
-
- </p><p>
-
- The name is mandatory, so we must set it. We will also
- change the severity as well. Let's start with the global
- logger.
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code>config set Logging/loggers[0]/name *</code></strong>
-> <strong class="userinput"><code>config set Logging/loggers[0]/severity WARN</code></strong>
-> <strong class="userinput"><code>config show Logging/loggers</code></strong>
-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)
-</pre><p>
-
- </p><p>
-
- Of course, we need to specify where we want the log
- messages to go, so we add an entry for an output option.
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code> config add Logging/loggers[0]/output_options</code></strong>
-> <strong class="userinput"><code> config show Logging/loggers[0]/output_options</code></strong>
-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)
-</pre><p>
-
-
- </p><p>
-
- These aren't the values we are looking for.
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code> config set Logging/loggers[0]/output_options[0]/destination file</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[0]/output_options[0]/output /var/log/bind10.log</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[0]/output_options[0]/maxsize 30000</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[0]/output_options[0]/maxver 8</code></strong>
-</pre><p>
-
- </p><p>
-
- Which would make the entire configuration for this logger
- look like:
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code> config show all Logging/loggers</code></strong>
-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 30000 integer (modified)
-Logging/loggers[0]/output_options[0]/maxver 8 integer (modified)
-</pre><p>
-
- </p><p>
-
- That looks OK, so let's commit it before we add the
- configuration for the authoritative server's logger.
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code> config commit</code></strong></pre><p>
-
- </p><p>
-
- Now that we have set it, and checked each value along
- the way, adding a second entry is quite similar.
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code> config add Logging/loggers</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[1]/name Auth</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[1]/severity DEBUG</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[1]/debuglevel 40</code></strong>
-> <strong class="userinput"><code> config add Logging/loggers[1]/output_options</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[1]/output_options[0]/destination file</code></strong>
-> <strong class="userinput"><code> config set Logging/loggers[1]/output_options[0]/output /tmp/auth_debug.log</code></strong>
-> <strong class="userinput"><code> config commit</code></strong>
-</pre><p>
-
- </p><p>
-
- 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.
-
- </p><p>
-
- </p><pre class="screen">> <strong class="userinput"><code> config remove Logging/loggers[1]</code></strong>
-> <strong class="userinput"><code> config commit</code></strong>
-</pre><p>
-
- </p><p>
-
- And every module will now be using the values from the
- logger named <span class="quote">“<span class="quote">*</span>”</span>.
-
- </p></div></div><div class="section" title="16.2. Logging Message Format"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp379592"></a>16.2. Logging Message Format</h2></div></div></div><p>
- 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.
- </p><p>
- Consider the message below logged to a file:
- </p><pre class="screen">2011-06-15 13:48:22.034 ERROR [b10-resolver.asiolink]
- ASIODNS_OPENSOCK error 111 opening TCP socket to 127.0.0.1(53)</pre><p>
- </p><p>
- 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.)
- </p><p>
- The log message comprises a number of components:
-
- </p><div class="variablelist"><dl><dt><span class="term">2011-06-15 13:48:22.034</span></dt><dd><p>
- The date and time at which the message was generated.
- </p></dd><dt><span class="term">ERROR</span></dt><dd><p>
- The severity of the message.
- </p></dd><dt><span class="term">[b10-resolver.asiolink]</span></dt><dd><p>
- The source of the message. This comprises two components:
- the BIND 10 process generating the message (in this
- case, <span class="command"><strong>b10-resolver</strong></span>) and the module
- within the program from which the message originated
- (which in the example is the asynchronous I/O link
- module, asiolink).
- </p></dd><dt><span class="term">ASIODNS_OPENSOCK</span></dt><dd><p>
- The message identification. Every message in BIND 10
- has a unique identification, which can be used as an
- index into the <a class="ulink" href="bind10-messages.html" target="_top"><em class="citetitle">BIND 10 Messages
- Manual</em></a> (<a class="ulink" href="http://bind10.isc.org/docs/bind10-messages.html" target="_top">http://bind10.isc.org/docs/bind10-messages.html</a>) from which more information can be obtained.
- </p></dd><dt><span class="term">error 111 opening TCP socket to 127.0.0.1(53)</span></dt><dd><p>
- 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.
- </p></dd></dl></div><p>
- </p></div></div></div></body></html>
diff --git a/doc/guide/bind10-guide.txt b/doc/guide/bind10-guide.txt
deleted file mode 100644
index 7ec35e6..0000000
--- a/doc/guide/bind10-guide.txt
+++ /dev/null
@@ -1,1726 +0,0 @@
- BIND 10 Guide
-
-Administrator Reference for BIND 10
-
- This is the reference guide for BIND 10 version 20120127.
-
- Copyright (c) 2010-2012 Internet Systems Consortium, Inc.
-
- Abstract
-
- BIND 10 is a framework that features Domain Name System (DNS) suite and
- Dynamic Host Configuration Protocol (DHCP) servers managed by Internet
- Systems Consortium (ISC). It includes DNS libraries, modular components
- for controlling authoritative and recursive DNS servers, and experimental
- DHCPv4 and DHCPv6 servers.
-
- This is the reference guide for BIND 10 version 20120127. 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
-
- 1.3. Starting and Stopping the Server
-
- 1.4. Managing BIND 10
-
- 2. Installation
-
- 2.1. Building Requirements
-
- 2.2. Quick start
-
- 2.3. Installation from source
-
- 2.3.1. Download Tar File
-
- 2.3.2. Retrieve from Git
-
- 2.3.3. Configure before the build
-
- 2.3.4. Build
-
- 2.3.5. Install
-
- 2.3.6. Install Hierarchy
-
- 3. Starting BIND10 with bind10
-
- 3.1. Starting BIND 10
-
- 3.2. Configuration of started processes
-
- 4. Command channel
-
- 5. Configuration manager
-
- 6. Remote control daemon
-
- 6.1. Configuration specification for b10-cmdctl
-
- 7. Control and configure user interface
-
- 8. Authoritative Server
-
- 8.1. Server Configurations
-
- 8.2. Data Source Backends
-
- 8.3. Loading Master Zones Files
-
- 9. Incoming Zone Transfers
-
- 9.1. Configuration for Incoming Zone Transfers
-
- 9.2. Enabling IXFR
-
- 9.3. Secondary Manager
-
- 9.4. Trigger an Incoming Zone Transfer Manually
-
- 10. Outbound Zone Transfers
-
- 11. Recursive Name Server
-
- 11.1. Access Control
-
- 11.2. Forwarding
-
- 12. DHCPv4 Server
-
- 12.1. DHCPv4 Server Usage
-
- 12.2. DHCPv4 Server Configuration
-
- 12.3. Supported standards
-
- 12.4. DHCPv4 Server Limitations
-
- 13. DHCPv6 Server
-
- 13.1. DHCPv6 Server Usage
-
- 13.2. DHCPv6 Server Configuration
-
- 13.3. Supported DHCPv6 Standards
-
- 13.4. DHCPv6 Server Limitations
-
- 14. libdhcp++ library
-
- 14.1. Interface detection
-
- 14.2. DHCPv4/DHCPv6 packet handling
-
- 15. Statistics
-
- 16. Logging
-
- 16.1. Logging configuration
-
- 16.1.1. Loggers
-
- 16.1.2. Output Options
-
- 16.1.3. Example session
-
- 16.2. Logging Message Format
-
- List of Tables
-
- 3.1.
-
-Preface
-
- Table of Contents
-
- 1. Acknowledgements
-
-1. Acknowledgements
-
- ISC would like to acknowledge generous support for BIND 10 development of
- DHCPv4 and DHCPv6 components provided by Comcast.
-
-Chapter 1. Introduction
-
- Table of Contents
-
- 1.1. Supported Platforms
-
- 1.2. Required Software
-
- 1.3. Starting and Stopping the Server
-
- 1.4. Managing BIND 10
-
- BIND is the popular implementation of a DNS server, developer interfaces,
- and DNS tools. BIND 10 is a rewrite of BIND 9. BIND 10 is written in C++
- and Python and provides a modular environment for serving and maintaining
- DNS. BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server
- and a caching recursive name server which also provides forwarding.
-
- This guide covers the experimental prototype of BIND 10 version 20120127.
-
-1.1. Supported Platforms
-
- BIND 10 builds have been tested on Debian GNU/Linux 5 and unstable, Ubuntu
- 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, CentOS Linux 5.3, and MacOS
- 10.6. 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
-
- BIND 10 requires at least Python 3.1 (http://www.python.org/). It has also
- been tested 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-xfrin, b10-xfrout, and b10-zonemgr components require the
- libpython3 library and the Python _sqlite3.so module (which is included
- with Python). The Python module needs to be built for the corresponding
- Python 3.
-
- Note
-
- Some operating systems do not provide these dependencies in their default
- installation nor standard packages collections. You may need to install
- them separately.
-
-1.3. Starting and Stopping the Server
-
- BIND 10 is modular. Part of this modularity is accomplished using multiple
- cooperating processes which, together, provide the server functionality.
- This is a change from the previous generation of BIND software, which used
- a single process.
-
- At first, running many different processes may seem confusing. However,
- these processes are started, stopped, and maintained by a single command,
- bind10. This command starts a master process which will start other
- processes as needed. The processes started by the bind10 command have
- names starting with "b10-", including:
-
- o b10-msgq -- Message bus daemon. This process coordinates communication
- between all of the other BIND 10 processes.
- o b10-auth -- Authoritative DNS server. This process serves DNS
- requests.
- o b10-cfgmgr -- Configuration manager. This process maintains all of the
- configuration for BIND 10.
- o b10-cmdctl -- Command and control service. This process allows
- external control of the BIND 10 system.
- o b10-resolver -- Recursive name server. This process handles incoming
- queries.
- o b10-stats -- Statistics collection daemon. This process collects and
- reports statistics data.
- o 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.
- o b10-xfrout -- Outgoing zone transfer service. This process is used to
- handle transfer requests to send a local zone to a remote secondary
- server, when acting as a master server.
- o b10-zonemgr -- Secondary manager. This process keeps track of timers
- and other necessary information for BIND 10 to act as a slave server.
-
- These are ran automatically by bind10 and do not need to be run manually.
-
-1.4. Managing BIND 10
-
- Once BIND 10 is running, a few commands are used to interact directly with
- the system:
-
- o bindctl -- interactive administration interface. This is a
- command-line tool which allows an administrator to control BIND 10.
- o b10-loadzone -- zone file loader. This tool will load standard
- masterfile-format zone files into BIND 10.
- o 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. Installation
-
- Table of Contents
-
- 2.1. Building Requirements
-
- 2.2. Quick start
-
- 2.3. Installation from source
-
- 2.3.1. Download Tar File
-
- 2.3.2. Retrieve from Git
-
- 2.3.3. Configure before the build
-
- 2.3.4. Build
-
- 2.3.5. Install
-
- 2.3.6. Install Hierarchy
-
-2.1. Building Requirements
-
- In addition to the run-time requirements, building BIND 10 from source
- code requires various development include headers.
-
- Note
-
- 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 wiki at http://bind10.isc.org/wiki/SystemSpecificNotes for
- system-specific installation tips.
-
-2.2. Quick start
-
- Note
-
- This quickly covers the standard steps for installing and deploying BIND
- 10 as an authoritative name server using its defaults. For
- troubleshooting, full customizations and further details, see the
- respective chapters in the BIND 10 guide.
-
- To quickly get started with BIND 10, follow these steps.
-
- 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 (to default /usr/local):
-
- $ make install
-
- 7. Start the server:
-
- $ /usr/local/sbin/bind10
-
- 8. Test it; for example:
-
- $ dig @127.0.0.1 -c CH -t TXT authors.bind
-
- 9. Load desired zone file(s), for example:
-
- $ b10-loadzone your.zone.example.org
-
- 10. Test the new zone.
-
-2.3. Installation from source
-
- BIND 10 is open source software written in C++ and Python. It is freely
- available in source code form from ISC via the Git code revision control
- system or as a downloadable tar file. It may also be available in
- pre-compiled ready-to-use packages from operating system vendors.
-
- 2.3.1. Download Tar File
-
- Downloading a release tar file is the recommended method to obtain the
- source code.
-
- The BIND 10 releases are available as tar file downloads from
- ftp://ftp.isc.org/isc/bind10/. Periodic development snapshots may also be
- available.
-
- 2.3.2. Retrieve from Git
-
- Downloading this "bleeding edge" code is recommended only for developers
- or advanced users. Using development code in a production environment is
- not recommended.
-
- 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, including temporary experiments and
- un-reviewed code, is available via the BIND 10 code revision control
- system. This is powered by Git and all the BIND 10 development is public.
- The leading development is done in the "master".
-
- The code can be checked out from git://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 the
- related configure files. They can be created by running autoreconf with
- the --install switch. This will run autoconf, aclocal, libtoolize,
- autoheader, automake, and related commands.
-
- 2.3.3. Configure before the build
-
- BIND 10 uses the GNU Build System to discover build environment details.
- To generate the makefiles using the defaults, simply run:
-
- $ ./configure
-
- Run ./configure with the --help switch to view the different options. The
- 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.
-
- 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.
-
- 2.3.4. Build
-
- After the configure step is complete, to build the executables from the
- C++ code and prepare the Python scripts, run:
-
- $ make
-
- 2.3.5. Install
-
- To install the BIND 10 executables, support files, and documentation, run:
-
- $ make install
-
- Note
-
- The install step may require superuser privileges.
-
- 2.3.6. Install Hierarchy
-
- The following is the layout of the complete BIND 10 installation:
-
- o bin/ -- general tools and diagnostic clients.
- o etc/bind10-devel/ -- configuration files.
- o lib/ -- libraries and python modules.
- o libexec/bind10-devel/ -- executables that a user wouldn't normally run
- directly and are not run independently. These are the BIND 10 modules
- which are daemons started by the bind10 tool.
- o sbin/ -- commands used by the system administrator.
- o share/bind10-devel/ -- configuration specifications.
- o share/man/ -- manual pages (online documentation).
- o var/bind10-devel/ -- data source and configuration databases.
-
-Chapter 3. Starting BIND10 with bind10
-
- Table of Contents
-
- 3.1. Starting BIND 10
-
- 3.2. Configuration of started processes
-
- BIND 10 provides the bind10 command which starts up the required
- processes. bind10 will also restart some processes that exit unexpectedly.
- This is the only command needed to start the BIND 10 system.
-
- After starting the b10-msgq communications channel, bind10 connects to it,
- runs the configuration manager, and reads its own configuration. Then it
- starts the other modules.
-
- The b10-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 will allocate sockets for the rest of the system.
-
- In its default configuration, the bind10 master process will also start up
- b10-cmdctl for admins to communicate with the system, b10-auth for
- authoritative DNS service, b10-stats for statistics collection, b10-xfrin
- for inbound DNS zone transfers, b10-xfrout for outbound DNS zone
- transfers, and b10-zonemgr for secondary service.
-
-3.1. Starting BIND 10
-
- To start the BIND 10 service, simply run bind10. Run it with the --verbose
- switch to get additional debugging or diagnostic output.
-
- 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.
-
-3.2. Configuration of started processes
-
- The processes to be started can be configured, with the exception of the
- b10-sockcreator, b10-msgq and b10-cfgmgr.
-
- The configuration is in the Boss/components section. Each element
- represents one component, which is an abstraction of a process (currently
- there's also one component which doesn't represent a process). If you
- didn't want to transfer out at all (your server is a slave only), you
- would just remove the corresponding component from the set, like this and
- the process would be stopped immediately (and not started on the next
- startup):
-
- > config remove Boss/components b10-xfrout
- > config commit
-
- To add a process to the set, let's say the resolver (which not started by
- default), you would do this:
-
- > config add Boss/components b10-resolver
- > config set Boss/components/b10-resolver/special resolver
- > config set Boss/components/b10-resolver/kind needed
- > config set Boss/components/b10-resolver/priority 10
- > config commit
-
- Now, what it means. We add an entry called b10-resolver. It is both a name
- used to reference this component in the configuration and the name of the
- process to start. Then we set some parameters on how to start it.
-
- The special one is for components that need some kind of special care
- during startup or shutdown. Unless specified, the component is started in
- usual way. This is the list of components that need to be started in a
- special way, with the value of special used for them:
-
- Table 3.1.
-
- +------------------------------------------------------------------------+
- | Component | Special | Description |
- |--------------+----------+----------------------------------------------|
- | b10-auth | auth | Authoritative server |
- |--------------+----------+----------------------------------------------|
- | b10-resolver | resolver | The resolver |
- |--------------+----------+----------------------------------------------|
- | b10-cmdctl | cmdctl | The command control (remote control |
- | | | interface) |
- +------------------------------------------------------------------------+
-
- The kind specifies how a failure of the component should be handled. If it
- is set to "dispensable" (the default unless you set something else), it
- will get started again if it fails. If it is set to "needed" and it fails
- at startup, the whole bind10 shuts down and exits with error exit code.
- But if it fails some time later, it is just started again. If you set it
- to "core", you indicate that the system is not usable without the
- component and if such component fails, the system shuts down no matter
- when the failure happened. This is the behaviour of the core components
- (the ones you can't turn off), but you can declare any other components as
- core as well if you wish (but you can turn these off, they just can't
- fail).
-
- The priority defines order in which the components should start. The ones
- with higher number are started sooner than the ones with lower ones. If
- you don't set it, 0 (zero) is used as the priority. Usually, leaving it at
- the default is enough.
-
- 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 capital (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.
-
- Note
-
- This system allows you to start the same component multiple times (by
- including it in the configuration with different names, but the same
- process setting). However, the rest of the system doesn't expect such
- situation, so it would probably not do what you want. Such support is yet
- to be implemented.
-
- Note
-
- The configuration is quite powerful, but that includes a lot of space for
- mistakes. You could turn off the b10-cmdctl, but then you couldn't 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 need b10-stats, b10-xfrout
- needs the b10-auth to be running, etc.
-
- In short, you should think twice before disabling something here.
-
-Chapter 4. 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 port 9912 for the b10-msgq service. It listens on
- 127.0.0.1.
-
-Chapter 5. 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 6, Remote control
- daemon.
-
- Note
-
- The development prototype release only provides the bindctl as a user
- interface to b10-cmdctl. Upcoming releases will provide another
- interactive command-line interface and a web-based interface.
-
- The b10-cfgmgr daemon can send all specifications and all current settings
- to the bindctl client (via b10-cmdctl).
-
- b10-cfgmgr relays configurations received from b10-cmdctl to the
- appropriate modules.
-
- The stored configuration file is at
- /usr/local/var/bind10-devel/b10-config.db. (The full path is what was
- defined at build configure time for --localstatedir. The default is
- /usr/local/var/.) The format is loosely based on JSON and is directly
- parseable python, but this may change in a future version. This
- configuration data file is not manually edited by the administrator.
-
- The configuration manager does not have any command line arguments.
- Normally it is not started manually, but is automatically started using
- the bind10 master process (as covered in Chapter 3, Starting BIND10 with
- bind10).
-
-Chapter 6. Remote control daemon
-
- Table of Contents
-
- 6.1. Configuration specification for b10-cmdctl
-
- b10-cmdctl is the gateway between administrators and the BIND 10 system.
- It is a HTTPS server that uses standard HTTP Digest Authentication for
- username and password validation. It provides a REST-ful interface for
- accessing and controlling BIND 10.
-
- When b10-cmdctl starts, it firsts asks b10-cfgmgr about what modules are
- running and what their configuration is (over the b10-msgq channel). Then
- it will start listening on HTTPS for clients -- the user interface -- such
- as bindctl.
-
- b10-cmdctl directly sends commands (received from the user interface) to
- the specified component. Configuration changes are actually commands to
- b10-cfgmgr so are sent there.
-
- The HTTPS server requires a private key, such as a RSA PRIVATE KEY. The
- default location is at /usr/local/etc/bind10-devel/cmdctl-keyfile.pem. (A
- sample key is at /usr/local/share/bind10-devel/cmdctl-keyfile.pem.) It
- also uses a certificate located at
- /usr/local/etc/bind10-devel/cmdctl-certfile.pem. (A sample certificate is
- at /usr/local/share/bind10-devel/cmdctl-certfile.pem.) This may be a
- self-signed certificate or purchased from a certification authority.
-
- 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-devel/cmdctl-accounts.csv. This comma-delimited file
- lists the accounts with a user name, hashed password, and salt. (A sample
- file is at /usr/local/share/bind10-devel/cmdctl-accounts.csv. It contains
- the user named "root" with the password "bind10".)
-
- The administrator may create a user account with the b10-cmdctl-usermgr
- tool.
-
- By default the HTTPS server listens on the localhost port 8080. The port
- can be set by using the --port command line option. The address to listen
- on can be set using the --address command line argument. Each HTTPS
- connection is stateless and timesout in 1200 seconds by default. This can
- be redefined by using the --idle-timeout command line argument.
-
-6.1. Configuration specification for b10-cmdctl
-
- The configuration items for b10-cmdctl are: key_file cert_file
- accounts_file
-
- The control commands are: print_settings shutdown
-
-Chapter 7. Control and configure user interface
-
- Note
-
- For this development prototype release, bindctl is the only user
- interface. It is expected that upcoming releases will provide another
- interactive command-line interface and a web-based interface for
- controlling and configuring BIND 10.
-
- The bindctl tool provides an interactive prompt for configuring,
- controlling, and querying the BIND 10 components. It communicates directly
- with a REST-ful interface over HTTPS provided by b10-cmdctl. It doesn't
- communicate to any other components directly.
-
- Configuration changes are actually commands to b10-cfgmgr. So when bindctl
- sends a configuration, it is sent to b10-cmdctl (over a HTTPS connection);
- then b10-cmdctl sends the command (over a b10-msgq command channel) to
- b10-cfgmgr which then stores the details and relays (over a b10-msgq
- command channel) the configuration on to the specified module.
-
-Chapter 8. Authoritative Server
-
- Table of Contents
-
- 8.1. Server Configurations
-
- 8.2. Data Source Backends
-
- 8.3. Loading Master Zones Files
-
- The b10-auth is the authoritative DNS server. It supports EDNS0 and
- DNSSEC. It supports IPv6. Normally it is started by the bind10 master
- process.
-
-8.1. Server Configurations
-
- b10-auth is configured via the b10-cfgmgr configuration manager. The
- module name is "Auth". The configuration data item is:
-
- database_file
- This is an optional string to define the path to find the SQLite3
- database file. Note: Later the DNS server will use various data
- source backends. This may be a temporary setting until then.
-
- The configuration command is:
-
- shutdown
- Stop the authoritative DNS server.
-
-8.2. Data Source Backends
-
- Note
-
- For the development prototype release, b10-auth supports a SQLite3 data
- source backend and in-memory data source backend. Upcoming versions will
- be able to use multiple different data sources, such as MySQL and Berkeley
- DB.
-
- By default, the SQLite3 backend uses the data file located at
- /usr/local/var/bind10-devel/zone.sqlite3. (The full path is what was
- defined at build configure time for --localstatedir. The default is
- /usr/local/var/.) This data file location may be changed by defining the
- "database_file" configuration.
-
-8.3. Loading Master Zones Files
-
- RFC 1035 style DNS master zone files may imported into a BIND 10 data
- source by using the b10-loadzone utility.
-
- 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.
-
- The -o argument may be used to define the default origin for loaded zone
- file records.
-
- Note
-
- In the development prototype release, only the SQLite3 back end is used.
- By default, it stores the zone data in
- /usr/local/var/bind10-devel/zone.sqlite3 unless the -d switch is used to
- set the database filename. Multiple zones are stored in a single SQLite3
- zone database.
-
- If you reload a zone already existing in the database, all records from
- that prior zone disappear and a whole new set appears.
-
-Chapter 9. Incoming Zone Transfers
-
- Table of Contents
-
- 9.1. Configuration for Incoming Zone Transfers
-
- 9.2. Enabling IXFR
-
- 9.3. Secondary Manager
-
- 9.4. Trigger an Incoming Zone Transfer Manually
-
- Incoming zones are transferred using the b10-xfrin process which is
- started by bind10. When received, the zone is stored in the corresponding
- BIND 10 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. Due to some
- implementation limitations of the current development release, however, it
- only tries AXFR by default, and care should be taken to enable IXFR.
-
- Note
-
- In the current development release of BIND 10, incoming zone transfers are
- only available for SQLite3-based data sources, that is, they don't work
- for an in-memory data source.
-
-9.1. Configuration for Incoming Zone Transfers
-
- In practice, you need to specify a list of secondary zones to enable
- incoming zone transfers for these zones (you can still trigger a zone
- transfer manually, without a prior configuration (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).
-
-9.2. Enabling IXFR
-
- As noted above, b10-xfrin uses AXFR for zone transfers by default. To
- enable IXFR for zone transfers for a particular zone, set the use_ixfr
- configuration parameter to true. In the above example of configuration
- sequence, you'll need to add the following before performing commit:
-
- > config set Xfrin/zones[0]/use_ixfr true
-
- Note
-
- One reason why IXFR is disabled by default in the current release is
- because it does not support automatic fallback from IXFR to AXFR when it
- encounters a primary server that doesn't support outbound IXFR (and, not
- many existing implementations support it). Another, related reason is that
- it does not use AXFR even if it has no knowledge about the zone (like at
- the very first time the secondary server is set up). IXFR requires the
- "current version" of the zone, so obviously it doesn't work in this
- situation and AXFR is the only workable choice. The current release of
- b10-xfrin does not make this selection automatically. These features will
- be implemented in a near future version, at which point we will enable
- IXFR by default.
-
-9.3. Secondary Manager
-
- The b10-zonemgr process is started by bind10. It keeps track of SOA
- refresh, retry, and expire timers and other details for BIND 10 to perform
- as a slave. When the b10-auth authoritative DNS server receives a NOTIFY
- message, b10-zonemgr may tell b10-xfrin to do a refresh to start an
- inbound zone transfer. The secondary manager resets its counters when a
- new zone is transferred in.
-
- 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 set Zonemgr/secondary_zones[0]/class "IN"
- > config commit
-
- If the zone does not exist in the data source already (i.e. no SOA record
- for it), b10-zonemgr will automatically tell b10-xfrin to transfer the
- zone in.
-
-9.4. Trigger an Incoming Zone Transfer Manually
-
- To manually trigger a zone transfer to retrieve a remote zone, you may use
- the bindctl utility. For example, at the bindctl prompt run:
-
- > Xfrin retransfer zone_name="foo.example.org" master=192.0.2.99
-
-Chapter 10. Outbound Zone Transfers
-
- The b10-xfrout process is started by bind10. When the b10-auth
- authoritative DNS server receives an AXFR or IXFR request, b10-auth
- internally forwards the request to b10-xfrout, which handles the rest of
- request processing. 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)
-
- You can change this to, for example, rejecting all transfer requests by
- default while allowing requests for the transfer of zone "example.com"
- from 192.0.2.1 and 2001:db8::1 as follows:
-
- > config set Xfrout/transfer_acl[0] {"action": "REJECT"}
- > config add Xfrout/zone_config
- > config set Xfrout/zone_config[0]/origin "example.com"
- > config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1"},
- {"action": "ACCEPT", "from": "2001:db8::1"}]
- > config commit
-
- Note
-
- In the above example the lines for transfer_acl were divided for
- readability. In the actual input it must be in a single line.
-
- If you want to require TSIG in access control, a separate TSIG "key ring"
- must be configured specifically for b10-xfrout as well as a system wide
- key ring, both containing a consistent set of keys. For example, to change
- the previous example to allowing requests from 192.0.2.1 signed by a TSIG
- with a key name of "key.example", you'll need to do this:
-
- > config set tsig_keys/keys ["key.example:<base64-key>"]
- > config set Xfrout/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
-
- The first line of configuration defines a system wide key ring. This is
- necessary because the b10-auth server also checks TSIGs and it uses the
- system wide configuration.
-
- Note
-
- In a future version, b10-xfrout will also use the system wide TSIG
- configuration. The way to specify zone specific configuration (ACLs, etc)
- is likely to be changed, too.
-
-Chapter 11. Recursive Name Server
-
- Table of Contents
-
- 11.1. Access Control
-
- 11.2. Forwarding
-
- The b10-resolver process is started by bind10.
-
- The main bind10 process can be configured to select to run either the
- authoritative or resolver or both. By default, it starts the authoritative
- service. You may change this using bindctl, for example:
-
- > config remove Boss/components b10-xfrout
- > config remove Boss/components b10-xfrin
- > config remove Boss/components b10-auth
- > config add Boss/components b10-resolver
- > config set Boss/components/b10-resolver/special resolver
- > config set Boss/components/b10-resolver/kind needed
- > config set Boss/components/b10-resolver/priority 10
- > config commit
-
- The master bind10 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.)
-
-11.1. Access Control
-
- By default, the b10-resolver daemon only accepts DNS queries from the
- localhost (127.0.0.1 and ::1). The Resolver/query_acl configuration may be
- used to reject, drop, or allow specific IPs or networks. This
- configuration list is first match.
-
- The configuration's action item may be set to "ACCEPT" to allow the
- incoming query, "REJECT" to respond with a DNS REFUSED return code, or
- "DROP" to ignore the query without any response (such as a blackhole). For
- more information, see the respective debugging messages:
- RESOLVER_QUERY_ACCEPTED, RESOLVER_QUERY_REJECTED, and
- RESOLVER_QUERY_DROPPED.
-
- The required configuration's from item is set to an IPv4 or IPv6 address,
- addresses with an network mask, or to the special lowercase keywords
- "any6" (for any IPv6 address) or "any4" (for any IPv4 address).
-
- For example to allow the 192.168.1.0/24 network to use your recursive name
- server, at the bindctl prompt run:
-
- > config add Resolver/query_acl
- > config set Resolver/query_acl[2]/action "ACCEPT"
- > config set Resolver/query_acl[2]/from "192.168.1.0/24"
- > config commit
-
- (Replace the "2" as needed; run "config show Resolver/query_acl" if
- needed.)
-
- Note
-
- This prototype access control configuration syntax may be changed.
-
-11.2. Forwarding
-
- 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 12. DHCPv4 Server
-
- Table of Contents
-
- 12.1. DHCPv4 Server Usage
-
- 12.2. DHCPv4 Server Configuration
-
- 12.3. Supported standards
-
- 12.4. DHCPv4 Server Limitations
-
- Dynamic Host Configuration Protocol for IPv4 (DHCP or DHCPv4) and Dynamic
- Host Configuration Protocol for IPv6 (DHCPv6) are protocols that allow one
- node (server) to provision configuration parameters to many hosts and
- devices (clients). To 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. BIND10 offers server
- implementations for both DHCPv4 and DHCPv6. This chapter is about DHCP for
- IPv4. For a description of the DHCPv6 server, see Chapter 13, DHCPv6
- Server.
-
- The DHCPv4 server component is currently under intense development. You
- may want to check out BIND10 DHCP (Kea) wiki and recent posts on BIND10
- developers mailing list.
-
- The DHCPv4 and DHCPv6 components in BIND10 architecture are internally
- code named "Kea".
-
- Note
-
- As of December 2011, both DHCPv4 and DHCPv6 components are skeleton
- servers. That means that while they are capable of performing DHCP
- configuration, they are not fully functional yet. In particular, neither
- has functional lease databases. This means that they will assign the same,
- fixed, hardcoded addresses to any client that will ask. See Section 12.4,
- "DHCPv4 Server Limitations" and Section 13.4, "DHCPv6 Server Limitations"
- for detailed description.
-
-12.1. DHCPv4 Server Usage
-
- BIND10 provides the DHCPv4 server component since December 2011. It is a
- skeleton server and can be described as an early prototype that is not
- fully functional yet. It is mature enough to conduct first tests in lab
- environment, but it has significant limitations. See Section 12.4, "DHCPv4
- Server Limitations" for details.
-
- The DHCPv4 server is implemented as b10-dhcp4 daemon. As it is not
- configurable yet, it is fully autonomous, that is it does not interact
- with b10-cfgmgr. To start DHCPv4 server, simply input:
-
- #cd src/bin/dhcp4
- #./b10-dhcp4
-
- Depending on your installation, b10-dhcp4 binary may reside in
- src/bin/dhcp4 in your source code directory, in /usr/local/bin/b10-dhcp4
- or other directory you specified during compilation. At start, the server
- will detect available network interfaces and will attempt to open UDP
- sockets on all interfaces that are up, running, are not loopback, and have
- IPv4 address 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.
-
- Note
-
- Integration with bind10 is planned. Ultimately, b10-dhcp4 will not be
- started directly, but rather via bind10. Please be aware of this planned
- change.
-
-12.2. DHCPv4 Server Configuration
-
- The DHCPv4 server does not have a lease database implemented yet nor any
- support for configuration, so every time the same set of configuration
- options (including the same fixed address) will be assigned every time.
-
- At this stage of development, the only way to alter the server
- configuration is to tweak its source code. To do so, please edit
- src/bin/dhcp4/dhcp4_srv.cc file and modify following parameters and
- recompile:
-
- const std::string HARDCODED_LEASE = "192.0.2.222"; // assigned lease
- const std::string HARDCODED_NETMASK = "255.255.255.0";
- const uint32_t HARDCODED_LEASE_TIME = 60; // in seconds
- const std::string HARDCODED_GATEWAY = "192.0.2.1";
- const std::string HARDCODED_DNS_SERVER = "192.0.2.2";
- const std::string HARDCODED_DOMAIN_NAME = "isc.example.com";
- const std::string HARDCODED_SERVER_ID = "192.0.2.1";
-
- Lease database and configuration support is planned for 2012.
-
-12.3. Supported standards
-
- The following standards and draft standards are currently supported:
-
- o RFC2131: Supported messages are DISCOVER, OFFER, REQUEST, and ACK.
- o RFC2132: 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).
-
-12.4. DHCPv4 Server Limitations
-
- These are the current limitations of the DHCPv4 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.
-
- o During initial IPv4 node configuration, the server is expected to send
- packets to a node that does not have IPv4 address assigned yet. The
- server requires certain tricks (or hacks) to transmit such packets.
- This is not implemented yet, therefore DHCPv4 server supports relayed
- traffic only (that is, normal point to point communication).
- o b10-dhcp4 provides a single, fixed, hardcoded lease to any client that
- asks. There is no lease manager implemented. If two clients request
- addresses, they will both get the same fixed address.
- o b10-dhcp4 does not support any configuration mechanisms yet. The whole
- configuration is currently hardcoded. The only way to tweak
- configuration is to directly modify source code. See see Section 12.2,
- "DHCPv4 Server Configuration" for details.
- o Upon start, the server will open sockets on all interfaces that are
- not loopback, are up and running and have IPv4 address. Support for
- multiple interfaces is not coded in reception routines yet, so if you
- are running this code on a machine that has many interfaces and
- b10-dhcp4 happens to listen on wrong interface, the easiest way to
- work around this problem is to turn down other interfaces. This
- limitation will be fixed shortly.
- o PRL (Parameter Request List, a list of options requested by a client)
- is currently ignored and server assigns DNS SERVER and DOMAIN NAME
- options.
- o b10-dhcp4 does not support BOOTP. That is a design choice. This
- limitation is permanent. If you have legacy nodes that can't use DHCP
- and require BOOTP support, please use latest version of ISC DHCP
- http://www.isc.org/software/dhcp.
- o Interface detection is currently working on Linux only. See
- Section 14.1, "Interface detection" for details.
- o b10-dhcp4 does not verify that assigned address is unused. According
- to RFC2131, the allocating server should verify that address is no
- used by sending ICMP echo request.
- o Address renewal (RENEW), rebinding (REBIND), confirmation (CONFIRM),
- duplication report (DECLINE) and release (RELEASE) are not supported
- yet.
- o DNS Update is not supported yet.
- o -v (verbose) command line option is currently the default, and cannot
- be disabled.
-
-Chapter 13. DHCPv6 Server
-
- Table of Contents
-
- 13.1. DHCPv6 Server Usage
-
- 13.2. DHCPv6 Server Configuration
-
- 13.3. Supported DHCPv6 Standards
-
- 13.4. DHCPv6 Server Limitations
-
- Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is specified in
- RFC3315. BIND10 provides DHCPv6 server implementation that is described in
- this chapter. For a description of the DHCPv4 server implementation, see
- Chapter 12, DHCPv4 Server.
-
- The DHCPv6 server component is currently under intense development. You
- may want to check out BIND10 DHCP (Kea) wiki and recent posts on BIND10
- developers mailing list.
-
- The DHCPv4 and DHCPv6 components in BIND10 architecture are internally
- code named "Kea".
-
- Note
-
- As of December 2011, both DHCPv4 and DHCPv6 components are skeleton
- servers. That means that while they are capable of performing DHCP
- configuration, they are not fully functional yet. In particular, neither
- has functional lease databases. This means that they will assign the same,
- fixed, hardcoded addresses to any client that will ask. See Section 12.4,
- "DHCPv4 Server Limitations" and Section 13.4, "DHCPv6 Server Limitations"
- for detailed description.
-
-13.1. DHCPv6 Server Usage
-
- BIND10 provides the DHCPv6 server component since September 2011. It is a
- skeleton server and can be described as an early prototype that is not
- fully functional yet. It is mature enough to conduct first tests in lab
- environment, but it has significant limitations. See Section 13.4, "DHCPv6
- Server Limitations" for details.
-
- The DHCPv6 server is implemented as b10-dhcp6 daemon. As it is not
- configurable yet, it is fully autonomous, that is it does not interact
- with b10-cfgmgr. To start DHCPv6 server, simply input:
-
- #cd src/bin/dhcp6
- #./b10-dhcp6
-
- Depending on your installation, b10-dhcp6 binary may reside in
- src/bin/dhcp6 in your source code directory, in /usr/local/bin/b10-dhcp6
- or other directory you specified during compilation. At start, 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. The server will then
- listen to incoming traffic. Currently supported client messages are
- SOLICIT and REQUEST. The server will respond to them with ADVERTISE and
- REPLY, respectively. Since the DHCPv6 server opens privileged ports, it
- requires root access. Make sure you run this daemon as root.
-
- Note
-
- Integration with bind10 is planned. Ultimately, b10-dhcp6 will not be
- started directly, but rather via bind10. Please be aware of this planned
- change.
-
-13.2. DHCPv6 Server Configuration
-
- The DHCPv6 server does not have lease database implemented yet or any
- support for configuration, so every time the same set of configuration
- options (including the same fixed address) will be assigned every time.
-
- At this stage of development, the only way to alter server configuration
- is to tweak its source code. To do so, please edit
- src/bin/dhcp6/dhcp6_srv.cc file and modify following parameters and
- recompile:
-
- const std::string HARDCODED_LEASE = "2001:db8:1::1234:abcd";
- const uint32_t HARDCODED_T1 = 1500; // in seconds
- const uint32_t HARDCODED_T2 = 2600; // in seconds
- const uint32_t HARDCODED_PREFERRED_LIFETIME = 3600; // in seconds
- const uint32_t HARDCODED_VALID_LIFETIME = 7200; // in seconds
- const std::string HARDCODED_DNS_SERVER = "2001:db8:1::1";
-
- Lease database and configuration support is planned for 2012.
-
-13.3. Supported DHCPv6 Standards
-
- The following standards and draft standards are currently supported:
-
- o RFC3315: Supported messages are SOLICIT, ADVERTISE, REQUEST, and
- REPLY. Supported options are SERVER_ID, CLIENT_ID, IA_NA, and
- IAADDRESS.
- o RFC3646: Supported option is DNS_SERVERS.
-
-13.4. DHCPv6 Server Limitations
-
- These are the current limitations of 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.
-
- o Relayed traffic is not supported.
- o b10-dhcp6 provides a single, fixed, hardcoded lease to any client that
- asks. There is no lease manager implemented. If two clients request
- addresses, they will both get the same fixed address.
- o b10-dhcp6 does not support any configuration mechanisms yet. The whole
- configuration is currently hardcoded. The only way to tweak
- configuration is to directly modify source code. See see Section 13.2,
- "DHCPv6 Server Configuration" for details.
- o Upon start, the server will open sockets on all interfaces that are
- not loopback, are up, running and are multicast capable and have IPv6
- address. Support for multiple interfaces is not coded in reception
- routines yet, so if you are running this code on a machine that has
- many interfaces and b10-dhcp6 happens to listen on wrong interface,
- the easiest way to work around this problem is to turn down other
- interfaces. This limitation will be fixed shortly.
- o ORO (Option Request Option, a list of options requested by a client)
- is currently ignored and server assigns DNS SERVER option.
- o Temporary addresses are not supported yet.
- o Prefix delegation is not supported yet.
- o Address renewal (RENEW), rebinding (REBIND), confirmation (CONFIRM),
- duplication report (DECLINE) and release (RELEASE) are not supported
- yet.
- o DNS Update is not supported yet.
- o Interface detection is currently working on Linux only. See
- Section 14.1, "Interface detection" for details.
- o -v (verbose) command line option is currently the default, and cannot
- be disabled.
-
-Chapter 14. libdhcp++ library
-
- Table of Contents
-
- 14.1. Interface detection
-
- 14.2. DHCPv4/DHCPv6 packet handling
-
- libdhcp++ is a common library written in C++ that handles many
- DHCP-related tasks, like DHCPv4 and DHCPv6 packets parsing, manipulation
- and assembly, option parsing, manipulation and assembly, network interface
- detection and socket operations, like socket creations, data transmission
- and reception and socket closing.
-
- While this library is currently used by b10-dhcp4 and b10-dhcp6 only, it
- is designed to be portable, universal library useful for any kind of
- DHCP-related software.
-
-14.1. Interface detection
-
- Both DHCPv4 and DHCPv6 components share network interface detection
- routines. Interface detection is currently only supported on Linux
- systems.
-
- For non-Linux systems, there is currently stub implementation provided. As
- DHCP servers need to know available addresses, there is a simple mechanism
- implemented to provide that information. User is expected to create
- interfaces.txt file. Format of this file is simple. It contains list of
- interfaces along with available address on each interface. This mechanism
- is temporary and is going to be removed as soon as interface detection
- becomes available on non-Linux systems. Here is an example of the
- interfaces.txt file:
-
- # For DHCPv6, please specify link-local address (starts with fe80::)
- # If in doubt, check output of 'ifconfig -a' command.
- eth0 fe80::21e:8cff:fe9b:7349
-
- # For DHCPv4, please use following format:
- #eth0 192.0.2.5
-
-14.2. DHCPv4/DHCPv6 packet handling
-
- TODO: Describe packet handling here, with pointers to wiki
-
-Chapter 15. Statistics
-
- The b10-stats process is started by bind10. It periodically collects
- statistics data from various modules and aggregates it.
-
- This stats daemon provides commands to identify if it is running, show
- specified or all statistics data, show specified or all statistics data
- schema, and set specified statistics data. For example, using bindctl:
-
- > Stats show
- {
- "Auth": {
- "opcode.iquery": 0,
- "opcode.notify": 10,
- "opcode.query": 869617,
- ...
- "queries.tcp": 1749,
- "queries.udp": 867868
- },
- "Boss": {
- "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 at jreed.example.net",
- "report_time": "2011-01-20T17:04:06Z",
- "timestamp": 1295543046.823504
- }
- }
-
-
-Chapter 16. Logging
-
- Table of Contents
-
- 16.1. Logging configuration
-
- 16.1.1. Loggers
-
- 16.1.2. Output Options
-
- 16.1.3. Example session
-
- 16.2. Logging Message Format
-
-16.1. Logging configuration
-
- The logging system in BIND 10 is configured through the Logging module.
- All BIND 10 modules will look at the configuration in Logging to see what
- should be logged and to where.
-
- 16.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).
-
- 16.1.1.1. name (string)
-
- Each logger in the system has a name, the name being that of the component
- using it to log messages. For instance, if you want to configure logging
- for the resolver module, 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 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").
-
- 16.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):
-
- o FATAL
- o ERROR
- o WARN
- o INFO
- o 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.
-
- 16.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:
-
- 16.1.1.4. debuglevel (integer)
-
- When a logger's severity is set to DEBUG, this value specifies what debug
- messages should be printed. It ranges from 0 (least verbose) to 99 (most
- verbose).
-
- If severity for the logger is not DEBUG, this value is ignored.
-
- 16.1.1.5. additive (true or false)
-
- If this is true, the output_options from the parent will be used. For
- example, if there are two 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".
-
- 16.1.2. Output Options
-
- The main settings for an output option are the destination and a value
- called output, the meaning of which depends on the destination that is
- set.
-
- 16.1.2.1. destination (string)
-
- The destination is the type of output. It can be one of:
-
- o console
- o file
- o syslog
-
- 16.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).
-
- 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:
-
- 16.1.2.2.1. flush (true of false)
-
- Flush buffers after each log message. Doing this will reduce performance
- but will ensure that if the program terminates abnormally, all messages up
- to the point of termination are output.
-
- 16.1.2.2.2. maxsize (integer)
-
- Only relevant when destination is file, this is maximum file size of
- output files in bytes. When the maximum size is reached, the file is
- renamed and a new file opened. (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.
-
- 16.1.2.2.3. maxver (integer)
-
- Maximum number of old log files to keep around when rolling the output
- file. Only relevant when destination is "file".
-
- 16.1.3. Example session
-
- In this example we want to set the global logging to write to the file
- /var/log/my_bind10.log, 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 30000
- > 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 30000 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 "*".
-
-16.2. Logging Message Format
-
- Each message written by BIND 10 to the configured logging destinations
- comprises a number of components that identify the origin of the message
- and, if the message indicates 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.
diff --git a/doc/guide/bind10-messages.html b/doc/guide/bind10-messages.html
deleted file mode 100644
index b82b485..0000000
--- a/doc/guide/bind10-messages.html
+++ /dev/null
@@ -1,2628 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>BIND 10 Messages Manual</title><link rel="stylesheet" href="./bind10-guide.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><meta name="description" content="BIND 10 is a Domain Name System (DNS) suite managed by Internet Systems Consortium (ISC). It includes DNS libraries and modular components for controlling authoritative and recursive DNS servers. This is the messages manual for BIND 10 version 20111129. The most up-to-date version of this document, along with other documents for BIND 10, can be found at ."></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="BIND 10 Messages Manual"><div class="titlepage"><div><div><h1 class="title"><a name="id1168229451102"></a>BIND 10 Messages Manual</h1></div><div><p class="releaseinfo">This is the messages manual for BIND 10 version
- 20111129.</p></div><div><p class="copyright">Copyright © 2011-2012 Internet Systems Consortium, Inc.</p></div><div><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>BIND 10 is a Domain Name System (DNS) suite managed by
- Internet Systems Consortium (ISC). It includes DNS libraries
- and modular components for controlling authoritative and
- recursive DNS servers.
- </p><p>
- This is the messages manual for BIND 10 version 20111129.
- The most up-to-date version of this document, along with
- other documents for BIND 10, can be found at
- <a class="ulink" href="http://bind10.isc.org/docs" target="_top">http://bind10.isc.org/docs</a>.
- </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dt><span class="chapter"><a href="#messages">2. BIND 10 Messages</a></span></dt></dl></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a name="intro"></a>Chapter 1. Introduction</h2></div></div></div><p>
- This document lists each message that can be logged by the
- programs in the BIND 10 package. Each entry in this manual
- is of the form:
- </p><pre class="screen">IDENTIFICATION message-text</pre><p>
- ... where "IDENTIFICATION" is the message identification included
- in each message logged and "message-text" is the accompanying
- message text. The "message-text" may include placeholders of the
- form "%1", "%2" etc.; these parameters are replaced by relevant
- values when the message is logged.
- </p><p>
- Each entry is also accompanied by a description giving more
- information about the circumstances that result in the message
- being logged.
- </p><p>
- For information on configuring and using BIND 10 logging,
- refer to the <a class="ulink" href="bind10-guide.html" target="_top">BIND 10 Guide</a>.
- </p></div><div class="chapter" title="Chapter 2. BIND 10 Messages"><div class="titlepage"><div><div><h2 class="title"><a name="messages"></a>Chapter 2. BIND 10 Messages</h2></div></div></div><p>
- </p><div class="variablelist"><dl><dt><a name="ASIODNS_FD_ADD_TCP"></a><span class="term">ASIODNS_FD_ADD_TCP adding a new TCP server by opened fd %1</span></dt><dd><p>
-A debug message informing about installing a file descriptor as a server.
-The file descriptor number is noted.
-</p></dd><dt><a name="ASIODNS_FD_ADD_UDP"></a><span class="term">ASIODNS_FD_ADD_UDP adding a new UDP server by opened fd %1</span></dt><dd><p>
-A debug message informing about installing a file descriptor as a server.
-The file descriptor number is noted.
-</p></dd><dt><a name="ASIODNS_FETCH_COMPLETED"></a><span class="term">ASIODNS_FETCH_COMPLETED upstream fetch to %1(%2) has now completed</span></dt><dd><p>
-A debug message, this records that the upstream fetch (a query made by the
-resolver on behalf of its client) to the specified address has completed.
-</p></dd><dt><a name="ASIODNS_FETCH_STOPPED"></a><span class="term">ASIODNS_FETCH_STOPPED upstream fetch to %1(%2) has been stopped</span></dt><dd><p>
-An external component has requested the halting of an upstream fetch. This
-is an allowed operation, and the message should only appear if debug is
-enabled.
-</p></dd><dt><a name="ASIODNS_OPEN_SOCKET"></a><span class="term">ASIODNS_OPEN_SOCKET error %1 opening %2 socket to %3(%4)</span></dt><dd><p>
-The asynchronous I/O code encountered an error when trying to open a socket
-of the specified protocol in order to send a message to the target address.
-The number of the system error that caused the problem is given in the
-message.
-</p></dd><dt><a name="ASIODNS_READ_DATA"></a><span class="term">ASIODNS_READ_DATA error %1 reading %2 data from %3(%4)</span></dt><dd><p>
-The asynchronous I/O code encountered an error when trying to read data from
-the specified address on the given protocol. The number of the system
-error that caused the problem is given in the message.
-</p></dd><dt><a name="ASIODNS_READ_TIMEOUT"></a><span class="term">ASIODNS_READ_TIMEOUT receive timeout while waiting for data from %1(%2)</span></dt><dd><p>
-An upstream fetch from the specified address timed out. This may happen for
-any number of reasons and is most probably a problem at the remote server
-or a problem on the network. The message will only appear if debug is
-enabled.
-</p></dd><dt><a name="ASIODNS_SEND_DATA"></a><span class="term">ASIODNS_SEND_DATA error %1 sending data using %2 to %3(%4)</span></dt><dd><p>
-The asynchronous I/O code encountered an error when trying to send data to
-the specified address on the given protocol. The number of the system
-error that caused the problem is given in the message.
-</p></dd><dt><a name="ASIODNS_UNKNOWN_ORIGIN"></a><span class="term">ASIODNS_UNKNOWN_ORIGIN unknown origin for ASIO error code %1 (protocol: %2, address %3)</span></dt><dd><p>
-An internal consistency check on the origin of a message from the
-asynchronous I/O module failed. This may indicate an internal error;
-please submit a bug report.
-</p></dd><dt><a name="ASIODNS_UNKNOWN_RESULT"></a><span class="term">ASIODNS_UNKNOWN_RESULT unknown result (%1) when IOFetch::stop() was executed for I/O to %2(%3)</span></dt><dd><p>
-An internal error indicating that the termination method of the resolver's
-upstream fetch class was called with an unknown result code (which is
-given in the message). Please submit a bug report.
-</p></dd><dt><a name="AUTH_AXFR_ERROR"></a><span class="term">AUTH_AXFR_ERROR error handling AXFR request: %1</span></dt><dd><p>
-This is a debug message produced by the authoritative server when it
-has encountered an error processing an AXFR request. The message gives
-the reason for the error, and the server will return a SERVFAIL code to
-the sender.
-</p></dd><dt><a name="AUTH_AXFR_UDP"></a><span class="term">AUTH_AXFR_UDP AXFR query received over UDP</span></dt><dd><p>
-This is a debug message output when the authoritative server has received
-an AXFR query over UDP. Use of UDP for AXFRs is not permitted by the
-protocol, so the server will return a FORMERR error to the sender.
-</p></dd><dt><a name="AUTH_COMMAND_FAILED"></a><span class="term">AUTH_COMMAND_FAILED execution of command channel instruction '%1' failed: %2</span></dt><dd><p>
-Execution of the specified command by the authoritative server failed. The
-message contains the reason for the failure.
-</p></dd><dt><a name="AUTH_CONFIG_CHANNEL_CREATED"></a><span class="term">AUTH_CONFIG_CHANNEL_CREATED configuration session channel created</span></dt><dd><p>
-This is a debug message indicating that authoritative server has created
-the channel to the configuration manager. It is issued during server
-startup is an indication that the initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_CONFIG_CHANNEL_ESTABLISHED"></a><span class="term">AUTH_CONFIG_CHANNEL_ESTABLISHED configuration session channel established</span></dt><dd><p>
-This is a debug message indicating that authoritative server
-has established communication the configuration manager over the
-previously-created channel. It is issued during server startup is an
-indication that the initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_CONFIG_CHANNEL_STARTED"></a><span class="term">AUTH_CONFIG_CHANNEL_STARTED configuration session channel started</span></dt><dd><p>
-This is a debug message, issued when the authoritative server has
-posted a request to be notified when new configuration information is
-available. It is issued during server startup is an indication that
-the initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_CONFIG_LOAD_FAIL"></a><span class="term">AUTH_CONFIG_LOAD_FAIL load of configuration failed: %1</span></dt><dd><p>
-An attempt to configure the server with information from the configuration
-database during the startup sequence has failed. (The reason for
-the failure is given in the message.) The server will continue its
-initialization although it may not be configured in the desired way.
-</p></dd><dt><a name="AUTH_CONFIG_UPDATE_FAIL"></a><span class="term">AUTH_CONFIG_UPDATE_FAIL update of configuration failed: %1</span></dt><dd><p>
-At attempt to update the configuration the server with information
-from the configuration database has failed, the reason being given in
-the message.
-</p></dd><dt><a name="AUTH_DATA_SOURCE"></a><span class="term">AUTH_DATA_SOURCE data source database file: %1</span></dt><dd><p>
-This is a debug message produced by the authoritative server when it accesses a
-datebase data source, listing the file that is being accessed.
-</p></dd><dt><a name="AUTH_DNS_SERVICES_CREATED"></a><span class="term">AUTH_DNS_SERVICES_CREATED DNS services created</span></dt><dd><p>
-This is a debug message indicating that the component that will handling
-incoming queries for the authoritative server (DNSServices) has been
-successfully created. It is issued during server startup is an indication
-that the initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_HEADER_PARSE_FAIL"></a><span class="term">AUTH_HEADER_PARSE_FAIL unable to parse header in received DNS packet: %1</span></dt><dd><p>
-This is a debug message, generated by the authoritative server when an
-attempt to parse the header of a received DNS packet has failed. (The
-reason for the failure is given in the message.) The server will drop the
-packet.
-</p></dd><dt><a name="AUTH_INVALID_STATISTICS_DATA"></a><span class="term">AUTH_INVALID_STATISTICS_DATA invalid specification of statistics data specified</span></dt><dd><p>
-An error was encountered when the authoritiative server specified
-statistics data which is invalid for the auth specification file.
-</p></dd><dt><a name="AUTH_LOAD_TSIG"></a><span class="term">AUTH_LOAD_TSIG loading TSIG keys</span></dt><dd><p>
-This is a debug message indicating that the authoritative server
-has requested the keyring holding TSIG keys from the configuration
-database. It is issued during server startup is an indication that the
-initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_LOAD_ZONE"></a><span class="term">AUTH_LOAD_ZONE loaded zone %1/%2</span></dt><dd><p>
-This debug message is issued during the processing of the 'loadzone' command
-when the authoritative server has successfully loaded the named zone of the
-named class.
-</p></dd><dt><a name="AUTH_MEM_DATASRC_DISABLED"></a><span class="term">AUTH_MEM_DATASRC_DISABLED memory data source is disabled for class %1</span></dt><dd><p>
-This is a debug message reporting that the authoritative server has
-discovered that the memory data source is disabled for the given class.
-</p></dd><dt><a name="AUTH_MEM_DATASRC_ENABLED"></a><span class="term">AUTH_MEM_DATASRC_ENABLED memory data source is enabled for class %1</span></dt><dd><p>
-This is a debug message reporting that the authoritative server has
-discovered that the memory data source is enabled for the given class.
-</p></dd><dt><a name="AUTH_NOTIFY_QUESTIONS"></a><span class="term">AUTH_NOTIFY_QUESTIONS invalid number of questions (%1) in incoming NOTIFY</span></dt><dd><p>
-This debug message is logged by the authoritative server when it receives
-a NOTIFY packet that contains zero or more than one question. (A valid
-NOTIFY packet contains one question.) The server will return a FORMERR
-error to the sender.
-</p></dd><dt><a name="AUTH_NOTIFY_RRTYPE"></a><span class="term">AUTH_NOTIFY_RRTYPE invalid question RR type (%1) in incoming NOTIFY</span></dt><dd><p>
-This debug message is logged by the authoritative server when it receives
-a NOTIFY packet that an RR type of something other than SOA in the
-question section. (The RR type received is included in the message.) The
-server will return a FORMERR error to the sender.
-</p></dd><dt><a name="AUTH_NO_STATS_SESSION"></a><span class="term">AUTH_NO_STATS_SESSION session interface for statistics is not available</span></dt><dd><p>
-The authoritative server had no session with the statistics module at the
-time it attempted to send it data: the attempt has been abandoned. This
-could be an error in configuration.
-</p></dd><dt><a name="AUTH_NO_XFRIN"></a><span class="term">AUTH_NO_XFRIN received NOTIFY but XFRIN session is not running</span></dt><dd><p>
-This is a debug message produced by the authoritative server when it receives
-a NOTIFY packet but the XFRIN process is not running. The packet will be
-dropped and nothing returned to the sender.
-</p></dd><dt><a name="AUTH_PACKET_PARSE_ERROR"></a><span class="term">AUTH_PACKET_PARSE_ERROR unable to parse received DNS packet: %1</span></dt><dd><p>
-This is a debug message, generated by the authoritative server when an
-attempt to parse a received DNS packet has failed due to something other
-than a protocol error. The reason for the failure is given in the message;
-the server will return a SERVFAIL error code to the sender.
-</p></dd><dt><a name="AUTH_PACKET_PROTOCOL_ERROR"></a><span class="term">AUTH_PACKET_PROTOCOL_ERROR DNS packet protocol error: %1. Returning %2</span></dt><dd><p>
-This is a debug message, generated by the authoritative server when an
-attempt to parse a received DNS packet has failed due to a protocol error.
-The reason for the failure is given in the message, as is the error code
-that will be returned to the sender.
-</p></dd><dt><a name="AUTH_PACKET_RECEIVED"></a><span class="term">AUTH_PACKET_RECEIVED message received:\n%1</span></dt><dd><p>
-This is a debug message output by the authoritative server when it
-receives a valid DNS packet.
-</p><p>
-Note: This message includes the packet received, rendered in the form of
-multiple lines of text. For this reason, it is suggested that this log message
-not be routed to the syslog file, where the multiple lines could confuse
-programs that expect a format of one message per line.
-</p></dd><dt><a name="AUTH_PROCESS_FAIL"></a><span class="term">AUTH_PROCESS_FAIL message processing failure: %1</span></dt><dd><p>
-This message is generated by the authoritative server when it has
-encountered an internal error whilst processing a received packet:
-the cause of the error is included in the message.
-</p><p>
-The server will return a SERVFAIL error code to the sender of the packet.
-This message indicates a potential error in the server. Please open a
-bug ticket for this issue.
-</p></dd><dt><a name="AUTH_RECEIVED_COMMAND"></a><span class="term">AUTH_RECEIVED_COMMAND command '%1' received</span></dt><dd><p>
-This is a debug message issued when the authoritative server has received
-a command on the command channel.
-</p></dd><dt><a name="AUTH_RECEIVED_SENDSTATS"></a><span class="term">AUTH_RECEIVED_SENDSTATS command 'sendstats' received</span></dt><dd><p>
-This is a debug message issued when the authoritative server has received
-a command from the statistics module to send it data. The 'sendstats'
-command is handled differently to other commands, which is why the debug
-message associated with it has its own code.
-</p></dd><dt><a name="AUTH_RESPONSE_RECEIVED"></a><span class="term">AUTH_RESPONSE_RECEIVED received response message, ignoring</span></dt><dd><p>
-This is a debug message, this is output if the authoritative server
-receives a DNS packet with the QR bit set, i.e. a DNS response. The
-server ignores the packet as it only responds to question packets.
-</p></dd><dt><a name="AUTH_SEND_ERROR_RESPONSE"></a><span class="term">AUTH_SEND_ERROR_RESPONSE sending an error response (%1 bytes):\n%2</span></dt><dd><p>
-This is a debug message recording that the authoritative server is sending
-an error response to the originator of the query. A previous message will
-have recorded details of the failure.
-</p><p>
-Note: This message includes the packet sent, rendered in the form of
-multiple lines of text. For this reason, it is suggested that this log message
-not be routed to the syslog file, where the multiple lines could confuse
-programs that expect a format of one message per line.
-</p></dd><dt><a name="AUTH_SEND_NORMAL_RESPONSE"></a><span class="term">AUTH_SEND_NORMAL_RESPONSE sending an error response (%1 bytes):\n%2</span></dt><dd><p>
-This is a debug message recording that the authoritative server is sending
-a response to the originator of a query.
-</p><p>
-Note: This message includes the packet sent, rendered in the form of
-multiple lines of text. For this reason, it is suggested that this log message
-not be routed to the syslog file, where the multiple lines could confuse
-programs that expect a format of one message per line.
-</p></dd><dt><a name="AUTH_SERVER_CREATED"></a><span class="term">AUTH_SERVER_CREATED server created</span></dt><dd><p>
-An informational message indicating that the authoritative server process has
-been created and is initializing. The AUTH_SERVER_STARTED message will be
-output when initialization has successfully completed and the server starts
-accepting queries.
-</p></dd><dt><a name="AUTH_SERVER_FAILED"></a><span class="term">AUTH_SERVER_FAILED server failed: %1</span></dt><dd><p>
-The authoritative server has encountered a fatal error and is terminating. The
-reason for the failure is included in the message.
-</p></dd><dt><a name="AUTH_SERVER_STARTED"></a><span class="term">AUTH_SERVER_STARTED server started</span></dt><dd><p>
-Initialization of the authoritative server has completed successfully
-and it is entering the main loop, waiting for queries to arrive.
-</p></dd><dt><a name="AUTH_SQLITE3"></a><span class="term">AUTH_SQLITE3 nothing to do for loading sqlite3</span></dt><dd><p>
-This is a debug message indicating that the authoritative server has
-found that the data source it is loading is an SQLite3 data source,
-so no further validation is needed.
-</p></dd><dt><a name="AUTH_STATS_CHANNEL_CREATED"></a><span class="term">AUTH_STATS_CHANNEL_CREATED STATS session channel created</span></dt><dd><p>
-This is a debug message indicating that the authoritative server has
-created a channel to the statistics process. It is issued during server
-startup is an indication that the initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_STATS_CHANNEL_ESTABLISHED"></a><span class="term">AUTH_STATS_CHANNEL_ESTABLISHED STATS session channel established</span></dt><dd><p>
-This is a debug message indicating that the authoritative server
-has established communication over the previously created statistics
-channel. It is issued during server startup is an indication that the
-initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_STATS_COMMS"></a><span class="term">AUTH_STATS_COMMS communication error in sending statistics data: %1</span></dt><dd><p>
-An error was encountered when the authoritative server tried to send data
-to the statistics daemon. The message includes additional information
-describing the reason for the failure.
-</p></dd><dt><a name="AUTH_STATS_TIMEOUT"></a><span class="term">AUTH_STATS_TIMEOUT timeout while sending statistics data: %1</span></dt><dd><p>
-The authoritative server sent data to the statistics daemon but received
-no acknowledgement within the specified time. The message includes
-additional information describing the reason for the failure.
-</p></dd><dt><a name="AUTH_STATS_TIMER_DISABLED"></a><span class="term">AUTH_STATS_TIMER_DISABLED statistics timer has been disabled</span></dt><dd><p>
-This is a debug message indicating that the statistics timer has been
-disabled in the authoritative server and no statistics information is
-being produced.
-</p></dd><dt><a name="AUTH_STATS_TIMER_SET"></a><span class="term">AUTH_STATS_TIMER_SET statistics timer set to %1 second(s)</span></dt><dd><p>
-This is a debug message indicating that the statistics timer has been
-enabled and that the authoritative server will produce statistics data
-at the specified interval.
-</p></dd><dt><a name="AUTH_UNSUPPORTED_OPCODE"></a><span class="term">AUTH_UNSUPPORTED_OPCODE unsupported opcode: %1</span></dt><dd><p>
-This is a debug message, produced when a received DNS packet being
-processed by the authoritative server has been found to contain an
-unsupported opcode. (The opcode is included in the message.) The server
-will return an error code of NOTIMPL to the sender.
-</p></dd><dt><a name="AUTH_XFRIN_CHANNEL_CREATED"></a><span class="term">AUTH_XFRIN_CHANNEL_CREATED XFRIN session channel created</span></dt><dd><p>
-This is a debug message indicating that the authoritative server has
-created a channel to the XFRIN (Transfer-in) process. It is issued
-during server startup is an indication that the initialization is
-proceeding normally.
-</p></dd><dt><a name="AUTH_XFRIN_CHANNEL_ESTABLISHED"></a><span class="term">AUTH_XFRIN_CHANNEL_ESTABLISHED XFRIN session channel established</span></dt><dd><p>
-This is a debug message indicating that the authoritative server has
-established communication over the previously-created channel to the
-XFRIN (Transfer-in) process. It is issued during server startup is an
-indication that the initialization is proceeding normally.
-</p></dd><dt><a name="AUTH_ZONEMGR_COMMS"></a><span class="term">AUTH_ZONEMGR_COMMS error communicating with zone manager: %1</span></dt><dd><p>
-This is a debug message output during the processing of a NOTIFY request.
-An error (listed in the message) has been encountered whilst communicating
-with the zone manager. The NOTIFY request will not be honored.
-</p></dd><dt><a name="AUTH_ZONEMGR_ERROR"></a><span class="term">AUTH_ZONEMGR_ERROR received error response from zone manager: %1</span></dt><dd><p>
-This is a debug message output during the processing of a NOTIFY
-request. The zone manager component has been informed of the request,
-but has returned an error response (which is included in the message). The
-NOTIFY request will not be honored.
-</p></dd><dt><a name="BIND10_CHECK_MSGQ_ALREADY_RUNNING"></a><span class="term">BIND10_CHECK_MSGQ_ALREADY_RUNNING checking if msgq is already running</span></dt><dd><p>
-The boss process is starting up and will now check if the message bus
-daemon is already running. If so, it will not be able to start, as it
-needs a dedicated message bus.
-</p></dd><dt><a name="BIND10_COMPONENT_FAILED"></a><span class="term">BIND10_COMPONENT_FAILED component %1 (pid %2) failed with %3 exit status</span></dt><dd><p>
-The process terminated, but the bind10 boss didn't expect it to, which means
-it must have failed.
-</p></dd><dt><a name="BIND10_COMPONENT_RESTART"></a><span class="term">BIND10_COMPONENT_RESTART component %1 is about to restart</span></dt><dd><p>
-The named component failed previously and we will try to restart it to provide
-as flawless service as possible, but it should be investigated what happened,
-as it could happen again.
-</p></dd><dt><a name="BIND10_COMPONENT_START"></a><span class="term">BIND10_COMPONENT_START component %1 is starting</span></dt><dd><p>
-The named component is about to be started by the boss process.
-</p></dd><dt><a name="BIND10_COMPONENT_START_EXCEPTION"></a><span class="term">BIND10_COMPONENT_START_EXCEPTION component %1 failed to start: %2</span></dt><dd><p>
-An exception (mentioned in the message) happened during the startup of the
-named component. The componet is not considered started and further actions
-will be taken about it.
-</p></dd><dt><a name="BIND10_COMPONENT_STOP"></a><span class="term">BIND10_COMPONENT_STOP component %1 is being stopped</span></dt><dd><p>
-A component is about to be asked to stop willingly by the boss.
-</p></dd><dt><a name="BIND10_COMPONENT_UNSATISFIED"></a><span class="term">BIND10_COMPONENT_UNSATISFIED component %1 is required to run and failed</span></dt><dd><p>
-A component failed for some reason (see previous messages). It is either a core
-component or needed component that was just started. In any case, the system
-can't continue without it and will terminate.
-</p></dd><dt><a name="BIND10_CONFIGURATOR_BUILD"></a><span class="term">BIND10_CONFIGURATOR_BUILD building plan '%1' -> '%2'</span></dt><dd><p>
-A debug message. This indicates that the configurator is building a plan
-how to change configuration from the older one to newer one. This does no
-real work yet, it just does the planning what needs to be done.
-</p></dd><dt><a name="BIND10_CONFIGURATOR_PLAN_INTERRUPTED"></a><span class="term">BIND10_CONFIGURATOR_PLAN_INTERRUPTED configurator plan interrupted, only %1 of %2 done</span></dt><dd><p>
-There was an exception during some planned task. The plan will not continue and
-only some tasks of the plan were completed. The rest is aborted. The exception
-will be propagated.
-</p></dd><dt><a name="BIND10_CONFIGURATOR_RECONFIGURE"></a><span class="term">BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components</span></dt><dd><p>
-A different configuration of which components should be running is being
-installed. All components that are no longer needed will be stopped and
-newly introduced ones started. This happens at startup, when the configuration
-is read the first time, or when an operator changes configuration of the boss.
-</p></dd><dt><a name="BIND10_CONFIGURATOR_RUN"></a><span class="term">BIND10_CONFIGURATOR_RUN running plan of %1 tasks</span></dt><dd><p>
-A debug message. The configurator is about to execute a plan of actions it
-computed previously.
-</p></dd><dt><a name="BIND10_CONFIGURATOR_START"></a><span class="term">BIND10_CONFIGURATOR_START bind10 component configurator is starting up</span></dt><dd><p>
-The part that cares about starting and stopping the right component from the
-boss process is starting up. This happens only once at the startup of the
-boss process. It will start the basic set of processes now (the ones boss
-needs to read the configuration), the rest will be started after the
-configuration is known.
-</p></dd><dt><a name="BIND10_CONFIGURATOR_STOP"></a><span class="term">BIND10_CONFIGURATOR_STOP bind10 component configurator is shutting down</span></dt><dd><p>
-The part that cares about starting and stopping processes in the boss is
-shutting down. All started components will be shut down now (more precisely,
-asked to terminate by their own, if they fail to comply, other parts of
-the boss process will try to force them).
-</p></dd><dt><a name="BIND10_CONFIGURATOR_TASK"></a><span class="term">BIND10_CONFIGURATOR_TASK performing task %1 on %2</span></dt><dd><p>
-A debug message. The configurator is about to perform one task of the plan it
-is currently executing on the named component.
-</p></dd><dt><a name="BIND10_INVALID_STATISTICS_DATA"></a><span class="term">BIND10_INVALID_STATISTICS_DATA invalid specification of statistics data specified</span></dt><dd><p>
-An error was encountered when the boss module specified
-statistics data which is invalid for the boss specification file.
-</p></dd><dt><a name="BIND10_INVALID_USER"></a><span class="term">BIND10_INVALID_USER invalid user: %1</span></dt><dd><p>
-The boss process was started with the -u option, to drop root privileges
-and continue running as the specified user, but the user is unknown.
-</p></dd><dt><a name="BIND10_KILLING_ALL_PROCESSES"></a><span class="term">BIND10_KILLING_ALL_PROCESSES killing all started processes</span></dt><dd><p>
-The boss module was not able to start every process it needed to start
-during startup, and will now kill the processes that did get started.
-</p></dd><dt><a name="BIND10_KILL_PROCESS"></a><span class="term">BIND10_KILL_PROCESS killing process %1</span></dt><dd><p>
-The boss module is sending a kill signal to process with the given name,
-as part of the process of killing all started processes during a failed
-startup, as described for BIND10_KILLING_ALL_PROCESSES
-</p></dd><dt><a name="BIND10_LOST_SOCKET_CONSUMER"></a><span class="term">BIND10_LOST_SOCKET_CONSUMER consumer %1 of sockets disconnected, considering all its sockets closed</span></dt><dd><p>
-A connection from one of the applications which requested a socket was
-closed. This means the application has terminated, so all the sockets it was
-using are now closed and bind10 process can release them as well, unless the
-same sockets are used by yet another application.
-</p></dd><dt><a name="BIND10_MSGQ_ALREADY_RUNNING"></a><span class="term">BIND10_MSGQ_ALREADY_RUNNING msgq daemon already running, cannot start</span></dt><dd><p>
-There already appears to be a message bus daemon running. Either an
-old process was not shut down correctly, and needs to be killed, or
-another instance of BIND10, with the same msgq domain socket, is
-running, which needs to be stopped.
-</p></dd><dt><a name="BIND10_MSGQ_DISAPPEARED"></a><span class="term">BIND10_MSGQ_DISAPPEARED msgq channel disappeared</span></dt><dd><p>
-While listening on the message bus channel for messages, it suddenly
-disappeared. The msgq daemon may have died. This might lead to an
-inconsistent state of the system, and BIND 10 will now shut down.
-</p></dd><dt><a name="BIND10_NO_SOCKET"></a><span class="term">BIND10_NO_SOCKET couldn't send a socket for token %1 because of error: %2</span></dt><dd><p>
-An error occurred when the bind10 process was asked to send a socket file
-descriptor. The error is mentioned, most common reason is that the request
-is invalid and may not come from bind10 process at all.
-</p></dd><dt><a name="BIND10_PROCESS_ENDED"></a><span class="term">BIND10_PROCESS_ENDED process %2 of %1 ended with status %3</span></dt><dd><p>
-This indicates a process started previously terminated. The process id
-and component owning the process are indicated, as well as the exit code.
-This doesn't distinguish if the process was supposed to terminate or not.
-</p></dd><dt><a name="BIND10_READING_BOSS_CONFIGURATION"></a><span class="term">BIND10_READING_BOSS_CONFIGURATION reading boss configuration</span></dt><dd><p>
-The boss process is starting up, and will now process the initial
-configuration, as received from the configuration manager.
-</p></dd><dt><a name="BIND10_RECEIVED_COMMAND"></a><span class="term">BIND10_RECEIVED_COMMAND received command: %1</span></dt><dd><p>
-The boss module received a command and shall now process it. The command
-is printed.
-</p></dd><dt><a name="BIND10_RECEIVED_NEW_CONFIGURATION"></a><span class="term">BIND10_RECEIVED_NEW_CONFIGURATION received new configuration: %1</span></dt><dd><p>
-The boss module received a configuration update and is going to apply
-it now. The new configuration is printed.
-</p></dd><dt><a name="BIND10_RECEIVED_SIGNAL"></a><span class="term">BIND10_RECEIVED_SIGNAL received signal %1</span></dt><dd><p>
-The boss module received the given signal.
-</p></dd><dt><a name="BIND10_RESURRECTED_PROCESS"></a><span class="term">BIND10_RESURRECTED_PROCESS resurrected %1 (PID %2)</span></dt><dd><p>
-The given process has been restarted successfully, and is now running
-with the given process id.
-</p></dd><dt><a name="BIND10_RESURRECTING_PROCESS"></a><span class="term">BIND10_RESURRECTING_PROCESS resurrecting dead %1 process...</span></dt><dd><p>
-The given process has ended unexpectedly, and is now restarted.
-</p></dd><dt><a name="BIND10_SELECT_ERROR"></a><span class="term">BIND10_SELECT_ERROR error in select() call: %1</span></dt><dd><p>
-There was a fatal error in the call to select(), used to see if a child
-process has ended or if there is a message on the message bus. This
-should not happen under normal circumstances and is considered fatal,
-so BIND 10 will now shut down. The specific error is printed.
-</p></dd><dt><a name="BIND10_SEND_SIGKILL"></a><span class="term">BIND10_SEND_SIGKILL sending SIGKILL to %1 (PID %2)</span></dt><dd><p>
-The boss module is sending a SIGKILL signal to the given process.
-</p></dd><dt><a name="BIND10_SEND_SIGTERM"></a><span class="term">BIND10_SEND_SIGTERM sending SIGTERM to %1 (PID %2)</span></dt><dd><p>
-The boss module is sending a SIGTERM signal to the given process.
-</p></dd><dt><a name="BIND10_SETUID"></a><span class="term">BIND10_SETUID setting UID to %1</span></dt><dd><p>
-The boss switches the user it runs as to the given UID.
-</p></dd><dt><a name="BIND10_SHUTDOWN"></a><span class="term">BIND10_SHUTDOWN stopping the server</span></dt><dd><p>
-The boss process received a command or signal telling it to shut down.
-It will send a shutdown command to each process. The processes that do
-not shut down will then receive a SIGTERM signal. If that doesn't work,
-it shall send SIGKILL signals to the processes still alive.
-</p></dd><dt><a name="BIND10_SHUTDOWN_COMPLETE"></a><span class="term">BIND10_SHUTDOWN_COMPLETE all processes ended, shutdown complete</span></dt><dd><p>
-All child processes have been stopped, and the boss process will now
-stop itself.
-</p></dd><dt><a name="BIND10_SOCKCREATOR_BAD_CAUSE"></a><span class="term">BIND10_SOCKCREATOR_BAD_CAUSE unknown error cause from socket creator: %1</span></dt><dd><p>
-The socket creator reported an error when creating a socket. But the function
-which failed is unknown (not one of 'S' for socket or 'B' for bind).
-</p></dd><dt><a name="BIND10_SOCKCREATOR_BAD_RESPONSE"></a><span class="term">BIND10_SOCKCREATOR_BAD_RESPONSE unknown response for socket request: %1</span></dt><dd><p>
-The boss requested a socket from the creator, but the answer is unknown. This
-looks like a programmer error.
-</p></dd><dt><a name="BIND10_SOCKCREATOR_EOF"></a><span class="term">BIND10_SOCKCREATOR_EOF eof while expecting data from socket creator</span></dt><dd><p>
-There should be more data from the socket creator, but it closed the socket.
-It probably crashed.
-</p></dd><dt><a name="BIND10_SOCKCREATOR_INIT"></a><span class="term">BIND10_SOCKCREATOR_INIT initializing socket creator parser</span></dt><dd><p>
-The boss module initializes routines for parsing the socket creator
-protocol.
-</p></dd><dt><a name="BIND10_SOCKCREATOR_KILL"></a><span class="term">BIND10_SOCKCREATOR_KILL killing the socket creator</span></dt><dd><p>
-The socket creator is being terminated the aggressive way, by sending it
-sigkill. This should not happen usually.
-</p></dd><dt><a name="BIND10_SOCKCREATOR_TERMINATE"></a><span class="term">BIND10_SOCKCREATOR_TERMINATE terminating socket creator</span></dt><dd><p>
-The boss module sends a request to terminate to the socket creator.
-</p></dd><dt><a name="BIND10_SOCKCREATOR_TRANSPORT_ERROR"></a><span class="term">BIND10_SOCKCREATOR_TRANSPORT_ERROR transport error when talking to the socket creator: %1</span></dt><dd><p>
-Either sending or receiving data from the socket creator failed with the given
-error. The creator probably crashed or some serious OS-level problem happened,
-as the communication happens only on local host.
-</p></dd><dt><a name="BIND10_SOCKET_CREATED"></a><span class="term">BIND10_SOCKET_CREATED successfully created socket %1</span></dt><dd><p>
-The socket creator successfully created and sent a requested socket, it has
-the given file number.
-</p></dd><dt><a name="BIND10_SOCKET_ERROR"></a><span class="term">BIND10_SOCKET_ERROR error on %1 call in the creator: %2/%3</span></dt><dd><p>
-The socket creator failed to create the requested socket. It failed on the
-indicated OS API function with given error.
-</p></dd><dt><a name="BIND10_SOCKET_GET"></a><span class="term">BIND10_SOCKET_GET requesting socket [%1]:%2 of type %3 from the creator</span></dt><dd><p>
-The boss forwards a request for a socket to the socket creator.
-</p></dd><dt><a name="BIND10_STARTED_CC"></a><span class="term">BIND10_STARTED_CC started configuration/command session</span></dt><dd><p>
-Debug message given when BIND 10 has successfull started the object that
-handles configuration and commands.
-</p></dd><dt><a name="BIND10_STARTED_PROCESS"></a><span class="term">BIND10_STARTED_PROCESS started %1</span></dt><dd><p>
-The given process has successfully been started.
-</p></dd><dt><a name="BIND10_STARTED_PROCESS_PID"></a><span class="term">BIND10_STARTED_PROCESS_PID started %1 (PID %2)</span></dt><dd><p>
-The given process has successfully been started, and has the given PID.
-</p></dd><dt><a name="BIND10_STARTING"></a><span class="term">BIND10_STARTING starting BIND10: %1</span></dt><dd><p>
-Informational message on startup that shows the full version.
-</p></dd><dt><a name="BIND10_STARTING_CC"></a><span class="term">BIND10_STARTING_CC starting configuration/command session</span></dt><dd><p>
-Informational message given when BIND 10 is starting the session object
-that handles configuration and commands.
-</p></dd><dt><a name="BIND10_STARTING_PROCESS"></a><span class="term">BIND10_STARTING_PROCESS starting process %1</span></dt><dd><p>
-The boss module is starting the given process.
-</p></dd><dt><a name="BIND10_STARTING_PROCESS_PORT"></a><span class="term">BIND10_STARTING_PROCESS_PORT starting process %1 (to listen on port %2)</span></dt><dd><p>
-The boss module is starting the given process, which will listen on the
-given port number.
-</p></dd><dt><a name="BIND10_STARTING_PROCESS_PORT_ADDRESS"></a><span class="term">BIND10_STARTING_PROCESS_PORT_ADDRESS starting process %1 (to listen on %2#%3)</span></dt><dd><p>
-The boss module is starting the given process, which will listen on the
-given address and port number (written as <address>#<port>).
-</p></dd><dt><a name="BIND10_STARTUP_COMPLETE"></a><span class="term">BIND10_STARTUP_COMPLETE BIND 10 started</span></dt><dd><p>
-All modules have been successfully started, and BIND 10 is now running.
-</p></dd><dt><a name="BIND10_STARTUP_ERROR"></a><span class="term">BIND10_STARTUP_ERROR error during startup: %1</span></dt><dd><p>
-There was a fatal error when BIND10 was trying to start. The error is
-shown, and BIND10 will now shut down.
-</p></dd><dt><a name="BIND10_STARTUP_UNEXPECTED_MESSAGE"></a><span class="term">BIND10_STARTUP_UNEXPECTED_MESSAGE unrecognised startup message %1</span></dt><dd><p>
-During the startup process, a number of messages are exchanged between the
-Boss process and the processes it starts. This error is output when a
-message received by the Boss process is recognised as being of the
-correct format but is unexpected. It may be that processes are starting
-of sequence.
-</p></dd><dt><a name="BIND10_STARTUP_UNRECOGNISED_MESSAGE"></a><span class="term">BIND10_STARTUP_UNRECOGNISED_MESSAGE unrecognised startup message %1</span></dt><dd><p>
-During the startup process, a number of messages are exchanged between the
-Boss process and the processes it starts. This error is output when a
-message received by the Boss process is not recognised.
-</p></dd><dt><a name="BIND10_START_AS_NON_ROOT_AUTH"></a><span class="term">BIND10_START_AS_NON_ROOT_AUTH starting b10-auth as a user, not root. This might fail.</span></dt><dd><p>
-The authoritative server is being started or restarted without root privileges.
-If the module needs these privileges, it may have problems starting.
-Note that this issue should be resolved by the pending 'socket-creator'
-process; once that has been implemented, modules should not need root
-privileges anymore. See tickets #800 and #801 for more information.
-</p></dd><dt><a name="BIND10_START_AS_NON_ROOT_RESOLVER"></a><span class="term">BIND10_START_AS_NON_ROOT_RESOLVER starting b10-resolver as a user, not root. This might fail.</span></dt><dd><p>
-The resolver is being started or restarted without root privileges.
-If the module needs these privileges, it may have problems starting.
-Note that this issue should be resolved by the pending 'socket-creator'
-process; once that has been implemented, modules should not need root
-privileges anymore. See tickets #800 and #801 for more information.
-</p></dd><dt><a name="BIND10_STOP_PROCESS"></a><span class="term">BIND10_STOP_PROCESS asking %1 to shut down</span></dt><dd><p>
-The boss module is sending a shutdown command to the given module over
-the message channel.
-</p></dd><dt><a name="BIND10_UNKNOWN_CHILD_PROCESS_ENDED"></a><span class="term">BIND10_UNKNOWN_CHILD_PROCESS_ENDED unknown child pid %1 exited</span></dt><dd><p>
-An unknown child process has exited. The PID is printed, but no further
-action will be taken by the boss process.
-</p></dd><dt><a name="BIND10_WAIT_CFGMGR"></a><span class="term">BIND10_WAIT_CFGMGR waiting for configuration manager process to initialize</span></dt><dd><p>
-The configuration manager process is so critical to operation of BIND 10
-that after starting it, the Boss module will wait for it to initialize
-itself before continuing. This debug message is produced during the
-wait and may be output zero or more times depending on how long it takes
-the configuration manager to start up. The total length of time Boss
-will wait for the configuration manager before reporting an error is
-set with the command line --wait switch, which has a default value of
-ten seconds.
-</p></dd><dt><a name="CACHE_ENTRY_MISSING_RRSET"></a><span class="term">CACHE_ENTRY_MISSING_RRSET missing RRset to generate message for %1</span></dt><dd><p>
-The cache tried to generate the complete answer message. It knows the structure
-of the message, but some of the RRsets to be put there are not in cache (they
-probably expired already). Therefore it pretends the message was not found.
-</p></dd><dt><a name="CACHE_LOCALZONE_FOUND"></a><span class="term">CACHE_LOCALZONE_FOUND found entry with key %1 in local zone data</span></dt><dd><p>
-Debug message, noting that the requested data was successfully found in the
-local zone data of the cache.
-</p></dd><dt><a name="CACHE_LOCALZONE_UNKNOWN"></a><span class="term">CACHE_LOCALZONE_UNKNOWN entry with key %1 not found in local zone data</span></dt><dd><p>
-Debug message. The requested data was not found in the local zone data.
-</p></dd><dt><a name="CACHE_LOCALZONE_UPDATE"></a><span class="term">CACHE_LOCALZONE_UPDATE updating local zone element at key %1</span></dt><dd><p>
-Debug message issued when there's update to the local zone section of cache.
-</p></dd><dt><a name="CACHE_MESSAGES_DEINIT"></a><span class="term">CACHE_MESSAGES_DEINIT deinitialized message cache</span></dt><dd><p>
-Debug message. It is issued when the server deinitializes the message cache.
-</p></dd><dt><a name="CACHE_MESSAGES_EXPIRED"></a><span class="term">CACHE_MESSAGES_EXPIRED found an expired message entry for %1 in the message cache</span></dt><dd><p>
-Debug message. The requested data was found in the message cache, but it
-already expired. Therefore the cache removes the entry and pretends it found
-nothing.
-</p></dd><dt><a name="CACHE_MESSAGES_FOUND"></a><span class="term">CACHE_MESSAGES_FOUND found a message entry for %1 in the message cache</span></dt><dd><p>
-Debug message. We found the whole message in the cache, so it can be returned
-to user without any other lookups.
-</p></dd><dt><a name="CACHE_MESSAGES_INIT"></a><span class="term">CACHE_MESSAGES_INIT initialized message cache for %1 messages of class %2</span></dt><dd><p>
-Debug message issued when a new message cache is issued. It lists the class
-of messages it can hold and the maximum size of the cache.
-</p></dd><dt><a name="CACHE_MESSAGES_REMOVE"></a><span class="term">CACHE_MESSAGES_REMOVE removing old instance of %1/%2/%3 first</span></dt><dd><p>
-Debug message. This may follow CACHE_MESSAGES_UPDATE and indicates that, while
-updating, the old instance is being removed prior of inserting a new one.
-</p></dd><dt><a name="CACHE_MESSAGES_UNCACHEABLE"></a><span class="term">CACHE_MESSAGES_UNCACHEABLE not inserting uncacheable message %1/%2/%3</span></dt><dd><p>
-Debug message, noting that the given message can not be cached. This is because
-there's no SOA record in the message. See RFC 2308 section 5 for more
-information.
-</p></dd><dt><a name="CACHE_MESSAGES_UNKNOWN"></a><span class="term">CACHE_MESSAGES_UNKNOWN no entry for %1 found in the message cache</span></dt><dd><p>
-Debug message. The message cache didn't find any entry for the given key.
-</p></dd><dt><a name="CACHE_MESSAGES_UPDATE"></a><span class="term">CACHE_MESSAGES_UPDATE updating message entry %1/%2/%3</span></dt><dd><p>
-Debug message issued when the message cache is being updated with a new
-message. Either the old instance is removed or, if none is found, new one
-is created.
-</p></dd><dt><a name="CACHE_RESOLVER_DEEPEST"></a><span class="term">CACHE_RESOLVER_DEEPEST looking up deepest NS for %1/%2</span></dt><dd><p>
-Debug message. The resolver cache is looking up the deepest known nameserver,
-so the resolution doesn't have to start from the root.
-</p></dd><dt><a name="CACHE_RESOLVER_INIT"></a><span class="term">CACHE_RESOLVER_INIT initializing resolver cache for class %1</span></dt><dd><p>
-Debug message. The resolver cache is being created for this given class.
-</p></dd><dt><a name="CACHE_RESOLVER_INIT_INFO"></a><span class="term">CACHE_RESOLVER_INIT_INFO initializing resolver cache for class %1</span></dt><dd><p>
-Debug message, the resolver cache is being created for this given class. The
-difference from CACHE_RESOLVER_INIT is only in different format of passed
-information, otherwise it does the same.
-</p></dd><dt><a name="CACHE_RESOLVER_LOCAL_MSG"></a><span class="term">CACHE_RESOLVER_LOCAL_MSG message for %1/%2 found in local zone data</span></dt><dd><p>
-Debug message. The resolver cache found a complete message for the user query
-in the zone data.
-</p></dd><dt><a name="CACHE_RESOLVER_LOCAL_RRSET"></a><span class="term">CACHE_RESOLVER_LOCAL_RRSET RRset for %1/%2 found in local zone data</span></dt><dd><p>
-Debug message. The resolver cache found a requested RRset in the local zone
-data.
-</p></dd><dt><a name="CACHE_RESOLVER_LOOKUP_MSG"></a><span class="term">CACHE_RESOLVER_LOOKUP_MSG looking up message in resolver cache for %1/%2</span></dt><dd><p>
-Debug message. The resolver cache is trying to find a message to answer the
-user query.
-</p></dd><dt><a name="CACHE_RESOLVER_LOOKUP_RRSET"></a><span class="term">CACHE_RESOLVER_LOOKUP_RRSET looking up RRset in resolver cache for %1/%2</span></dt><dd><p>
-Debug message. The resolver cache is trying to find an RRset (which usually
-originates as internally from resolver).
-</p></dd><dt><a name="CACHE_RESOLVER_NO_QUESTION"></a><span class="term">CACHE_RESOLVER_NO_QUESTION answer message for %1/%2 has empty question section</span></dt><dd><p>
-The cache tried to fill in found data into the response message. But it
-discovered the message contains no question section, which is invalid.
-This is likely a programmer error, please submit a bug report.
-</p></dd><dt><a name="CACHE_RESOLVER_UNKNOWN_CLASS_MSG"></a><span class="term">CACHE_RESOLVER_UNKNOWN_CLASS_MSG no cache for class %1</span></dt><dd><p>
-Debug message. While trying to lookup a message in the resolver cache, it was
-discovered there's no cache for this class at all. Therefore no message is
-found.
-</p></dd><dt><a name="CACHE_RESOLVER_UNKNOWN_CLASS_RRSET"></a><span class="term">CACHE_RESOLVER_UNKNOWN_CLASS_RRSET no cache for class %1</span></dt><dd><p>
-Debug message. While trying to lookup an RRset in the resolver cache, it was
-discovered there's no cache for this class at all. Therefore no data is found.
-</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_MSG"></a><span class="term">CACHE_RESOLVER_UPDATE_MSG updating message for %1/%2/%3</span></dt><dd><p>
-Debug message. The resolver is updating a message in the cache.
-</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_RRSET"></a><span class="term">CACHE_RESOLVER_UPDATE_RRSET updating RRset for %1/%2/%3</span></dt><dd><p>
-Debug message. The resolver is updating an RRset in the cache.
-</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_MSG"></a><span class="term">CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_MSG no cache for class %1</span></dt><dd><p>
-Debug message. While trying to insert a message into the cache, it was
-discovered that there's no cache for the class of message. Therefore
-the message will not be cached.
-</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_RRSET"></a><span class="term">CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_RRSET no cache for class %1</span></dt><dd><p>
-Debug message. While trying to insert an RRset into the cache, it was
-discovered that there's no cache for the class of the RRset. Therefore
-the message will not be cached.
-</p></dd><dt><a name="CACHE_RRSET_EXPIRED"></a><span class="term">CACHE_RRSET_EXPIRED found expired RRset %1/%2/%3</span></dt><dd><p>
-Debug message. The requested data was found in the RRset cache. However, it is
-expired, so the cache removed it and is going to pretend nothing was found.
-</p></dd><dt><a name="CACHE_RRSET_INIT"></a><span class="term">CACHE_RRSET_INIT initializing RRset cache for %1 RRsets of class %2</span></dt><dd><p>
-Debug message. The RRset cache to hold at most this many RRsets for the given
-class is being created.
-</p></dd><dt><a name="CACHE_RRSET_LOOKUP"></a><span class="term">CACHE_RRSET_LOOKUP looking up %1/%2/%3 in RRset cache</span></dt><dd><p>
-Debug message. The resolver is trying to look up data in the RRset cache.
-</p></dd><dt><a name="CACHE_RRSET_NOT_FOUND"></a><span class="term">CACHE_RRSET_NOT_FOUND no RRset found for %1/%2/%3 in cache</span></dt><dd><p>
-Debug message which can follow CACHE_RRSET_LOOKUP. This means the data is not
-in the cache.
-</p></dd><dt><a name="CACHE_RRSET_REMOVE_OLD"></a><span class="term">CACHE_RRSET_REMOVE_OLD removing old RRset for %1/%2/%3 to make space for new one</span></dt><dd><p>
-Debug message which can follow CACHE_RRSET_UPDATE. During the update, the cache
-removed an old instance of the RRset to replace it with the new one.
-</p></dd><dt><a name="CACHE_RRSET_UNTRUSTED"></a><span class="term">CACHE_RRSET_UNTRUSTED not replacing old RRset for %1/%2/%3, it has higher trust level</span></dt><dd><p>
-Debug message which can follow CACHE_RRSET_UPDATE. The cache already holds the
-same RRset, but from more trusted source, so the old one is kept and new one
-ignored.
-</p></dd><dt><a name="CACHE_RRSET_UPDATE"></a><span class="term">CACHE_RRSET_UPDATE updating RRset %1/%2/%3 in the cache</span></dt><dd><p>
-Debug message. The RRset is updating its data with this given RRset.
-</p></dd><dt><a name="CC_ASYNC_READ_FAILED"></a><span class="term">CC_ASYNC_READ_FAILED asynchronous read failed</span></dt><dd><p>
-This marks a low level error, we tried to read data from the message queue
-daemon asynchronously, but the ASIO library returned an error.
-</p></dd><dt><a name="CC_CONN_ERROR"></a><span class="term">CC_CONN_ERROR error connecting to message queue (%1)</span></dt><dd><p>
-It is impossible to reach the message queue daemon for the reason given. It
-is unlikely there'll be reason for whatever program this currently is to
-continue running, as the communication with the rest of BIND 10 is vital
-for the components.
-</p></dd><dt><a name="CC_DISCONNECT"></a><span class="term">CC_DISCONNECT disconnecting from message queue daemon</span></dt><dd><p>
-The library is disconnecting from the message queue daemon. This debug message
-indicates that the program is trying to shut down gracefully.
-</p></dd><dt><a name="CC_ESTABLISH"></a><span class="term">CC_ESTABLISH trying to establish connection with message queue daemon at %1</span></dt><dd><p>
-This debug message indicates that the command channel library is about to
-connect to the message queue daemon, which should be listening on the UNIX-domain
-socket listed in the output.
-</p></dd><dt><a name="CC_ESTABLISHED"></a><span class="term">CC_ESTABLISHED successfully connected to message queue daemon</span></dt><dd><p>
-This debug message indicates that the connection was successfully made, this
-should follow CC_ESTABLISH.
-</p></dd><dt><a name="CC_GROUP_RECEIVE"></a><span class="term">CC_GROUP_RECEIVE trying to receive a message</span></dt><dd><p>
-Debug message, noting that a message is expected to come over the command
-channel.
-</p></dd><dt><a name="CC_GROUP_RECEIVED"></a><span class="term">CC_GROUP_RECEIVED message arrived ('%1', '%2')</span></dt><dd><p>
-Debug message, noting that we successfully received a message (its envelope and
-payload listed). This follows CC_GROUP_RECEIVE, but might happen some time
-later, depending if we waited for it or just polled.
-</p></dd><dt><a name="CC_GROUP_SEND"></a><span class="term">CC_GROUP_SEND sending message '%1' to group '%2'</span></dt><dd><p>
-Debug message, we're about to send a message over the command channel.
-</p></dd><dt><a name="CC_INVALID_LENGTHS"></a><span class="term">CC_INVALID_LENGTHS invalid length parameters (%1, %2)</span></dt><dd><p>
-This happens when garbage comes over the command channel or some kind of
-confusion happens in the program. The data received from the socket make no
-sense if we interpret it as lengths of message. The first one is total length
-of the message; the second is the length of the header. The header
-and its length (2 bytes) is counted in the total length.
-</p></dd><dt><a name="CC_LENGTH_NOT_READY"></a><span class="term">CC_LENGTH_NOT_READY length not ready</span></dt><dd><p>
-There should be data representing the length of message on the socket, but it
-is not there.
-</p></dd><dt><a name="CC_NO_MESSAGE"></a><span class="term">CC_NO_MESSAGE no message ready to be received yet</span></dt><dd><p>
-The program polled for incoming messages, but there was no message waiting.
-This is a debug message which may happen only after CC_GROUP_RECEIVE.
-</p></dd><dt><a name="CC_NO_MSGQ"></a><span class="term">CC_NO_MSGQ unable to connect to message queue (%1)</span></dt><dd><p>
-It isn't possible to connect to the message queue daemon, for reason listed.
-It is unlikely any program will be able continue without the communication.
-</p></dd><dt><a name="CC_READ_ERROR"></a><span class="term">CC_READ_ERROR error reading data from command channel (%1)</span></dt><dd><p>
-A low level error happened when the library tried to read data from the
-command channel socket. The reason is listed.
-</p></dd><dt><a name="CC_READ_EXCEPTION"></a><span class="term">CC_READ_EXCEPTION error reading data from command channel (%1)</span></dt><dd><p>
-We received an exception while trying to read data from the command
-channel socket. The reason is listed.
-</p></dd><dt><a name="CC_REPLY"></a><span class="term">CC_REPLY replying to message from '%1' with '%2'</span></dt><dd><p>
-Debug message, noting we're sending a response to the original message
-with the given envelope.
-</p></dd><dt><a name="CC_SET_TIMEOUT"></a><span class="term">CC_SET_TIMEOUT setting timeout to %1ms</span></dt><dd><p>
-Debug message. A timeout for which the program is willing to wait for a reply
-is being set.
-</p></dd><dt><a name="CC_START_READ"></a><span class="term">CC_START_READ starting asynchronous read</span></dt><dd><p>
-Debug message. From now on, when a message (or command) comes, it'll wake the
-program and the library will automatically pass it over to correct place.
-</p></dd><dt><a name="CC_SUBSCRIBE"></a><span class="term">CC_SUBSCRIBE subscribing to communication group %1</span></dt><dd><p>
-Debug message. The program wants to receive messages addressed to this group.
-</p></dd><dt><a name="CC_TIMEOUT"></a><span class="term">CC_TIMEOUT timeout reading data from command channel</span></dt><dd><p>
-The program waited too long for data from the command channel (usually when it
-sent a query to different program and it didn't answer for whatever reason).
-</p></dd><dt><a name="CC_UNSUBSCRIBE"></a><span class="term">CC_UNSUBSCRIBE unsubscribing from communication group %1</span></dt><dd><p>
-Debug message. The program no longer wants to receive messages addressed to
-this group.
-</p></dd><dt><a name="CC_WRITE_ERROR"></a><span class="term">CC_WRITE_ERROR error writing data to command channel (%1)</span></dt><dd><p>
-A low level error happened when the library tried to write data to the command
-channel socket.
-</p></dd><dt><a name="CC_ZERO_LENGTH"></a><span class="term">CC_ZERO_LENGTH invalid message length (0)</span></dt><dd><p>
-The library received a message length being zero, which makes no sense, since
-all messages must contain at least the envelope.
-</p></dd><dt><a name="CFGMGR_AUTOMATIC_CONFIG_DATABASE_UPDATE"></a><span class="term">CFGMGR_AUTOMATIC_CONFIG_DATABASE_UPDATE Updating configuration database from version %1 to %2</span></dt><dd><p>
-An older version of the configuration database has been found, from which
-there was an automatic upgrade path to the current version. These changes
-are now applied, and no action from the administrator is necessary.
-</p></dd><dt><a name="CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE"></a><span class="term">CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE Unable to parse response from module %1: %2</span></dt><dd><p>
-The configuration manager sent a configuration update to a module, but
-the module responded with an answer that could not be parsed. The answer
-message appears to be invalid JSON data, or not decodable to a string.
-This is likely to be a problem in the module in question. The update is
-assumed to have failed, and will not be stored.
-</p></dd><dt><a name="CFGMGR_CC_SESSION_ERROR"></a><span class="term">CFGMGR_CC_SESSION_ERROR Error connecting to command channel: %1</span></dt><dd><p>
-The configuration manager daemon was unable to connect to the messaging
-system. The most likely cause is that msgq is not running.
-</p></dd><dt><a name="CFGMGR_DATA_READ_ERROR"></a><span class="term">CFGMGR_DATA_READ_ERROR error reading configuration database from disk: %1</span></dt><dd><p>
-There was a problem reading the persistent configuration data as stored
-on disk. The file may be corrupted, or it is of a version from where
-there is no automatic upgrade path. The file needs to be repaired or
-removed. The configuration manager daemon will now shut down.
-</p></dd><dt><a name="CFGMGR_IOERROR_WHILE_WRITING_CONFIGURATION"></a><span class="term">CFGMGR_IOERROR_WHILE_WRITING_CONFIGURATION Unable to write configuration file; configuration not stored: %1</span></dt><dd><p>
-There was an IO error from the system while the configuration manager
-was trying to write the configuration database to disk. The specific
-error is given. The most likely cause is that the directory where
-the file is stored does not exist, or is not writable. The updated
-configuration is not stored.
-</p></dd><dt><a name="CFGMGR_OSERROR_WHILE_WRITING_CONFIGURATION"></a><span class="term">CFGMGR_OSERROR_WHILE_WRITING_CONFIGURATION Unable to write configuration file; configuration not stored: %1</span></dt><dd><p>
-There was an OS error from the system while the configuration manager
-was trying to write the configuration database to disk. The specific
-error is given. The most likely cause is that the system does not have
-write access to the configuration database file. The updated
-configuration is not stored.
-</p></dd><dt><a name="CFGMGR_STOPPED_BY_KEYBOARD"></a><span class="term">CFGMGR_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the cfgmgr daemon. The
-daemon will now shut down.
-</p></dd><dt><a name="CMDCTL_BAD_CONFIG_DATA"></a><span class="term">CMDCTL_BAD_CONFIG_DATA error in config data: %1</span></dt><dd><p>
-There was an error reading the updated configuration data. The specific
-error is printed.
-</p></dd><dt><a name="CMDCTL_BAD_PASSWORD"></a><span class="term">CMDCTL_BAD_PASSWORD bad password for user: %1</span></dt><dd><p>
-A login attempt was made to b10-cmdctl, but the password was wrong.
-Users can be managed with the tool b10-cmdctl-usermgr.
-</p></dd><dt><a name="CMDCTL_CC_SESSION_ERROR"></a><span class="term">CMDCTL_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
-There was a problem reading from the command and control channel. The
-most likely cause is that the message bus daemon is not running.
-</p></dd><dt><a name="CMDCTL_CC_SESSION_TIMEOUT"></a><span class="term">CMDCTL_CC_SESSION_TIMEOUT timeout on cc channel</span></dt><dd><p>
-A timeout occurred when waiting for essential data from the cc session.
-This usually occurs when b10-cfgmgr is not running or not responding.
-Since we are waiting for essential information, this is a fatal error,
-and the cmdctl daemon will now shut down.
-</p></dd><dt><a name="CMDCTL_COMMAND_ERROR"></a><span class="term">CMDCTL_COMMAND_ERROR error in command %1 to module %2: %3</span></dt><dd><p>
-An error was encountered sending the given command to the given module.
-Either there was a communication problem with the module, or the module
-was not able to process the command, and sent back an error. The
-specific error is printed in the message.
-</p></dd><dt><a name="CMDCTL_COMMAND_SENT"></a><span class="term">CMDCTL_COMMAND_SENT command '%1' to module '%2' was sent</span></dt><dd><p>
-This debug message indicates that the given command has been sent to
-the given module.
-</p></dd><dt><a name="CMDCTL_NO_SUCH_USER"></a><span class="term">CMDCTL_NO_SUCH_USER username not found in user database: %1</span></dt><dd><p>
-A login attempt was made to b10-cmdctl, but the username was not known.
-Users can be added with the tool b10-cmdctl-usermgr.
-</p></dd><dt><a name="CMDCTL_NO_USER_ENTRIES_READ"></a><span class="term">CMDCTL_NO_USER_ENTRIES_READ failed to read user information, all users will be denied</span></dt><dd><p>
-The b10-cmdctl daemon was unable to find any user data in the user
-database file. Either it was unable to read the file (in which case
-this message follows a message CMDCTL_USER_DATABASE_READ_ERROR
-containing a specific error), or the file was empty. Users can be added
-with the tool b10-cmdctl-usermgr.
-</p></dd><dt><a name="CMDCTL_SEND_COMMAND"></a><span class="term">CMDCTL_SEND_COMMAND sending command %1 to module %2</span></dt><dd><p>
-This debug message indicates that the given command is being sent to
-the given module.
-</p></dd><dt><a name="CMDCTL_SSL_SETUP_FAILURE_USER_DENIED"></a><span class="term">CMDCTL_SSL_SETUP_FAILURE_USER_DENIED failed to create an SSL connection (user denied): %1</span></dt><dd><p>
-The user was denied because the SSL connection could not successfully
-be set up. The specific error is given in the log message. Possible
-causes may be that the ssl request itself was bad, or the local key or
-certificate file could not be read.
-</p></dd><dt><a name="CMDCTL_STARTED"></a><span class="term">CMDCTL_STARTED cmdctl is listening for connections on %1:%2</span></dt><dd><p>
-The cmdctl daemon has started and is now listening for connections.
-</p></dd><dt><a name="CMDCTL_STOPPED_BY_KEYBOARD"></a><span class="term">CMDCTL_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the cmdctl daemon. The
-daemon will now shut down.
-</p></dd><dt><a name="CMDCTL_UNCAUGHT_EXCEPTION"></a><span class="term">CMDCTL_UNCAUGHT_EXCEPTION uncaught exception: %1</span></dt><dd><p>
-The b10-cmdctl daemon encountered an uncaught exception and
-will now shut down. This is indicative of a programming error and
-should not happen under normal circumstances. The exception message
-is printed.
-</p></dd><dt><a name="CMDCTL_USER_DATABASE_READ_ERROR"></a><span class="term">CMDCTL_USER_DATABASE_READ_ERROR failed to read user database file %1: %2</span></dt><dd><p>
-The b10-cmdctl daemon was unable to read the user database file. The
-file may be unreadable for the daemon, or it may be corrupted. In the
-latter case, it can be recreated with b10-cmdctl-usermgr. The specific
-error is printed in the log message.
-</p></dd><dt><a name="CONFIG_CCSESSION_MSG"></a><span class="term">CONFIG_CCSESSION_MSG error in CC session message: %1</span></dt><dd><p>
-There was a problem with an incoming message on the command and control
-channel. The message does not appear to be a valid command, and is
-missing a required element or contains an unknown data format. This
-most likely means that another BIND10 module is sending a bad message.
-The message itself is ignored by this module.
-</p></dd><dt><a name="CONFIG_CCSESSION_MSG_INTERNAL"></a><span class="term">CONFIG_CCSESSION_MSG_INTERNAL error handling CC session message: %1</span></dt><dd><p>
-There was an internal problem handling an incoming message on the command
-and control channel. An unexpected exception was thrown, details of
-which are appended to the message. The module will continue to run,
-but will not send back an answer.
-</p><p>
-The most likely cause of this error is a programming error. Please raise
-a bug report.
-</p></dd><dt><a name="CONFIG_GET_FAIL"></a><span class="term">CONFIG_GET_FAIL error getting configuration from cfgmgr: %1</span></dt><dd><p>
-The configuration manager returned an error when this module requested
-the configuration. The full error message answer from the configuration
-manager is appended to the log error. The most likely cause is that
-the module is of a different (command specification) version than the
-running configuration manager.
-</p></dd><dt><a name="CONFIG_GET_FAILED"></a><span class="term">CONFIG_GET_FAILED error getting configuration from cfgmgr: %1</span></dt><dd><p>
-The configuration manager returned an error response when the module
-requested its configuration. The full error message answer from the
-configuration manager is appended to the log error.
-</p></dd><dt><a name="CONFIG_JSON_PARSE"></a><span class="term">CONFIG_JSON_PARSE JSON parse error in %1: %2</span></dt><dd><p>
-There was an error parsing the JSON file. The given file does not appear
-to be in valid JSON format. Please verify that the filename is correct
-and that the contents are valid JSON.
-</p></dd><dt><a name="CONFIG_LOG_CONFIG_ERRORS"></a><span class="term">CONFIG_LOG_CONFIG_ERRORS error(s) in logging configuration: %1</span></dt><dd><p>
-There was a logging configuration update, but the internal validator
-for logging configuration found that it contained errors. The errors
-are shown, and the update is ignored.
-</p></dd><dt><a name="CONFIG_LOG_EXPLICIT"></a><span class="term">CONFIG_LOG_EXPLICIT will use logging configuration for explicitly-named logger %1</span></dt><dd><p>
-This is a debug message. When processing the "loggers" part of the
-configuration file, the configuration library found an entry for the named
-logger that matches the logger specification for the program. The logging
-configuration for the program will be updated with the information.
-</p></dd><dt><a name="CONFIG_LOG_IGNORE_EXPLICIT"></a><span class="term">CONFIG_LOG_IGNORE_EXPLICIT ignoring logging configuration for explicitly-named logger %1</span></dt><dd><p>
-This is a debug message. When processing the "loggers" part of the
-configuration file, the configuration library found an entry for the
-named logger. As this does not match the logger specification for the
-program, it has been ignored.
-</p></dd><dt><a name="CONFIG_LOG_IGNORE_WILD"></a><span class="term">CONFIG_LOG_IGNORE_WILD ignoring logging configuration for wildcard logger %1</span></dt><dd><p>
-This is a debug message. When processing the "loggers" part of the
-configuration file, the configuration library found the named wildcard
-entry (one containing the "*" character) that matched a logger already
-matched by an explicitly named entry. The configuration is ignored.
-</p></dd><dt><a name="CONFIG_LOG_WILD_MATCH"></a><span class="term">CONFIG_LOG_WILD_MATCH will use logging configuration for wildcard logger %1</span></dt><dd><p>
-This is a debug message. When processing the "loggers" part of
-the configuration file, the configuration library found the named
-wildcard entry (one containing the "*" character) that matches a logger
-specification in the program. The logging configuration for the program
-will be updated with the information.
-</p></dd><dt><a name="CONFIG_MOD_SPEC_FORMAT"></a><span class="term">CONFIG_MOD_SPEC_FORMAT module specification error in %1: %2</span></dt><dd><p>
-The given file does not appear to be a valid specification file: details
-are included in the message. Please verify that the filename is correct
-and that its contents are a valid BIND10 module specification.
-</p></dd><dt><a name="CONFIG_MOD_SPEC_REJECT"></a><span class="term">CONFIG_MOD_SPEC_REJECT module specification rejected by cfgmgr: %1</span></dt><dd><p>
-The specification file for this module was rejected by the configuration
-manager. The full error message answer from the configuration manager is
-appended to the log error. The most likely cause is that the module is of
-a different (specification file) version than the running configuration
-manager.
-</p></dd><dt><a name="CONFIG_OPEN_FAIL"></a><span class="term">CONFIG_OPEN_FAIL error opening %1: %2</span></dt><dd><p>
-There was an error opening the given file. The reason for the failure
-is included in the message.
-</p></dd><dt><a name="DATASRC_CACHE_CREATE"></a><span class="term">DATASRC_CACHE_CREATE creating the hotspot cache</span></dt><dd><p>
-This is a debug message issued during startup when the hotspot cache
-is created.
-</p></dd><dt><a name="DATASRC_CACHE_DESTROY"></a><span class="term">DATASRC_CACHE_DESTROY destroying the hotspot cache</span></dt><dd><p>
-Debug information. The hotspot cache is being destroyed.
-</p></dd><dt><a name="DATASRC_CACHE_DISABLE"></a><span class="term">DATASRC_CACHE_DISABLE disabling the hotspot cache</span></dt><dd><p>
-A debug message issued when the hotspot cache is disabled.
-</p></dd><dt><a name="DATASRC_CACHE_ENABLE"></a><span class="term">DATASRC_CACHE_ENABLE enabling the hotspot cache</span></dt><dd><p>
-A debug message issued when the hotspot cache is enabled.
-</p></dd><dt><a name="DATASRC_CACHE_EXPIRED"></a><span class="term">DATASRC_CACHE_EXPIRED item '%1' in the hotspot cache has expired</span></dt><dd><p>
-A debug message issued when a hotspot cache lookup located the item but it
-had expired. The item was removed and the program proceeded as if the item
-had not been found.
-</p></dd><dt><a name="DATASRC_CACHE_FOUND"></a><span class="term">DATASRC_CACHE_FOUND the item '%1' was found</span></dt><dd><p>
-Debug information. An item was successfully located in the hotspot cache.
-</p></dd><dt><a name="DATASRC_CACHE_FULL"></a><span class="term">DATASRC_CACHE_FULL hotspot cache is full, dropping oldest</span></dt><dd><p>
-Debug information. After inserting an item into the hotspot cache, the
-maximum number of items was exceeded, so the least recently used item will
-be dropped. This should be directly followed by CACHE_REMOVE.
-</p></dd><dt><a name="DATASRC_CACHE_INSERT"></a><span class="term">DATASRC_CACHE_INSERT inserting item '%1' into the hotspot cache</span></dt><dd><p>
-A debug message indicating that a new item is being inserted into the hotspot
-cache.
-</p></dd><dt><a name="DATASRC_CACHE_NOT_FOUND"></a><span class="term">DATASRC_CACHE_NOT_FOUND the item '%1' was not found in the hotspot cache</span></dt><dd><p>
-A debug message issued when hotspot cache was searched for the specified
-item but it was not found.
-</p></dd><dt><a name="DATASRC_CACHE_OLD_FOUND"></a><span class="term">DATASRC_CACHE_OLD_FOUND older instance of hotspot cache item '%1' found, replacing</span></dt><dd><p>
-Debug information. While inserting an item into the hotspot cache, an older
-instance of an item with the same name was found; the old instance will be
-removed. This will be directly followed by CACHE_REMOVE.
-</p></dd><dt><a name="DATASRC_CACHE_REMOVE"></a><span class="term">DATASRC_CACHE_REMOVE removing '%1' from the hotspot cache</span></dt><dd><p>
-Debug information. An item is being removed from the hotspot cache.
-</p></dd><dt><a name="DATASRC_CACHE_SLOTS"></a><span class="term">DATASRC_CACHE_SLOTS setting the hotspot cache size to '%1', dropping '%2' items</span></dt><dd><p>
-The maximum allowed number of items of the hotspot cache is set to the given
-number. If there are too many, some of them will be dropped. The size of 0
-means no limit.
-</p></dd><dt><a name="DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED"></a><span class="term">DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED %1 doesn't support DNSSEC when asked for NSEC data covering %2</span></dt><dd><p>
-The datasource tried to provide an NSEC proof that the named domain does not
-exist, but the database backend doesn't support DNSSEC. No proof is included
-in the answer as a result.
-</p></dd><dt><a name="DATASRC_DATABASE_FIND_RECORDS"></a><span class="term">DATASRC_DATABASE_FIND_RECORDS looking in datasource %1 for record %2/%3/%4</span></dt><dd><p>
-Debug information. The database data source is looking up records with the given
-name and type in the database.
-</p></dd><dt><a name="DATASRC_DATABASE_FIND_TTL_MISMATCH"></a><span class="term">DATASRC_DATABASE_FIND_TTL_MISMATCH TTL values differ in %1 for elements of %2/%3/%4, setting to %5</span></dt><dd><p>
-The datasource backend provided resource records for the given RRset with
-different TTL values. This isn't allowed on the wire and is considered
-an error, so we set it to the lowest value we found (but we don't modify the
-database). The data in database should be checked and fixed.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_ANY"></a><span class="term">DATASRC_DATABASE_FOUND_ANY search in datasource %1 resulted in returning all records of %2</span></dt><dd><p>
-The data returned by the database backend contained data for the given domain
-name, so all the RRsets of the domain are returned.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_CNAME"></a><span class="term">DATASRC_DATABASE_FOUND_CNAME search in datasource %1 for %2/%3/%4 found CNAME, resulting in %5</span></dt><dd><p>
-When searching the domain for a name a CNAME was found at that name.
-Even though it was not the RR type being sought, it is returned. (The
-caller may want to continue the lookup by replacing the query name with
-the canonical name and restarting the query with the original RR type.)
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_DELEGATION"></a><span class="term">DATASRC_DATABASE_FOUND_DELEGATION Found delegation at %2 in %1</span></dt><dd><p>
-When searching for a domain, the program met a delegation to a different zone
-at the given domain name. It will return that one instead.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_DELEGATION_EXACT"></a><span class="term">DATASRC_DATABASE_FOUND_DELEGATION_EXACT search in datasource %1 for %2/%3/%4 found delegation at %5</span></dt><dd><p>
-The program found the domain requested, but it is a delegation point to a
-different zone, therefore it is not authoritative for this domain name.
-It will return the NS record instead.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_DNAME"></a><span class="term">DATASRC_DATABASE_FOUND_DNAME Found DNAME at %2 in %1</span></dt><dd><p>
-When searching for a domain, the program met a DNAME redirection to a different
-place in the domain space at the given domain name. It will return that one
-instead.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL"></a><span class="term">DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL empty non-terminal %2 in %1</span></dt><dd><p>
-The domain name does not have any RRs associated with it, so it doesn't
-exist in the database. However, it has a subdomain, so it does exist
-in the DNS address space. This type of domain is known an an "empty
-non-terminal" and so we return NXRRSET instead of NXDOMAIN.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_NXDOMAIN"></a><span class="term">DATASRC_DATABASE_FOUND_NXDOMAIN search in datasource %1 resulted in NXDOMAIN for %2/%3/%4</span></dt><dd><p>
-The data returned by the database backend did not contain any data for the given
-domain name, class and type.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_NXRRSET"></a><span class="term">DATASRC_DATABASE_FOUND_NXRRSET search in datasource %1 for %2/%3/%4 resulted in NXRRSET</span></dt><dd><p>
-The data returned by the database backend contained data for the given domain
-name and class, but not for the given type.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_NXRRSET_NSEC"></a><span class="term">DATASRC_DATABASE_FOUND_NXRRSET_NSEC search in datasource %1 for %2/%3/%4 resulted in RRset %5</span></dt><dd><p>
-A search in the database for RRs for the specified name, type and class has
-located RRs that match the name and class but not the type. DNSSEC information
-has been requested and returned.
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_RRSET"></a><span class="term">DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %5</span></dt><dd><p>
-The data returned by the database backend contained data for the given domain
-name, and it either matches the type or has a relevant type. The RRset that is
-returned is printed.
-</p></dd><dt><a name="DATASRC_DATABASE_ITERATE"></a><span class="term">DATASRC_DATABASE_ITERATE iterating zone %1</span></dt><dd><p>
-The program is reading the whole zone, eg. not searching for data, but going
-through each of the RRsets there.
-</p></dd><dt><a name="DATASRC_DATABASE_ITERATE_END"></a><span class="term">DATASRC_DATABASE_ITERATE_END iterating zone finished</span></dt><dd><p>
-While iterating through the zone, the program reached end of the data.
-</p></dd><dt><a name="DATASRC_DATABASE_ITERATE_NEXT"></a><span class="term">DATASRC_DATABASE_ITERATE_NEXT next RRset in zone is %1/%2</span></dt><dd><p>
-While iterating through the zone, the program extracted next RRset from it.
-The name and RRtype of the RRset is indicated in the message.
-</p></dd><dt><a name="DATASRC_DATABASE_ITERATE_TTL_MISMATCH"></a><span class="term">DATASRC_DATABASE_ITERATE_TTL_MISMATCH TTL values differ for RRs of %1/%2/%3, setting to %4</span></dt><dd><p>
-While iterating through the zone, the time to live for RRs of the given RRset
-were found to be different. This isn't allowed on the wire and is considered
-an error, so we set it to the lowest value we found (but we don't modify the
-database). The data in database should be checked and fixed.
-</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADER_END"></a><span class="term">DATASRC_DATABASE_JOURNALREADER_END %1/%2 on %3 from %4 to %5</span></dt><dd><p>
-This is a debug message indicating that the program (successfully)
-reaches the end of sequences of a zone's differences. The zone's name
-and class, database name, and the start and end serials are shown in
-the message.
-</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADER_NEXT"></a><span class="term">DATASRC_DATABASE_JOURNALREADER_NEXT %1/%2 in %3/%4 on %5</span></dt><dd><p>
-This is a debug message indicating that the program retrieves one
-difference in difference sequences of a zone and successfully converts
-it to an RRset. The zone's name and class, database name, and the
-name and RR type of the retrieved diff are shown in the message.
-</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADER_START"></a><span class="term">DATASRC_DATABASE_JOURNALREADER_START %1/%2 on %3 from %4 to %5</span></dt><dd><p>
-This is a debug message indicating that the program starts reading
-a zone's difference sequences from a database-based data source. The
-zone's name and class, database name, and the start and end serials
-are shown in the message.
-</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADR_BADDATA"></a><span class="term">DATASRC_DATABASE_JOURNALREADR_BADDATA failed to convert a diff to RRset in %1/%2 on %3 between %4 and %5: %6</span></dt><dd><p>
-This is an error message indicating that a zone's diff is broken and
-the data source library failed to convert it to a valid RRset. The
-most likely cause of this is that someone has manually modified the
-zone's diff in the database and inserted invalid data as a result.
-The zone's name and class, database name, and the start and end
-serials, and an additional detail of the error are shown in the
-message. The administrator should examine the diff in the database
-to find any invalid data and fix it.
-</p></dd><dt><a name="DATASRC_DATABASE_NO_MATCH"></a><span class="term">DATASRC_DATABASE_NO_MATCH not match for %2/%3/%4 in %1</span></dt><dd><p>
-No match (not even a wildcard) was found in the named data source for the given
-name/type/class in the data source.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_COMMIT"></a><span class="term">DATASRC_DATABASE_UPDATER_COMMIT updates committed for '%1/%2' on %3</span></dt><dd><p>
-Debug information. A set of updates to a zone has been successfully
-committed to the corresponding database backend. The zone name,
-its class and the database name are printed.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_COMMIT%20(1)"></a><span class="term">DATASRC_DATABASE_UPDATER_COMMIT (1) updates committed for '%1/%2' on %3</span></dt><dd><p>
-Debug information. A set of updates to a zone has been successfully
-committed to the corresponding database backend. The zone name,
-its class and the database name are printed.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_CREATED"></a><span class="term">DATASRC_DATABASE_UPDATER_CREATED zone updater created for '%1/%2' on %3</span></dt><dd><p>
-Debug information. A zone updater object is created to make updates to
-the shown zone on the shown backend database.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_CREATED%20(1)"></a><span class="term">DATASRC_DATABASE_UPDATER_CREATED (1) zone updater created for '%1/%2' on %3</span></dt><dd><p>
-Debug information. A zone updater object is created to make updates to
-the shown zone on the shown backend database.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_DESTROYED"></a><span class="term">DATASRC_DATABASE_UPDATER_DESTROYED zone updater destroyed for '%1/%2' on %3</span></dt><dd><p>
-Debug information. A zone updater object is destroyed, either successfully
-or after failure of, making updates to the shown zone on the shown backend
-database.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_DESTROYED%20(1)"></a><span class="term">DATASRC_DATABASE_UPDATER_DESTROYED (1) zone updater destroyed for '%1/%2' on %3</span></dt><dd><p>
-Debug information. A zone updater object is destroyed, either successfully
-or after failure of, making updates to the shown zone on the shown backend
-database.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_ROLLBACK"></a><span class="term">DATASRC_DATABASE_UPDATER_ROLLBACK zone updates roll-backed for '%1/%2' on %3</span></dt><dd><p>
-A zone updater is being destroyed without committing the changes.
-This would typically mean the update attempt was aborted due to some
-error, but may also be a bug of the application that forgets committing
-the changes. The intermediate changes made through the updater won't
-be applied to the underlying database. The zone name, its class, and
-the underlying database name are shown in the log message.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_ROLLBACK%20(1)"></a><span class="term">DATASRC_DATABASE_UPDATER_ROLLBACK (1) zone updates roll-backed for '%1/%2' on %3</span></dt><dd><p>
-A zone updater is being destroyed without committing the changes.
-This would typically mean the update attempt was aborted due to some
-error, but may also be a bug of the application that forgets committing
-the changes. The intermediate changes made through the updater won't
-be applied to the underlying database. The zone name, its class, and
-the underlying database name are shown in the log message.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL"></a><span class="term">DATASRC_DATABASE_UPDATER_ROLLBACKFAIL failed to roll back zone updates for '%1/%2' on %3: %4</span></dt><dd><p>
-A zone updater is being destroyed without committing the changes to
-the database, and attempts to rollback incomplete updates, but it
-unexpectedly fails. The higher level implementation does not expect
-it to fail, so this means either a serious operational error in the
-underlying data source (such as a system failure of a database) or
-software bug in the underlying data source implementation. In either
-case if this message is logged the administrator should carefully
-examine the underlying data source to see what exactly happens and
-whether the data is still valid. The zone name, its class, and the
-underlying database name as well as the error message thrown from the
-database module are shown in the log message.
-</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL%20(1)"></a><span class="term">DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1) failed to roll back zone updates for '%1/%2' on %3: %4</span></dt><dd><p>
-A zone updater is being destroyed without committing the changes to
-the database, and attempts to rollback incomplete updates, but it
-unexpectedly fails. The higher level implementation does not expect
-it to fail, so this means either a serious operational error in the
-underlying data source (such as a system failure of a database) or
-software bug in the underlying data source implementation. In either
-case if this message is logged the administrator should carefully
-examine the underlying data source to see what exactly happens and
-whether the data is still valid. The zone name, its class, and the
-underlying database name as well as the error message thrown from the
-database module are shown in the log message.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_ANY"></a><span class="term">DATASRC_DATABASE_WILDCARD_ANY search in datasource %1 resulted in wildcard match type ANY on %2</span></dt><dd><p>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a wildcard record matching the name of the query
-containing some RRsets was found. All the RRsets of the node are returned.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_CANCEL_NS"></a><span class="term">DATASRC_DATABASE_WILDCARD_CANCEL_NS canceled wildcard match on %3 because %2 contains NS (data source %1)</span></dt><dd><p>
-The database was queried to provide glue data and it didn't find direct match.
-It could create it from given wildcard, but matching wildcards is forbidden
-under a zone cut, which was found. Therefore the delegation will be returned
-instead.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_CANCEL_SUB"></a><span class="term">DATASRC_DATABASE_WILDCARD_CANCEL_SUB wildcard %2 can't be used to construct %3 because %4 exists in %1</span></dt><dd><p>
-The answer could be constructed using the wildcard, but the given subdomain
-exists, therefore this name is something like empty non-terminal (actually,
-from the protocol point of view, it is empty non-terminal, but the code
-discovers it differently).
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_CNAME"></a><span class="term">DATASRC_DATABASE_WILDCARD_CNAME search in datasource %1 for %2/%3/%4 found wildcard CNAME at %5, resulting in %6</span></dt><dd><p>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a CNAME RR was found at a wildcard record
-matching the name. This is returned as the result of the search.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_EMPTY"></a><span class="term">DATASRC_DATABASE_WILDCARD_EMPTY found subdomains of %2 which is a wildcard match for %3 in %1</span></dt><dd><p>
-The given wildcard matches the name being sough but it as an empty
-nonterminal (e.g. there's nothing at *.example.com but something like
-subdomain.*.example.org, do exist: so *.example.org exists in the
-namespace but has no RRs assopciated with it). This will produce NXRRSET.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_MATCH"></a><span class="term">DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %5 with RRset %6</span></dt><dd><p>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a wildcard record matching the name and type of
-the query was found. The data at this point is returned.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_NS"></a><span class="term">DATASRC_DATABASE_WILDCARD_NS search in datasource %1 for %2/%3/%4 found wildcard delegation at %5, resulting in %6</span></dt><dd><p>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, an NS RR was found at a wildcard record matching
-the name. This is returned as the result of the search.
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_NXRRSET"></a><span class="term">DATASRC_DATABASE_WILDCARD_NXRRSET search in datasource %1 for %2/%3/%4 resulted in wildcard NXRRSET at %5</span></dt><dd><p>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a matching wildcard entry was found but it did
-not contain RRs the requested type. AN NXRRSET indication is returned.
-</p></dd><dt><a name="DATASRC_DO_QUERY"></a><span class="term">DATASRC_DO_QUERY handling query for '%1/%2'</span></dt><dd><p>
-A debug message indicating that a query for the given name and RR type is being
-processed.
-</p></dd><dt><a name="DATASRC_MEM_ADD_RRSET"></a><span class="term">DATASRC_MEM_ADD_RRSET adding RRset '%1/%2' into zone '%3'</span></dt><dd><p>
-Debug information. An RRset is being added to the in-memory data source.
-</p></dd><dt><a name="DATASRC_MEM_ADD_WILDCARD"></a><span class="term">DATASRC_MEM_ADD_WILDCARD adding wildcards for '%1'</span></dt><dd><p>
-This is a debug message issued during the processing of a wildcard
-name. The internal domain name tree is scanned and some nodes are
-specially marked to allow the wildcard lookup to succeed.
-</p></dd><dt><a name="DATASRC_MEM_ADD_ZONE"></a><span class="term">DATASRC_MEM_ADD_ZONE adding zone '%1/%2'</span></dt><dd><p>
-Debug information. A zone is being added into the in-memory data source.
-</p></dd><dt><a name="DATASRC_MEM_ANY_SUCCESS"></a><span class="term">DATASRC_MEM_ANY_SUCCESS ANY query for '%1' successful</span></dt><dd><p>
-Debug information. The domain was found and an ANY type query is being answered
-by providing everything found inside the domain.
-</p></dd><dt><a name="DATASRC_MEM_CNAME"></a><span class="term">DATASRC_MEM_CNAME CNAME at the domain '%1'</span></dt><dd><p>
-Debug information. The requested domain is an alias to a different domain,
-returning the CNAME instead.
-</p></dd><dt><a name="DATASRC_MEM_CNAME_COEXIST"></a><span class="term">DATASRC_MEM_CNAME_COEXIST can't add data to CNAME in domain '%1'</span></dt><dd><p>
-This is the same problem as in MEM_CNAME_TO_NONEMPTY, but it happened the
-other way around -- adding some other data to CNAME.
-</p></dd><dt><a name="DATASRC_MEM_CNAME_TO_NONEMPTY"></a><span class="term">DATASRC_MEM_CNAME_TO_NONEMPTY can't add CNAME to domain with other data in '%1'</span></dt><dd><p>
-Someone or something tried to add a CNAME into a domain that already contains
-some other data. But the protocol forbids coexistence of CNAME with anything
-(RFC 1034, section 3.6.2). This indicates a problem with provided data.
-</p></dd><dt><a name="DATASRC_MEM_CREATE"></a><span class="term">DATASRC_MEM_CREATE creating zone '%1' in '%2' class</span></dt><dd><p>
-Debug information. A representation of a zone for the in-memory data source is
-being created.
-</p></dd><dt><a name="DATASRC_MEM_DELEG_FOUND"></a><span class="term">DATASRC_MEM_DELEG_FOUND delegation found at '%1'</span></dt><dd><p>
-Debug information. A delegation point was found above the requested record.
-</p></dd><dt><a name="DATASRC_MEM_DESTROY"></a><span class="term">DATASRC_MEM_DESTROY destroying zone '%1' in '%2' class</span></dt><dd><p>
-Debug information. A zone from in-memory data source is being destroyed.
-</p></dd><dt><a name="DATASRC_MEM_DNAME_ENCOUNTERED"></a><span class="term">DATASRC_MEM_DNAME_ENCOUNTERED encountered a DNAME</span></dt><dd><p>
-Debug information. While searching for the requested domain, a DNAME was
-encountered on the way. This may lead to redirection to a different domain and
-stop the search.
-</p></dd><dt><a name="DATASRC_MEM_DNAME_FOUND"></a><span class="term">DATASRC_MEM_DNAME_FOUND DNAME found at '%1'</span></dt><dd><p>
-Debug information. A DNAME was found instead of the requested information.
-</p></dd><dt><a name="DATASRC_MEM_DNAME_NS"></a><span class="term">DATASRC_MEM_DNAME_NS DNAME and NS can't coexist in non-apex domain '%1'</span></dt><dd><p>
-A request was made for DNAME and NS records to be put into the same
-domain which is not the apex (the top of the zone). This is forbidden
-by RFC 2672 (section 3) and indicates a problem with provided data.
-</p></dd><dt><a name="DATASRC_MEM_DOMAIN_EMPTY"></a><span class="term">DATASRC_MEM_DOMAIN_EMPTY requested domain '%1' is empty</span></dt><dd><p>
-Debug information. The requested domain exists in the tree of domains, but
-it is empty. Therefore it doesn't contain the requested resource type.
-</p></dd><dt><a name="DATASRC_MEM_DUP_RRSET"></a><span class="term">DATASRC_MEM_DUP_RRSET duplicate RRset '%1/%2'</span></dt><dd><p>
-An RRset is being inserted into in-memory data source for a second time. The
-original version must be removed first. Note that loading master files where an
-RRset is split into multiple locations is not supported yet.
-</p></dd><dt><a name="DATASRC_MEM_EXACT_DELEGATION"></a><span class="term">DATASRC_MEM_EXACT_DELEGATION delegation at the exact domain '%1'</span></dt><dd><p>
-Debug information. There's a NS record at the requested domain. This means
-this zone is not authoritative for the requested domain, but a delegation
-should be followed. The requested domain is an apex of some zone.
-</p></dd><dt><a name="DATASRC_MEM_FIND"></a><span class="term">DATASRC_MEM_FIND find '%1/%2'</span></dt><dd><p>
-Debug information. A search for the requested RRset is being started.
-</p></dd><dt><a name="DATASRC_MEM_FIND_ZONE"></a><span class="term">DATASRC_MEM_FIND_ZONE looking for zone '%1'</span></dt><dd><p>
-Debug information. A zone object for this zone is being searched for in the
-in-memory data source.
-</p></dd><dt><a name="DATASRC_MEM_LOAD"></a><span class="term">DATASRC_MEM_LOAD loading zone '%1' from file '%2'</span></dt><dd><p>
-Debug information. The content of master file is being loaded into the memory.
-</p></dd><dt><a name="DATASRC_MEM_NOT_FOUND"></a><span class="term">DATASRC_MEM_NOT_FOUND requested domain '%1' not found</span></dt><dd><p>
-Debug information. The requested domain does not exist.
-</p></dd><dt><a name="DATASRC_MEM_NS_ENCOUNTERED"></a><span class="term">DATASRC_MEM_NS_ENCOUNTERED encountered a NS</span></dt><dd><p>
-Debug information. While searching for the requested domain, a NS was
-encountered on the way (a delegation). This may lead to stop of the search.
-</p></dd><dt><a name="DATASRC_MEM_NXRRSET"></a><span class="term">DATASRC_MEM_NXRRSET no such type '%1' at '%2'</span></dt><dd><p>
-Debug information. The domain exists, but it doesn't hold any record of the
-requested type.
-</p></dd><dt><a name="DATASRC_MEM_OUT_OF_ZONE"></a><span class="term">DATASRC_MEM_OUT_OF_ZONE domain '%1' doesn't belong to zone '%2'</span></dt><dd><p>
-It was attempted to add the domain into a zone that shouldn't have it
-(eg. the domain is not subdomain of the zone origin). This indicates a
-problem with provided data.
-</p></dd><dt><a name="DATASRC_MEM_RENAME"></a><span class="term">DATASRC_MEM_RENAME renaming RRset from '%1' to '%2'</span></dt><dd><p>
-Debug information. A RRset is being generated from a different RRset (most
-probably a wildcard). So it must be renamed to whatever the user asked for. In
-fact, it's impossible to rename RRsets with our libraries, so a new one is
-created and all resource records are copied over.
-</p></dd><dt><a name="DATASRC_MEM_SINGLETON"></a><span class="term">DATASRC_MEM_SINGLETON trying to add multiple RRs for domain '%1' and type '%2'</span></dt><dd><p>
-Some resource types are singletons -- only one is allowed in a domain
-(for example CNAME or SOA). This indicates a problem with provided data.
-</p></dd><dt><a name="DATASRC_MEM_SUCCESS"></a><span class="term">DATASRC_MEM_SUCCESS query for '%1/%2' successful</span></dt><dd><p>
-Debug information. The requested record was found.
-</p></dd><dt><a name="DATASRC_MEM_SUPER_STOP"></a><span class="term">DATASRC_MEM_SUPER_STOP stopped at superdomain '%1', domain '%2' is empty</span></dt><dd><p>
-Debug information. The search stopped at a superdomain of the requested
-domain. The domain is an empty nonterminal, therefore it is treated as NXRRSET
-case (eg. the domain exists, but it doesn't have the requested record type).
-</p></dd><dt><a name="DATASRC_MEM_SWAP"></a><span class="term">DATASRC_MEM_SWAP swapping contents of two zone representations ('%1' and '%2')</span></dt><dd><p>
-Debug information. The contents of two in-memory zones are being exchanged.
-This is usual practice to do some manipulation in exception-safe manner -- the
-new data are prepared in a different zone object and when it works, they are
-swapped. The old one contains the new data and the other one can be safely
-destroyed.
-</p></dd><dt><a name="DATASRC_MEM_WILDCARD_CANCEL"></a><span class="term">DATASRC_MEM_WILDCARD_CANCEL wildcard match canceled for '%1'</span></dt><dd><p>
-Debug information. A domain above wildcard was reached, but there's something
-below the requested domain. Therefore the wildcard doesn't apply here. This
-behaviour is specified by RFC 1034, section 4.3.3
-</p></dd><dt><a name="DATASRC_MEM_WILDCARD_DNAME"></a><span class="term">DATASRC_MEM_WILDCARD_DNAME DNAME record in wildcard domain '%1'</span></dt><dd><p>
-The software refuses to load DNAME records into a wildcard domain. It isn't
-explicitly forbidden, but the protocol is ambiguous about how this should
-behave and BIND 9 refuses that as well. Please describe your intention using
-different tools.
-</p></dd><dt><a name="DATASRC_MEM_WILDCARD_NS"></a><span class="term">DATASRC_MEM_WILDCARD_NS NS record in wildcard domain '%1'</span></dt><dd><p>
-The software refuses to load NS records into a wildcard domain. It isn't
-explicitly forbidden, but the protocol is ambiguous about how this should
-behave and BIND 9 refuses that as well. Please describe your intention using
-different tools.
-</p></dd><dt><a name="DATASRC_META_ADD"></a><span class="term">DATASRC_META_ADD adding a data source into meta data source</span></dt><dd><p>
-This is a debug message issued during startup or reconfiguration.
-Another data source is being added into the meta data source.
-</p></dd><dt><a name="DATASRC_META_ADD_CLASS_MISMATCH"></a><span class="term">DATASRC_META_ADD_CLASS_MISMATCH mismatch between classes '%1' and '%2'</span></dt><dd><p>
-It was attempted to add a data source into a meta data source, but their
-classes do not match.
-</p></dd><dt><a name="DATASRC_META_REMOVE"></a><span class="term">DATASRC_META_REMOVE removing data source from meta data source</span></dt><dd><p>
-Debug information. A data source is being removed from meta data source.
-</p></dd><dt><a name="DATASRC_QUERY_ADD_NSEC"></a><span class="term">DATASRC_QUERY_ADD_NSEC adding NSEC record for '%1'</span></dt><dd><p>
-Debug information. A NSEC record covering this zone is being added.
-</p></dd><dt><a name="DATASRC_QUERY_ADD_NSEC3"></a><span class="term">DATASRC_QUERY_ADD_NSEC3 adding NSEC3 record of zone '%1'</span></dt><dd><p>
-Debug information. A NSEC3 record for the given zone is being added to the
-response message.
-</p></dd><dt><a name="DATASRC_QUERY_ADD_RRSET"></a><span class="term">DATASRC_QUERY_ADD_RRSET adding RRset '%1/%2' to message</span></dt><dd><p>
-Debug information. An RRset is being added to the response message.
-</p></dd><dt><a name="DATASRC_QUERY_ADD_SOA"></a><span class="term">DATASRC_QUERY_ADD_SOA adding SOA of '%1'</span></dt><dd><p>
-Debug information. A SOA record of the given zone is being added to the
-authority section of the response message.
-</p></dd><dt><a name="DATASRC_QUERY_AUTH_FAIL"></a><span class="term">DATASRC_QUERY_AUTH_FAIL the underlying data source failed with %1</span></dt><dd><p>
-The underlying data source failed to answer the authoritative query. 1 means
-some error, 2 is not implemented. The data source should have logged the
-specific error already.
-</p></dd><dt><a name="DATASRC_QUERY_BAD_REFERRAL"></a><span class="term">DATASRC_QUERY_BAD_REFERRAL bad referral to '%1'</span></dt><dd><p>
-The domain lives in another zone. But it is not possible to generate referral
-information for it.
-</p></dd><dt><a name="DATASRC_QUERY_CACHED"></a><span class="term">DATASRC_QUERY_CACHED data for %1/%2 found in hotspot cache</span></dt><dd><p>
-Debug information. The requested data were found in the hotspot cache, so
-no query is sent to the real data source.
-</p></dd><dt><a name="DATASRC_QUERY_CHECK_CACHE"></a><span class="term">DATASRC_QUERY_CHECK_CACHE checking hotspot cache for '%1/%2'</span></dt><dd><p>
-Debug information. While processing a query, lookup to the hotspot cache
-is being made.
-</p></dd><dt><a name="DATASRC_QUERY_COPY_AUTH"></a><span class="term">DATASRC_QUERY_COPY_AUTH copying authoritative section into message</span></dt><dd><p>
-Debug information. The whole referral information is being copied into the
-response message.
-</p></dd><dt><a name="DATASRC_QUERY_DELEGATION"></a><span class="term">DATASRC_QUERY_DELEGATION looking for delegation on the path to '%1'</span></dt><dd><p>
-Debug information. The software is trying to identify delegation points on the
-way down to the given domain.
-</p></dd><dt><a name="DATASRC_QUERY_EMPTY_CNAME"></a><span class="term">DATASRC_QUERY_EMPTY_CNAME CNAME at '%1' is empty</span></dt><dd><p>
-A CNAME chain was being followed and an entry was found that pointed
-to a domain name that had no RRsets associated with it. As a result,
-the query cannot be answered. This indicates a problem with supplied data.
-</p></dd><dt><a name="DATASRC_QUERY_EMPTY_DNAME"></a><span class="term">DATASRC_QUERY_EMPTY_DNAME the DNAME on '%1' is empty</span></dt><dd><p>
-During an attempt to synthesize CNAME from this DNAME it was discovered the
-DNAME is empty (it has no records). This indicates problem with supplied data.
-</p></dd><dt><a name="DATASRC_QUERY_FAIL"></a><span class="term">DATASRC_QUERY_FAIL query failed</span></dt><dd><p>
-Some subtask of query processing failed. The reason should have been reported
-already and a SERVFAIL will be returned to the querying system.
-</p></dd><dt><a name="DATASRC_QUERY_FOLLOW_CNAME"></a><span class="term">DATASRC_QUERY_FOLLOW_CNAME following CNAME at '%1'</span></dt><dd><p>
-Debug information. The domain is a CNAME (or a DNAME and a CNAME for it
-has already been created) and the search is following this chain.
-</p></dd><dt><a name="DATASRC_QUERY_GET_MX_ADDITIONAL"></a><span class="term">DATASRC_QUERY_GET_MX_ADDITIONAL addition of A/AAAA for '%1' requested by MX '%2'</span></dt><dd><p>
-Debug information. While processing a query, a MX record was met. It
-references the mentioned address, so A/AAAA records for it are looked up
-and put it into the additional section.
-</p></dd><dt><a name="DATASRC_QUERY_GET_NS_ADDITIONAL"></a><span class="term">DATASRC_QUERY_GET_NS_ADDITIONAL addition of A/AAAA for '%1' requested by NS '%2'</span></dt><dd><p>
-Debug information. While processing a query, a NS record was met. It
-references the mentioned address, so A/AAAA records for it are looked up
-and put it into the additional section.
-</p></dd><dt><a name="DATASRC_QUERY_GLUE_FAIL"></a><span class="term">DATASRC_QUERY_GLUE_FAIL the underlying data source failed with %1</span></dt><dd><p>
-The underlying data source failed to answer the glue query. 1 means some error,
-2 is not implemented. The data source should have logged the specific error
-already.
-</p></dd><dt><a name="DATASRC_QUERY_INVALID_OP"></a><span class="term">DATASRC_QUERY_INVALID_OP invalid query operation requested</span></dt><dd><p>
-This indicates a programmer error. The DO_QUERY was called with unknown
-operation code.
-</p></dd><dt><a name="DATASRC_QUERY_IS_AUTH"></a><span class="term">DATASRC_QUERY_IS_AUTH auth query (%1/%2)</span></dt><dd><p>
-Debug information. The last DO_QUERY is an auth query.
-</p></dd><dt><a name="DATASRC_QUERY_IS_GLUE"></a><span class="term">DATASRC_QUERY_IS_GLUE glue query (%1/%2)</span></dt><dd><p>
-Debug information. The last DO_QUERY is a query for glue addresses.
-</p></dd><dt><a name="DATASRC_QUERY_IS_NOGLUE"></a><span class="term">DATASRC_QUERY_IS_NOGLUE query for non-glue addresses (%1/%2)</span></dt><dd><p>
-Debug information. The last DO_QUERY is a query for addresses that are not
-glue.
-</p></dd><dt><a name="DATASRC_QUERY_IS_REF"></a><span class="term">DATASRC_QUERY_IS_REF query for referral (%1/%2)</span></dt><dd><p>
-Debug information. The last DO_QUERY is a query for referral information.
-</p></dd><dt><a name="DATASRC_QUERY_IS_SIMPLE"></a><span class="term">DATASRC_QUERY_IS_SIMPLE simple query (%1/%2)</span></dt><dd><p>
-Debug information. The last DO_QUERY is a simple query.
-</p></dd><dt><a name="DATASRC_QUERY_MISPLACED_TASK"></a><span class="term">DATASRC_QUERY_MISPLACED_TASK task of this type should not be here</span></dt><dd><p>
-This indicates a programming error. A task was found in the internal task
-queue, but this kind of task wasn't designed to be inside the queue (it should
-be handled right away, not queued).
-</p></dd><dt><a name="DATASRC_QUERY_MISSING_NS"></a><span class="term">DATASRC_QUERY_MISSING_NS missing NS records for '%1'</span></dt><dd><p>
-NS records should have been put into the authority section. However, this zone
-has none. This indicates problem with provided data.
-</p></dd><dt><a name="DATASRC_QUERY_MISSING_SOA"></a><span class="term">DATASRC_QUERY_MISSING_SOA the zone '%1' has no SOA</span></dt><dd><p>
-The answer should have been a negative one (eg. of nonexistence of something).
-To do so, a SOA record should be put into the authority section, but the zone
-does not have one. This indicates problem with provided data.
-</p></dd><dt><a name="DATASRC_QUERY_NOGLUE_FAIL"></a><span class="term">DATASRC_QUERY_NOGLUE_FAIL the underlying data source failed with %1</span></dt><dd><p>
-The underlying data source failed to answer the no-glue query. 1 means some
-error, 2 is not implemented. The data source should have logged the specific
-error already.
-</p></dd><dt><a name="DATASRC_QUERY_NO_CACHE_ANY_AUTH"></a><span class="term">DATASRC_QUERY_NO_CACHE_ANY_AUTH ignoring hotspot cache for ANY query (%1/%2 in %3 class)</span></dt><dd><p>
-Debug information. The hotspot cache is ignored for authoritative ANY queries
-for consistency reasons.
-</p></dd><dt><a name="DATASRC_QUERY_NO_CACHE_ANY_SIMPLE"></a><span class="term">DATASRC_QUERY_NO_CACHE_ANY_SIMPLE ignoring hotspot cache for ANY query (%1/%2 in %3 class)</span></dt><dd><p>
-Debug information. The hotspot cache is ignored for ANY queries for consistency
-reasons.
-</p></dd><dt><a name="DATASRC_QUERY_NO_DS_NSEC"></a><span class="term">DATASRC_QUERY_NO_DS_NSEC there's no DS record in the '%1' zone</span></dt><dd><p>
-An attempt to add a NSEC record into the message failed, because the zone does
-not have any DS record. This indicates problem with the provided data.
-</p></dd><dt><a name="DATASRC_QUERY_NO_DS_NSEC3"></a><span class="term">DATASRC_QUERY_NO_DS_NSEC3 there's no DS record in the '%1' zone</span></dt><dd><p>
-An attempt to add a NSEC3 record into the message failed, because the zone does
-not have any DS record. This indicates problem with the provided data.
-</p></dd><dt><a name="DATASRC_QUERY_NO_ZONE"></a><span class="term">DATASRC_QUERY_NO_ZONE no zone containing '%1' in class '%2'</span></dt><dd><p>
-Lookup of domain failed because the data have no zone that contain the
-domain. Maybe someone sent a query to the wrong server for some reason.
-</p></dd><dt><a name="DATASRC_QUERY_PROCESS"></a><span class="term">DATASRC_QUERY_PROCESS processing query '%1/%2' in the '%3' class</span></dt><dd><p>
-Debug information. A sure query is being processed now.
-</p></dd><dt><a name="DATASRC_QUERY_PROVE_NX_FAIL"></a><span class="term">DATASRC_QUERY_PROVE_NX_FAIL unable to prove nonexistence of '%1'</span></dt><dd><p>
-The user wants DNSSEC and we discovered the entity doesn't exist (either
-domain or the record). But there was an error getting NSEC/NSEC3 record
-to prove the nonexistence.
-</p></dd><dt><a name="DATASRC_QUERY_REF_FAIL"></a><span class="term">DATASRC_QUERY_REF_FAIL the underlying data source failed with %1</span></dt><dd><p>
-The underlying data source failed to answer the query for referral information.
-1 means some error, 2 is not implemented. The data source should have logged
-the specific error already.
-</p></dd><dt><a name="DATASRC_QUERY_RRSIG"></a><span class="term">DATASRC_QUERY_RRSIG unable to answer RRSIG query</span></dt><dd><p>
-The server is unable to answer a direct query for RRSIG type, but was asked
-to do so.
-</p></dd><dt><a name="DATASRC_QUERY_SIMPLE_FAIL"></a><span class="term">DATASRC_QUERY_SIMPLE_FAIL the underlying data source failed with %1</span></dt><dd><p>
-The underlying data source failed to answer the simple query. 1 means some
-error, 2 is not implemented. The data source should have logged the specific
-error already.
-</p></dd><dt><a name="DATASRC_QUERY_SYNTH_CNAME"></a><span class="term">DATASRC_QUERY_SYNTH_CNAME synthesizing CNAME from DNAME on '%1'</span></dt><dd><p>
-This is a debug message. While answering a query, a DNAME was encountered. The
-DNAME itself will be returned, along with a synthesized CNAME for clients that
-do not understand the DNAME RR.
-</p></dd><dt><a name="DATASRC_QUERY_TASK_FAIL"></a><span class="term">DATASRC_QUERY_TASK_FAIL task failed with %1</span></dt><dd><p>
-The query subtask failed. The reason should have been reported by the subtask
-already. The code is 1 for error, 2 for not implemented.
-</p></dd><dt><a name="DATASRC_QUERY_TOO_MANY_CNAMES"></a><span class="term">DATASRC_QUERY_TOO_MANY_CNAMES CNAME chain limit exceeded at '%1'</span></dt><dd><p>
-A CNAME led to another CNAME and it led to another, and so on. After 16
-CNAMEs, the software gave up. Long CNAME chains are discouraged, and this
-might possibly be a loop as well. Note that some of the CNAMEs might have
-been synthesized from DNAMEs. This indicates problem with supplied data.
-</p></dd><dt><a name="DATASRC_QUERY_UNKNOWN_RESULT"></a><span class="term">DATASRC_QUERY_UNKNOWN_RESULT unknown result of subtask</span></dt><dd><p>
-This indicates a programmer error. The answer of subtask doesn't look like
-anything known.
-</p></dd><dt><a name="DATASRC_QUERY_WILDCARD"></a><span class="term">DATASRC_QUERY_WILDCARD looking for a wildcard covering '%1'</span></dt><dd><p>
-Debug information. A direct match wasn't found, so a wildcard covering the
-domain is being looked for now.
-</p></dd><dt><a name="DATASRC_QUERY_WILDCARD_FAIL"></a><span class="term">DATASRC_QUERY_WILDCARD_FAIL error processing wildcard for '%1'</span></dt><dd><p>
-During an attempt to cover the domain by a wildcard an error happened. The
-exact kind was hopefully already reported.
-</p></dd><dt><a name="DATASRC_QUERY_WILDCARD_PROVE_NX_FAIL"></a><span class="term">DATASRC_QUERY_WILDCARD_PROVE_NX_FAIL unable to prove nonexistence of '%1' (%2)</span></dt><dd><p>
-While processing a wildcard, it wasn't possible to prove nonexistence of the
-given domain or record. The code is 1 for error and 2 for not implemented.
-</p></dd><dt><a name="DATASRC_QUERY_WILDCARD_REFERRAL"></a><span class="term">DATASRC_QUERY_WILDCARD_REFERRAL unable to find referral info for '%1' (%2)</span></dt><dd><p>
-While processing a wildcard, a referral was met. But it wasn't possible to get
-enough information for it. The code is 1 for error, 2 for not implemented.
-</p></dd><dt><a name="DATASRC_SQLITE_CLOSE"></a><span class="term">DATASRC_SQLITE_CLOSE closing SQLite database</span></dt><dd><p>
-Debug information. The SQLite data source is closing the database file.
-</p></dd><dt><a name="DATASRC_SQLITE_CONNCLOSE"></a><span class="term">DATASRC_SQLITE_CONNCLOSE Closing sqlite database</span></dt><dd><p>
-The database file is no longer needed and is being closed.
-</p></dd><dt><a name="DATASRC_SQLITE_CONNOPEN"></a><span class="term">DATASRC_SQLITE_CONNOPEN Opening sqlite database file '%1'</span></dt><dd><p>
-The database file is being opened so it can start providing data.
-</p></dd><dt><a name="DATASRC_SQLITE_CREATE"></a><span class="term">DATASRC_SQLITE_CREATE SQLite data source created</span></dt><dd><p>
-Debug information. An instance of SQLite data source is being created.
-</p></dd><dt><a name="DATASRC_SQLITE_DESTROY"></a><span class="term">DATASRC_SQLITE_DESTROY SQLite data source destroyed</span></dt><dd><p>
-Debug information. An instance of SQLite data source is being destroyed.
-</p></dd><dt><a name="DATASRC_SQLITE_DROPCONN"></a><span class="term">DATASRC_SQLITE_DROPCONN SQLite3Database is being deinitialized</span></dt><dd><p>
-The object around a database connection is being destroyed.
-</p></dd><dt><a name="DATASRC_SQLITE_ENCLOSURE"></a><span class="term">DATASRC_SQLITE_ENCLOSURE looking for zone containing '%1'</span></dt><dd><p>
-Debug information. The SQLite data source is trying to identify which zone
-should hold this domain.
-</p></dd><dt><a name="DATASRC_SQLITE_ENCLOSURE_NOT_FOUND"></a><span class="term">DATASRC_SQLITE_ENCLOSURE_NOT_FOUND no zone contains '%1'</span></dt><dd><p>
-Debug information. The last SQLITE_ENCLOSURE query was unsuccessful; there's
-no such zone in our data.
-</p></dd><dt><a name="DATASRC_SQLITE_FIND"></a><span class="term">DATASRC_SQLITE_FIND looking for RRset '%1/%2'</span></dt><dd><p>
-Debug information. The SQLite data source is looking up a resource record
-set.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDADDRS"></a><span class="term">DATASRC_SQLITE_FINDADDRS looking for A/AAAA addresses for '%1'</span></dt><dd><p>
-Debug information. The data source is looking up the addresses for given
-domain name.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDADDRS_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FINDADDRS_BAD_CLASS class mismatch looking for addresses ('%1' and '%2')</span></dt><dd><p>
-The SQLite data source was looking up A/AAAA addresses, but the data source
-contains different class than the query was for.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDEXACT"></a><span class="term">DATASRC_SQLITE_FINDEXACT looking for exact RRset '%1/%2'</span></dt><dd><p>
-Debug information. The SQLite data source is looking up an exact resource
-record.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDEXACT_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FINDEXACT_BAD_CLASS class mismatch looking for an RRset ('%1' and '%2')</span></dt><dd><p>
-The SQLite data source was looking up an exact RRset, but the data source
-contains different class than the query was for.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDREC"></a><span class="term">DATASRC_SQLITE_FINDREC looking for record '%1/%2'</span></dt><dd><p>
-Debug information. The SQLite data source is looking up records of given name
-and type in the database.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDREF"></a><span class="term">DATASRC_SQLITE_FINDREF looking for referral at '%1'</span></dt><dd><p>
-Debug information. The SQLite data source is identifying if this domain is
-a referral and where it goes.
-</p></dd><dt><a name="DATASRC_SQLITE_FINDREF_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FINDREF_BAD_CLASS class mismatch looking for referral ('%1' and '%2')</span></dt><dd><p>
-The SQLite data source was trying to identify if there's a referral. But
-it contains different class than the query was for.
-</p></dd><dt><a name="DATASRC_SQLITE_FIND_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FIND_BAD_CLASS class mismatch looking for an RRset ('%1' and '%2')</span></dt><dd><p>
-The SQLite data source was looking up an RRset, but the data source contains
-different class than the query was for.
-</p></dd><dt><a name="DATASRC_SQLITE_FIND_NSEC3"></a><span class="term">DATASRC_SQLITE_FIND_NSEC3 looking for NSEC3 in zone '%1' for hash '%2'</span></dt><dd><p>
-Debug information. We're trying to look up a NSEC3 record in the SQLite data
-source.
-</p></dd><dt><a name="DATASRC_SQLITE_FIND_NSEC3_NO_ZONE"></a><span class="term">DATASRC_SQLITE_FIND_NSEC3_NO_ZONE no such zone '%1'</span></dt><dd><p>
-The SQLite data source was asked to provide a NSEC3 record for given zone.
-But it doesn't contain that zone.
-</p></dd><dt><a name="DATASRC_SQLITE_NEWCONN"></a><span class="term">DATASRC_SQLITE_NEWCONN SQLite3Database is being initialized</span></dt><dd><p>
-A wrapper object to hold database connection is being initialized.
-</p></dd><dt><a name="DATASRC_SQLITE_OPEN"></a><span class="term">DATASRC_SQLITE_OPEN opening SQLite database '%1'</span></dt><dd><p>
-Debug information. The SQLite data source is loading an SQLite database in
-the provided file.
-</p></dd><dt><a name="DATASRC_SQLITE_PREVIOUS"></a><span class="term">DATASRC_SQLITE_PREVIOUS looking for name previous to '%1'</span></dt><dd><p>
-This is a debug message. The name given was not found, so the program
-is searching for the next name higher up the hierarchy (e.g. if
-www.example.com were queried for and not found, the software searches
-for the "previous" name, example.com).
-</p></dd><dt><a name="DATASRC_SQLITE_PREVIOUS_NO_ZONE"></a><span class="term">DATASRC_SQLITE_PREVIOUS_NO_ZONE no zone containing '%1'</span></dt><dd><p>
-The name given was not found, so the program is searching for the next
-name higher up the hierarchy (e.g. if www.example.com were queried
-for and not found, the software searches for the "previous" name,
-example.com). However, this name is not contained in any zone in the
-data source. This is an error since it indicates a problem in the earlier
-processing of the query.
-</p></dd><dt><a name="DATASRC_SQLITE_SETUP"></a><span class="term">DATASRC_SQLITE_SETUP setting up SQLite database</span></dt><dd><p>
-The database for SQLite data source was found empty. It is assumed this is the
-first run and it is being initialized with current schema. It'll still contain
-no data, but it will be ready for use.
-</p></dd><dt><a name="DATASRC_STATIC_CLASS_NOT_CH"></a><span class="term">DATASRC_STATIC_CLASS_NOT_CH static data source can handle CH class only</span></dt><dd><p>
-An error message indicating that a query requesting a RR for a class other
-that CH was sent to the static data source (which only handles CH queries).
-</p></dd><dt><a name="DATASRC_STATIC_CREATE"></a><span class="term">DATASRC_STATIC_CREATE creating the static datasource</span></dt><dd><p>
-Debug information. The static data source (the one holding stuff like
-version.bind) is being created.
-</p></dd><dt><a name="DATASRC_STATIC_FIND"></a><span class="term">DATASRC_STATIC_FIND looking for '%1/%2'</span></dt><dd><p>
-Debug information. This resource record set is being looked up in the static
-data source.
-</p></dd><dt><a name="DATASRC_UNEXPECTED_QUERY_STATE"></a><span class="term">DATASRC_UNEXPECTED_QUERY_STATE unexpected query state</span></dt><dd><p>
-This indicates a programming error. An internal task of unknown type was
-generated.
-</p></dd><dt><a name="DDNS_CC_SESSION_ERROR"></a><span class="term">DDNS_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
-There was a problem reading from the command and control channel. The
-most likely cause is that the msgq process is not running.
-</p></dd><dt><a name="DDNS_CC_SESSION_TIMEOUT_ERROR"></a><span class="term">DDNS_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</span></dt><dd><p>
-There was a problem reading a response from another module over the
-command and control channel. The most likely cause is that the
-configuration manager b10-cfgmgr is not running.
-</p></dd><dt><a name="DDNS_CONFIG_ERROR"></a><span class="term">DDNS_CONFIG_ERROR error found in configuration data: %1</span></dt><dd><p>
-The ddns process encountered an error when installing the configuration at
-startup time. Details of the error are included in the log message.
-</p></dd><dt><a name="DDNS_MODULECC_SESSION_ERROR"></a><span class="term">DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</span></dt><dd><p>
-There was a problem in the lower level module handling configuration and
-control commands. This could happen for various reasons, but the most likely
-cause is that the configuration database contains a syntax error and ddns
-failed to start at initialization. A detailed error message from the module
-will also be displayed.
-</p></dd><dt><a name="DDNS_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
-The ddns process received a shutdown command from the command channel
-and will now shut down.
-</p></dd><dt><a name="DDNS_RUNNING"></a><span class="term">DDNS_RUNNING ddns server is running and listening for updates</span></dt><dd><p>
-The ddns process has successfully started and is now ready to receive commands
-and updates.
-</p></dd><dt><a name="DDNS_SHUTDOWN"></a><span class="term">DDNS_SHUTDOWN ddns server shutting down</span></dt><dd><p>
-The ddns process is shutting down. It will no longer listen for new commands
-or updates. Any command or update that is being addressed at this moment will
-be completed, after which the process will exit.
-</p></dd><dt><a name="DDNS_STOPPED"></a><span class="term">DDNS_STOPPED ddns server has stopped</span></dt><dd><p>
-The ddns process has successfully stopped and is no longer listening for or
-handling commands or updates, and will now exit.
-</p></dd><dt><a name="DDNS_STOPPED_BY_KEYBOARD"></a><span class="term">DDNS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the ddns process. The
-process will now shut down.
-</p></dd><dt><a name="DDNS_UNCAUGHT_EXCEPTION"></a><span class="term">DDNS_UNCAUGHT_EXCEPTION uncaught exception of type %1: %2</span></dt><dd><p>
-The b10-ddns process encountered an uncaught exception and will now shut
-down. This is indicative of a programming error and should not happen under
-normal circumstances. The exception type and message are printed.
-</p></dd><dt><a name="LIBXFRIN_DIFFERENT_TTL"></a><span class="term">LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (%1, %2) on %3/%4/%5. Adjusting %2 -> %1.</span></dt><dd><p>
-The xfrin module received an update containing multiple rdata changes for the
-same RRset. But the TTLs of these don't match each other. As we combine them
-together, the latter one gets overwritten to the earlier one in the sequence.
-</p></dd><dt><a name="LIBXFRIN_NO_JOURNAL"></a><span class="term">LIBXFRIN_NO_JOURNAL disabled journaling for updates to %1 on %2</span></dt><dd><p>
-An attempt was made to create a Diff object with journaling enabled, but
-the underlying data source didn't support journaling (while still allowing
-updates) and so the created object has it disabled. At a higher level this
-means that the updates will be applied to the zone but subsequent IXFR requests
-will result in a full zone transfer (i.e., an AXFR-style IXFR). Unless the
-overhead of the full transfer is an issue this message can be ignored;
-otherwise you may want to check why the journaling wasn't allowed on the
-data source and either fix the issue or use a different type of data source.
-</p></dd><dt><a name="LOGIMPL_ABOVE_MAX_DEBUG"></a><span class="term">LOGIMPL_ABOVE_MAX_DEBUG debug level of %1 is too high and will be set to the maximum of %2</span></dt><dd><p>
-A message from the interface to the underlying logger implementation reporting
-that the debug level (as set by an internally-created string DEBUGn, where n
-is an integer, e.g. DEBUG22) is above the maximum allowed value and has
-been reduced to that value. The appearance of this message may indicate
-a programming error - please submit a bug report.
-</p></dd><dt><a name="LOGIMPL_BAD_DEBUG_STRING"></a><span class="term">LOGIMPL_BAD_DEBUG_STRING debug string '%1' has invalid format</span></dt><dd><p>
-A message from the interface to the underlying logger implementation
-reporting that an internally-created string used to set the debug level
-is not of the correct format (it should be of the form DEBUGn, where n
-is an integer, e.g. DEBUG22). The appearance of this message indicates
-a programming error - please submit a bug report.
-</p></dd><dt><a name="LOGIMPL_BELOW_MIN_DEBUG"></a><span class="term">LOGIMPL_BELOW_MIN_DEBUG debug level of %1 is too low and will be set to the minimum of %2</span></dt><dd><p>
-A message from the interface to the underlying logger implementation reporting
-that the debug level (as set by an internally-created string DEBUGn, where n
-is an integer, e.g. DEBUG22) is below the minimum allowed value and has
-been increased to that value. The appearance of this message may indicate
-a programming error - please submit a bug report.
-</p></dd><dt><a name="LOG_BAD_DESTINATION"></a><span class="term">LOG_BAD_DESTINATION unrecognized log destination: %1</span></dt><dd><p>
-A logger destination value was given that was not recognized. The
-destination should be one of "console", "file", or "syslog".
-</p></dd><dt><a name="LOG_BAD_SEVERITY"></a><span class="term">LOG_BAD_SEVERITY unrecognized log severity: %1</span></dt><dd><p>
-A logger severity value was given that was not recognized. The severity
-should be one of "DEBUG", "INFO", "WARN", "ERROR", "FATAL" or "NONE".
-</p></dd><dt><a name="LOG_BAD_STREAM"></a><span class="term">LOG_BAD_STREAM bad log console output stream: %1</span></dt><dd><p>
-Logging has been configured so that output is written to the terminal
-(console) but the stream on which it is to be written is not recognised.
-Allowed values are "stdout" and "stderr".
-</p></dd><dt><a name="LOG_DUPLICATE_MESSAGE_ID"></a><span class="term">LOG_DUPLICATE_MESSAGE_ID duplicate message ID (%1) in compiled code</span></dt><dd><p>
-During start-up, BIND 10 detected that the given message identification
-had been defined multiple times in the BIND 10 code. This indicates a
-programming error; please submit a bug report.
-</p></dd><dt><a name="LOG_DUPLICATE_NAMESPACE"></a><span class="term">LOG_DUPLICATE_NAMESPACE line %1: duplicate $NAMESPACE directive found</span></dt><dd><p>
-When reading a message file, more than one $NAMESPACE directive was found.
-(This directive is used to set a C++ namespace when generating header
-files during software development.) Such a condition is regarded as an
-error and the read will be abandoned.
-</p></dd><dt><a name="LOG_INPUT_OPEN_FAIL"></a><span class="term">LOG_INPUT_OPEN_FAIL unable to open message file %1 for input: %2</span></dt><dd><p>
-The program was not able to open the specified input message file for
-the reason given.
-</p></dd><dt><a name="LOG_INVALID_MESSAGE_ID"></a><span class="term">LOG_INVALID_MESSAGE_ID line %1: invalid message identification '%2'</span></dt><dd><p>
-An invalid message identification (ID) has been found during the read of
-a message file. Message IDs should comprise only alphanumeric characters
-and the underscore, and should not start with a digit.
-</p></dd><dt><a name="LOG_NAMESPACE_EXTRA_ARGS"></a><span class="term">LOG_NAMESPACE_EXTRA_ARGS line %1: $NAMESPACE directive has too many arguments</span></dt><dd><p>
-The $NAMESPACE directive in a message file takes a single argument, a
-namespace in which all the generated symbol names are placed. This error
-is generated when the compiler finds a $NAMESPACE directive with more
-than one argument.
-</p></dd><dt><a name="LOG_NAMESPACE_INVALID_ARG"></a><span class="term">LOG_NAMESPACE_INVALID_ARG line %1: $NAMESPACE directive has an invalid argument ('%2')</span></dt><dd><p>
-The $NAMESPACE argument in a message file should be a valid C++ namespace.
-This message is output if the simple check on the syntax of the string
-carried out by the reader fails.
-</p></dd><dt><a name="LOG_NAMESPACE_NO_ARGS"></a><span class="term">LOG_NAMESPACE_NO_ARGS line %1: no arguments were given to the $NAMESPACE directive</span></dt><dd><p>
-The $NAMESPACE directive in a message file takes a single argument,
-a C++ namespace in which all the generated symbol names are placed.
-This error is generated when the compiler finds a $NAMESPACE directive
-with no arguments.
-</p></dd><dt><a name="LOG_NO_MESSAGE_ID"></a><span class="term">LOG_NO_MESSAGE_ID line %1: message definition line found without a message ID</span></dt><dd><p>
-Within a message file, message are defined by lines starting with a "%".
-The rest of the line should comprise the message ID and text describing
-the message. This error indicates the message compiler found a line in
-the message file comprising just the "%" and nothing else.
-</p></dd><dt><a name="LOG_NO_MESSAGE_TEXT"></a><span class="term">LOG_NO_MESSAGE_TEXT line %1: line found containing a message ID ('%2') and no text</span></dt><dd><p>
-Within a message file, message are defined by lines starting with a "%".
-The rest of the line should comprise the message ID and text describing
-the message. This error indicates the message compiler found a line
-in the message file comprising just the "%" and message identification,
-but no text.
-</p></dd><dt><a name="LOG_NO_SUCH_MESSAGE"></a><span class="term">LOG_NO_SUCH_MESSAGE could not replace message text for '%1': no such message</span></dt><dd><p>
-During start-up a local message file was read. A line with the listed
-message identification was found in the file, but the identification is
-not one contained in the compiled-in message dictionary. This message
-may appear a number of times in the file, once for every such unknown
-message identification.
-</p><p>
-There may be several reasons why this message may appear:
-</p><p>
-- The message ID has been mis-spelled in the local message file.
-</p><p>
-- The program outputting the message may not use that particular message
-(e.g. it originates in a module not used by the program.)
-</p><p>
-- The local file was written for an earlier version of the BIND 10 software
-and the later version no longer generates that message.
-</p><p>
-Whatever the reason, there is no impact on the operation of BIND 10.
-</p></dd><dt><a name="LOG_OPEN_OUTPUT_FAIL"></a><span class="term">LOG_OPEN_OUTPUT_FAIL unable to open %1 for output: %2</span></dt><dd><p>
-Originating within the logging code, the program was not able to open
-the specified output file for the reason given.
-</p></dd><dt><a name="LOG_PREFIX_EXTRA_ARGS"></a><span class="term">LOG_PREFIX_EXTRA_ARGS line %1: $PREFIX directive has too many arguments</span></dt><dd><p>
-Within a message file, the $PREFIX directive takes a single argument,
-a prefix to be added to the symbol names when a C++ file is created.
-This error is generated when the compiler finds a $PREFIX directive with
-more than one argument.
-</p><p>
-Note: the $PREFIX directive is deprecated and will be removed in a future
-version of BIND 10.
-</p></dd><dt><a name="LOG_PREFIX_INVALID_ARG"></a><span class="term">LOG_PREFIX_INVALID_ARG line %1: $PREFIX directive has an invalid argument ('%2')</span></dt><dd><p>
-Within a message file, the $PREFIX directive takes a single argument,
-a prefix to be added to the symbol names when a C++ file is created.
-As such, it must adhere to restrictions on C++ symbol names (e.g. may
-only contain alphanumeric characters or underscores, and may nor start
-with a digit). A $PREFIX directive was found with an argument (given
-in the message) that violates those restrictions.
-</p><p>
-Note: the $PREFIX directive is deprecated and will be removed in a future
-version of BIND 10.
-</p></dd><dt><a name="LOG_READING_LOCAL_FILE"></a><span class="term">LOG_READING_LOCAL_FILE reading local message file %1</span></dt><dd><p>
-This is an informational message output by BIND 10 when it starts to read
-a local message file. (A local message file may replace the text of
-one of more messages; the ID of the message will not be changed though.)
-</p></dd><dt><a name="LOG_READ_ERROR"></a><span class="term">LOG_READ_ERROR error reading from message file %1: %2</span></dt><dd><p>
-The specified error was encountered reading from the named message file.
-</p></dd><dt><a name="LOG_UNRECOGNISED_DIRECTIVE"></a><span class="term">LOG_UNRECOGNISED_DIRECTIVE line %1: unrecognised directive '%2'</span></dt><dd><p>
-Within a message file, a line starting with a dollar symbol was found
-(indicating the presence of a directive) but the first word on the line
-(shown in the message) was not recognised.
-</p></dd><dt><a name="LOG_WRITE_ERROR"></a><span class="term">LOG_WRITE_ERROR error writing to %1: %2</span></dt><dd><p>
-The specified error was encountered by the message compiler when writing
-to the named output file.
-</p></dd><dt><a name="NOTIFY_OUT_DATASRC_ACCESS_FAILURE"></a><span class="term">NOTIFY_OUT_DATASRC_ACCESS_FAILURE failed to get access to data source: %1</span></dt><dd><p>
-notify_out failed to get access to one of configured data sources.
-Detailed error is shown in the log message. This can be either a
-configuration error or installation setup failure.
-</p></dd><dt><a name="NOTIFY_OUT_DATASRC_ZONE_NOT_FOUND"></a><span class="term">NOTIFY_OUT_DATASRC_ZONE_NOT_FOUND Zone %1 is not found</span></dt><dd><p>
-notify_out attempted to get slave information of a zone but the zone
-isn't found in the expected data source. This shouldn't happen,
-because notify_out first identifies a list of available zones before
-this process. So this means some critical inconsistency in the data
-source or software bug.
-</p></dd><dt><a name="NOTIFY_OUT_INVALID_ADDRESS"></a><span class="term">NOTIFY_OUT_INVALID_ADDRESS invalid address %1#%2: %3</span></dt><dd><p>
-The notify_out library tried to send a notify message to the given
-address, but it appears to be an invalid address. The configuration
-for secondary nameservers might contain a typographic error, or a
-different BIND 10 module has forgotten to validate its data before
-sending this module a notify command. As such, this should normally
-not happen, and points to an oversight in a different module.
-</p></dd><dt><a name="NOTIFY_OUT_REPLY_BAD_OPCODE"></a><span class="term">NOTIFY_OUT_REPLY_BAD_OPCODE bad opcode in notify reply from %1#%2: %3</span></dt><dd><p>
-The notify_out library sent a notify message to the nameserver at
-the given address, but the response did not have the opcode set to
-NOTIFY. The opcode in the response is printed. Since there was a
-response, no more notifies will be sent to this server for this
-notification event.
-</p></dd><dt><a name="NOTIFY_OUT_REPLY_BAD_QID"></a><span class="term">NOTIFY_OUT_REPLY_BAD_QID bad QID in notify reply from %1#%2: got %3, should be %4</span></dt><dd><p>
-The notify_out library sent a notify message to the nameserver at
-the given address, but the query id in the response does not match
-the one we sent. Since there was a response, no more notifies will
-be sent to this server for this notification event.
-</p></dd><dt><a name="NOTIFY_OUT_REPLY_BAD_QUERY_NAME"></a><span class="term">NOTIFY_OUT_REPLY_BAD_QUERY_NAME bad query name in notify reply from %1#%2: got %3, should be %4</span></dt><dd><p>
-The notify_out library sent a notify message to the nameserver at
-the given address, but the query name in the response does not match
-the one we sent. Since there was a response, no more notifies will
-be sent to this server for this notification event.
-</p></dd><dt><a name="NOTIFY_OUT_REPLY_QR_NOT_SET"></a><span class="term">NOTIFY_OUT_REPLY_QR_NOT_SET QR flags set to 0 in reply to notify from %1#%2</span></dt><dd><p>
-The notify_out library sent a notify message to the namesever at the
-given address, but the reply did not have the QR bit set to one.
-Since there was a response, no more notifies will be sent to this
-server for this notification event.
-</p></dd><dt><a name="NOTIFY_OUT_REPLY_UNCAUGHT_EXCEPTION"></a><span class="term">NOTIFY_OUT_REPLY_UNCAUGHT_EXCEPTION uncaught exception: %1</span></dt><dd><p>
-There was an uncaught exception in the handling of a notify reply
-message, either in the message parser, or while trying to extract data
-from the parsed message. The error is printed, and notify_out will
-treat the response as a bad message, but this does point to a
-programming error, since all exceptions should have been caught
-explicitly. Please file a bug report. Since there was a response,
-no more notifies will be sent to this server for this notification
-event.
-</p></dd><dt><a name="NOTIFY_OUT_RETRY_EXCEEDED"></a><span class="term">NOTIFY_OUT_RETRY_EXCEEDED notify to %1#%2: number of retries (%3) exceeded</span></dt><dd><p>
-The maximum number of retries for the notify target has been exceeded.
-Either the address of the secondary nameserver is wrong, or it is not
-responding.
-</p></dd><dt><a name="NOTIFY_OUT_SENDING_NOTIFY"></a><span class="term">NOTIFY_OUT_SENDING_NOTIFY sending notify to %1#%2</span></dt><dd><p>
-A notify message is sent to the secondary nameserver at the given
-address.
-</p></dd><dt><a name="NOTIFY_OUT_SOCKET_ERROR"></a><span class="term">NOTIFY_OUT_SOCKET_ERROR socket error sending notify to %1#%2: %3</span></dt><dd><p>
-There was a network error while trying to send a notify message to
-the given address. The address might be unreachable. The socket
-error is printed and should provide more information.
-</p></dd><dt><a name="NOTIFY_OUT_SOCKET_RECV_ERROR"></a><span class="term">NOTIFY_OUT_SOCKET_RECV_ERROR socket error reading notify reply from %1#%2: %3</span></dt><dd><p>
-There was a network error while trying to read a notify reply
-message from the given address. The socket error is printed and should
-provide more information.
-</p></dd><dt><a name="NOTIFY_OUT_TIMEOUT"></a><span class="term">NOTIFY_OUT_TIMEOUT retry notify to %1#%2</span></dt><dd><p>
-The notify message to the given address (noted as address#port) has
-timed out, and the message will be resent until the max retry limit
-is reached.
-</p></dd><dt><a name="NOTIFY_OUT_ZONE_BAD_SOA"></a><span class="term">NOTIFY_OUT_ZONE_BAD_SOA Zone %1 is invalid in terms of SOA</span></dt><dd><p>
-This is a warning issued when the notify_out module finds a zone that
-doesn't have an SOA RR or has multiple SOA RRs. Notify message won't
-be sent to such a zone.
-</p></dd><dt><a name="NOTIFY_OUT_ZONE_NO_NS"></a><span class="term">NOTIFY_OUT_ZONE_NO_NS Zone %1 doesn't have NS RR</span></dt><dd><p>
-This is a warning issued when the notify_out module finds a zone that
-doesn't have an NS RR. Notify message won't be sent to such a zone.
-</p></dd><dt><a name="NSAS_EMPTY_RESPONSE"></a><span class="term">NSAS_EMPTY_RESPONSE response to query for %1 returned an empty answer section</span></dt><dd><p>
-The NSAS (nameserver address store - part of the resolver) made a query
-for information it needed. The query completed successfully but the
-answer section in the response was empty.
-</p></dd><dt><a name="NSAS_ERROR_RESPONSE"></a><span class="term">NSAS_ERROR_RESPONSE error response of %1 returned in query for %2</span></dt><dd><p>
-The NSAS (nameserver address store - part of the resolver) made a query
-for information it needed. The query completed successfully but the
-RCODE in the response was something other than NOERROR.
-</p></dd><dt><a name="NSAS_FIND_NS_ADDRESS"></a><span class="term">NSAS_FIND_NS_ADDRESS asking resolver to obtain A and AAAA records for %1</span></dt><dd><p>
-A debug message issued when the NSAS (nameserver address store - part
-of the resolver) is making a callback into the resolver to retrieve the
-address records for the specified nameserver.
-</p></dd><dt><a name="NSAS_FOUND_ADDRESS"></a><span class="term">NSAS_FOUND_ADDRESS found address %1 for %2</span></dt><dd><p>
-A debug message issued when the NSAS (nameserver address store - part
-of the resolver) has retrieved the given address for the specified
-nameserver through an external query.
-</p></dd><dt><a name="NSAS_LOOKUP_CANCEL"></a><span class="term">NSAS_LOOKUP_CANCEL lookup for zone %1 has been canceled</span></dt><dd><p>
-A debug message issued when an NSAS (nameserver address store - part of
-the resolver) lookup for a zone has been canceled.
-</p></dd><dt><a name="NSAS_NS_LOOKUP_FAIL"></a><span class="term">NSAS_NS_LOOKUP_FAIL failed to lookup any %1 for %2</span></dt><dd><p>
-A debug message issued when the NSAS (nameserver address store - part of
-the resolver) has been unable to retrieve the specified resource record
-for the specified nameserver. This is not necessarily a problem - the
-nameserver may be unreachable, in which case the NSAS will try other
-nameservers in the zone.
-</p></dd><dt><a name="NSAS_NULL_RESPONSE"></a><span class="term">NSAS_NULL_RESPONSE got null message in success callback for query for %1</span></dt><dd><p>
-The NSAS (nameserver address store - part of the resolver) made a query
-for information it needed. The query completed successfully, but the
-message passed to the callback was null.
-</p><p>
-This message indicates an internal error in the NSAS. Please raise a
-bug report.
-</p></dd><dt><a name="NSAS_SEARCH_ZONE_NS"></a><span class="term">NSAS_SEARCH_ZONE_NS searching NSAS for nameservers for zone %1</span></dt><dd><p>
-A debug message output when a call is made to the NSAS (nameserver
-address store - part of the resolver) to obtain the nameservers for
-the specified zone.
-</p></dd><dt><a name="NSAS_UPDATE_RTT"></a><span class="term">NSAS_UPDATE_RTT update RTT for %1: was %2 ms, is now %3 ms</span></dt><dd><p>
-A NSAS (nameserver address store - part of the resolver) debug message
-reporting the update of a round-trip time (RTT) for a query made to the
-specified nameserver. The RTT has been updated using the value given
-and the new RTT is displayed. (The RTT is subject to a calculation that
-damps out sudden changes. As a result, the new RTT used by the NSAS in
-future decisions of which nameserver to use is not necessarily equal to
-the RTT reported.)
-</p></dd><dt><a name="NSAS_WRONG_ANSWER"></a><span class="term">NSAS_WRONG_ANSWER queried for %1 RR of type/class %2/%3, received response %4/%5</span></dt><dd><p>
-A NSAS (nameserver address store - part of the resolver) made a query for
-a resource record of a particular type and class, but instead received
-an answer with a different given type and class.
-</p><p>
-This message indicates an internal error in the NSAS. Please raise a
-bug report.
-</p></dd><dt><a name="RESLIB_ANSWER"></a><span class="term">RESLIB_ANSWER answer received in response to query for <%1></span></dt><dd><p>
-A debug message reporting that an answer has been received to an upstream
-query for the specified question. Previous debug messages will have
-indicated the server to which the question was sent.
-</p></dd><dt><a name="RESLIB_CNAME"></a><span class="term">RESLIB_CNAME CNAME received in response to query for <%1></span></dt><dd><p>
-A debug message recording that CNAME response has been received to an
-upstream query for the specified question. Previous debug messages will
-have indicated the server to which the question was sent.
-</p></dd><dt><a name="RESLIB_DEEPEST"></a><span class="term">RESLIB_DEEPEST did not find <%1> in cache, deepest delegation found is %2</span></dt><dd><p>
-A debug message, a cache lookup did not find the specified <name,
-class, type> tuple in the cache; instead, the deepest delegation found
-is indicated.
-</p></dd><dt><a name="RESLIB_EMPTY_RESPONSE"></a><span class="term">RESLIB_EMPTY_RESPONSE empty response received to query for <%1></span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver did not contain anything in the answer or authority sections,
-although in all other respects it was a valid response. A SERVFAIL will
-be returned to the system making the original query.
-</p></dd><dt><a name="RESLIB_ERROR_RESPONSE"></a><span class="term">RESLIB_ERROR_RESPONSE unspecified error received in response to query for <%1></span></dt><dd><p>
-A debug message, the response to the specified query to an upstream
-nameserver indicated that the response was classified as an erroneous
-response, but that the nature of the error cannot be identified.
-A SERVFAIL will be returned to the system making the original query.
-</p></dd><dt><a name="RESLIB_EXTRADATA_RESPONSE"></a><span class="term">RESLIB_EXTRADATA_RESPONSE extra data in response to query for <%1></span></dt><dd><p>
-A debug message indicating that the response to the specified query
-from an upstream nameserver contained too much data. This can happen if
-an ANY query was sent and the answer section in the response contained
-multiple RRs with different names. A SERVFAIL will be returned to the
-system making the original query.
-</p></dd><dt><a name="RESLIB_FOLLOW_CNAME"></a><span class="term">RESLIB_FOLLOW_CNAME following CNAME chain to <%1></span></dt><dd><p>
-A debug message, a CNAME response was received and another query is
-being issued for the <name, class, type> tuple.
-</p></dd><dt><a name="RESLIB_INVALID_NAMECLASS_RESPONSE"></a><span class="term">RESLIB_INVALID_NAMECLASS_RESPONSE invalid name or class in response to query for <%1></span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) contained either
-an answer not matching the query name or an answer having a different
-class to that queried for. A SERVFAIL will be returned to the system
-making the original query.
-</p></dd><dt><a name="RESLIB_INVALID_QNAME_RESPONSE"></a><span class="term">RESLIB_INVALID_QNAME_RESPONSE invalid name or class in response to query for <%1></span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) contained a name
-in the question section that did not match that of the query. A SERVFAIL
-will be returned to the system making the original query.
-</p></dd><dt><a name="RESLIB_INVALID_TYPE_RESPONSE"></a><span class="term">RESLIB_INVALID_TYPE_RESPONSE invalid name or class in response to query for <%1></span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) contained an
-invalid type field. A SERVFAIL will be returned to the system making
-the original query.
-</p></dd><dt><a name="RESLIB_LONG_CHAIN"></a><span class="term">RESLIB_LONG_CHAIN CNAME received in response to query for <%1>: CNAME chain length exceeded</span></dt><dd><p>
-A debug message recording that a CNAME response has been received to an upstream
-query for the specified question (Previous debug messages will have indicated
-the server to which the question was sent). However, receipt of this CNAME
-has meant that the resolver has exceeded the CNAME chain limit (a CNAME chain
-is where on CNAME points to another) and so an error is being returned.
-</p></dd><dt><a name="RESLIB_MULTIPLE_CLASS_RESPONSE"></a><span class="term">RESLIB_MULTIPLE_CLASS_RESPONSE response to query for <%1> contained multiple RRsets with different classes</span></dt><dd><p>
-A debug message reporting that the response to an upstream query for
-the specified name contained multiple RRsets in the answer and not all
-were of the same class. This is a violation of the standard and so a
-SERVFAIL will be returned.
-</p></dd><dt><a name="RESLIB_NOTSINGLE_RESPONSE"></a><span class="term">RESLIB_NOTSINGLE_RESPONSE response to query for <%1> was not a response</span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver was a CNAME that had mutiple RRs in the RRset. This is
-an invalid response according to the standards so a SERVFAIL will be
-returned to the system making the original query.
-</p></dd><dt><a name="RESLIB_NOT_ONE_QNAME_RESPONSE"></a><span class="term">RESLIB_NOT_ONE_QNAME_RESPONSE not one question in response to query for <%1></span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) did not contain
-one name in the question section as required by the standard. A SERVFAIL
-will be returned to the system making the original query.
-</p></dd><dt><a name="RESLIB_NOT_RESPONSE"></a><span class="term">RESLIB_NOT_RESPONSE response to query for <%1> was not a response</span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) did not have the QR
-bit set (thus indicating that the packet was a query, not a response).
-A SERVFAIL will be returned to the system making the original query.
-</p></dd><dt><a name="RESLIB_NO_NS_RRSET"></a><span class="term">RESLIB_NO_NS_RRSET no NS RRSet in referral response received to query for <%1></span></dt><dd><p>
-A debug message, this indicates that a response was received for the specified
-query and was categorized as a referral. However, the received message did
-not contain any NS RRsets. This may indicate a programming error in the
-response classification code.
-</p></dd><dt><a name="RESLIB_NSAS_LOOKUP"></a><span class="term">RESLIB_NSAS_LOOKUP looking up nameserver for zone %1 in the NSAS</span></dt><dd><p>
-A debug message, the RunningQuery object is querying the NSAS for the
-nameservers for the specified zone.
-</p></dd><dt><a name="RESLIB_NXDOM_NXRR"></a><span class="term">RESLIB_NXDOM_NXRR NXDOMAIN/NXRRSET received in response to query for <%1></span></dt><dd><p>
-A debug message recording that either a NXDOMAIN or an NXRRSET response has
-been received to an upstream query for the specified question. Previous debug
-messages will have indicated the server to which the question was sent.
-</p></dd><dt><a name="RESLIB_OPCODE_RESPONSE"></a><span class="term">RESLIB_OPCODE_RESPONSE response to query for <%1> did not have query opcode</span></dt><dd><p>
-A debug message, the response to the specified query from an upstream
-nameserver was a response that did not have the opcode set to that of
-a query. According to the standards, this is an invalid response to
-the query that was made, so a SERVFAIL will be returned to the system
-making the original query.
-</p></dd><dt><a name="RESLIB_PROTOCOL"></a><span class="term">RESLIB_PROTOCOL protocol error in answer for %1: %3</span></dt><dd><p>
-A debug message indicating that a protocol error was received. As there
-are no retries left, an error will be reported.
-</p></dd><dt><a name="RESLIB_PROTOCOL_RETRY"></a><span class="term">RESLIB_PROTOCOL_RETRY protocol error in answer for %1: %2 (retries left: %3)</span></dt><dd><p>
-A debug message indicating that a protocol error was received and that
-the resolver is repeating the query to the same nameserver. After this
-repeated query, there will be the indicated number of retries left.
-</p></dd><dt><a name="RESLIB_RCODE_ERROR"></a><span class="term">RESLIB_RCODE_ERROR response to query for <%1> returns RCODE of %2</span></dt><dd><p>
-A debug message, the response to the specified query indicated an error
-that is not covered by a specific code path. A SERVFAIL will be returned.
-</p></dd><dt><a name="RESLIB_RECQ_CACHE_FIND"></a><span class="term">RESLIB_RECQ_CACHE_FIND found <%1> in the cache (resolve() instance %2)</span></dt><dd><p>
-This is a debug message and indicates that a RecursiveQuery object found the
-the specified <name, class, type> tuple in the cache. The instance number
-at the end of the message indicates which of the two resolve() methods has
-been called.
-</p></dd><dt><a name="RESLIB_RECQ_CACHE_NO_FIND"></a><span class="term">RESLIB_RECQ_CACHE_NO_FIND did not find <%1> in the cache, starting RunningQuery (resolve() instance %2)</span></dt><dd><p>
-This is a debug message and indicates that the look in the cache made by the
-RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery
-object has been created to resolve the question. The instance number at
-the end of the message indicates which of the two resolve() methods has
-been called.
-</p></dd><dt><a name="RESLIB_REFERRAL"></a><span class="term">RESLIB_REFERRAL referral received in response to query for <%1></span></dt><dd><p>
-A debug message recording that a referral response has been received to an
-upstream query for the specified question. Previous debug messages will
-have indicated the server to which the question was sent.
-</p></dd><dt><a name="RESLIB_REFER_ZONE"></a><span class="term">RESLIB_REFER_ZONE referred to zone %1</span></dt><dd><p>
-A debug message indicating that the last referral message was to the specified
-zone.
-</p></dd><dt><a name="RESLIB_RESOLVE"></a><span class="term">RESLIB_RESOLVE asked to resolve <%1> (resolve() instance %2)</span></dt><dd><p>
-A debug message, the RecursiveQuery::resolve method has been called to resolve
-the specified <name, class, type> tuple. The first action will be to lookup
-the specified tuple in the cache. The instance number at the end of the
-message indicates which of the two resolve() methods has been called.
-</p></dd><dt><a name="RESLIB_RRSET_FOUND"></a><span class="term">RESLIB_RRSET_FOUND found single RRset in the cache when querying for <%1> (resolve() instance %2)</span></dt><dd><p>
-A debug message, indicating that when RecursiveQuery::resolve queried the
-cache, a single RRset was found which was put in the answer. The instance
-number at the end of the message indicates which of the two resolve()
-methods has been called.
-</p></dd><dt><a name="RESLIB_RTT"></a><span class="term">RESLIB_RTT round-trip time of last query calculated as %1 ms</span></dt><dd><p>
-A debug message giving the round-trip time of the last query and response.
-</p></dd><dt><a name="RESLIB_RUNQ_CACHE_FIND"></a><span class="term">RESLIB_RUNQ_CACHE_FIND found <%1> in the cache</span></dt><dd><p>
-This is a debug message and indicates that a RunningQuery object found
-the specified <name, class, type> tuple in the cache.
-</p></dd><dt><a name="RESLIB_RUNQ_CACHE_LOOKUP"></a><span class="term">RESLIB_RUNQ_CACHE_LOOKUP looking up up <%1> in the cache</span></dt><dd><p>
-This is a debug message and indicates that a RunningQuery object has made
-a call to its doLookup() method to look up the specified <name, class, type>
-tuple, the first action of which will be to examine the cache.
-</p></dd><dt><a name="RESLIB_RUNQ_FAIL"></a><span class="term">RESLIB_RUNQ_FAIL failure callback - nameservers are unreachable</span></dt><dd><p>
-A debug message indicating that a RunningQuery's failure callback has been
-called because all nameservers for the zone in question are unreachable.
-</p></dd><dt><a name="RESLIB_RUNQ_SUCCESS"></a><span class="term">RESLIB_RUNQ_SUCCESS success callback - sending query to %1</span></dt><dd><p>
-A debug message indicating that a RunningQuery's success callback has been
-called because a nameserver has been found, and that a query is being sent
-to the specified nameserver.
-</p></dd><dt><a name="RESLIB_TCP_TRUNCATED"></a><span class="term">RESLIB_TCP_TRUNCATED TCP response to query for %1 was truncated</span></dt><dd><p>
-This is a debug message logged when a response to the specified query to an
-upstream nameserver returned a response with the TC (truncation) bit set. This
-is treated as an error by the code.
-</p></dd><dt><a name="RESLIB_TEST_SERVER"></a><span class="term">RESLIB_TEST_SERVER setting test server to %1(%2)</span></dt><dd><p>
-This is a warning message only generated in unit tests. It indicates
-that all upstream queries from the resolver are being routed to the
-specified server, regardless of the address of the nameserver to which
-the query would normally be routed. If seen during normal operation,
-please submit a bug report.
-</p></dd><dt><a name="RESLIB_TEST_UPSTREAM"></a><span class="term">RESLIB_TEST_UPSTREAM sending upstream query for <%1> to test server at %2</span></dt><dd><p>
-This is a debug message and should only be seen in unit tests. A query for
-the specified <name, class, type> tuple is being sent to a test nameserver
-whose address is given in the message.
-</p></dd><dt><a name="RESLIB_TIMEOUT"></a><span class="term">RESLIB_TIMEOUT query <%1> to %2 timed out</span></dt><dd><p>
-A debug message indicating that the specified upstream query has timed out and
-there are no retries left.
-</p></dd><dt><a name="RESLIB_TIMEOUT_RETRY"></a><span class="term">RESLIB_TIMEOUT_RETRY query <%1> to %2 timed out, re-trying (retries left: %3)</span></dt><dd><p>
-A debug message indicating that the specified query has timed out and that
-the resolver is repeating the query to the same nameserver. After this
-repeated query, there will be the indicated number of retries left.
-</p></dd><dt><a name="RESLIB_TRUNCATED"></a><span class="term">RESLIB_TRUNCATED response to query for <%1> was truncated, re-querying over TCP</span></dt><dd><p>
-A debug message, this indicates that the response to the specified query was
-truncated and that the resolver will be re-querying over TCP. There are
-various reasons why responses may be truncated, so this message is normal and
-gives no cause for concern.
-</p></dd><dt><a name="RESLIB_UPSTREAM"></a><span class="term">RESLIB_UPSTREAM sending upstream query for <%1> to %2</span></dt><dd><p>
-A debug message indicating that a query for the specified <name, class, type>
-tuple is being sent to a nameserver whose address is given in the message.
-</p></dd><dt><a name="RESOLVER_AXFR_TCP"></a><span class="term">RESOLVER_AXFR_TCP AXFR request received over TCP</span></dt><dd><p>
-This is a debug message output when the resolver received a request for
-an AXFR (full transfer of a zone) over TCP. Only authoritative servers
-are able to handle AXFR requests, so the resolver will return an error
-message to the sender with the RCODE set to NOTIMP.
-</p></dd><dt><a name="RESOLVER_AXFR_UDP"></a><span class="term">RESOLVER_AXFR_UDP AXFR request received over UDP</span></dt><dd><p>
-This is a debug message output when the resolver received a request for
-an AXFR (full transfer of a zone) over UDP. Only authoritative servers
-are able to handle AXFR requests (and in any case, an AXFR request should
-be sent over TCP), so the resolver will return an error message to the
-sender with the RCODE set to NOTIMP.
-</p></dd><dt><a name="RESOLVER_CLIENT_TIME_SMALL"></a><span class="term">RESOLVER_CLIENT_TIME_SMALL client timeout of %1 is too small</span></dt><dd><p>
-During the update of the resolver's configuration parameters, the value
-of the client timeout was found to be too small. The configuration
-update was abandoned and the parameters were not changed.
-</p></dd><dt><a name="RESOLVER_CONFIG_CHANNEL"></a><span class="term">RESOLVER_CONFIG_CHANNEL configuration channel created</span></dt><dd><p>
-This is a debug message output when the resolver has successfully
-established a connection to the configuration channel.
-</p></dd><dt><a name="RESOLVER_CONFIG_ERROR"></a><span class="term">RESOLVER_CONFIG_ERROR error in configuration: %1</span></dt><dd><p>
-An error was detected in a configuration update received by the
-resolver. This may be in the format of the configuration message (in
-which case this is a programming error) or it may be in the data supplied
-(in which case it is a user error). The reason for the error, included
-in the message, will give more details. The configuration update is
-not applied and the resolver parameters were not changed.
-</p></dd><dt><a name="RESOLVER_CONFIG_LOADED"></a><span class="term">RESOLVER_CONFIG_LOADED configuration loaded</span></dt><dd><p>
-This is a debug message output when the resolver configuration has been
-successfully loaded.
-</p></dd><dt><a name="RESOLVER_CONFIG_UPDATED"></a><span class="term">RESOLVER_CONFIG_UPDATED configuration updated: %1</span></dt><dd><p>
-This is a debug message output when the resolver configuration is being
-updated with the specified information.
-</p></dd><dt><a name="RESOLVER_CREATED"></a><span class="term">RESOLVER_CREATED main resolver object created</span></dt><dd><p>
-This is a debug message indicating that the main resolver object has
-been created.
-</p></dd><dt><a name="RESOLVER_DNS_MESSAGE_RECEIVED"></a><span class="term">RESOLVER_DNS_MESSAGE_RECEIVED DNS message received: %1</span></dt><dd><p>
-This is a debug message from the resolver listing the contents of a
-received DNS message.
-</p></dd><dt><a name="RESOLVER_DNS_MESSAGE_SENT"></a><span class="term">RESOLVER_DNS_MESSAGE_SENT DNS message of %1 bytes sent: %2</span></dt><dd><p>
-This is a debug message containing details of the response returned by
-the resolver to the querying system.
-</p></dd><dt><a name="RESOLVER_FAILED"></a><span class="term">RESOLVER_FAILED resolver failed, reason: %1</span></dt><dd><p>
-This is an error message output when an unhandled exception is caught
-by the resolver. After this, the resolver will shut itself down.
-Please submit a bug report.
-</p></dd><dt><a name="RESOLVER_FORWARD_ADDRESS"></a><span class="term">RESOLVER_FORWARD_ADDRESS setting forward address %1(%2)</span></dt><dd><p>
-If the resolver is running in forward mode, this message will appear
-during startup to list the forward address. If multiple addresses are
-specified, it will appear once for each address.
-</p></dd><dt><a name="RESOLVER_FORWARD_QUERY"></a><span class="term">RESOLVER_FORWARD_QUERY processing forward query</span></dt><dd><p>
-This is a debug message indicating that a query received by the resolver
-has passed a set of checks (message is well-formed, it is allowed by the
-ACL, it is a supported opcode, etc.) and is being forwarded to upstream
-servers.
-</p></dd><dt><a name="RESOLVER_HEADER_ERROR"></a><span class="term">RESOLVER_HEADER_ERROR message received, exception when processing header: %1</span></dt><dd><p>
-This is a debug message from the resolver noting that an exception
-occurred during the processing of a received packet. The packet has
-been dropped.
-</p></dd><dt><a name="RESOLVER_IXFR"></a><span class="term">RESOLVER_IXFR IXFR request received</span></dt><dd><p>
-This is a debug message indicating that the resolver received a request
-for an IXFR (incremental transfer of a zone). Only authoritative servers
-are able to handle IXFR requests, so the resolver will return an error
-message to the sender with the RCODE set to NOTIMP.
-</p></dd><dt><a name="RESOLVER_LOOKUP_TIME_SMALL"></a><span class="term">RESOLVER_LOOKUP_TIME_SMALL lookup timeout of %1 is too small</span></dt><dd><p>
-During the update of the resolver's configuration parameters, the value
-of the lookup timeout was found to be too small. The configuration
-update will not be applied.
-</p></dd><dt><a name="RESOLVER_MESSAGE_ERROR"></a><span class="term">RESOLVER_MESSAGE_ERROR error parsing received message: %1 - returning %2</span></dt><dd><p>
-This is a debug message noting that parsing of the body of a received
-message by the resolver failed due to some error (although the parsing of
-the header succeeded). The message parameters give a textual description
-of the problem and the RCODE returned.
-</p></dd><dt><a name="RESOLVER_NEGATIVE_RETRIES"></a><span class="term">RESOLVER_NEGATIVE_RETRIES negative number of retries (%1) specified in the configuration</span></dt><dd><p>
-This error is issued when a resolver configuration update has specified
-a negative retry count: only zero or positive values are valid. The
-configuration update was abandoned and the parameters were not changed.
-</p></dd><dt><a name="RESOLVER_NON_IN_PACKET"></a><span class="term">RESOLVER_NON_IN_PACKET non-IN class request received, returning REFUSED message</span></dt><dd><p>
-This debug message is issued when resolver has received a DNS packet that
-was not IN (Internet) class. The resolver cannot handle such packets,
-so is returning a REFUSED response to the sender.
-</p></dd><dt><a name="RESOLVER_NORMAL_QUERY"></a><span class="term">RESOLVER_NORMAL_QUERY processing normal query</span></dt><dd><p>
-This is a debug message indicating that the query received by the resolver
-has passed a set of checks (message is well-formed, it is allowed by the
-ACL, it is a supported opcode, etc.) and is being processed by the resolver.
-</p></dd><dt><a name="RESOLVER_NOTIFY_RECEIVED"></a><span class="term">RESOLVER_NOTIFY_RECEIVED NOTIFY arrived but server is not authoritative</span></dt><dd><p>
-The resolver has received a NOTIFY message. As the server is not
-authoritative it cannot process it, so it returns an error message to
-the sender with the RCODE set to NOTAUTH.
-</p></dd><dt><a name="RESOLVER_NOT_ONE_QUESTION"></a><span class="term">RESOLVER_NOT_ONE_QUESTION query contained %1 questions, exactly one question was expected</span></dt><dd><p>
-This debug message indicates that the resolver received a query that
-contained the number of entries in the question section detailed in
-the message. This is a malformed message, as a DNS query must contain
-only one question. The resolver will return a message to the sender
-with the RCODE set to FORMERR.
-</p></dd><dt><a name="RESOLVER_NO_ROOT_ADDRESS"></a><span class="term">RESOLVER_NO_ROOT_ADDRESS no root addresses available</span></dt><dd><p>
-A warning message issued during resolver startup, this indicates that
-no root addresses have been set. This may be because the resolver will
-get them from a priming query.
-</p></dd><dt><a name="RESOLVER_PARSE_ERROR"></a><span class="term">RESOLVER_PARSE_ERROR error parsing received message: %1 - returning %2</span></dt><dd><p>
-This is a debug message noting that the resolver received a message and
-the parsing of the body of the message failed due to some non-protocol
-related reason (although the parsing of the header succeeded).
-The message parameters give a textual description of the problem and
-the RCODE returned.
-</p></dd><dt><a name="RESOLVER_PRINT_COMMAND"></a><span class="term">RESOLVER_PRINT_COMMAND print message command, arguments are: %1</span></dt><dd><p>
-This debug message is logged when a "print_message" command is received
-by the resolver over the command channel.
-</p></dd><dt><a name="RESOLVER_PROTOCOL_ERROR"></a><span class="term">RESOLVER_PROTOCOL_ERROR protocol error parsing received message: %1 - returning %2</span></dt><dd><p>
-This is a debug message noting that the resolver received a message and
-the parsing of the body of the message failed due to some protocol error
-(although the parsing of the header succeeded). The message parameters
-give a textual description of the problem and the RCODE returned.
-</p></dd><dt><a name="RESOLVER_QUERY_ACCEPTED"></a><span class="term">RESOLVER_QUERY_ACCEPTED query accepted: '%1/%2/%3' from %4</span></dt><dd><p>
-This debug message is produced by the resolver when an incoming query
-is accepted in terms of the query ACL. The log message shows the query
-in the form of <query name>/<query type>/<query class>, and the client
-that sends the query in the form of <Source IP address>#<source port>.
-</p></dd><dt><a name="RESOLVER_QUERY_DROPPED"></a><span class="term">RESOLVER_QUERY_DROPPED query dropped: '%1/%2/%3' from %4</span></dt><dd><p>
-This is an informational message that indicates an incoming query has
-been dropped by the resolver because of the query ACL. Unlike the
-RESOLVER_QUERY_REJECTED case, the server does not return any response.
-The log message shows the query in the form of <query name>/<query
-type>/<query class>, and the client that sends the query in the form of
-<Source IP address>#<source port>.
-</p></dd><dt><a name="RESOLVER_QUERY_REJECTED"></a><span class="term">RESOLVER_QUERY_REJECTED query rejected: '%1/%2/%3' from %4</span></dt><dd><p>
-This is an informational message that indicates an incoming query has
-been rejected by the resolver because of the query ACL. This results
-in a response with an RCODE of REFUSED. The log message shows the query
-in the form of <query name>/<query type>/<query class>, and the client
-that sends the query in the form of <Source IP address>#<source port>.
-</p></dd><dt><a name="RESOLVER_QUERY_SETUP"></a><span class="term">RESOLVER_QUERY_SETUP query setup</span></dt><dd><p>
-This is a debug message noting that the resolver is creating a
-RecursiveQuery object.
-</p></dd><dt><a name="RESOLVER_QUERY_SHUTDOWN"></a><span class="term">RESOLVER_QUERY_SHUTDOWN query shutdown</span></dt><dd><p>
-This is a debug message noting that the resolver is destroying a
-RecursiveQuery object.
-</p></dd><dt><a name="RESOLVER_QUERY_TIME_SMALL"></a><span class="term">RESOLVER_QUERY_TIME_SMALL query timeout of %1 is too small</span></dt><dd><p>
-During the update of the resolver's configuration parameters, the value
-of the query timeout was found to be too small. The configuration
-parameters were not changed.
-</p></dd><dt><a name="RESOLVER_RECEIVED_MESSAGE"></a><span class="term">RESOLVER_RECEIVED_MESSAGE resolver has received a DNS message</span></dt><dd><p>
-This is a debug message indicating that the resolver has received a
-DNS message. Depending on the debug settings, subsequent log output
-will indicate the nature of the message.
-</p></dd><dt><a name="RESOLVER_RECURSIVE"></a><span class="term">RESOLVER_RECURSIVE running in recursive mode</span></dt><dd><p>
-This is an informational message that appears at startup noting that
-the resolver is running in recursive mode.
-</p></dd><dt><a name="RESOLVER_SERVICE_CREATED"></a><span class="term">RESOLVER_SERVICE_CREATED service object created</span></dt><dd><p>
-This debug message is output when resolver creates the main service object
-(which handles the received queries).
-</p></dd><dt><a name="RESOLVER_SET_PARAMS"></a><span class="term">RESOLVER_SET_PARAMS query timeout: %1, client timeout: %2, lookup timeout: %3, retry count: %4</span></dt><dd><p>
-This debug message lists the parameters being set for the resolver. These are:
-query timeout: the timeout (in ms) used for queries originated by the resolver
-to upstream servers. Client timeout: the interval to resolve a query by
-a client: after this time, the resolver sends back a SERVFAIL to the client
-whilst continuing to resolve the query. Lookup timeout: the time at which the
-resolver gives up trying to resolve a query. Retry count: the number of times
-the resolver will retry a query to an upstream server if it gets a timeout.
-</p><p>
-The client and lookup timeouts require a bit more explanation. The
-resolution of the client query might require a large number of queries to
-upstream nameservers. Even if none of these queries timeout, the total time
-taken to perform all the queries may exceed the client timeout. When this
-happens, a SERVFAIL is returned to the client, but the resolver continues
-with the resolution process; data received is added to the cache. However,
-there comes a time - the lookup timeout - when even the resolver gives up.
-At this point it will wait for pending upstream queries to complete or
-timeout and drop the query.
-</p></dd><dt><a name="RESOLVER_SET_QUERY_ACL"></a><span class="term">RESOLVER_SET_QUERY_ACL query ACL is configured</span></dt><dd><p>
-This debug message is generated when a new query ACL is configured for
-the resolver.
-</p></dd><dt><a name="RESOLVER_SET_ROOT_ADDRESS"></a><span class="term">RESOLVER_SET_ROOT_ADDRESS setting root address %1(%2)</span></dt><dd><p>
-This message gives the address of one of the root servers used by the
-resolver. It is output during startup and may appear multiple times,
-once for each root server address.
-</p></dd><dt><a name="RESOLVER_SHUTDOWN"></a><span class="term">RESOLVER_SHUTDOWN resolver shutdown complete</span></dt><dd><p>
-This informational message is output when the resolver has shut down.
-</p></dd><dt><a name="RESOLVER_STARTED"></a><span class="term">RESOLVER_STARTED resolver started</span></dt><dd><p>
-This informational message is output by the resolver when all initialization
-has been completed and it is entering its main loop.
-</p></dd><dt><a name="RESOLVER_STARTING"></a><span class="term">RESOLVER_STARTING starting resolver with command line '%1'</span></dt><dd><p>
-An informational message, this is output when the resolver starts up.
-</p></dd><dt><a name="RESOLVER_UNEXPECTED_RESPONSE"></a><span class="term">RESOLVER_UNEXPECTED_RESPONSE received unexpected response, ignoring</span></dt><dd><p>
-This is a debug message noting that the resolver received a DNS response
-packet on the port on which is it listening for queries. The packet
-has been ignored.
-</p></dd><dt><a name="RESOLVER_UNSUPPORTED_OPCODE"></a><span class="term">RESOLVER_UNSUPPORTED_OPCODE opcode %1 not supported by the resolver</span></dt><dd><p>
-This is debug message output when the resolver received a message with an
-unsupported opcode (it can only process QUERY opcodes). It will return
-a message to the sender with the RCODE set to NOTIMP.
-</p></dd><dt><a name="SOCKETREQUESTOR_CREATED"></a><span class="term">SOCKETREQUESTOR_CREATED Socket requestor created</span></dt><dd><p>
-Debug message. A socket requesor (client of the socket creator) is created
-for the corresponding application. Normally this should happen at most
-one time throughout the lifetime of the application.
-</p></dd><dt><a name="SOCKETREQUESTOR_DESTROYED"></a><span class="term">SOCKETREQUESTOR_DESTROYED Socket requestor destoryed</span></dt><dd><p>
-Debug message. The socket requestor created at SOCKETREQUESTOR_CREATED
-has been destroyed. This event is generally unexpected other than in
-test cases.
-</p></dd><dt><a name="SOCKETREQUESTOR_GETSOCKET"></a><span class="term">SOCKETREQUESTOR_GETSOCKET Received a %1 socket for [%2]:%3, FD=%4, token=%5, path=%6</span></dt><dd><p>
-Debug message. The socket requestor for the corresponding application
-has requested a socket for a set of address, port and protocol (shown
-in the log message) and successfully got it from the creator. The
-corresponding file descriptor and the associated "token" (an internal
-ID used between the creator and requestor) are shown in the log
-message.
-</p></dd><dt><a name="SOCKETREQUESTOR_RELEASESOCKET"></a><span class="term">SOCKETREQUESTOR_RELEASESOCKET Released a socket of token %1</span></dt><dd><p>
-Debug message. The socket requestor has released a socket passed by
-the creator. The associated token of the socket is shown in the
-log message. If the corresponding SOCKETREQUESTOR_GETSOCKET was logged
-more detailed information of the socket can be identified by matching
-the token.
-</p></dd><dt><a name="SRVCOMM_ADDRESSES_NOT_LIST"></a><span class="term">SRVCOMM_ADDRESSES_NOT_LIST the address and port specification is not a list in %1</span></dt><dd><p>
-This points to an error in configuration. What was supposed to be a list of
-IP address - port pairs isn't a list at all but something else.
-</p></dd><dt><a name="SRVCOMM_ADDRESS_FAIL"></a><span class="term">SRVCOMM_ADDRESS_FAIL failed to listen on addresses (%1)</span></dt><dd><p>
-The server failed to bind to one of the address/port pair it should according
-to configuration, for reason listed in the message (usually because that pair
-is already used by other service or missing privileges). The server will try
-to recover and bind the address/port pairs it was listening to before (if any).
-</p></dd><dt><a name="SRVCOMM_ADDRESS_MISSING"></a><span class="term">SRVCOMM_ADDRESS_MISSING address specification is missing "address" or "port" element in %1</span></dt><dd><p>
-This points to an error in configuration. An address specification in the
-configuration is missing either an address or port and so cannot be used. The
-specification causing the error is given in the message.
-</p></dd><dt><a name="SRVCOMM_ADDRESS_TYPE"></a><span class="term">SRVCOMM_ADDRESS_TYPE address specification type is invalid in %1</span></dt><dd><p>
-This points to an error in configuration. An address specification in the
-configuration malformed. The specification causing the error is given in the
-message. A valid specification contains an address part (which must be a string
-and must represent a valid IPv4 or IPv6 address) and port (which must be an
-integer in the range valid for TCP/UDP ports on your system).
-</p></dd><dt><a name="SRVCOMM_ADDRESS_UNRECOVERABLE"></a><span class="term">SRVCOMM_ADDRESS_UNRECOVERABLE failed to recover original addresses also (%1)</span></dt><dd><p>
-The recovery of old addresses after SRVCOMM_ADDRESS_FAIL also failed for
-the reason listed.
-</p><p>
-The condition indicates problems with the server and/or the system on
-which it is running. The server will continue running to allow
-reconfiguration, but will not be listening on any address or port until
-an administrator does so.
-</p></dd><dt><a name="SRVCOMM_ADDRESS_VALUE"></a><span class="term">SRVCOMM_ADDRESS_VALUE address to set: %1#%2</span></dt><dd><p>
-Debug message. This lists one address and port value of the set of
-addresses we are going to listen on (eg. there will be one log message
-per pair). This appears only after SRVCOMM_SET_LISTEN, but might
-be hidden, as it has higher debug level.
-</p></dd><dt><a name="SRVCOMM_KEYS_DEINIT"></a><span class="term">SRVCOMM_KEYS_DEINIT deinitializing TSIG keyring</span></dt><dd><p>
-Debug message indicating that the server is deinitializing the TSIG keyring.
-</p></dd><dt><a name="SRVCOMM_KEYS_INIT"></a><span class="term">SRVCOMM_KEYS_INIT initializing TSIG keyring</span></dt><dd><p>
-Debug message indicating that the server is initializing the global TSIG
-keyring. This should be seen only at server start.
-</p></dd><dt><a name="SRVCOMM_KEYS_UPDATE"></a><span class="term">SRVCOMM_KEYS_UPDATE updating TSIG keyring</span></dt><dd><p>
-Debug message indicating new keyring is being loaded from configuration (either
-on startup or as a result of configuration update).
-</p></dd><dt><a name="SRVCOMM_PORT_RANGE"></a><span class="term">SRVCOMM_PORT_RANGE port out of valid range (%1 in %2)</span></dt><dd><p>
-This points to an error in configuration. The port in an address
-specification is outside the valid range of 0 to 65535.
-</p></dd><dt><a name="SRVCOMM_SET_LISTEN"></a><span class="term">SRVCOMM_SET_LISTEN setting addresses to listen to</span></dt><dd><p>
-Debug message, noting that the server is about to start listening on a
-different set of IP addresses and ports than before.
-</p></dd><dt><a name="STATHTTPD_BAD_OPTION_VALUE"></a><span class="term">STATHTTPD_BAD_OPTION_VALUE bad command line argument: %1</span></dt><dd><p>
-The stats-httpd module was called with a bad command-line argument
-and will not start.
-</p></dd><dt><a name="STATHTTPD_CC_SESSION_ERROR"></a><span class="term">STATHTTPD_CC_SESSION_ERROR error connecting to message bus: %1</span></dt><dd><p>
-The stats-httpd module was unable to connect to the BIND 10 command
-and control bus. A likely problem is that the message bus daemon
-(b10-msgq) is not running. The stats-httpd module will now shut down.
-</p></dd><dt><a name="STATHTTPD_CLOSING"></a><span class="term">STATHTTPD_CLOSING closing %1#%2</span></dt><dd><p>
-The stats-httpd daemon will stop listening for requests on the given
-address and port number.
-</p></dd><dt><a name="STATHTTPD_CLOSING_CC_SESSION"></a><span class="term">STATHTTPD_CLOSING_CC_SESSION stopping cc session</span></dt><dd><p>
-Debug message indicating that the stats-httpd module is disconnecting
-from the command and control bus.
-</p></dd><dt><a name="STATHTTPD_HANDLE_CONFIG"></a><span class="term">STATHTTPD_HANDLE_CONFIG reading configuration: %1</span></dt><dd><p>
-The stats-httpd daemon has received new configuration data and will now
-process it. The (changed) data is printed.
-</p></dd><dt><a name="STATHTTPD_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">STATHTTPD_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
-A shutdown command was sent to the stats-httpd module, and it will
-now shut down.
-</p></dd><dt><a name="STATHTTPD_RECEIVED_STATUS_COMMAND"></a><span class="term">STATHTTPD_RECEIVED_STATUS_COMMAND received command to return status</span></dt><dd><p>
-A status command was sent to the stats-httpd module, and it will
-respond with 'Stats Httpd is up.' and its PID.
-</p></dd><dt><a name="STATHTTPD_RECEIVED_UNKNOWN_COMMAND"></a><span class="term">STATHTTPD_RECEIVED_UNKNOWN_COMMAND received unknown command: %1</span></dt><dd><p>
-An unknown command has been sent to the stats-httpd module. The
-stats-httpd module will respond with an error, and the command will
-be ignored.
-</p></dd><dt><a name="STATHTTPD_SERVER_DATAERROR"></a><span class="term">STATHTTPD_SERVER_DATAERROR HTTP server data error: %1</span></dt><dd><p>
-An internal error occurred while handling an HTTP request. An HTTP 404
-response will be sent back, and the specific error is printed. This
-is an error condition that likely points the specified data
-corresponding to the requested URI is incorrect.
-</p></dd><dt><a name="STATHTTPD_SERVER_ERROR"></a><span class="term">STATHTTPD_SERVER_ERROR HTTP server error: %1</span></dt><dd><p>
-An internal error occurred while handling an HTTP request. An HTTP 500
-response will be sent back, and the specific error is printed. This
-is an error condition that likely points to a module that is not
-responding correctly to statistic requests.
-</p></dd><dt><a name="STATHTTPD_SERVER_INIT_ERROR"></a><span class="term">STATHTTPD_SERVER_INIT_ERROR HTTP server initialization error: %1</span></dt><dd><p>
-There was a problem initializing the HTTP server in the stats-httpd
-module upon receiving its configuration data. The most likely cause
-is a port binding problem or a bad configuration value. The specific
-error is printed in the message. The new configuration is ignored,
-and an error is sent back.
-</p></dd><dt><a name="STATHTTPD_SHUTDOWN"></a><span class="term">STATHTTPD_SHUTDOWN shutting down</span></dt><dd><p>
-The stats-httpd daemon is shutting down.
-</p></dd><dt><a name="STATHTTPD_STARTED"></a><span class="term">STATHTTPD_STARTED listening on %1#%2</span></dt><dd><p>
-The stats-httpd daemon will now start listening for requests on the
-given address and port number.
-</p></dd><dt><a name="STATHTTPD_STARTING_CC_SESSION"></a><span class="term">STATHTTPD_STARTING_CC_SESSION starting cc session</span></dt><dd><p>
-Debug message indicating that the stats-httpd module is connecting to
-the command and control bus.
-</p></dd><dt><a name="STATHTTPD_START_SERVER_INIT_ERROR"></a><span class="term">STATHTTPD_START_SERVER_INIT_ERROR HTTP server initialization error: %1</span></dt><dd><p>
-There was a problem initializing the HTTP server in the stats-httpd
-module upon startup. The most likely cause is that it was not able
-to bind to the listening port. The specific error is printed, and the
-module will shut down.
-</p></dd><dt><a name="STATHTTPD_STOPPED_BY_KEYBOARD"></a><span class="term">STATHTTPD_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the stats-httpd
-daemon. The daemon will now shut down.
-</p></dd><dt><a name="STATHTTPD_UNKNOWN_CONFIG_ITEM"></a><span class="term">STATHTTPD_UNKNOWN_CONFIG_ITEM unknown configuration item: %1</span></dt><dd><p>
-The stats-httpd daemon received a configuration update from the
-configuration manager. However, one of the items in the
-configuration is unknown. The new configuration is ignored, and an
-error is sent back. As possible cause is that there was an upgrade
-problem, and the stats-httpd version is out of sync with the rest of
-the system.
-</p></dd><dt><a name="STATS_BAD_OPTION_VALUE"></a><span class="term">STATS_BAD_OPTION_VALUE bad command line argument: %1</span></dt><dd><p>
-The stats module was called with a bad command-line argument and will
-not start.
-</p></dd><dt><a name="STATS_CC_SESSION_ERROR"></a><span class="term">STATS_CC_SESSION_ERROR error connecting to message bus: %1</span></dt><dd><p>
-The stats module was unable to connect to the BIND 10 command and
-control bus. A likely problem is that the message bus daemon
-(b10-msgq) is not running. The stats module will now shut down.
-</p></dd><dt><a name="STATS_RECEIVED_NEW_CONFIG"></a><span class="term">STATS_RECEIVED_NEW_CONFIG received new configuration: %1</span></dt><dd><p>
-This debug message is printed when the stats module has received a
-configuration update from the configuration manager.
-</p></dd><dt><a name="STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND"></a><span class="term">STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND received command to show all statistics schema</span></dt><dd><p>
-The stats module received a command to show all statistics schemas of all modules.
-</p></dd><dt><a name="STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND"></a><span class="term">STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND received command to show statistics schema for %1</span></dt><dd><p>
-The stats module received a command to show the specified statistics schema of the specified module.
-</p></dd><dt><a name="STATS_RECEIVED_SHOW_ALL_COMMAND"></a><span class="term">STATS_RECEIVED_SHOW_ALL_COMMAND received command to show all statistics</span></dt><dd><p>
-The stats module received a command to show all statistics that it has
-collected.
-</p></dd><dt><a name="STATS_RECEIVED_SHOW_NAME_COMMAND"></a><span class="term">STATS_RECEIVED_SHOW_NAME_COMMAND received command to show statistics for %1</span></dt><dd><p>
-The stats module received a command to show the statistics that it has
-collected for the given item.
-</p></dd><dt><a name="STATS_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">STATS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
-A shutdown command was sent to the stats module and it will now shut down.
-</p></dd><dt><a name="STATS_RECEIVED_STATUS_COMMAND"></a><span class="term">STATS_RECEIVED_STATUS_COMMAND received command to return status</span></dt><dd><p>
-A status command was sent to the stats module. It will return a
-response indicating that it is running normally.
-</p></dd><dt><a name="STATS_RECEIVED_UNKNOWN_COMMAND"></a><span class="term">STATS_RECEIVED_UNKNOWN_COMMAND received unknown command: %1</span></dt><dd><p>
-An unknown command has been sent to the stats module. The stats module
-will respond with an error and the command will be ignored.
-</p></dd><dt><a name="STATS_SEND_REQUEST_BOSS"></a><span class="term">STATS_SEND_REQUEST_BOSS requesting boss to send statistics</span></dt><dd><p>
-This debug message is printed when a request is sent to the boss module
-to send its data to the stats module.
-</p></dd><dt><a name="STATS_STARTING"></a><span class="term">STATS_STARTING starting</span></dt><dd><p>
-The stats module will be now starting.
-</p></dd><dt><a name="STATS_START_ERROR"></a><span class="term">STATS_START_ERROR stats module error: %1</span></dt><dd><p>
-An internal error occurred while starting the stats module. The stats
-module will be now shutting down.
-</p></dd><dt><a name="STATS_STOPPED_BY_KEYBOARD"></a><span class="term">STATS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the stats module. The
-daemon will now shut down.
-</p></dd><dt><a name="STATS_UNKNOWN_COMMAND_IN_SPEC"></a><span class="term">STATS_UNKNOWN_COMMAND_IN_SPEC unknown command in specification file: %1</span></dt><dd><p>
-The specification file for the stats module contains a command that
-is unknown in the implementation. The most likely cause is an
-installation problem, where the specification file stats.spec is
-from a different version of BIND 10 than the stats module itself.
-Please check your installation.
-</p></dd><dt><a name="XFRIN_AXFR_INCONSISTENT_SOA"></a><span class="term">XFRIN_AXFR_INCONSISTENT_SOA AXFR SOAs are inconsistent for %1: %2 expected, %3 received</span></dt><dd><p>
-The serial fields of the first and last SOAs of AXFR (including AXFR-style
-IXFR) are not the same. According to RFC 5936 these two SOAs must be the
-"same" (not only for the serial), but it is still not clear what the
-receiver should do if this condition does not hold. There was a discussion
-about this at the IETF dnsext wg:
-http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
-and the general feeling seems that it would be better to reject the
-transfer if a mismatch is detected. On the other hand, also as noted
-in that email thread, neither BIND 9 nor NSD performs any comparison
-on the SOAs. For now, we only check the serials (ignoring other fields)
-and only leave a warning log message when a mismatch is found. If it
-turns out to happen with a real world primary server implementation
-and that server actually feeds broken data (e.g. mixed versions of
-zone), we can consider a stricter action.
-</p></dd><dt><a name="XFRIN_BAD_MASTER_ADDR_FORMAT"></a><span class="term">XFRIN_BAD_MASTER_ADDR_FORMAT bad format for master address: %1</span></dt><dd><p>
-The given master address is not a valid IP address.
-</p></dd><dt><a name="XFRIN_BAD_MASTER_PORT_FORMAT"></a><span class="term">XFRIN_BAD_MASTER_PORT_FORMAT bad format for master port: %1</span></dt><dd><p>
-The master port as read from the configuration is not a valid port number.
-</p></dd><dt><a name="XFRIN_BAD_TSIG_KEY_STRING"></a><span class="term">XFRIN_BAD_TSIG_KEY_STRING bad TSIG key string: %1</span></dt><dd><p>
-The TSIG key string as read from the configuration does not represent
-a valid TSIG key.
-</p></dd><dt><a name="XFRIN_BAD_ZONE_CLASS"></a><span class="term">XFRIN_BAD_ZONE_CLASS Invalid zone class: %1</span></dt><dd><p>
-The zone class as read from the configuration is not a valid DNS class.
-</p></dd><dt><a name="XFRIN_CC_SESSION_ERROR"></a><span class="term">XFRIN_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
-There was a problem reading from the command and control channel. The
-most likely cause is that xfrin the msgq daemon is not running.
-</p></dd><dt><a name="XFRIN_COMMAND_ERROR"></a><span class="term">XFRIN_COMMAND_ERROR error while executing command '%1': %2</span></dt><dd><p>
-There was an error while the given command was being processed. The
-error is given in the log message.
-</p></dd><dt><a name="XFRIN_CONNECT_MASTER"></a><span class="term">XFRIN_CONNECT_MASTER error connecting to master at %1: %2</span></dt><dd><p>
-There was an error opening a connection to the master. The error is
-shown in the log message.
-</p></dd><dt><a name="XFRIN_GOT_INCREMENTAL_RESP"></a><span class="term">XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1</span></dt><dd><p>
-In an attempt of IXFR processing, the begenning SOA of the first difference
-(following the initial SOA that specified the final SOA for all the
-differences) was found. This means a connection for xfrin tried IXFR
-and really aot a response for incremental updates.
-</p></dd><dt><a name="XFRIN_GOT_NONINCREMENTAL_RESP"></a><span class="term">XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1</span></dt><dd><p>
-Non incremental transfer was detected at the "first data" of a transfer,
-which is the RR following the initial SOA. Non incremental transfer is
-either AXFR or AXFR-style IXFR. In the latter case, it means that
-in a response to IXFR query the first data is not SOA or its SOA serial
-is not equal to the requested SOA serial.
-</p></dd><dt><a name="XFRIN_IMPORT_DNS"></a><span class="term">XFRIN_IMPORT_DNS error importing python DNS module: %1</span></dt><dd><p>
-There was an error importing the python DNS module pydnspp. The most
-likely cause is a PYTHONPATH problem.
-</p></dd><dt><a name="XFRIN_IXFR_UPTODATE"></a><span class="term">XFRIN_IXFR_UPTODATE IXFR requested serial for %1 is %2, master has %3, not updating</span></dt><dd><p>
-The first SOA record in an IXFR response indicates the zone's serial
-at the primary server is not newer than the client's. This is
-basically unexpected event because normally the client first checks
-the SOA serial by an SOA query, but can still happen if the transfer
-is manually invoked or (although unlikely) there is a rapid change at
-the primary server between the SOA and IXFR queries. The client
-implementation confirms the whole response is this single SOA, and
-aborts the transfer just like a successful case.
-</p></dd><dt><a name="XFRIN_MSGQ_SEND_ERROR"></a><span class="term">XFRIN_MSGQ_SEND_ERROR error while contacting %1 and %2</span></dt><dd><p>
-There was a problem sending a message to the xfrout module or the
-zone manager. This most likely means that the msgq daemon has quit or
-was killed.
-</p></dd><dt><a name="XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER"></a><span class="term">XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER error while contacting %1</span></dt><dd><p>
-There was a problem sending a message to the zone manager. This most
-likely means that the msgq daemon has quit or was killed.
-</p></dd><dt><a name="XFRIN_NOTIFY_UNKNOWN_MASTER"></a><span class="term">XFRIN_NOTIFY_UNKNOWN_MASTER got notification to retransfer zone %1 from %2, expected %3</span></dt><dd><p>
-The system received a notify for the given zone, but the address it came
-from does not match the master address in the Xfrin configuration. The notify
-is ignored. This may indicate that the configuration for the master is wrong,
-that a wrong machine is sending notifies, or that fake notifies are being sent.
-</p></dd><dt><a name="XFRIN_RETRANSFER_UNKNOWN_ZONE"></a><span class="term">XFRIN_RETRANSFER_UNKNOWN_ZONE got notification to retransfer unknown zone %1</span></dt><dd><p>
-There was an internal command to retransfer the given zone, but the
-zone is not known to the system. This may indicate that the configuration
-for xfrin is incomplete, or there was a typographical error in the
-zone name in the configuration.
-</p></dd><dt><a name="XFRIN_STARTING"></a><span class="term">XFRIN_STARTING starting resolver with command line '%1'</span></dt><dd><p>
-An informational message, this is output when the resolver starts up.
-</p></dd><dt><a name="XFRIN_STOPPED_BY_KEYBOARD"></a><span class="term">XFRIN_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the xfrin daemon. The
-daemon will now shut down.
-</p></dd><dt><a name="XFRIN_UNKNOWN_ERROR"></a><span class="term">XFRIN_UNKNOWN_ERROR unknown error: %1</span></dt><dd><p>
-An uncaught exception was raised while running the xfrin daemon. The
-exception message is printed in the log message.
-</p></dd><dt><a name="XFRIN_XFR_OTHER_FAILURE"></a><span class="term">XFRIN_XFR_OTHER_FAILURE %1 transfer of zone %2 failed: %3</span></dt><dd><p>
-The XFR transfer for the given zone has failed due to a problem outside
-of the xfrin module. Possible reasons are a broken DNS message or failure
-in database connection. The error is shown in the log message.
-</p></dd><dt><a name="XFRIN_XFR_PROCESS_FAILURE"></a><span class="term">XFRIN_XFR_PROCESS_FAILURE %1 transfer of zone %2/%3 failed: %4</span></dt><dd><p>
-An XFR session failed outside the main protocol handling. This
-includes an error at the data source level at the initialization
-phase, unexpected failure in the network connection setup to the
-master server, or even more unexpected failure due to unlikely events
-such as memory allocation failure. Details of the error are shown in
-the log message. In general, these errors are not really expected
-ones, and indicate an installation error or a program bug. The
-session handler thread tries to clean up all intermediate resources
-even on these errors, but it may be incomplete. So, if this log
-message continuously appears, system resource consumption should be
-checked, and you may even want to disable the corresponding transfers.
-You may also want to file a bug report if this message appears so
-often.
-</p></dd><dt><a name="XFRIN_XFR_TRANSFER_FAILURE"></a><span class="term">XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 with %3 failed: %4</span></dt><dd><p>
-The XFR transfer for the given zone has failed due to an internal error.
-The error is shown in the log message.
-</p></dd><dt><a name="XFRIN_XFR_TRANSFER_FALLBACK"></a><span class="term">XFRIN_XFR_TRANSFER_FALLBACK falling back from IXFR to AXFR for %1</span></dt><dd><p>
-The IXFR transfer of the given zone failed. This might happen in many cases,
-such that the remote server doesn't support IXFR, we don't have the SOA record
-(or the zone at all), we are out of sync, etc. In many of these situations,
-AXFR could still work. Therefore we try that one in case it helps.
-</p></dd><dt><a name="XFRIN_XFR_TRANSFER_PROTOCOL_ERROR"></a><span class="term">XFRIN_XFR_TRANSFER_PROTOCOL_ERROR %1 transfer of zone %2 with %3 failed: %4</span></dt><dd><p>
-The XFR transfer for the given zone has failed due to a protocol
-error, such as an unexpected response from the primary server. The
-error is shown in the log message. It may be because the primary
-server implementation is broken or (although less likely) there was
-some attack attempt, but it can also happen due to configuration
-mismatch such as the remote server does not have authority for the
-zone any more but the local configuration hasn't been updated. So it
-is recommended to check the primary server configuration.
-</p></dd><dt><a name="XFRIN_XFR_TRANSFER_STARTED"></a><span class="term">XFRIN_XFR_TRANSFER_STARTED %1 transfer of zone %2 started</span></dt><dd><p>
-A connection to the master server has been made, the serial value in
-the SOA record has been checked, and a zone transfer has been started.
-</p></dd><dt><a name="XFRIN_XFR_TRANSFER_SUCCESS"></a><span class="term">XFRIN_XFR_TRANSFER_SUCCESS %1 transfer of zone %2 succeeded</span></dt><dd><p>
-The XFR transfer of the given zone was successfully completed.
-</p></dd><dt><a name="XFRIN_ZONE_CREATED"></a><span class="term">XFRIN_ZONE_CREATED Zone %1 not found in the given data source, newly created</span></dt><dd><p>
-On starting an xfrin session, it is identified that the zone to be
-transferred is not found in the data source. This can happen if a
-secondary DNS server first tries to perform AXFR from a primary server
-without creating the zone image beforehand (e.g. by b10-loadzone). As
-of this writing the xfrin process provides backward compatible
-behavior to previous versions: creating a new one in the data source
-not to surprise existing users too much. This is probably not a good
-idea, however, in terms of who should be responsible for managing
-zones at a higher level. In future it is more likely that a separate
-zone management framework is provided, and the situation where the
-given zone isn't found in xfrout will be treated as an error.
-</p></dd><dt><a name="XFRIN_ZONE_MULTIPLE_SOA"></a><span class="term">XFRIN_ZONE_MULTIPLE_SOA Zone %1 has %2 SOA RRs</span></dt><dd><p>
-On starting an xfrin session, it is identified that the zone to be
-transferred has multiple SOA RRs. Such a zone is broken, but could be
-accidentally configured especially in a data source using "non
-captive" backend database. The implementation ignores entire SOA RRs
-and tries to continue processing as if the zone were empty. This
-means subsequent AXFR can succeed and possibly replace the zone with
-valid content, but an IXFR attempt will fail.
-</p></dd><dt><a name="XFRIN_ZONE_NO_SOA"></a><span class="term">XFRIN_ZONE_NO_SOA Zone %1 does not have SOA</span></dt><dd><p>
-On starting an xfrin session, it is identified that the zone to be
-transferred does not have an SOA RR in the data source. This is not
-necessarily an error; if a secondary DNS server first tries to perform
-transfer from a primary server, the zone can be empty, and therefore
-doesn't have an SOA. Subsequent AXFR will fill in the zone; if the
-attempt is IXFR it will fail in query creation.
-</p></dd><dt><a name="XFRIN_ZONE_SERIAL_AHEAD"></a><span class="term">XFRIN_ZONE_SERIAL_AHEAD Serial number (%1) for %2 received from master %3 < ours (%4)</span></dt><dd><p>
-The response to an SOA query prior to xfr indicated that the zone's
-SOA serial at the primary server is smaller than that of the xfrin
-client. This is not necessarily an error especially if that
-particular primary server is another secondary server which hasn't got
-the latest version of the zone. But if the primary server is known to
-be the real source of the zone, some unexpected inconsistency may have
-happened, and you may want to take a closer look. In this case xfrin
-doesn't perform subsequent zone transfer.
-</p></dd><dt><a name="XFROUT_BAD_TSIG_KEY_STRING"></a><span class="term">XFROUT_BAD_TSIG_KEY_STRING bad TSIG key string: %1</span></dt><dd><p>
-The TSIG key string as read from the configuration does not represent
-a valid TSIG key.
-</p></dd><dt><a name="XFROUT_CC_SESSION_ERROR"></a><span class="term">XFROUT_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
-There was a problem reading from the command and control channel. The
-most likely cause is that the msgq daemon is not running.
-</p></dd><dt><a name="XFROUT_CC_SESSION_TIMEOUT_ERROR"></a><span class="term">XFROUT_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</span></dt><dd><p>
-There was a problem reading a response from another module over the
-command and control channel. The most likely cause is that the
-configuration manager b10-cfgmgr is not running.
-</p></dd><dt><a name="XFROUT_CONFIG_ERROR"></a><span class="term">XFROUT_CONFIG_ERROR error found in configuration data: %1</span></dt><dd><p>
-The xfrout process encountered an error when installing the configuration at
-startup time. Details of the error are included in the log message.
-</p></dd><dt><a name="XFROUT_FETCH_REQUEST_ERROR"></a><span class="term">XFROUT_FETCH_REQUEST_ERROR socket error while fetching a request from the auth daemon</span></dt><dd><p>
-There was a socket error while contacting the b10-auth daemon to
-fetch a transfer request. The auth daemon may have shutdown.
-</p></dd><dt><a name="XFROUT_HANDLE_QUERY_ERROR"></a><span class="term">XFROUT_HANDLE_QUERY_ERROR error while handling query: %1</span></dt><dd><p>
-There was a general error handling an xfrout query. The error is shown
-in the message. In principle this error should not appear, and points
-to an oversight catching exceptions in the right place. However, to
-ensure the daemon keeps running, this error is caught and reported.
-</p></dd><dt><a name="XFROUT_IMPORT"></a><span class="term">XFROUT_IMPORT error importing python module: %1</span></dt><dd><p>
-There was an error importing a python module. One of the modules needed
-by xfrout could not be found. This suggests that either some libraries
-are missing on the system, or the PYTHONPATH variable is not correct.
-The specific place where this library needs to be depends on your
-system and your specific installation.
-</p></dd><dt><a name="XFROUT_IXFR_MULTIPLE_SOA"></a><span class="term">XFROUT_IXFR_MULTIPLE_SOA IXFR client %1: authority section has multiple SOAs</span></dt><dd><p>
-An IXFR request was received with more than one SOA RRs in the authority
-section. The xfrout daemon rejects the request with an RCODE of
-FORMERR.
-</p></dd><dt><a name="XFROUT_IXFR_NO_JOURNAL_SUPPORT"></a><span class="term">XFROUT_IXFR_NO_JOURNAL_SUPPORT IXFR client %1, %2: journaling not supported in the data source, falling back to AXFR</span></dt><dd><p>
-An IXFR request was received but the underlying data source did
-not support journaling. The xfrout daemon fell back to AXFR-style
-IXFR.
-</p></dd><dt><a name="XFROUT_IXFR_NO_SOA"></a><span class="term">XFROUT_IXFR_NO_SOA IXFR client %1: missing SOA</span></dt><dd><p>
-An IXFR request was received with no SOA RR in the authority section.
-The xfrout daemon rejects the request with an RCODE of FORMERR.
-</p></dd><dt><a name="XFROUT_IXFR_NO_VERSION"></a><span class="term">XFROUT_IXFR_NO_VERSION IXFR client %1, %2: version (%3 to %4) not in journal, falling back to AXFR</span></dt><dd><p>
-An IXFR request was received, but the requested range of differences
-were not found in the data source. The xfrout daemon fell back to
-AXFR-style IXFR.
-</p></dd><dt><a name="XFROUT_IXFR_NO_ZONE"></a><span class="term">XFROUT_IXFR_NO_ZONE IXFR client %1, %2: zone not found with journal</span></dt><dd><p>
-The requested zone in IXFR was not found in the data source
-even though the xfrout daemon sucessfully found the SOA RR of the zone
-in the data source. This can happen if the administrator removed the
-zone from the data source within the small duration between these
-operations, but it's more likely to be a bug or broken data source.
-Unless you know why this message was logged, and especially if it
-happens often, it's advisable to check whether the data source is
-valid for this zone. The xfrout daemon considers it a possible,
-though unlikely, event, and returns a response with an RCODE of
-NOTAUTH.
-</p></dd><dt><a name="XFROUT_IXFR_UPTODATE"></a><span class="term">XFROUT_IXFR_UPTODATE IXFR client %1, %2: client version is new enough (theirs=%3, ours=%4)</span></dt><dd><p>
-An IXFR request was received, but the client's SOA version is the same as
-or newer than that of the server. The xfrout server responds to the
-request with the answer section being just one SOA of that version.
-Note: as of this wrting the 'newer version' cannot be identified due to
-the lack of support for the serial number arithmetic. This will soon
-be implemented.
-</p></dd><dt><a name="XFROUT_MODULECC_SESSION_ERROR"></a><span class="term">XFROUT_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</span></dt><dd><p>
-There was a problem in the lower level module handling configuration and
-control commands. This could happen for various reasons, but the most likely
-cause is that the configuration database contains a syntax error and xfrout
-failed to start at initialization. A detailed error message from the module
-will also be displayed.
-</p></dd><dt><a name="XFROUT_NEW_CONFIG"></a><span class="term">XFROUT_NEW_CONFIG Update xfrout configuration</span></dt><dd><p>
-New configuration settings have been sent from the configuration
-manager. The xfrout daemon will now apply them.
-</p></dd><dt><a name="XFROUT_NEW_CONFIG_DONE"></a><span class="term">XFROUT_NEW_CONFIG_DONE Update xfrout configuration done</span></dt><dd><p>
-The xfrout daemon is now done reading the new configuration settings
-received from the configuration manager.
-</p></dd><dt><a name="XFROUT_NOTIFY_COMMAND"></a><span class="term">XFROUT_NOTIFY_COMMAND received command to send notifies for %1/%2</span></dt><dd><p>
-The xfrout daemon received a command on the command channel that
-NOTIFY packets should be sent for the given zone.
-</p></dd><dt><a name="XFROUT_PARSE_QUERY_ERROR"></a><span class="term">XFROUT_PARSE_QUERY_ERROR error parsing query: %1</span></dt><dd><p>
-There was a parse error while reading an incoming query. The parse
-error is shown in the log message. A remote client sent a packet we
-do not understand or support. The xfrout request will be ignored.
-In general, this should only occur for unexpected problems like
-memory allocation failures, as the query should already have been
-parsed by the b10-auth daemon, before it was passed here.
-</p></dd><dt><a name="XFROUT_PROCESS_REQUEST_ERROR"></a><span class="term">XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %2</span></dt><dd><p>
-There was an error processing a transfer request. The error is included
-in the log message, but at this point no specific information other
-than that could be given. This points to incomplete exception handling
-in the code.
-</p></dd><dt><a name="XFROUT_QUERY_DROPPED"></a><span class="term">XFROUT_QUERY_DROPPED %1 client %2: request to transfer %3 dropped</span></dt><dd><p>
-The xfrout process silently dropped a request to transfer zone to
-given host. This is required by the ACLs. The %2 represents the IP
-address and port of the peer requesting the transfer, and the %3
-represents the zone name and class.
-</p></dd><dt><a name="XFROUT_QUERY_QUOTA_EXCCEEDED"></a><span class="term">XFROUT_QUERY_QUOTA_EXCCEEDED %1 client %2: request denied due to quota (%3)</span></dt><dd><p>
-The xfr request was rejected because the server was already handling
-the maximum number of allowable transfers as specified in the transfers_out
-configuration parameter, which is also shown in the log message. The
-request was immediately responded and terminated with an RCODE of REFUSED.
-This can happen for a busy xfrout server, and you may want to increase
-this parameter; if the server is being too busy due to requests from
-unexpected clients you may want to restrict the legitimate clients
-with ACL.
-</p></dd><dt><a name="XFROUT_QUERY_REJECTED"></a><span class="term">XFROUT_QUERY_REJECTED %1 client %2: request to transfer %3 rejected</span></dt><dd><p>
-The xfrout process rejected (by REFUSED rcode) a request to transfer zone to
-given host. This is because of ACLs. The %2 represents the IP
-address and port of the peer requesting the transfer, and the %3
-represents the zone name and class.
-</p></dd><dt><a name="XFROUT_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">XFROUT_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
-The xfrout daemon received a shutdown command from the command channel
-and will now shut down.
-</p></dd><dt><a name="XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR"></a><span class="term">XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR error receiving the file descriptor for an XFR connection</span></dt><dd><p>
-There was an error receiving the file descriptor for the transfer
-request. Normally, the request is received by b10-auth, and passed on
-to the xfrout daemon, so it can answer directly. However, there was a
-problem receiving this file descriptor. The request will be ignored.
-</p></dd><dt><a name="XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR"></a><span class="term">XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR error removing unix socket file %1: %2</span></dt><dd><p>
-The unix socket file xfrout needs for contact with the auth daemon
-already exists, and needs to be removed first, but there is a problem
-removing it. It is likely that we do not have permission to remove
-this file. The specific error is show in the log message. The xfrout
-daemon will shut down.
-</p></dd><dt><a name="XFROUT_REMOVE_UNIX_SOCKET_FILE_ERROR"></a><span class="term">XFROUT_REMOVE_UNIX_SOCKET_FILE_ERROR error clearing unix socket file %1: %2</span></dt><dd><p>
-When shutting down, the xfrout daemon tried to clear the unix socket
-file used for communication with the auth daemon. It failed to remove
-the file. The reason for the failure is given in the error message.
-</p></dd><dt><a name="XFROUT_SOCKET_SELECT_ERROR"></a><span class="term">XFROUT_SOCKET_SELECT_ERROR error while calling select() on request socket: %1</span></dt><dd><p>
-There was an error while calling select() on the socket that informs
-the xfrout daemon that a new xfrout request has arrived. This should
-be a result of rare local error such as memory allocation failure and
-shouldn't happen under normal conditions. The error is included in the
-log message.
-</p></dd><dt><a name="XFROUT_STOPPED_BY_KEYBOARD"></a><span class="term">XFROUT_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
-There was a keyboard interrupt signal to stop the xfrout daemon. The
-daemon will now shut down.
-</p></dd><dt><a name="XFROUT_STOPPING"></a><span class="term">XFROUT_STOPPING the xfrout daemon is shutting down</span></dt><dd><p>
-The current transfer is aborted, as the xfrout daemon is shutting down.
-</p></dd><dt><a name="XFROUT_UNIX_SOCKET_FILE_IN_USE"></a><span class="term">XFROUT_UNIX_SOCKET_FILE_IN_USE another xfrout process seems to be using the unix socket file %1</span></dt><dd><p>
-While starting up, the xfrout daemon tried to clear the unix domain
-socket needed for contacting the b10-auth daemon to pass requests
-on, but the file is in use. The most likely cause is that another
-xfrout daemon process is still running. This xfrout daemon (the one
-printing this message) will not start.
-</p></dd><dt><a name="XFROUT_XFR_TRANSFER_CHECK_ERROR"></a><span class="term">XFROUT_XFR_TRANSFER_CHECK_ERROR %1 client %2: check for transfer of %3 failed: %4</span></dt><dd><p>
-Pre-response check for an incomding XFR request failed unexpectedly.
-The most likely cause of this is that some low level error in the data
-source, but it may also be other general (more unlikely) errors such
-as memory shortage. Some detail of the error is also included in the
-message. The xfrout server tries to return a SERVFAIL response in this case.
-</p></dd><dt><a name="XFROUT_XFR_TRANSFER_DONE"></a><span class="term">XFROUT_XFR_TRANSFER_DONE %1 client %2: transfer of %3 complete</span></dt><dd><p>
-The transfer of the given zone has been completed successfully, or was
-aborted due to a shutdown event.
-</p></dd><dt><a name="XFROUT_XFR_TRANSFER_ERROR"></a><span class="term">XFROUT_XFR_TRANSFER_ERROR %1 client %2: error transferring zone %3: %4</span></dt><dd><p>
-An uncaught exception was encountered while sending the response to
-an AXFR query. The error message of the exception is included in the
-log message, but this error most likely points to incomplete exception
-handling in the code.
-</p></dd><dt><a name="XFROUT_XFR_TRANSFER_FAILED"></a><span class="term">XFROUT_XFR_TRANSFER_FAILED %1 client %2: transfer of %3 failed, rcode: %4</span></dt><dd><p>
-A transfer out for the given zone failed. An error response is sent
-to the client. The given rcode is the rcode that is set in the error
-response. This is either NOTAUTH (we are not authoritative for the
-zone), SERVFAIL (our internal database is missing the SOA record for
-the zone), or REFUSED (the limit of simultaneous outgoing AXFR
-transfers, as specified by the configuration value
-Xfrout/max_transfers_out, has been reached).
-</p></dd><dt><a name="XFROUT_XFR_TRANSFER_STARTED"></a><span class="term">XFROUT_XFR_TRANSFER_STARTED %1 client %2: transfer of zone %3 has started</span></dt><dd><p>
-A transfer out of the given zone has started.
-</p></dd><dt><a name="ZONEMGR_CCSESSION_ERROR"></a><span class="term">ZONEMGR_CCSESSION_ERROR command channel session error: %1</span></dt><dd><p>
-An error was encountered on the command channel. The message indicates
-the nature of the error.
-</p></dd><dt><a name="ZONEMGR_JITTER_TOO_BIG"></a><span class="term">ZONEMGR_JITTER_TOO_BIG refresh_jitter is too big, setting to 0.5</span></dt><dd><p>
-The value specified in the configuration for the refresh jitter is too large
-so its value has been set to the maximum of 0.5.
-</p></dd><dt><a name="ZONEMGR_KEYBOARD_INTERRUPT"></a><span class="term">ZONEMGR_KEYBOARD_INTERRUPT exiting zonemgr process as result of keyboard interrupt</span></dt><dd><p>
-An informational message output when the zone manager was being run at a
-terminal and it was terminated via a keyboard interrupt signal.
-</p></dd><dt><a name="ZONEMGR_LOAD_ZONE"></a><span class="term">ZONEMGR_LOAD_ZONE loading zone %1 (class %2)</span></dt><dd><p>
-This is a debug message indicating that the zone of the specified class
-is being loaded.
-</p></dd><dt><a name="ZONEMGR_NO_MASTER_ADDRESS"></a><span class="term">ZONEMGR_NO_MASTER_ADDRESS internal BIND 10 command did not contain address of master</span></dt><dd><p>
-A command received by the zone manager from the Auth module did not
-contain the address of the master server from which a NOTIFY message
-was received. This may be due to an internal programming error; please
-submit a bug report.
-</p></dd><dt><a name="ZONEMGR_NO_SOA"></a><span class="term">ZONEMGR_NO_SOA zone %1 (class %2) does not have an SOA record</span></dt><dd><p>
-When loading the named zone of the specified class the zone manager
-discovered that the data did not contain an SOA record. The load has
-been abandoned.
-</p></dd><dt><a name="ZONEMGR_NO_TIMER_THREAD"></a><span class="term">ZONEMGR_NO_TIMER_THREAD trying to stop zone timer thread but it is not running</span></dt><dd><p>
-An attempt was made to stop the timer thread (used to track when zones
-should be refreshed) but it was not running. This may indicate an
-internal program error. Please submit a bug report.
-</p></dd><dt><a name="ZONEMGR_NO_ZONE_CLASS"></a><span class="term">ZONEMGR_NO_ZONE_CLASS internal BIND 10 command did not contain class of zone</span></dt><dd><p>
-A command received by the zone manager from another BIND 10 module did
-not contain the class of the zone on which the zone manager should act.
-This may be due to an internal programming error; please submit a
-bug report.
-</p></dd><dt><a name="ZONEMGR_NO_ZONE_NAME"></a><span class="term">ZONEMGR_NO_ZONE_NAME internal BIND 10 command did not contain name of zone</span></dt><dd><p>
-A command received by the zone manager from another BIND 10 module did
-not contain the name of the zone on which the zone manager should act.
-This may be due to an internal programming error; please submit a
-bug report.
-</p></dd><dt><a name="ZONEMGR_RECEIVE_NOTIFY"></a><span class="term">ZONEMGR_RECEIVE_NOTIFY received NOTIFY command for zone %1 (class %2)</span></dt><dd><p>
-This is a debug message indicating that the zone manager has received a
-NOTIFY command over the command channel. The command is sent by the Auth
-process when it is acting as a slave server for the zone and causes the
-zone manager to record the master server for the zone and start a timer;
-when the timer expires, the master will be polled to see if it contains
-new data.
-</p></dd><dt><a name="ZONEMGR_RECEIVE_SHUTDOWN"></a><span class="term">ZONEMGR_RECEIVE_SHUTDOWN received SHUTDOWN command</span></dt><dd><p>
-This is a debug message indicating that the zone manager has received
-a SHUTDOWN command over the command channel from the Boss process.
-It will act on this command and shut down.
-</p></dd><dt><a name="ZONEMGR_RECEIVE_UNKNOWN"></a><span class="term">ZONEMGR_RECEIVE_UNKNOWN received unknown command '%1'</span></dt><dd><p>
-This is a warning message indicating that the zone manager has received
-the stated command over the command channel. The command is not known
-to the zone manager and although the command is ignored, its receipt
-may indicate an internal error. Please submit a bug report.
-</p></dd><dt><a name="ZONEMGR_RECEIVE_XFRIN_FAILED"></a><span class="term">ZONEMGR_RECEIVE_XFRIN_FAILED received XFRIN FAILED command for zone %1 (class %2)</span></dt><dd><p>
-This is a debug message indicating that the zone manager has received
-an XFRIN FAILED command over the command channel. The command is sent
-by the Xfrin process when a transfer of zone data into the system has
-failed, and causes the zone manager to schedule another transfer attempt.
-</p></dd><dt><a name="ZONEMGR_RECEIVE_XFRIN_SUCCESS"></a><span class="term">ZONEMGR_RECEIVE_XFRIN_SUCCESS received XFRIN SUCCESS command for zone %1 (class %2)</span></dt><dd><p>
-This is a debug message indicating that the zone manager has received
-an XFRIN SUCCESS command over the command channel. The command is sent
-by the Xfrin process when the transfer of zone data into the system has
-succeeded, and causes the data to be loaded and served by BIND 10.
-</p></dd><dt><a name="ZONEMGR_REFRESH_ZONE"></a><span class="term">ZONEMGR_REFRESH_ZONE refreshing zone %1 (class %2)</span></dt><dd><p>
-The zone manager is refreshing the named zone of the specified class
-with updated information.
-</p></dd><dt><a name="ZONEMGR_SELECT_ERROR"></a><span class="term">ZONEMGR_SELECT_ERROR error with select(): %1</span></dt><dd><p>
-An attempt to wait for input from a socket failed. The failing operation
-is a call to the operating system's select() function, which failed for
-the given reason.
-</p></dd><dt><a name="ZONEMGR_SEND_FAIL"></a><span class="term">ZONEMGR_SEND_FAIL failed to send command to %1, session has been closed</span></dt><dd><p>
-The zone manager attempted to send a command to the named BIND 10 module,
-but the send failed. The session between the modules has been closed.
-</p></dd><dt><a name="ZONEMGR_SESSION_ERROR"></a><span class="term">ZONEMGR_SESSION_ERROR unable to establish session to command channel daemon</span></dt><dd><p>
-The zonemgr process was not able to be started because it could not
-connect to the command channel daemon. The most usual cause of this
-problem is that the daemon is not running.
-</p></dd><dt><a name="ZONEMGR_SESSION_TIMEOUT"></a><span class="term">ZONEMGR_SESSION_TIMEOUT timeout on session to command channel daemon</span></dt><dd><p>
-The zonemgr process was not able to be started because it timed out when
-connecting to the command channel daemon. The most usual cause of this
-problem is that the daemon is not running.
-</p></dd><dt><a name="ZONEMGR_SHUTDOWN"></a><span class="term">ZONEMGR_SHUTDOWN zone manager has shut down</span></dt><dd><p>
-A debug message, output when the zone manager has shut down completely.
-</p></dd><dt><a name="ZONEMGR_STARTING"></a><span class="term">ZONEMGR_STARTING zone manager starting</span></dt><dd><p>
-A debug message output when the zone manager starts up.
-</p></dd><dt><a name="ZONEMGR_TIMER_THREAD_RUNNING"></a><span class="term">ZONEMGR_TIMER_THREAD_RUNNING trying to start timer thread but one is already running</span></dt><dd><p>
-This message is issued when an attempt is made to start the timer
-thread (which keeps track of when zones need a refresh) but one is
-already running. It indicates either an error in the program logic or
-a problem with stopping a previous instance of the timer. Please submit
-a bug report.
-</p></dd><dt><a name="ZONEMGR_UNKNOWN_ZONE_FAIL"></a><span class="term">ZONEMGR_UNKNOWN_ZONE_FAIL zone %1 (class %2) is not known to the zone manager</span></dt><dd><p>
-An XFRIN operation has failed but the zone that was the subject of the
-operation is not being managed by the zone manager. This may indicate
-an error in the program (as the operation should not have been initiated
-if this were the case). Please submit a bug report.
-</p></dd><dt><a name="ZONEMGR_UNKNOWN_ZONE_NOTIFIED"></a><span class="term">ZONEMGR_UNKNOWN_ZONE_NOTIFIED notified zone %1 (class %2) is not known to the zone manager</span></dt><dd><p>
-A NOTIFY was received but the zone that was the subject of the operation
-is not being managed by the zone manager. This may indicate an error
-in the program (as the operation should not have been initiated if this
-were the case). Please submit a bug report.
-</p></dd><dt><a name="ZONEMGR_UNKNOWN_ZONE_SUCCESS"></a><span class="term">ZONEMGR_UNKNOWN_ZONE_SUCCESS zone %1 (class %2) is not known to the zone manager</span></dt><dd><p>
-An XFRIN operation has succeeded but the zone received is not being
-managed by the zone manager. This may indicate an error in the program
-(as the operation should not have been initiated if this were the case).
-Please submit a bug report.
-</p></dd></dl></div><p>
- </p></div></div></body></html>
diff --git a/doc/guide/bind10-messages.xml b/doc/guide/bind10-messages.xml
deleted file mode 100644
index c085cb1..0000000
--- a/doc/guide/bind10-messages.xml
+++ /dev/null
@@ -1,5896 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
-<!ENTITY mdash "—" >
-<!ENTITY % version SYSTEM "version.ent">
-%version;
-]>
-<!--
- This XML document is generated using the system_messages.py tool
- based on the .mes message files.
-
- Do not edit this file.
--->
-<book>
- <?xml-stylesheet href="bind10-guide.css" type="text/css"?>
-
- <bookinfo>
- <title>BIND 10 Messages Manual</title>
-
- <copyright>
- <year>2011-2012</year><holder>Internet Systems Consortium, Inc.</holder>
- </copyright>
-
- <abstract>
- <para>BIND 10 is a Domain Name System (DNS) suite managed by
- Internet Systems Consortium (ISC). It includes DNS libraries
- and modular components for controlling authoritative and
- recursive DNS servers.
- </para>
- <para>
- This is the messages manual for BIND 10 version &__VERSION__;.
- The most up-to-date version of this document, along with
- other documents for BIND 10, can be found at
- <ulink url="http://bind10.isc.org/docs"/>.
- </para>
- </abstract>
-
- <releaseinfo>This is the messages manual for BIND 10 version
- &__VERSION__;.</releaseinfo>
- </bookinfo>
-
- <chapter id="intro">
- <title>Introduction</title>
- <para>
- This document lists each message that can be logged by the
- programs in the BIND 10 package. Each entry in this manual
- is of the form:
- <screen>IDENTIFICATION message-text</screen>
- ... where "IDENTIFICATION" is the message identification included
- in each message logged and "message-text" is the accompanying
- message text. The "message-text" may include placeholders of the
- form "%1", "%2" etc.; these parameters are replaced by relevant
- values when the message is logged.
- </para>
- <para>
- Each entry is also accompanied by a description giving more
- information about the circumstances that result in the message
- being logged.
- </para>
- <para>
- For information on configuring and using BIND 10 logging,
- refer to the <ulink url="bind10-guide.html">BIND 10 Guide</ulink>.
- </para>
- </chapter>
-
- <chapter id="messages">
- <title>BIND 10 Messages</title>
- <para>
- <variablelist>
-
-<varlistentry id="ASIODNS_FD_ADD_TCP">
-<term>ASIODNS_FD_ADD_TCP adding a new TCP server by opened fd %1</term>
-<listitem><para>
-A debug message informing about installing a file descriptor as a server.
-The file descriptor number is noted.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_FD_ADD_UDP">
-<term>ASIODNS_FD_ADD_UDP adding a new UDP server by opened fd %1</term>
-<listitem><para>
-A debug message informing about installing a file descriptor as a server.
-The file descriptor number is noted.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_FETCH_COMPLETED">
-<term>ASIODNS_FETCH_COMPLETED upstream fetch to %1(%2) has now completed</term>
-<listitem><para>
-A debug message, this records that the upstream fetch (a query made by the
-resolver on behalf of its client) to the specified address has completed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_FETCH_STOPPED">
-<term>ASIODNS_FETCH_STOPPED upstream fetch to %1(%2) has been stopped</term>
-<listitem><para>
-An external component has requested the halting of an upstream fetch. This
-is an allowed operation, and the message should only appear if debug is
-enabled.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_OPEN_SOCKET">
-<term>ASIODNS_OPEN_SOCKET error %1 opening %2 socket to %3(%4)</term>
-<listitem><para>
-The asynchronous I/O code encountered an error when trying to open a socket
-of the specified protocol in order to send a message to the target address.
-The number of the system error that caused the problem is given in the
-message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_READ_DATA">
-<term>ASIODNS_READ_DATA error %1 reading %2 data from %3(%4)</term>
-<listitem><para>
-The asynchronous I/O code encountered an error when trying to read data from
-the specified address on the given protocol. The number of the system
-error that caused the problem is given in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_READ_TIMEOUT">
-<term>ASIODNS_READ_TIMEOUT receive timeout while waiting for data from %1(%2)</term>
-<listitem><para>
-An upstream fetch from the specified address timed out. This may happen for
-any number of reasons and is most probably a problem at the remote server
-or a problem on the network. The message will only appear if debug is
-enabled.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_SEND_DATA">
-<term>ASIODNS_SEND_DATA error %1 sending data using %2 to %3(%4)</term>
-<listitem><para>
-The asynchronous I/O code encountered an error when trying to send data to
-the specified address on the given protocol. The number of the system
-error that caused the problem is given in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_UNKNOWN_ORIGIN">
-<term>ASIODNS_UNKNOWN_ORIGIN unknown origin for ASIO error code %1 (protocol: %2, address %3)</term>
-<listitem><para>
-An internal consistency check on the origin of a message from the
-asynchronous I/O module failed. This may indicate an internal error;
-please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ASIODNS_UNKNOWN_RESULT">
-<term>ASIODNS_UNKNOWN_RESULT unknown result (%1) when IOFetch::stop() was executed for I/O to %2(%3)</term>
-<listitem><para>
-An internal error indicating that the termination method of the resolver's
-upstream fetch class was called with an unknown result code (which is
-given in the message). Please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_AXFR_ERROR">
-<term>AUTH_AXFR_ERROR error handling AXFR request: %1</term>
-<listitem><para>
-This is a debug message produced by the authoritative server when it
-has encountered an error processing an AXFR request. The message gives
-the reason for the error, and the server will return a SERVFAIL code to
-the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_AXFR_UDP">
-<term>AUTH_AXFR_UDP AXFR query received over UDP</term>
-<listitem><para>
-This is a debug message output when the authoritative server has received
-an AXFR query over UDP. Use of UDP for AXFRs is not permitted by the
-protocol, so the server will return a FORMERR error to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_COMMAND_FAILED">
-<term>AUTH_COMMAND_FAILED execution of command channel instruction '%1' failed: %2</term>
-<listitem><para>
-Execution of the specified command by the authoritative server failed. The
-message contains the reason for the failure.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_CONFIG_CHANNEL_CREATED">
-<term>AUTH_CONFIG_CHANNEL_CREATED configuration session channel created</term>
-<listitem><para>
-This is a debug message indicating that authoritative server has created
-the channel to the configuration manager. It is issued during server
-startup is an indication that the initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_CONFIG_CHANNEL_ESTABLISHED">
-<term>AUTH_CONFIG_CHANNEL_ESTABLISHED configuration session channel established</term>
-<listitem><para>
-This is a debug message indicating that authoritative server
-has established communication the configuration manager over the
-previously-created channel. It is issued during server startup is an
-indication that the initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_CONFIG_CHANNEL_STARTED">
-<term>AUTH_CONFIG_CHANNEL_STARTED configuration session channel started</term>
-<listitem><para>
-This is a debug message, issued when the authoritative server has
-posted a request to be notified when new configuration information is
-available. It is issued during server startup is an indication that
-the initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_CONFIG_LOAD_FAIL">
-<term>AUTH_CONFIG_LOAD_FAIL load of configuration failed: %1</term>
-<listitem><para>
-An attempt to configure the server with information from the configuration
-database during the startup sequence has failed. (The reason for
-the failure is given in the message.) The server will continue its
-initialization although it may not be configured in the desired way.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_CONFIG_UPDATE_FAIL">
-<term>AUTH_CONFIG_UPDATE_FAIL update of configuration failed: %1</term>
-<listitem><para>
-At attempt to update the configuration the server with information
-from the configuration database has failed, the reason being given in
-the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_DATA_SOURCE">
-<term>AUTH_DATA_SOURCE data source database file: %1</term>
-<listitem><para>
-This is a debug message produced by the authoritative server when it accesses a
-datebase data source, listing the file that is being accessed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_DNS_SERVICES_CREATED">
-<term>AUTH_DNS_SERVICES_CREATED DNS services created</term>
-<listitem><para>
-This is a debug message indicating that the component that will handling
-incoming queries for the authoritative server (DNSServices) has been
-successfully created. It is issued during server startup is an indication
-that the initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_HEADER_PARSE_FAIL">
-<term>AUTH_HEADER_PARSE_FAIL unable to parse header in received DNS packet: %1</term>
-<listitem><para>
-This is a debug message, generated by the authoritative server when an
-attempt to parse the header of a received DNS packet has failed. (The
-reason for the failure is given in the message.) The server will drop the
-packet.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_INVALID_STATISTICS_DATA">
-<term>AUTH_INVALID_STATISTICS_DATA invalid specification of statistics data specified</term>
-<listitem><para>
-An error was encountered when the authoritiative server specified
-statistics data which is invalid for the auth specification file.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_LOAD_TSIG">
-<term>AUTH_LOAD_TSIG loading TSIG keys</term>
-<listitem><para>
-This is a debug message indicating that the authoritative server
-has requested the keyring holding TSIG keys from the configuration
-database. It is issued during server startup is an indication that the
-initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_LOAD_ZONE">
-<term>AUTH_LOAD_ZONE loaded zone %1/%2</term>
-<listitem><para>
-This debug message is issued during the processing of the 'loadzone' command
-when the authoritative server has successfully loaded the named zone of the
-named class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_MEM_DATASRC_DISABLED">
-<term>AUTH_MEM_DATASRC_DISABLED memory data source is disabled for class %1</term>
-<listitem><para>
-This is a debug message reporting that the authoritative server has
-discovered that the memory data source is disabled for the given class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_MEM_DATASRC_ENABLED">
-<term>AUTH_MEM_DATASRC_ENABLED memory data source is enabled for class %1</term>
-<listitem><para>
-This is a debug message reporting that the authoritative server has
-discovered that the memory data source is enabled for the given class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_NOTIFY_QUESTIONS">
-<term>AUTH_NOTIFY_QUESTIONS invalid number of questions (%1) in incoming NOTIFY</term>
-<listitem><para>
-This debug message is logged by the authoritative server when it receives
-a NOTIFY packet that contains zero or more than one question. (A valid
-NOTIFY packet contains one question.) The server will return a FORMERR
-error to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_NOTIFY_RRTYPE">
-<term>AUTH_NOTIFY_RRTYPE invalid question RR type (%1) in incoming NOTIFY</term>
-<listitem><para>
-This debug message is logged by the authoritative server when it receives
-a NOTIFY packet that an RR type of something other than SOA in the
-question section. (The RR type received is included in the message.) The
-server will return a FORMERR error to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_NO_STATS_SESSION">
-<term>AUTH_NO_STATS_SESSION session interface for statistics is not available</term>
-<listitem><para>
-The authoritative server had no session with the statistics module at the
-time it attempted to send it data: the attempt has been abandoned. This
-could be an error in configuration.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_NO_XFRIN">
-<term>AUTH_NO_XFRIN received NOTIFY but XFRIN session is not running</term>
-<listitem><para>
-This is a debug message produced by the authoritative server when it receives
-a NOTIFY packet but the XFRIN process is not running. The packet will be
-dropped and nothing returned to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_PACKET_PARSE_ERROR">
-<term>AUTH_PACKET_PARSE_ERROR unable to parse received DNS packet: %1</term>
-<listitem><para>
-This is a debug message, generated by the authoritative server when an
-attempt to parse a received DNS packet has failed due to something other
-than a protocol error. The reason for the failure is given in the message;
-the server will return a SERVFAIL error code to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_PACKET_PROTOCOL_ERROR">
-<term>AUTH_PACKET_PROTOCOL_ERROR DNS packet protocol error: %1. Returning %2</term>
-<listitem><para>
-This is a debug message, generated by the authoritative server when an
-attempt to parse a received DNS packet has failed due to a protocol error.
-The reason for the failure is given in the message, as is the error code
-that will be returned to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_PACKET_RECEIVED">
-<term>AUTH_PACKET_RECEIVED message received:\n%1</term>
-<listitem><para>
-This is a debug message output by the authoritative server when it
-receives a valid DNS packet.
-</para><para>
-Note: This message includes the packet received, rendered in the form of
-multiple lines of text. For this reason, it is suggested that this log message
-not be routed to the syslog file, where the multiple lines could confuse
-programs that expect a format of one message per line.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_PROCESS_FAIL">
-<term>AUTH_PROCESS_FAIL message processing failure: %1</term>
-<listitem><para>
-This message is generated by the authoritative server when it has
-encountered an internal error whilst processing a received packet:
-the cause of the error is included in the message.
-</para><para>
-The server will return a SERVFAIL error code to the sender of the packet.
-This message indicates a potential error in the server. Please open a
-bug ticket for this issue.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_RECEIVED_COMMAND">
-<term>AUTH_RECEIVED_COMMAND command '%1' received</term>
-<listitem><para>
-This is a debug message issued when the authoritative server has received
-a command on the command channel.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_RECEIVED_SENDSTATS">
-<term>AUTH_RECEIVED_SENDSTATS command 'sendstats' received</term>
-<listitem><para>
-This is a debug message issued when the authoritative server has received
-a command from the statistics module to send it data. The 'sendstats'
-command is handled differently to other commands, which is why the debug
-message associated with it has its own code.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_RESPONSE_RECEIVED">
-<term>AUTH_RESPONSE_RECEIVED received response message, ignoring</term>
-<listitem><para>
-This is a debug message, this is output if the authoritative server
-receives a DNS packet with the QR bit set, i.e. a DNS response. The
-server ignores the packet as it only responds to question packets.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_SEND_ERROR_RESPONSE">
-<term>AUTH_SEND_ERROR_RESPONSE sending an error response (%1 bytes):\n%2</term>
-<listitem><para>
-This is a debug message recording that the authoritative server is sending
-an error response to the originator of the query. A previous message will
-have recorded details of the failure.
-</para><para>
-Note: This message includes the packet sent, rendered in the form of
-multiple lines of text. For this reason, it is suggested that this log message
-not be routed to the syslog file, where the multiple lines could confuse
-programs that expect a format of one message per line.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_SEND_NORMAL_RESPONSE">
-<term>AUTH_SEND_NORMAL_RESPONSE sending an error response (%1 bytes):\n%2</term>
-<listitem><para>
-This is a debug message recording that the authoritative server is sending
-a response to the originator of a query.
-</para><para>
-Note: This message includes the packet sent, rendered in the form of
-multiple lines of text. For this reason, it is suggested that this log message
-not be routed to the syslog file, where the multiple lines could confuse
-programs that expect a format of one message per line.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_SERVER_CREATED">
-<term>AUTH_SERVER_CREATED server created</term>
-<listitem><para>
-An informational message indicating that the authoritative server process has
-been created and is initializing. The AUTH_SERVER_STARTED message will be
-output when initialization has successfully completed and the server starts
-accepting queries.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_SERVER_FAILED">
-<term>AUTH_SERVER_FAILED server failed: %1</term>
-<listitem><para>
-The authoritative server has encountered a fatal error and is terminating. The
-reason for the failure is included in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_SERVER_STARTED">
-<term>AUTH_SERVER_STARTED server started</term>
-<listitem><para>
-Initialization of the authoritative server has completed successfully
-and it is entering the main loop, waiting for queries to arrive.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_SQLITE3">
-<term>AUTH_SQLITE3 nothing to do for loading sqlite3</term>
-<listitem><para>
-This is a debug message indicating that the authoritative server has
-found that the data source it is loading is an SQLite3 data source,
-so no further validation is needed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_STATS_CHANNEL_CREATED">
-<term>AUTH_STATS_CHANNEL_CREATED STATS session channel created</term>
-<listitem><para>
-This is a debug message indicating that the authoritative server has
-created a channel to the statistics process. It is issued during server
-startup is an indication that the initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_STATS_CHANNEL_ESTABLISHED">
-<term>AUTH_STATS_CHANNEL_ESTABLISHED STATS session channel established</term>
-<listitem><para>
-This is a debug message indicating that the authoritative server
-has established communication over the previously created statistics
-channel. It is issued during server startup is an indication that the
-initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_STATS_COMMS">
-<term>AUTH_STATS_COMMS communication error in sending statistics data: %1</term>
-<listitem><para>
-An error was encountered when the authoritative server tried to send data
-to the statistics daemon. The message includes additional information
-describing the reason for the failure.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_STATS_TIMEOUT">
-<term>AUTH_STATS_TIMEOUT timeout while sending statistics data: %1</term>
-<listitem><para>
-The authoritative server sent data to the statistics daemon but received
-no acknowledgement within the specified time. The message includes
-additional information describing the reason for the failure.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_STATS_TIMER_DISABLED">
-<term>AUTH_STATS_TIMER_DISABLED statistics timer has been disabled</term>
-<listitem><para>
-This is a debug message indicating that the statistics timer has been
-disabled in the authoritative server and no statistics information is
-being produced.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_STATS_TIMER_SET">
-<term>AUTH_STATS_TIMER_SET statistics timer set to %1 second(s)</term>
-<listitem><para>
-This is a debug message indicating that the statistics timer has been
-enabled and that the authoritative server will produce statistics data
-at the specified interval.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_UNSUPPORTED_OPCODE">
-<term>AUTH_UNSUPPORTED_OPCODE unsupported opcode: %1</term>
-<listitem><para>
-This is a debug message, produced when a received DNS packet being
-processed by the authoritative server has been found to contain an
-unsupported opcode. (The opcode is included in the message.) The server
-will return an error code of NOTIMPL to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_XFRIN_CHANNEL_CREATED">
-<term>AUTH_XFRIN_CHANNEL_CREATED XFRIN session channel created</term>
-<listitem><para>
-This is a debug message indicating that the authoritative server has
-created a channel to the XFRIN (Transfer-in) process. It is issued
-during server startup is an indication that the initialization is
-proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_XFRIN_CHANNEL_ESTABLISHED">
-<term>AUTH_XFRIN_CHANNEL_ESTABLISHED XFRIN session channel established</term>
-<listitem><para>
-This is a debug message indicating that the authoritative server has
-established communication over the previously-created channel to the
-XFRIN (Transfer-in) process. It is issued during server startup is an
-indication that the initialization is proceeding normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_ZONEMGR_COMMS">
-<term>AUTH_ZONEMGR_COMMS error communicating with zone manager: %1</term>
-<listitem><para>
-This is a debug message output during the processing of a NOTIFY request.
-An error (listed in the message) has been encountered whilst communicating
-with the zone manager. The NOTIFY request will not be honored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="AUTH_ZONEMGR_ERROR">
-<term>AUTH_ZONEMGR_ERROR received error response from zone manager: %1</term>
-<listitem><para>
-This is a debug message output during the processing of a NOTIFY
-request. The zone manager component has been informed of the request,
-but has returned an error response (which is included in the message). The
-NOTIFY request will not be honored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CHECK_MSGQ_ALREADY_RUNNING">
-<term>BIND10_CHECK_MSGQ_ALREADY_RUNNING checking if msgq is already running</term>
-<listitem><para>
-The boss process is starting up and will now check if the message bus
-daemon is already running. If so, it will not be able to start, as it
-needs a dedicated message bus.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_COMPONENT_FAILED">
-<term>BIND10_COMPONENT_FAILED component %1 (pid %2) failed with %3 exit status</term>
-<listitem><para>
-The process terminated, but the bind10 boss didn't expect it to, which means
-it must have failed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_COMPONENT_RESTART">
-<term>BIND10_COMPONENT_RESTART component %1 is about to restart</term>
-<listitem><para>
-The named component failed previously and we will try to restart it to provide
-as flawless service as possible, but it should be investigated what happened,
-as it could happen again.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_COMPONENT_START">
-<term>BIND10_COMPONENT_START component %1 is starting</term>
-<listitem><para>
-The named component is about to be started by the boss process.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_COMPONENT_START_EXCEPTION">
-<term>BIND10_COMPONENT_START_EXCEPTION component %1 failed to start: %2</term>
-<listitem><para>
-An exception (mentioned in the message) happened during the startup of the
-named component. The componet is not considered started and further actions
-will be taken about it.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_COMPONENT_STOP">
-<term>BIND10_COMPONENT_STOP component %1 is being stopped</term>
-<listitem><para>
-A component is about to be asked to stop willingly by the boss.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_COMPONENT_UNSATISFIED">
-<term>BIND10_COMPONENT_UNSATISFIED component %1 is required to run and failed</term>
-<listitem><para>
-A component failed for some reason (see previous messages). It is either a core
-component or needed component that was just started. In any case, the system
-can't continue without it and will terminate.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_BUILD">
-<term>BIND10_CONFIGURATOR_BUILD building plan '%1' -> '%2'</term>
-<listitem><para>
-A debug message. This indicates that the configurator is building a plan
-how to change configuration from the older one to newer one. This does no
-real work yet, it just does the planning what needs to be done.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_PLAN_INTERRUPTED">
-<term>BIND10_CONFIGURATOR_PLAN_INTERRUPTED configurator plan interrupted, only %1 of %2 done</term>
-<listitem><para>
-There was an exception during some planned task. The plan will not continue and
-only some tasks of the plan were completed. The rest is aborted. The exception
-will be propagated.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_RECONFIGURE">
-<term>BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components</term>
-<listitem><para>
-A different configuration of which components should be running is being
-installed. All components that are no longer needed will be stopped and
-newly introduced ones started. This happens at startup, when the configuration
-is read the first time, or when an operator changes configuration of the boss.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_RUN">
-<term>BIND10_CONFIGURATOR_RUN running plan of %1 tasks</term>
-<listitem><para>
-A debug message. The configurator is about to execute a plan of actions it
-computed previously.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_START">
-<term>BIND10_CONFIGURATOR_START bind10 component configurator is starting up</term>
-<listitem><para>
-The part that cares about starting and stopping the right component from the
-boss process is starting up. This happens only once at the startup of the
-boss process. It will start the basic set of processes now (the ones boss
-needs to read the configuration), the rest will be started after the
-configuration is known.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_STOP">
-<term>BIND10_CONFIGURATOR_STOP bind10 component configurator is shutting down</term>
-<listitem><para>
-The part that cares about starting and stopping processes in the boss is
-shutting down. All started components will be shut down now (more precisely,
-asked to terminate by their own, if they fail to comply, other parts of
-the boss process will try to force them).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_CONFIGURATOR_TASK">
-<term>BIND10_CONFIGURATOR_TASK performing task %1 on %2</term>
-<listitem><para>
-A debug message. The configurator is about to perform one task of the plan it
-is currently executing on the named component.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_INVALID_STATISTICS_DATA">
-<term>BIND10_INVALID_STATISTICS_DATA invalid specification of statistics data specified</term>
-<listitem><para>
-An error was encountered when the boss module specified
-statistics data which is invalid for the boss specification file.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_INVALID_USER">
-<term>BIND10_INVALID_USER invalid user: %1</term>
-<listitem><para>
-The boss process was started with the -u option, to drop root privileges
-and continue running as the specified user, but the user is unknown.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_KILLING_ALL_PROCESSES">
-<term>BIND10_KILLING_ALL_PROCESSES killing all started processes</term>
-<listitem><para>
-The boss module was not able to start every process it needed to start
-during startup, and will now kill the processes that did get started.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_KILL_PROCESS">
-<term>BIND10_KILL_PROCESS killing process %1</term>
-<listitem><para>
-The boss module is sending a kill signal to process with the given name,
-as part of the process of killing all started processes during a failed
-startup, as described for BIND10_KILLING_ALL_PROCESSES
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_LOST_SOCKET_CONSUMER">
-<term>BIND10_LOST_SOCKET_CONSUMER consumer %1 of sockets disconnected, considering all its sockets closed</term>
-<listitem><para>
-A connection from one of the applications which requested a socket was
-closed. This means the application has terminated, so all the sockets it was
-using are now closed and bind10 process can release them as well, unless the
-same sockets are used by yet another application.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_MSGQ_ALREADY_RUNNING">
-<term>BIND10_MSGQ_ALREADY_RUNNING msgq daemon already running, cannot start</term>
-<listitem><para>
-There already appears to be a message bus daemon running. Either an
-old process was not shut down correctly, and needs to be killed, or
-another instance of BIND10, with the same msgq domain socket, is
-running, which needs to be stopped.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_MSGQ_DISAPPEARED">
-<term>BIND10_MSGQ_DISAPPEARED msgq channel disappeared</term>
-<listitem><para>
-While listening on the message bus channel for messages, it suddenly
-disappeared. The msgq daemon may have died. This might lead to an
-inconsistent state of the system, and BIND 10 will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_NO_SOCKET">
-<term>BIND10_NO_SOCKET couldn't send a socket for token %1 because of error: %2</term>
-<listitem><para>
-An error occurred when the bind10 process was asked to send a socket file
-descriptor. The error is mentioned, most common reason is that the request
-is invalid and may not come from bind10 process at all.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_PROCESS_ENDED">
-<term>BIND10_PROCESS_ENDED process %2 of %1 ended with status %3</term>
-<listitem><para>
-This indicates a process started previously terminated. The process id
-and component owning the process are indicated, as well as the exit code.
-This doesn't distinguish if the process was supposed to terminate or not.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_READING_BOSS_CONFIGURATION">
-<term>BIND10_READING_BOSS_CONFIGURATION reading boss configuration</term>
-<listitem><para>
-The boss process is starting up, and will now process the initial
-configuration, as received from the configuration manager.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_RECEIVED_COMMAND">
-<term>BIND10_RECEIVED_COMMAND received command: %1</term>
-<listitem><para>
-The boss module received a command and shall now process it. The command
-is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_RECEIVED_NEW_CONFIGURATION">
-<term>BIND10_RECEIVED_NEW_CONFIGURATION received new configuration: %1</term>
-<listitem><para>
-The boss module received a configuration update and is going to apply
-it now. The new configuration is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_RECEIVED_SIGNAL">
-<term>BIND10_RECEIVED_SIGNAL received signal %1</term>
-<listitem><para>
-The boss module received the given signal.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_RESURRECTED_PROCESS">
-<term>BIND10_RESURRECTED_PROCESS resurrected %1 (PID %2)</term>
-<listitem><para>
-The given process has been restarted successfully, and is now running
-with the given process id.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_RESURRECTING_PROCESS">
-<term>BIND10_RESURRECTING_PROCESS resurrecting dead %1 process...</term>
-<listitem><para>
-The given process has ended unexpectedly, and is now restarted.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SELECT_ERROR">
-<term>BIND10_SELECT_ERROR error in select() call: %1</term>
-<listitem><para>
-There was a fatal error in the call to select(), used to see if a child
-process has ended or if there is a message on the message bus. This
-should not happen under normal circumstances and is considered fatal,
-so BIND 10 will now shut down. The specific error is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SEND_SIGKILL">
-<term>BIND10_SEND_SIGKILL sending SIGKILL to %1 (PID %2)</term>
-<listitem><para>
-The boss module is sending a SIGKILL signal to the given process.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SEND_SIGTERM">
-<term>BIND10_SEND_SIGTERM sending SIGTERM to %1 (PID %2)</term>
-<listitem><para>
-The boss module is sending a SIGTERM signal to the given process.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SETUID">
-<term>BIND10_SETUID setting UID to %1</term>
-<listitem><para>
-The boss switches the user it runs as to the given UID.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SHUTDOWN">
-<term>BIND10_SHUTDOWN stopping the server</term>
-<listitem><para>
-The boss process received a command or signal telling it to shut down.
-It will send a shutdown command to each process. The processes that do
-not shut down will then receive a SIGTERM signal. If that doesn't work,
-it shall send SIGKILL signals to the processes still alive.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SHUTDOWN_COMPLETE">
-<term>BIND10_SHUTDOWN_COMPLETE all processes ended, shutdown complete</term>
-<listitem><para>
-All child processes have been stopped, and the boss process will now
-stop itself.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_BAD_CAUSE">
-<term>BIND10_SOCKCREATOR_BAD_CAUSE unknown error cause from socket creator: %1</term>
-<listitem><para>
-The socket creator reported an error when creating a socket. But the function
-which failed is unknown (not one of 'S' for socket or 'B' for bind).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_BAD_RESPONSE">
-<term>BIND10_SOCKCREATOR_BAD_RESPONSE unknown response for socket request: %1</term>
-<listitem><para>
-The boss requested a socket from the creator, but the answer is unknown. This
-looks like a programmer error.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_EOF">
-<term>BIND10_SOCKCREATOR_EOF eof while expecting data from socket creator</term>
-<listitem><para>
-There should be more data from the socket creator, but it closed the socket.
-It probably crashed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_INIT">
-<term>BIND10_SOCKCREATOR_INIT initializing socket creator parser</term>
-<listitem><para>
-The boss module initializes routines for parsing the socket creator
-protocol.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_KILL">
-<term>BIND10_SOCKCREATOR_KILL killing the socket creator</term>
-<listitem><para>
-The socket creator is being terminated the aggressive way, by sending it
-sigkill. This should not happen usually.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_TERMINATE">
-<term>BIND10_SOCKCREATOR_TERMINATE terminating socket creator</term>
-<listitem><para>
-The boss module sends a request to terminate to the socket creator.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKCREATOR_TRANSPORT_ERROR">
-<term>BIND10_SOCKCREATOR_TRANSPORT_ERROR transport error when talking to the socket creator: %1</term>
-<listitem><para>
-Either sending or receiving data from the socket creator failed with the given
-error. The creator probably crashed or some serious OS-level problem happened,
-as the communication happens only on local host.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKET_CREATED">
-<term>BIND10_SOCKET_CREATED successfully created socket %1</term>
-<listitem><para>
-The socket creator successfully created and sent a requested socket, it has
-the given file number.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKET_ERROR">
-<term>BIND10_SOCKET_ERROR error on %1 call in the creator: %2/%3</term>
-<listitem><para>
-The socket creator failed to create the requested socket. It failed on the
-indicated OS API function with given error.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_SOCKET_GET">
-<term>BIND10_SOCKET_GET requesting socket [%1]:%2 of type %3 from the creator</term>
-<listitem><para>
-The boss forwards a request for a socket to the socket creator.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTED_CC">
-<term>BIND10_STARTED_CC started configuration/command session</term>
-<listitem><para>
-Debug message given when BIND 10 has successfull started the object that
-handles configuration and commands.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTED_PROCESS">
-<term>BIND10_STARTED_PROCESS started %1</term>
-<listitem><para>
-The given process has successfully been started.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTED_PROCESS_PID">
-<term>BIND10_STARTED_PROCESS_PID started %1 (PID %2)</term>
-<listitem><para>
-The given process has successfully been started, and has the given PID.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTING">
-<term>BIND10_STARTING starting BIND10: %1</term>
-<listitem><para>
-Informational message on startup that shows the full version.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTING_CC">
-<term>BIND10_STARTING_CC starting configuration/command session</term>
-<listitem><para>
-Informational message given when BIND 10 is starting the session object
-that handles configuration and commands.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTING_PROCESS">
-<term>BIND10_STARTING_PROCESS starting process %1</term>
-<listitem><para>
-The boss module is starting the given process.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTING_PROCESS_PORT">
-<term>BIND10_STARTING_PROCESS_PORT starting process %1 (to listen on port %2)</term>
-<listitem><para>
-The boss module is starting the given process, which will listen on the
-given port number.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTING_PROCESS_PORT_ADDRESS">
-<term>BIND10_STARTING_PROCESS_PORT_ADDRESS starting process %1 (to listen on %2#%3)</term>
-<listitem><para>
-The boss module is starting the given process, which will listen on the
-given address and port number (written as <address>#<port>).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTUP_COMPLETE">
-<term>BIND10_STARTUP_COMPLETE BIND 10 started</term>
-<listitem><para>
-All modules have been successfully started, and BIND 10 is now running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTUP_ERROR">
-<term>BIND10_STARTUP_ERROR error during startup: %1</term>
-<listitem><para>
-There was a fatal error when BIND10 was trying to start. The error is
-shown, and BIND10 will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTUP_UNEXPECTED_MESSAGE">
-<term>BIND10_STARTUP_UNEXPECTED_MESSAGE unrecognised startup message %1</term>
-<listitem><para>
-During the startup process, a number of messages are exchanged between the
-Boss process and the processes it starts. This error is output when a
-message received by the Boss process is recognised as being of the
-correct format but is unexpected. It may be that processes are starting
-of sequence.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STARTUP_UNRECOGNISED_MESSAGE">
-<term>BIND10_STARTUP_UNRECOGNISED_MESSAGE unrecognised startup message %1</term>
-<listitem><para>
-During the startup process, a number of messages are exchanged between the
-Boss process and the processes it starts. This error is output when a
-message received by the Boss process is not recognised.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_START_AS_NON_ROOT_AUTH">
-<term>BIND10_START_AS_NON_ROOT_AUTH starting b10-auth as a user, not root. This might fail.</term>
-<listitem><para>
-The authoritative server is being started or restarted without root privileges.
-If the module needs these privileges, it may have problems starting.
-Note that this issue should be resolved by the pending 'socket-creator'
-process; once that has been implemented, modules should not need root
-privileges anymore. See tickets #800 and #801 for more information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_START_AS_NON_ROOT_RESOLVER">
-<term>BIND10_START_AS_NON_ROOT_RESOLVER starting b10-resolver as a user, not root. This might fail.</term>
-<listitem><para>
-The resolver is being started or restarted without root privileges.
-If the module needs these privileges, it may have problems starting.
-Note that this issue should be resolved by the pending 'socket-creator'
-process; once that has been implemented, modules should not need root
-privileges anymore. See tickets #800 and #801 for more information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_STOP_PROCESS">
-<term>BIND10_STOP_PROCESS asking %1 to shut down</term>
-<listitem><para>
-The boss module is sending a shutdown command to the given module over
-the message channel.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_UNKNOWN_CHILD_PROCESS_ENDED">
-<term>BIND10_UNKNOWN_CHILD_PROCESS_ENDED unknown child pid %1 exited</term>
-<listitem><para>
-An unknown child process has exited. The PID is printed, but no further
-action will be taken by the boss process.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="BIND10_WAIT_CFGMGR">
-<term>BIND10_WAIT_CFGMGR waiting for configuration manager process to initialize</term>
-<listitem><para>
-The configuration manager process is so critical to operation of BIND 10
-that after starting it, the Boss module will wait for it to initialize
-itself before continuing. This debug message is produced during the
-wait and may be output zero or more times depending on how long it takes
-the configuration manager to start up. The total length of time Boss
-will wait for the configuration manager before reporting an error is
-set with the command line --wait switch, which has a default value of
-ten seconds.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_ENTRY_MISSING_RRSET">
-<term>CACHE_ENTRY_MISSING_RRSET missing RRset to generate message for %1</term>
-<listitem><para>
-The cache tried to generate the complete answer message. It knows the structure
-of the message, but some of the RRsets to be put there are not in cache (they
-probably expired already). Therefore it pretends the message was not found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_LOCALZONE_FOUND">
-<term>CACHE_LOCALZONE_FOUND found entry with key %1 in local zone data</term>
-<listitem><para>
-Debug message, noting that the requested data was successfully found in the
-local zone data of the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_LOCALZONE_UNKNOWN">
-<term>CACHE_LOCALZONE_UNKNOWN entry with key %1 not found in local zone data</term>
-<listitem><para>
-Debug message. The requested data was not found in the local zone data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_LOCALZONE_UPDATE">
-<term>CACHE_LOCALZONE_UPDATE updating local zone element at key %1</term>
-<listitem><para>
-Debug message issued when there's update to the local zone section of cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_DEINIT">
-<term>CACHE_MESSAGES_DEINIT deinitialized message cache</term>
-<listitem><para>
-Debug message. It is issued when the server deinitializes the message cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_EXPIRED">
-<term>CACHE_MESSAGES_EXPIRED found an expired message entry for %1 in the message cache</term>
-<listitem><para>
-Debug message. The requested data was found in the message cache, but it
-already expired. Therefore the cache removes the entry and pretends it found
-nothing.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_FOUND">
-<term>CACHE_MESSAGES_FOUND found a message entry for %1 in the message cache</term>
-<listitem><para>
-Debug message. We found the whole message in the cache, so it can be returned
-to user without any other lookups.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_INIT">
-<term>CACHE_MESSAGES_INIT initialized message cache for %1 messages of class %2</term>
-<listitem><para>
-Debug message issued when a new message cache is issued. It lists the class
-of messages it can hold and the maximum size of the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_REMOVE">
-<term>CACHE_MESSAGES_REMOVE removing old instance of %1/%2/%3 first</term>
-<listitem><para>
-Debug message. This may follow CACHE_MESSAGES_UPDATE and indicates that, while
-updating, the old instance is being removed prior of inserting a new one.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_UNCACHEABLE">
-<term>CACHE_MESSAGES_UNCACHEABLE not inserting uncacheable message %1/%2/%3</term>
-<listitem><para>
-Debug message, noting that the given message can not be cached. This is because
-there's no SOA record in the message. See RFC 2308 section 5 for more
-information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_UNKNOWN">
-<term>CACHE_MESSAGES_UNKNOWN no entry for %1 found in the message cache</term>
-<listitem><para>
-Debug message. The message cache didn't find any entry for the given key.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_MESSAGES_UPDATE">
-<term>CACHE_MESSAGES_UPDATE updating message entry %1/%2/%3</term>
-<listitem><para>
-Debug message issued when the message cache is being updated with a new
-message. Either the old instance is removed or, if none is found, new one
-is created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_DEEPEST">
-<term>CACHE_RESOLVER_DEEPEST looking up deepest NS for %1/%2</term>
-<listitem><para>
-Debug message. The resolver cache is looking up the deepest known nameserver,
-so the resolution doesn't have to start from the root.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_INIT">
-<term>CACHE_RESOLVER_INIT initializing resolver cache for class %1</term>
-<listitem><para>
-Debug message. The resolver cache is being created for this given class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_INIT_INFO">
-<term>CACHE_RESOLVER_INIT_INFO initializing resolver cache for class %1</term>
-<listitem><para>
-Debug message, the resolver cache is being created for this given class. The
-difference from CACHE_RESOLVER_INIT is only in different format of passed
-information, otherwise it does the same.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_LOCAL_MSG">
-<term>CACHE_RESOLVER_LOCAL_MSG message for %1/%2 found in local zone data</term>
-<listitem><para>
-Debug message. The resolver cache found a complete message for the user query
-in the zone data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_LOCAL_RRSET">
-<term>CACHE_RESOLVER_LOCAL_RRSET RRset for %1/%2 found in local zone data</term>
-<listitem><para>
-Debug message. The resolver cache found a requested RRset in the local zone
-data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_LOOKUP_MSG">
-<term>CACHE_RESOLVER_LOOKUP_MSG looking up message in resolver cache for %1/%2</term>
-<listitem><para>
-Debug message. The resolver cache is trying to find a message to answer the
-user query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_LOOKUP_RRSET">
-<term>CACHE_RESOLVER_LOOKUP_RRSET looking up RRset in resolver cache for %1/%2</term>
-<listitem><para>
-Debug message. The resolver cache is trying to find an RRset (which usually
-originates as internally from resolver).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_NO_QUESTION">
-<term>CACHE_RESOLVER_NO_QUESTION answer message for %1/%2 has empty question section</term>
-<listitem><para>
-The cache tried to fill in found data into the response message. But it
-discovered the message contains no question section, which is invalid.
-This is likely a programmer error, please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_UNKNOWN_CLASS_MSG">
-<term>CACHE_RESOLVER_UNKNOWN_CLASS_MSG no cache for class %1</term>
-<listitem><para>
-Debug message. While trying to lookup a message in the resolver cache, it was
-discovered there's no cache for this class at all. Therefore no message is
-found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_UNKNOWN_CLASS_RRSET">
-<term>CACHE_RESOLVER_UNKNOWN_CLASS_RRSET no cache for class %1</term>
-<listitem><para>
-Debug message. While trying to lookup an RRset in the resolver cache, it was
-discovered there's no cache for this class at all. Therefore no data is found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_UPDATE_MSG">
-<term>CACHE_RESOLVER_UPDATE_MSG updating message for %1/%2/%3</term>
-<listitem><para>
-Debug message. The resolver is updating a message in the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_UPDATE_RRSET">
-<term>CACHE_RESOLVER_UPDATE_RRSET updating RRset for %1/%2/%3</term>
-<listitem><para>
-Debug message. The resolver is updating an RRset in the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_MSG">
-<term>CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_MSG no cache for class %1</term>
-<listitem><para>
-Debug message. While trying to insert a message into the cache, it was
-discovered that there's no cache for the class of message. Therefore
-the message will not be cached.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_RRSET">
-<term>CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_RRSET no cache for class %1</term>
-<listitem><para>
-Debug message. While trying to insert an RRset into the cache, it was
-discovered that there's no cache for the class of the RRset. Therefore
-the message will not be cached.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_EXPIRED">
-<term>CACHE_RRSET_EXPIRED found expired RRset %1/%2/%3</term>
-<listitem><para>
-Debug message. The requested data was found in the RRset cache. However, it is
-expired, so the cache removed it and is going to pretend nothing was found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_INIT">
-<term>CACHE_RRSET_INIT initializing RRset cache for %1 RRsets of class %2</term>
-<listitem><para>
-Debug message. The RRset cache to hold at most this many RRsets for the given
-class is being created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_LOOKUP">
-<term>CACHE_RRSET_LOOKUP looking up %1/%2/%3 in RRset cache</term>
-<listitem><para>
-Debug message. The resolver is trying to look up data in the RRset cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_NOT_FOUND">
-<term>CACHE_RRSET_NOT_FOUND no RRset found for %1/%2/%3 in cache</term>
-<listitem><para>
-Debug message which can follow CACHE_RRSET_LOOKUP. This means the data is not
-in the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_REMOVE_OLD">
-<term>CACHE_RRSET_REMOVE_OLD removing old RRset for %1/%2/%3 to make space for new one</term>
-<listitem><para>
-Debug message which can follow CACHE_RRSET_UPDATE. During the update, the cache
-removed an old instance of the RRset to replace it with the new one.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_UNTRUSTED">
-<term>CACHE_RRSET_UNTRUSTED not replacing old RRset for %1/%2/%3, it has higher trust level</term>
-<listitem><para>
-Debug message which can follow CACHE_RRSET_UPDATE. The cache already holds the
-same RRset, but from more trusted source, so the old one is kept and new one
-ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CACHE_RRSET_UPDATE">
-<term>CACHE_RRSET_UPDATE updating RRset %1/%2/%3 in the cache</term>
-<listitem><para>
-Debug message. The RRset is updating its data with this given RRset.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_ASYNC_READ_FAILED">
-<term>CC_ASYNC_READ_FAILED asynchronous read failed</term>
-<listitem><para>
-This marks a low level error, we tried to read data from the message queue
-daemon asynchronously, but the ASIO library returned an error.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_CONN_ERROR">
-<term>CC_CONN_ERROR error connecting to message queue (%1)</term>
-<listitem><para>
-It is impossible to reach the message queue daemon for the reason given. It
-is unlikely there'll be reason for whatever program this currently is to
-continue running, as the communication with the rest of BIND 10 is vital
-for the components.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_DISCONNECT">
-<term>CC_DISCONNECT disconnecting from message queue daemon</term>
-<listitem><para>
-The library is disconnecting from the message queue daemon. This debug message
-indicates that the program is trying to shut down gracefully.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_ESTABLISH">
-<term>CC_ESTABLISH trying to establish connection with message queue daemon at %1</term>
-<listitem><para>
-This debug message indicates that the command channel library is about to
-connect to the message queue daemon, which should be listening on the UNIX-domain
-socket listed in the output.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_ESTABLISHED">
-<term>CC_ESTABLISHED successfully connected to message queue daemon</term>
-<listitem><para>
-This debug message indicates that the connection was successfully made, this
-should follow CC_ESTABLISH.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_GROUP_RECEIVE">
-<term>CC_GROUP_RECEIVE trying to receive a message</term>
-<listitem><para>
-Debug message, noting that a message is expected to come over the command
-channel.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_GROUP_RECEIVED">
-<term>CC_GROUP_RECEIVED message arrived ('%1', '%2')</term>
-<listitem><para>
-Debug message, noting that we successfully received a message (its envelope and
-payload listed). This follows CC_GROUP_RECEIVE, but might happen some time
-later, depending if we waited for it or just polled.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_GROUP_SEND">
-<term>CC_GROUP_SEND sending message '%1' to group '%2'</term>
-<listitem><para>
-Debug message, we're about to send a message over the command channel.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_INVALID_LENGTHS">
-<term>CC_INVALID_LENGTHS invalid length parameters (%1, %2)</term>
-<listitem><para>
-This happens when garbage comes over the command channel or some kind of
-confusion happens in the program. The data received from the socket make no
-sense if we interpret it as lengths of message. The first one is total length
-of the message; the second is the length of the header. The header
-and its length (2 bytes) is counted in the total length.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_LENGTH_NOT_READY">
-<term>CC_LENGTH_NOT_READY length not ready</term>
-<listitem><para>
-There should be data representing the length of message on the socket, but it
-is not there.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_NO_MESSAGE">
-<term>CC_NO_MESSAGE no message ready to be received yet</term>
-<listitem><para>
-The program polled for incoming messages, but there was no message waiting.
-This is a debug message which may happen only after CC_GROUP_RECEIVE.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_NO_MSGQ">
-<term>CC_NO_MSGQ unable to connect to message queue (%1)</term>
-<listitem><para>
-It isn't possible to connect to the message queue daemon, for reason listed.
-It is unlikely any program will be able continue without the communication.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_READ_ERROR">
-<term>CC_READ_ERROR error reading data from command channel (%1)</term>
-<listitem><para>
-A low level error happened when the library tried to read data from the
-command channel socket. The reason is listed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_READ_EXCEPTION">
-<term>CC_READ_EXCEPTION error reading data from command channel (%1)</term>
-<listitem><para>
-We received an exception while trying to read data from the command
-channel socket. The reason is listed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_REPLY">
-<term>CC_REPLY replying to message from '%1' with '%2'</term>
-<listitem><para>
-Debug message, noting we're sending a response to the original message
-with the given envelope.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_SET_TIMEOUT">
-<term>CC_SET_TIMEOUT setting timeout to %1ms</term>
-<listitem><para>
-Debug message. A timeout for which the program is willing to wait for a reply
-is being set.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_START_READ">
-<term>CC_START_READ starting asynchronous read</term>
-<listitem><para>
-Debug message. From now on, when a message (or command) comes, it'll wake the
-program and the library will automatically pass it over to correct place.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_SUBSCRIBE">
-<term>CC_SUBSCRIBE subscribing to communication group %1</term>
-<listitem><para>
-Debug message. The program wants to receive messages addressed to this group.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_TIMEOUT">
-<term>CC_TIMEOUT timeout reading data from command channel</term>
-<listitem><para>
-The program waited too long for data from the command channel (usually when it
-sent a query to different program and it didn't answer for whatever reason).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_UNSUBSCRIBE">
-<term>CC_UNSUBSCRIBE unsubscribing from communication group %1</term>
-<listitem><para>
-Debug message. The program no longer wants to receive messages addressed to
-this group.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_WRITE_ERROR">
-<term>CC_WRITE_ERROR error writing data to command channel (%1)</term>
-<listitem><para>
-A low level error happened when the library tried to write data to the command
-channel socket.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CC_ZERO_LENGTH">
-<term>CC_ZERO_LENGTH invalid message length (0)</term>
-<listitem><para>
-The library received a message length being zero, which makes no sense, since
-all messages must contain at least the envelope.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_AUTOMATIC_CONFIG_DATABASE_UPDATE">
-<term>CFGMGR_AUTOMATIC_CONFIG_DATABASE_UPDATE Updating configuration database from version %1 to %2</term>
-<listitem><para>
-An older version of the configuration database has been found, from which
-there was an automatic upgrade path to the current version. These changes
-are now applied, and no action from the administrator is necessary.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE">
-<term>CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE Unable to parse response from module %1: %2</term>
-<listitem><para>
-The configuration manager sent a configuration update to a module, but
-the module responded with an answer that could not be parsed. The answer
-message appears to be invalid JSON data, or not decodable to a string.
-This is likely to be a problem in the module in question. The update is
-assumed to have failed, and will not be stored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_CC_SESSION_ERROR">
-<term>CFGMGR_CC_SESSION_ERROR Error connecting to command channel: %1</term>
-<listitem><para>
-The configuration manager daemon was unable to connect to the messaging
-system. The most likely cause is that msgq is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_DATA_READ_ERROR">
-<term>CFGMGR_DATA_READ_ERROR error reading configuration database from disk: %1</term>
-<listitem><para>
-There was a problem reading the persistent configuration data as stored
-on disk. The file may be corrupted, or it is of a version from where
-there is no automatic upgrade path. The file needs to be repaired or
-removed. The configuration manager daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_IOERROR_WHILE_WRITING_CONFIGURATION">
-<term>CFGMGR_IOERROR_WHILE_WRITING_CONFIGURATION Unable to write configuration file; configuration not stored: %1</term>
-<listitem><para>
-There was an IO error from the system while the configuration manager
-was trying to write the configuration database to disk. The specific
-error is given. The most likely cause is that the directory where
-the file is stored does not exist, or is not writable. The updated
-configuration is not stored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_OSERROR_WHILE_WRITING_CONFIGURATION">
-<term>CFGMGR_OSERROR_WHILE_WRITING_CONFIGURATION Unable to write configuration file; configuration not stored: %1</term>
-<listitem><para>
-There was an OS error from the system while the configuration manager
-was trying to write the configuration database to disk. The specific
-error is given. The most likely cause is that the system does not have
-write access to the configuration database file. The updated
-configuration is not stored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CFGMGR_STOPPED_BY_KEYBOARD">
-<term>CFGMGR_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the cfgmgr daemon. The
-daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_BAD_CONFIG_DATA">
-<term>CMDCTL_BAD_CONFIG_DATA error in config data: %1</term>
-<listitem><para>
-There was an error reading the updated configuration data. The specific
-error is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_BAD_PASSWORD">
-<term>CMDCTL_BAD_PASSWORD bad password for user: %1</term>
-<listitem><para>
-A login attempt was made to b10-cmdctl, but the password was wrong.
-Users can be managed with the tool b10-cmdctl-usermgr.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_CC_SESSION_ERROR">
-<term>CMDCTL_CC_SESSION_ERROR error reading from cc channel: %1</term>
-<listitem><para>
-There was a problem reading from the command and control channel. The
-most likely cause is that the message bus daemon is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_CC_SESSION_TIMEOUT">
-<term>CMDCTL_CC_SESSION_TIMEOUT timeout on cc channel</term>
-<listitem><para>
-A timeout occurred when waiting for essential data from the cc session.
-This usually occurs when b10-cfgmgr is not running or not responding.
-Since we are waiting for essential information, this is a fatal error,
-and the cmdctl daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_COMMAND_ERROR">
-<term>CMDCTL_COMMAND_ERROR error in command %1 to module %2: %3</term>
-<listitem><para>
-An error was encountered sending the given command to the given module.
-Either there was a communication problem with the module, or the module
-was not able to process the command, and sent back an error. The
-specific error is printed in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_COMMAND_SENT">
-<term>CMDCTL_COMMAND_SENT command '%1' to module '%2' was sent</term>
-<listitem><para>
-This debug message indicates that the given command has been sent to
-the given module.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_NO_SUCH_USER">
-<term>CMDCTL_NO_SUCH_USER username not found in user database: %1</term>
-<listitem><para>
-A login attempt was made to b10-cmdctl, but the username was not known.
-Users can be added with the tool b10-cmdctl-usermgr.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_NO_USER_ENTRIES_READ">
-<term>CMDCTL_NO_USER_ENTRIES_READ failed to read user information, all users will be denied</term>
-<listitem><para>
-The b10-cmdctl daemon was unable to find any user data in the user
-database file. Either it was unable to read the file (in which case
-this message follows a message CMDCTL_USER_DATABASE_READ_ERROR
-containing a specific error), or the file was empty. Users can be added
-with the tool b10-cmdctl-usermgr.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_SEND_COMMAND">
-<term>CMDCTL_SEND_COMMAND sending command %1 to module %2</term>
-<listitem><para>
-This debug message indicates that the given command is being sent to
-the given module.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_SSL_SETUP_FAILURE_USER_DENIED">
-<term>CMDCTL_SSL_SETUP_FAILURE_USER_DENIED failed to create an SSL connection (user denied): %1</term>
-<listitem><para>
-The user was denied because the SSL connection could not successfully
-be set up. The specific error is given in the log message. Possible
-causes may be that the ssl request itself was bad, or the local key or
-certificate file could not be read.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_STARTED">
-<term>CMDCTL_STARTED cmdctl is listening for connections on %1:%2</term>
-<listitem><para>
-The cmdctl daemon has started and is now listening for connections.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_STOPPED_BY_KEYBOARD">
-<term>CMDCTL_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the cmdctl daemon. The
-daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_UNCAUGHT_EXCEPTION">
-<term>CMDCTL_UNCAUGHT_EXCEPTION uncaught exception: %1</term>
-<listitem><para>
-The b10-cmdctl daemon encountered an uncaught exception and
-will now shut down. This is indicative of a programming error and
-should not happen under normal circumstances. The exception message
-is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CMDCTL_USER_DATABASE_READ_ERROR">
-<term>CMDCTL_USER_DATABASE_READ_ERROR failed to read user database file %1: %2</term>
-<listitem><para>
-The b10-cmdctl daemon was unable to read the user database file. The
-file may be unreadable for the daemon, or it may be corrupted. In the
-latter case, it can be recreated with b10-cmdctl-usermgr. The specific
-error is printed in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_CCSESSION_MSG">
-<term>CONFIG_CCSESSION_MSG error in CC session message: %1</term>
-<listitem><para>
-There was a problem with an incoming message on the command and control
-channel. The message does not appear to be a valid command, and is
-missing a required element or contains an unknown data format. This
-most likely means that another BIND10 module is sending a bad message.
-The message itself is ignored by this module.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_CCSESSION_MSG_INTERNAL">
-<term>CONFIG_CCSESSION_MSG_INTERNAL error handling CC session message: %1</term>
-<listitem><para>
-There was an internal problem handling an incoming message on the command
-and control channel. An unexpected exception was thrown, details of
-which are appended to the message. The module will continue to run,
-but will not send back an answer.
-</para><para>
-The most likely cause of this error is a programming error. Please raise
-a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_GET_FAIL">
-<term>CONFIG_GET_FAIL error getting configuration from cfgmgr: %1</term>
-<listitem><para>
-The configuration manager returned an error when this module requested
-the configuration. The full error message answer from the configuration
-manager is appended to the log error. The most likely cause is that
-the module is of a different (command specification) version than the
-running configuration manager.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_GET_FAILED">
-<term>CONFIG_GET_FAILED error getting configuration from cfgmgr: %1</term>
-<listitem><para>
-The configuration manager returned an error response when the module
-requested its configuration. The full error message answer from the
-configuration manager is appended to the log error.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_JSON_PARSE">
-<term>CONFIG_JSON_PARSE JSON parse error in %1: %2</term>
-<listitem><para>
-There was an error parsing the JSON file. The given file does not appear
-to be in valid JSON format. Please verify that the filename is correct
-and that the contents are valid JSON.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_LOG_CONFIG_ERRORS">
-<term>CONFIG_LOG_CONFIG_ERRORS error(s) in logging configuration: %1</term>
-<listitem><para>
-There was a logging configuration update, but the internal validator
-for logging configuration found that it contained errors. The errors
-are shown, and the update is ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_LOG_EXPLICIT">
-<term>CONFIG_LOG_EXPLICIT will use logging configuration for explicitly-named logger %1</term>
-<listitem><para>
-This is a debug message. When processing the "loggers" part of the
-configuration file, the configuration library found an entry for the named
-logger that matches the logger specification for the program. The logging
-configuration for the program will be updated with the information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_LOG_IGNORE_EXPLICIT">
-<term>CONFIG_LOG_IGNORE_EXPLICIT ignoring logging configuration for explicitly-named logger %1</term>
-<listitem><para>
-This is a debug message. When processing the "loggers" part of the
-configuration file, the configuration library found an entry for the
-named logger. As this does not match the logger specification for the
-program, it has been ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_LOG_IGNORE_WILD">
-<term>CONFIG_LOG_IGNORE_WILD ignoring logging configuration for wildcard logger %1</term>
-<listitem><para>
-This is a debug message. When processing the "loggers" part of the
-configuration file, the configuration library found the named wildcard
-entry (one containing the "*" character) that matched a logger already
-matched by an explicitly named entry. The configuration is ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_LOG_WILD_MATCH">
-<term>CONFIG_LOG_WILD_MATCH will use logging configuration for wildcard logger %1</term>
-<listitem><para>
-This is a debug message. When processing the "loggers" part of
-the configuration file, the configuration library found the named
-wildcard entry (one containing the "*" character) that matches a logger
-specification in the program. The logging configuration for the program
-will be updated with the information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_MOD_SPEC_FORMAT">
-<term>CONFIG_MOD_SPEC_FORMAT module specification error in %1: %2</term>
-<listitem><para>
-The given file does not appear to be a valid specification file: details
-are included in the message. Please verify that the filename is correct
-and that its contents are a valid BIND10 module specification.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_MOD_SPEC_REJECT">
-<term>CONFIG_MOD_SPEC_REJECT module specification rejected by cfgmgr: %1</term>
-<listitem><para>
-The specification file for this module was rejected by the configuration
-manager. The full error message answer from the configuration manager is
-appended to the log error. The most likely cause is that the module is of
-a different (specification file) version than the running configuration
-manager.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="CONFIG_OPEN_FAIL">
-<term>CONFIG_OPEN_FAIL error opening %1: %2</term>
-<listitem><para>
-There was an error opening the given file. The reason for the failure
-is included in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_CREATE">
-<term>DATASRC_CACHE_CREATE creating the hotspot cache</term>
-<listitem><para>
-This is a debug message issued during startup when the hotspot cache
-is created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_DESTROY">
-<term>DATASRC_CACHE_DESTROY destroying the hotspot cache</term>
-<listitem><para>
-Debug information. The hotspot cache is being destroyed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_DISABLE">
-<term>DATASRC_CACHE_DISABLE disabling the hotspot cache</term>
-<listitem><para>
-A debug message issued when the hotspot cache is disabled.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_ENABLE">
-<term>DATASRC_CACHE_ENABLE enabling the hotspot cache</term>
-<listitem><para>
-A debug message issued when the hotspot cache is enabled.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_EXPIRED">
-<term>DATASRC_CACHE_EXPIRED item '%1' in the hotspot cache has expired</term>
-<listitem><para>
-A debug message issued when a hotspot cache lookup located the item but it
-had expired. The item was removed and the program proceeded as if the item
-had not been found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_FOUND">
-<term>DATASRC_CACHE_FOUND the item '%1' was found</term>
-<listitem><para>
-Debug information. An item was successfully located in the hotspot cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_FULL">
-<term>DATASRC_CACHE_FULL hotspot cache is full, dropping oldest</term>
-<listitem><para>
-Debug information. After inserting an item into the hotspot cache, the
-maximum number of items was exceeded, so the least recently used item will
-be dropped. This should be directly followed by CACHE_REMOVE.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_INSERT">
-<term>DATASRC_CACHE_INSERT inserting item '%1' into the hotspot cache</term>
-<listitem><para>
-A debug message indicating that a new item is being inserted into the hotspot
-cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_NOT_FOUND">
-<term>DATASRC_CACHE_NOT_FOUND the item '%1' was not found in the hotspot cache</term>
-<listitem><para>
-A debug message issued when hotspot cache was searched for the specified
-item but it was not found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_OLD_FOUND">
-<term>DATASRC_CACHE_OLD_FOUND older instance of hotspot cache item '%1' found, replacing</term>
-<listitem><para>
-Debug information. While inserting an item into the hotspot cache, an older
-instance of an item with the same name was found; the old instance will be
-removed. This will be directly followed by CACHE_REMOVE.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_REMOVE">
-<term>DATASRC_CACHE_REMOVE removing '%1' from the hotspot cache</term>
-<listitem><para>
-Debug information. An item is being removed from the hotspot cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_CACHE_SLOTS">
-<term>DATASRC_CACHE_SLOTS setting the hotspot cache size to '%1', dropping '%2' items</term>
-<listitem><para>
-The maximum allowed number of items of the hotspot cache is set to the given
-number. If there are too many, some of them will be dropped. The size of 0
-means no limit.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED">
-<term>DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED %1 doesn't support DNSSEC when asked for NSEC data covering %2</term>
-<listitem><para>
-The datasource tried to provide an NSEC proof that the named domain does not
-exist, but the database backend doesn't support DNSSEC. No proof is included
-in the answer as a result.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FIND_RECORDS">
-<term>DATASRC_DATABASE_FIND_RECORDS looking in datasource %1 for record %2/%3/%4</term>
-<listitem><para>
-Debug information. The database data source is looking up records with the given
-name and type in the database.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FIND_TTL_MISMATCH">
-<term>DATASRC_DATABASE_FIND_TTL_MISMATCH TTL values differ in %1 for elements of %2/%3/%4, setting to %5</term>
-<listitem><para>
-The datasource backend provided resource records for the given RRset with
-different TTL values. This isn't allowed on the wire and is considered
-an error, so we set it to the lowest value we found (but we don't modify the
-database). The data in database should be checked and fixed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_ANY">
-<term>DATASRC_DATABASE_FOUND_ANY search in datasource %1 resulted in returning all records of %2</term>
-<listitem><para>
-The data returned by the database backend contained data for the given domain
-name, so all the RRsets of the domain are returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_CNAME">
-<term>DATASRC_DATABASE_FOUND_CNAME search in datasource %1 for %2/%3/%4 found CNAME, resulting in %5</term>
-<listitem><para>
-When searching the domain for a name a CNAME was found at that name.
-Even though it was not the RR type being sought, it is returned. (The
-caller may want to continue the lookup by replacing the query name with
-the canonical name and restarting the query with the original RR type.)
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_DELEGATION">
-<term>DATASRC_DATABASE_FOUND_DELEGATION Found delegation at %2 in %1</term>
-<listitem><para>
-When searching for a domain, the program met a delegation to a different zone
-at the given domain name. It will return that one instead.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_DELEGATION_EXACT">
-<term>DATASRC_DATABASE_FOUND_DELEGATION_EXACT search in datasource %1 for %2/%3/%4 found delegation at %5</term>
-<listitem><para>
-The program found the domain requested, but it is a delegation point to a
-different zone, therefore it is not authoritative for this domain name.
-It will return the NS record instead.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_DNAME">
-<term>DATASRC_DATABASE_FOUND_DNAME Found DNAME at %2 in %1</term>
-<listitem><para>
-When searching for a domain, the program met a DNAME redirection to a different
-place in the domain space at the given domain name. It will return that one
-instead.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL">
-<term>DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL empty non-terminal %2 in %1</term>
-<listitem><para>
-The domain name does not have any RRs associated with it, so it doesn't
-exist in the database. However, it has a subdomain, so it does exist
-in the DNS address space. This type of domain is known an an "empty
-non-terminal" and so we return NXRRSET instead of NXDOMAIN.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_NXDOMAIN">
-<term>DATASRC_DATABASE_FOUND_NXDOMAIN search in datasource %1 resulted in NXDOMAIN for %2/%3/%4</term>
-<listitem><para>
-The data returned by the database backend did not contain any data for the given
-domain name, class and type.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_NXRRSET">
-<term>DATASRC_DATABASE_FOUND_NXRRSET search in datasource %1 for %2/%3/%4 resulted in NXRRSET</term>
-<listitem><para>
-The data returned by the database backend contained data for the given domain
-name and class, but not for the given type.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_NXRRSET_NSEC">
-<term>DATASRC_DATABASE_FOUND_NXRRSET_NSEC search in datasource %1 for %2/%3/%4 resulted in RRset %5</term>
-<listitem><para>
-A search in the database for RRs for the specified name, type and class has
-located RRs that match the name and class but not the type. DNSSEC information
-has been requested and returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FOUND_RRSET">
-<term>DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %5</term>
-<listitem><para>
-The data returned by the database backend contained data for the given domain
-name, and it either matches the type or has a relevant type. The RRset that is
-returned is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_ITERATE">
-<term>DATASRC_DATABASE_ITERATE iterating zone %1</term>
-<listitem><para>
-The program is reading the whole zone, eg. not searching for data, but going
-through each of the RRsets there.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_ITERATE_END">
-<term>DATASRC_DATABASE_ITERATE_END iterating zone finished</term>
-<listitem><para>
-While iterating through the zone, the program reached end of the data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_ITERATE_NEXT">
-<term>DATASRC_DATABASE_ITERATE_NEXT next RRset in zone is %1/%2</term>
-<listitem><para>
-While iterating through the zone, the program extracted next RRset from it.
-The name and RRtype of the RRset is indicated in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_ITERATE_TTL_MISMATCH">
-<term>DATASRC_DATABASE_ITERATE_TTL_MISMATCH TTL values differ for RRs of %1/%2/%3, setting to %4</term>
-<listitem><para>
-While iterating through the zone, the time to live for RRs of the given RRset
-were found to be different. This isn't allowed on the wire and is considered
-an error, so we set it to the lowest value we found (but we don't modify the
-database). The data in database should be checked and fixed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_JOURNALREADER_END">
-<term>DATASRC_DATABASE_JOURNALREADER_END %1/%2 on %3 from %4 to %5</term>
-<listitem><para>
-This is a debug message indicating that the program (successfully)
-reaches the end of sequences of a zone's differences. The zone's name
-and class, database name, and the start and end serials are shown in
-the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_JOURNALREADER_NEXT">
-<term>DATASRC_DATABASE_JOURNALREADER_NEXT %1/%2 in %3/%4 on %5</term>
-<listitem><para>
-This is a debug message indicating that the program retrieves one
-difference in difference sequences of a zone and successfully converts
-it to an RRset. The zone's name and class, database name, and the
-name and RR type of the retrieved diff are shown in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_JOURNALREADER_START">
-<term>DATASRC_DATABASE_JOURNALREADER_START %1/%2 on %3 from %4 to %5</term>
-<listitem><para>
-This is a debug message indicating that the program starts reading
-a zone's difference sequences from a database-based data source. The
-zone's name and class, database name, and the start and end serials
-are shown in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_JOURNALREADR_BADDATA">
-<term>DATASRC_DATABASE_JOURNALREADR_BADDATA failed to convert a diff to RRset in %1/%2 on %3 between %4 and %5: %6</term>
-<listitem><para>
-This is an error message indicating that a zone's diff is broken and
-the data source library failed to convert it to a valid RRset. The
-most likely cause of this is that someone has manually modified the
-zone's diff in the database and inserted invalid data as a result.
-The zone's name and class, database name, and the start and end
-serials, and an additional detail of the error are shown in the
-message. The administrator should examine the diff in the database
-to find any invalid data and fix it.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_NO_MATCH">
-<term>DATASRC_DATABASE_NO_MATCH not match for %2/%3/%4 in %1</term>
-<listitem><para>
-No match (not even a wildcard) was found in the named data source for the given
-name/type/class in the data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_COMMIT">
-<term>DATASRC_DATABASE_UPDATER_COMMIT updates committed for '%1/%2' on %3</term>
-<listitem><para>
-Debug information. A set of updates to a zone has been successfully
-committed to the corresponding database backend. The zone name,
-its class and the database name are printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_COMMIT (1)">
-<term>DATASRC_DATABASE_UPDATER_COMMIT (1) updates committed for '%1/%2' on %3</term>
-<listitem><para>
-Debug information. A set of updates to a zone has been successfully
-committed to the corresponding database backend. The zone name,
-its class and the database name are printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_CREATED">
-<term>DATASRC_DATABASE_UPDATER_CREATED zone updater created for '%1/%2' on %3</term>
-<listitem><para>
-Debug information. A zone updater object is created to make updates to
-the shown zone on the shown backend database.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_CREATED (1)">
-<term>DATASRC_DATABASE_UPDATER_CREATED (1) zone updater created for '%1/%2' on %3</term>
-<listitem><para>
-Debug information. A zone updater object is created to make updates to
-the shown zone on the shown backend database.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED">
-<term>DATASRC_DATABASE_UPDATER_DESTROYED zone updater destroyed for '%1/%2' on %3</term>
-<listitem><para>
-Debug information. A zone updater object is destroyed, either successfully
-or after failure of, making updates to the shown zone on the shown backend
-database.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED (1)">
-<term>DATASRC_DATABASE_UPDATER_DESTROYED (1) zone updater destroyed for '%1/%2' on %3</term>
-<listitem><para>
-Debug information. A zone updater object is destroyed, either successfully
-or after failure of, making updates to the shown zone on the shown backend
-database.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK">
-<term>DATASRC_DATABASE_UPDATER_ROLLBACK zone updates roll-backed for '%1/%2' on %3</term>
-<listitem><para>
-A zone updater is being destroyed without committing the changes.
-This would typically mean the update attempt was aborted due to some
-error, but may also be a bug of the application that forgets committing
-the changes. The intermediate changes made through the updater won't
-be applied to the underlying database. The zone name, its class, and
-the underlying database name are shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK (1)">
-<term>DATASRC_DATABASE_UPDATER_ROLLBACK (1) zone updates roll-backed for '%1/%2' on %3</term>
-<listitem><para>
-A zone updater is being destroyed without committing the changes.
-This would typically mean the update attempt was aborted due to some
-error, but may also be a bug of the application that forgets committing
-the changes. The intermediate changes made through the updater won't
-be applied to the underlying database. The zone name, its class, and
-the underlying database name are shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL">
-<term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL failed to roll back zone updates for '%1/%2' on %3: %4</term>
-<listitem><para>
-A zone updater is being destroyed without committing the changes to
-the database, and attempts to rollback incomplete updates, but it
-unexpectedly fails. The higher level implementation does not expect
-it to fail, so this means either a serious operational error in the
-underlying data source (such as a system failure of a database) or
-software bug in the underlying data source implementation. In either
-case if this message is logged the administrator should carefully
-examine the underlying data source to see what exactly happens and
-whether the data is still valid. The zone name, its class, and the
-underlying database name as well as the error message thrown from the
-database module are shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1)">
-<term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1) failed to roll back zone updates for '%1/%2' on %3: %4</term>
-<listitem><para>
-A zone updater is being destroyed without committing the changes to
-the database, and attempts to rollback incomplete updates, but it
-unexpectedly fails. The higher level implementation does not expect
-it to fail, so this means either a serious operational error in the
-underlying data source (such as a system failure of a database) or
-software bug in the underlying data source implementation. In either
-case if this message is logged the administrator should carefully
-examine the underlying data source to see what exactly happens and
-whether the data is still valid. The zone name, its class, and the
-underlying database name as well as the error message thrown from the
-database module are shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_ANY">
-<term>DATASRC_DATABASE_WILDCARD_ANY search in datasource %1 resulted in wildcard match type ANY on %2</term>
-<listitem><para>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a wildcard record matching the name of the query
-containing some RRsets was found. All the RRsets of the node are returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_CANCEL_NS">
-<term>DATASRC_DATABASE_WILDCARD_CANCEL_NS canceled wildcard match on %3 because %2 contains NS (data source %1)</term>
-<listitem><para>
-The database was queried to provide glue data and it didn't find direct match.
-It could create it from given wildcard, but matching wildcards is forbidden
-under a zone cut, which was found. Therefore the delegation will be returned
-instead.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_CANCEL_SUB">
-<term>DATASRC_DATABASE_WILDCARD_CANCEL_SUB wildcard %2 can't be used to construct %3 because %4 exists in %1</term>
-<listitem><para>
-The answer could be constructed using the wildcard, but the given subdomain
-exists, therefore this name is something like empty non-terminal (actually,
-from the protocol point of view, it is empty non-terminal, but the code
-discovers it differently).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_CNAME">
-<term>DATASRC_DATABASE_WILDCARD_CNAME search in datasource %1 for %2/%3/%4 found wildcard CNAME at %5, resulting in %6</term>
-<listitem><para>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a CNAME RR was found at a wildcard record
-matching the name. This is returned as the result of the search.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_EMPTY">
-<term>DATASRC_DATABASE_WILDCARD_EMPTY found subdomains of %2 which is a wildcard match for %3 in %1</term>
-<listitem><para>
-The given wildcard matches the name being sough but it as an empty
-nonterminal (e.g. there's nothing at *.example.com but something like
-subdomain.*.example.org, do exist: so *.example.org exists in the
-namespace but has no RRs assopciated with it). This will produce NXRRSET.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_MATCH">
-<term>DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %5 with RRset %6</term>
-<listitem><para>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a wildcard record matching the name and type of
-the query was found. The data at this point is returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_NS">
-<term>DATASRC_DATABASE_WILDCARD_NS search in datasource %1 for %2/%3/%4 found wildcard delegation at %5, resulting in %6</term>
-<listitem><para>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, an NS RR was found at a wildcard record matching
-the name. This is returned as the result of the search.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_WILDCARD_NXRRSET">
-<term>DATASRC_DATABASE_WILDCARD_NXRRSET search in datasource %1 for %2/%3/%4 resulted in wildcard NXRRSET at %5</term>
-<listitem><para>
-The database doesn't contain directly matching name. When searching
-for a wildcard match, a matching wildcard entry was found but it did
-not contain RRs the requested type. AN NXRRSET indication is returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DO_QUERY">
-<term>DATASRC_DO_QUERY handling query for '%1/%2'</term>
-<listitem><para>
-A debug message indicating that a query for the given name and RR type is being
-processed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_ADD_RRSET">
-<term>DATASRC_MEM_ADD_RRSET adding RRset '%1/%2' into zone '%3'</term>
-<listitem><para>
-Debug information. An RRset is being added to the in-memory data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_ADD_WILDCARD">
-<term>DATASRC_MEM_ADD_WILDCARD adding wildcards for '%1'</term>
-<listitem><para>
-This is a debug message issued during the processing of a wildcard
-name. The internal domain name tree is scanned and some nodes are
-specially marked to allow the wildcard lookup to succeed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_ADD_ZONE">
-<term>DATASRC_MEM_ADD_ZONE adding zone '%1/%2'</term>
-<listitem><para>
-Debug information. A zone is being added into the in-memory data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_ANY_SUCCESS">
-<term>DATASRC_MEM_ANY_SUCCESS ANY query for '%1' successful</term>
-<listitem><para>
-Debug information. The domain was found and an ANY type query is being answered
-by providing everything found inside the domain.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_CNAME">
-<term>DATASRC_MEM_CNAME CNAME at the domain '%1'</term>
-<listitem><para>
-Debug information. The requested domain is an alias to a different domain,
-returning the CNAME instead.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_CNAME_COEXIST">
-<term>DATASRC_MEM_CNAME_COEXIST can't add data to CNAME in domain '%1'</term>
-<listitem><para>
-This is the same problem as in MEM_CNAME_TO_NONEMPTY, but it happened the
-other way around -- adding some other data to CNAME.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_CNAME_TO_NONEMPTY">
-<term>DATASRC_MEM_CNAME_TO_NONEMPTY can't add CNAME to domain with other data in '%1'</term>
-<listitem><para>
-Someone or something tried to add a CNAME into a domain that already contains
-some other data. But the protocol forbids coexistence of CNAME with anything
-(RFC 1034, section 3.6.2). This indicates a problem with provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_CREATE">
-<term>DATASRC_MEM_CREATE creating zone '%1' in '%2' class</term>
-<listitem><para>
-Debug information. A representation of a zone for the in-memory data source is
-being created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DELEG_FOUND">
-<term>DATASRC_MEM_DELEG_FOUND delegation found at '%1'</term>
-<listitem><para>
-Debug information. A delegation point was found above the requested record.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DESTROY">
-<term>DATASRC_MEM_DESTROY destroying zone '%1' in '%2' class</term>
-<listitem><para>
-Debug information. A zone from in-memory data source is being destroyed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DNAME_ENCOUNTERED">
-<term>DATASRC_MEM_DNAME_ENCOUNTERED encountered a DNAME</term>
-<listitem><para>
-Debug information. While searching for the requested domain, a DNAME was
-encountered on the way. This may lead to redirection to a different domain and
-stop the search.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DNAME_FOUND">
-<term>DATASRC_MEM_DNAME_FOUND DNAME found at '%1'</term>
-<listitem><para>
-Debug information. A DNAME was found instead of the requested information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DNAME_NS">
-<term>DATASRC_MEM_DNAME_NS DNAME and NS can't coexist in non-apex domain '%1'</term>
-<listitem><para>
-A request was made for DNAME and NS records to be put into the same
-domain which is not the apex (the top of the zone). This is forbidden
-by RFC 2672 (section 3) and indicates a problem with provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DOMAIN_EMPTY">
-<term>DATASRC_MEM_DOMAIN_EMPTY requested domain '%1' is empty</term>
-<listitem><para>
-Debug information. The requested domain exists in the tree of domains, but
-it is empty. Therefore it doesn't contain the requested resource type.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_DUP_RRSET">
-<term>DATASRC_MEM_DUP_RRSET duplicate RRset '%1/%2'</term>
-<listitem><para>
-An RRset is being inserted into in-memory data source for a second time. The
-original version must be removed first. Note that loading master files where an
-RRset is split into multiple locations is not supported yet.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_EXACT_DELEGATION">
-<term>DATASRC_MEM_EXACT_DELEGATION delegation at the exact domain '%1'</term>
-<listitem><para>
-Debug information. There's a NS record at the requested domain. This means
-this zone is not authoritative for the requested domain, but a delegation
-should be followed. The requested domain is an apex of some zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_FIND">
-<term>DATASRC_MEM_FIND find '%1/%2'</term>
-<listitem><para>
-Debug information. A search for the requested RRset is being started.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_FIND_ZONE">
-<term>DATASRC_MEM_FIND_ZONE looking for zone '%1'</term>
-<listitem><para>
-Debug information. A zone object for this zone is being searched for in the
-in-memory data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_LOAD">
-<term>DATASRC_MEM_LOAD loading zone '%1' from file '%2'</term>
-<listitem><para>
-Debug information. The content of master file is being loaded into the memory.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_NOT_FOUND">
-<term>DATASRC_MEM_NOT_FOUND requested domain '%1' not found</term>
-<listitem><para>
-Debug information. The requested domain does not exist.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_NS_ENCOUNTERED">
-<term>DATASRC_MEM_NS_ENCOUNTERED encountered a NS</term>
-<listitem><para>
-Debug information. While searching for the requested domain, a NS was
-encountered on the way (a delegation). This may lead to stop of the search.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_NXRRSET">
-<term>DATASRC_MEM_NXRRSET no such type '%1' at '%2'</term>
-<listitem><para>
-Debug information. The domain exists, but it doesn't hold any record of the
-requested type.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_OUT_OF_ZONE">
-<term>DATASRC_MEM_OUT_OF_ZONE domain '%1' doesn't belong to zone '%2'</term>
-<listitem><para>
-It was attempted to add the domain into a zone that shouldn't have it
-(eg. the domain is not subdomain of the zone origin). This indicates a
-problem with provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_RENAME">
-<term>DATASRC_MEM_RENAME renaming RRset from '%1' to '%2'</term>
-<listitem><para>
-Debug information. A RRset is being generated from a different RRset (most
-probably a wildcard). So it must be renamed to whatever the user asked for. In
-fact, it's impossible to rename RRsets with our libraries, so a new one is
-created and all resource records are copied over.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_SINGLETON">
-<term>DATASRC_MEM_SINGLETON trying to add multiple RRs for domain '%1' and type '%2'</term>
-<listitem><para>
-Some resource types are singletons -- only one is allowed in a domain
-(for example CNAME or SOA). This indicates a problem with provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_SUCCESS">
-<term>DATASRC_MEM_SUCCESS query for '%1/%2' successful</term>
-<listitem><para>
-Debug information. The requested record was found.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_SUPER_STOP">
-<term>DATASRC_MEM_SUPER_STOP stopped at superdomain '%1', domain '%2' is empty</term>
-<listitem><para>
-Debug information. The search stopped at a superdomain of the requested
-domain. The domain is an empty nonterminal, therefore it is treated as NXRRSET
-case (eg. the domain exists, but it doesn't have the requested record type).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_SWAP">
-<term>DATASRC_MEM_SWAP swapping contents of two zone representations ('%1' and '%2')</term>
-<listitem><para>
-Debug information. The contents of two in-memory zones are being exchanged.
-This is usual practice to do some manipulation in exception-safe manner -- the
-new data are prepared in a different zone object and when it works, they are
-swapped. The old one contains the new data and the other one can be safely
-destroyed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_WILDCARD_CANCEL">
-<term>DATASRC_MEM_WILDCARD_CANCEL wildcard match canceled for '%1'</term>
-<listitem><para>
-Debug information. A domain above wildcard was reached, but there's something
-below the requested domain. Therefore the wildcard doesn't apply here. This
-behaviour is specified by RFC 1034, section 4.3.3
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_WILDCARD_DNAME">
-<term>DATASRC_MEM_WILDCARD_DNAME DNAME record in wildcard domain '%1'</term>
-<listitem><para>
-The software refuses to load DNAME records into a wildcard domain. It isn't
-explicitly forbidden, but the protocol is ambiguous about how this should
-behave and BIND 9 refuses that as well. Please describe your intention using
-different tools.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_MEM_WILDCARD_NS">
-<term>DATASRC_MEM_WILDCARD_NS NS record in wildcard domain '%1'</term>
-<listitem><para>
-The software refuses to load NS records into a wildcard domain. It isn't
-explicitly forbidden, but the protocol is ambiguous about how this should
-behave and BIND 9 refuses that as well. Please describe your intention using
-different tools.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_META_ADD">
-<term>DATASRC_META_ADD adding a data source into meta data source</term>
-<listitem><para>
-This is a debug message issued during startup or reconfiguration.
-Another data source is being added into the meta data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_META_ADD_CLASS_MISMATCH">
-<term>DATASRC_META_ADD_CLASS_MISMATCH mismatch between classes '%1' and '%2'</term>
-<listitem><para>
-It was attempted to add a data source into a meta data source, but their
-classes do not match.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_META_REMOVE">
-<term>DATASRC_META_REMOVE removing data source from meta data source</term>
-<listitem><para>
-Debug information. A data source is being removed from meta data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_ADD_NSEC">
-<term>DATASRC_QUERY_ADD_NSEC adding NSEC record for '%1'</term>
-<listitem><para>
-Debug information. A NSEC record covering this zone is being added.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_ADD_NSEC3">
-<term>DATASRC_QUERY_ADD_NSEC3 adding NSEC3 record of zone '%1'</term>
-<listitem><para>
-Debug information. A NSEC3 record for the given zone is being added to the
-response message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_ADD_RRSET">
-<term>DATASRC_QUERY_ADD_RRSET adding RRset '%1/%2' to message</term>
-<listitem><para>
-Debug information. An RRset is being added to the response message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_ADD_SOA">
-<term>DATASRC_QUERY_ADD_SOA adding SOA of '%1'</term>
-<listitem><para>
-Debug information. A SOA record of the given zone is being added to the
-authority section of the response message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_AUTH_FAIL">
-<term>DATASRC_QUERY_AUTH_FAIL the underlying data source failed with %1</term>
-<listitem><para>
-The underlying data source failed to answer the authoritative query. 1 means
-some error, 2 is not implemented. The data source should have logged the
-specific error already.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_BAD_REFERRAL">
-<term>DATASRC_QUERY_BAD_REFERRAL bad referral to '%1'</term>
-<listitem><para>
-The domain lives in another zone. But it is not possible to generate referral
-information for it.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_CACHED">
-<term>DATASRC_QUERY_CACHED data for %1/%2 found in hotspot cache</term>
-<listitem><para>
-Debug information. The requested data were found in the hotspot cache, so
-no query is sent to the real data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_CHECK_CACHE">
-<term>DATASRC_QUERY_CHECK_CACHE checking hotspot cache for '%1/%2'</term>
-<listitem><para>
-Debug information. While processing a query, lookup to the hotspot cache
-is being made.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_COPY_AUTH">
-<term>DATASRC_QUERY_COPY_AUTH copying authoritative section into message</term>
-<listitem><para>
-Debug information. The whole referral information is being copied into the
-response message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_DELEGATION">
-<term>DATASRC_QUERY_DELEGATION looking for delegation on the path to '%1'</term>
-<listitem><para>
-Debug information. The software is trying to identify delegation points on the
-way down to the given domain.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_EMPTY_CNAME">
-<term>DATASRC_QUERY_EMPTY_CNAME CNAME at '%1' is empty</term>
-<listitem><para>
-A CNAME chain was being followed and an entry was found that pointed
-to a domain name that had no RRsets associated with it. As a result,
-the query cannot be answered. This indicates a problem with supplied data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_EMPTY_DNAME">
-<term>DATASRC_QUERY_EMPTY_DNAME the DNAME on '%1' is empty</term>
-<listitem><para>
-During an attempt to synthesize CNAME from this DNAME it was discovered the
-DNAME is empty (it has no records). This indicates problem with supplied data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_FAIL">
-<term>DATASRC_QUERY_FAIL query failed</term>
-<listitem><para>
-Some subtask of query processing failed. The reason should have been reported
-already and a SERVFAIL will be returned to the querying system.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_FOLLOW_CNAME">
-<term>DATASRC_QUERY_FOLLOW_CNAME following CNAME at '%1'</term>
-<listitem><para>
-Debug information. The domain is a CNAME (or a DNAME and a CNAME for it
-has already been created) and the search is following this chain.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_GET_MX_ADDITIONAL">
-<term>DATASRC_QUERY_GET_MX_ADDITIONAL addition of A/AAAA for '%1' requested by MX '%2'</term>
-<listitem><para>
-Debug information. While processing a query, a MX record was met. It
-references the mentioned address, so A/AAAA records for it are looked up
-and put it into the additional section.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_GET_NS_ADDITIONAL">
-<term>DATASRC_QUERY_GET_NS_ADDITIONAL addition of A/AAAA for '%1' requested by NS '%2'</term>
-<listitem><para>
-Debug information. While processing a query, a NS record was met. It
-references the mentioned address, so A/AAAA records for it are looked up
-and put it into the additional section.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_GLUE_FAIL">
-<term>DATASRC_QUERY_GLUE_FAIL the underlying data source failed with %1</term>
-<listitem><para>
-The underlying data source failed to answer the glue query. 1 means some error,
-2 is not implemented. The data source should have logged the specific error
-already.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_INVALID_OP">
-<term>DATASRC_QUERY_INVALID_OP invalid query operation requested</term>
-<listitem><para>
-This indicates a programmer error. The DO_QUERY was called with unknown
-operation code.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_IS_AUTH">
-<term>DATASRC_QUERY_IS_AUTH auth query (%1/%2)</term>
-<listitem><para>
-Debug information. The last DO_QUERY is an auth query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_IS_GLUE">
-<term>DATASRC_QUERY_IS_GLUE glue query (%1/%2)</term>
-<listitem><para>
-Debug information. The last DO_QUERY is a query for glue addresses.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_IS_NOGLUE">
-<term>DATASRC_QUERY_IS_NOGLUE query for non-glue addresses (%1/%2)</term>
-<listitem><para>
-Debug information. The last DO_QUERY is a query for addresses that are not
-glue.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_IS_REF">
-<term>DATASRC_QUERY_IS_REF query for referral (%1/%2)</term>
-<listitem><para>
-Debug information. The last DO_QUERY is a query for referral information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_IS_SIMPLE">
-<term>DATASRC_QUERY_IS_SIMPLE simple query (%1/%2)</term>
-<listitem><para>
-Debug information. The last DO_QUERY is a simple query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_MISPLACED_TASK">
-<term>DATASRC_QUERY_MISPLACED_TASK task of this type should not be here</term>
-<listitem><para>
-This indicates a programming error. A task was found in the internal task
-queue, but this kind of task wasn't designed to be inside the queue (it should
-be handled right away, not queued).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_MISSING_NS">
-<term>DATASRC_QUERY_MISSING_NS missing NS records for '%1'</term>
-<listitem><para>
-NS records should have been put into the authority section. However, this zone
-has none. This indicates problem with provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_MISSING_SOA">
-<term>DATASRC_QUERY_MISSING_SOA the zone '%1' has no SOA</term>
-<listitem><para>
-The answer should have been a negative one (eg. of nonexistence of something).
-To do so, a SOA record should be put into the authority section, but the zone
-does not have one. This indicates problem with provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_NOGLUE_FAIL">
-<term>DATASRC_QUERY_NOGLUE_FAIL the underlying data source failed with %1</term>
-<listitem><para>
-The underlying data source failed to answer the no-glue query. 1 means some
-error, 2 is not implemented. The data source should have logged the specific
-error already.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_NO_CACHE_ANY_AUTH">
-<term>DATASRC_QUERY_NO_CACHE_ANY_AUTH ignoring hotspot cache for ANY query (%1/%2 in %3 class)</term>
-<listitem><para>
-Debug information. The hotspot cache is ignored for authoritative ANY queries
-for consistency reasons.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_NO_CACHE_ANY_SIMPLE">
-<term>DATASRC_QUERY_NO_CACHE_ANY_SIMPLE ignoring hotspot cache for ANY query (%1/%2 in %3 class)</term>
-<listitem><para>
-Debug information. The hotspot cache is ignored for ANY queries for consistency
-reasons.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_NO_DS_NSEC">
-<term>DATASRC_QUERY_NO_DS_NSEC there's no DS record in the '%1' zone</term>
-<listitem><para>
-An attempt to add a NSEC record into the message failed, because the zone does
-not have any DS record. This indicates problem with the provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_NO_DS_NSEC3">
-<term>DATASRC_QUERY_NO_DS_NSEC3 there's no DS record in the '%1' zone</term>
-<listitem><para>
-An attempt to add a NSEC3 record into the message failed, because the zone does
-not have any DS record. This indicates problem with the provided data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_NO_ZONE">
-<term>DATASRC_QUERY_NO_ZONE no zone containing '%1' in class '%2'</term>
-<listitem><para>
-Lookup of domain failed because the data have no zone that contain the
-domain. Maybe someone sent a query to the wrong server for some reason.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_PROCESS">
-<term>DATASRC_QUERY_PROCESS processing query '%1/%2' in the '%3' class</term>
-<listitem><para>
-Debug information. A sure query is being processed now.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_PROVE_NX_FAIL">
-<term>DATASRC_QUERY_PROVE_NX_FAIL unable to prove nonexistence of '%1'</term>
-<listitem><para>
-The user wants DNSSEC and we discovered the entity doesn't exist (either
-domain or the record). But there was an error getting NSEC/NSEC3 record
-to prove the nonexistence.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_REF_FAIL">
-<term>DATASRC_QUERY_REF_FAIL the underlying data source failed with %1</term>
-<listitem><para>
-The underlying data source failed to answer the query for referral information.
-1 means some error, 2 is not implemented. The data source should have logged
-the specific error already.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_RRSIG">
-<term>DATASRC_QUERY_RRSIG unable to answer RRSIG query</term>
-<listitem><para>
-The server is unable to answer a direct query for RRSIG type, but was asked
-to do so.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_SIMPLE_FAIL">
-<term>DATASRC_QUERY_SIMPLE_FAIL the underlying data source failed with %1</term>
-<listitem><para>
-The underlying data source failed to answer the simple query. 1 means some
-error, 2 is not implemented. The data source should have logged the specific
-error already.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_SYNTH_CNAME">
-<term>DATASRC_QUERY_SYNTH_CNAME synthesizing CNAME from DNAME on '%1'</term>
-<listitem><para>
-This is a debug message. While answering a query, a DNAME was encountered. The
-DNAME itself will be returned, along with a synthesized CNAME for clients that
-do not understand the DNAME RR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_TASK_FAIL">
-<term>DATASRC_QUERY_TASK_FAIL task failed with %1</term>
-<listitem><para>
-The query subtask failed. The reason should have been reported by the subtask
-already. The code is 1 for error, 2 for not implemented.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_TOO_MANY_CNAMES">
-<term>DATASRC_QUERY_TOO_MANY_CNAMES CNAME chain limit exceeded at '%1'</term>
-<listitem><para>
-A CNAME led to another CNAME and it led to another, and so on. After 16
-CNAMEs, the software gave up. Long CNAME chains are discouraged, and this
-might possibly be a loop as well. Note that some of the CNAMEs might have
-been synthesized from DNAMEs. This indicates problem with supplied data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_UNKNOWN_RESULT">
-<term>DATASRC_QUERY_UNKNOWN_RESULT unknown result of subtask</term>
-<listitem><para>
-This indicates a programmer error. The answer of subtask doesn't look like
-anything known.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_WILDCARD">
-<term>DATASRC_QUERY_WILDCARD looking for a wildcard covering '%1'</term>
-<listitem><para>
-Debug information. A direct match wasn't found, so a wildcard covering the
-domain is being looked for now.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_WILDCARD_FAIL">
-<term>DATASRC_QUERY_WILDCARD_FAIL error processing wildcard for '%1'</term>
-<listitem><para>
-During an attempt to cover the domain by a wildcard an error happened. The
-exact kind was hopefully already reported.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_WILDCARD_PROVE_NX_FAIL">
-<term>DATASRC_QUERY_WILDCARD_PROVE_NX_FAIL unable to prove nonexistence of '%1' (%2)</term>
-<listitem><para>
-While processing a wildcard, it wasn't possible to prove nonexistence of the
-given domain or record. The code is 1 for error and 2 for not implemented.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_QUERY_WILDCARD_REFERRAL">
-<term>DATASRC_QUERY_WILDCARD_REFERRAL unable to find referral info for '%1' (%2)</term>
-<listitem><para>
-While processing a wildcard, a referral was met. But it wasn't possible to get
-enough information for it. The code is 1 for error, 2 for not implemented.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_CLOSE">
-<term>DATASRC_SQLITE_CLOSE closing SQLite database</term>
-<listitem><para>
-Debug information. The SQLite data source is closing the database file.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_CONNCLOSE">
-<term>DATASRC_SQLITE_CONNCLOSE Closing sqlite database</term>
-<listitem><para>
-The database file is no longer needed and is being closed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_CONNOPEN">
-<term>DATASRC_SQLITE_CONNOPEN Opening sqlite database file '%1'</term>
-<listitem><para>
-The database file is being opened so it can start providing data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_CREATE">
-<term>DATASRC_SQLITE_CREATE SQLite data source created</term>
-<listitem><para>
-Debug information. An instance of SQLite data source is being created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_DESTROY">
-<term>DATASRC_SQLITE_DESTROY SQLite data source destroyed</term>
-<listitem><para>
-Debug information. An instance of SQLite data source is being destroyed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_DROPCONN">
-<term>DATASRC_SQLITE_DROPCONN SQLite3Database is being deinitialized</term>
-<listitem><para>
-The object around a database connection is being destroyed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_ENCLOSURE">
-<term>DATASRC_SQLITE_ENCLOSURE looking for zone containing '%1'</term>
-<listitem><para>
-Debug information. The SQLite data source is trying to identify which zone
-should hold this domain.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_ENCLOSURE_NOT_FOUND">
-<term>DATASRC_SQLITE_ENCLOSURE_NOT_FOUND no zone contains '%1'</term>
-<listitem><para>
-Debug information. The last SQLITE_ENCLOSURE query was unsuccessful; there's
-no such zone in our data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FIND">
-<term>DATASRC_SQLITE_FIND looking for RRset '%1/%2'</term>
-<listitem><para>
-Debug information. The SQLite data source is looking up a resource record
-set.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDADDRS">
-<term>DATASRC_SQLITE_FINDADDRS looking for A/AAAA addresses for '%1'</term>
-<listitem><para>
-Debug information. The data source is looking up the addresses for given
-domain name.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDADDRS_BAD_CLASS">
-<term>DATASRC_SQLITE_FINDADDRS_BAD_CLASS class mismatch looking for addresses ('%1' and '%2')</term>
-<listitem><para>
-The SQLite data source was looking up A/AAAA addresses, but the data source
-contains different class than the query was for.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDEXACT">
-<term>DATASRC_SQLITE_FINDEXACT looking for exact RRset '%1/%2'</term>
-<listitem><para>
-Debug information. The SQLite data source is looking up an exact resource
-record.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDEXACT_BAD_CLASS">
-<term>DATASRC_SQLITE_FINDEXACT_BAD_CLASS class mismatch looking for an RRset ('%1' and '%2')</term>
-<listitem><para>
-The SQLite data source was looking up an exact RRset, but the data source
-contains different class than the query was for.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDREC">
-<term>DATASRC_SQLITE_FINDREC looking for record '%1/%2'</term>
-<listitem><para>
-Debug information. The SQLite data source is looking up records of given name
-and type in the database.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDREF">
-<term>DATASRC_SQLITE_FINDREF looking for referral at '%1'</term>
-<listitem><para>
-Debug information. The SQLite data source is identifying if this domain is
-a referral and where it goes.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FINDREF_BAD_CLASS">
-<term>DATASRC_SQLITE_FINDREF_BAD_CLASS class mismatch looking for referral ('%1' and '%2')</term>
-<listitem><para>
-The SQLite data source was trying to identify if there's a referral. But
-it contains different class than the query was for.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FIND_BAD_CLASS">
-<term>DATASRC_SQLITE_FIND_BAD_CLASS class mismatch looking for an RRset ('%1' and '%2')</term>
-<listitem><para>
-The SQLite data source was looking up an RRset, but the data source contains
-different class than the query was for.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FIND_NSEC3">
-<term>DATASRC_SQLITE_FIND_NSEC3 looking for NSEC3 in zone '%1' for hash '%2'</term>
-<listitem><para>
-Debug information. We're trying to look up a NSEC3 record in the SQLite data
-source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_FIND_NSEC3_NO_ZONE">
-<term>DATASRC_SQLITE_FIND_NSEC3_NO_ZONE no such zone '%1'</term>
-<listitem><para>
-The SQLite data source was asked to provide a NSEC3 record for given zone.
-But it doesn't contain that zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_NEWCONN">
-<term>DATASRC_SQLITE_NEWCONN SQLite3Database is being initialized</term>
-<listitem><para>
-A wrapper object to hold database connection is being initialized.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_OPEN">
-<term>DATASRC_SQLITE_OPEN opening SQLite database '%1'</term>
-<listitem><para>
-Debug information. The SQLite data source is loading an SQLite database in
-the provided file.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_PREVIOUS">
-<term>DATASRC_SQLITE_PREVIOUS looking for name previous to '%1'</term>
-<listitem><para>
-This is a debug message. The name given was not found, so the program
-is searching for the next name higher up the hierarchy (e.g. if
-www.example.com were queried for and not found, the software searches
-for the "previous" name, example.com).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_PREVIOUS_NO_ZONE">
-<term>DATASRC_SQLITE_PREVIOUS_NO_ZONE no zone containing '%1'</term>
-<listitem><para>
-The name given was not found, so the program is searching for the next
-name higher up the hierarchy (e.g. if www.example.com were queried
-for and not found, the software searches for the "previous" name,
-example.com). However, this name is not contained in any zone in the
-data source. This is an error since it indicates a problem in the earlier
-processing of the query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_SQLITE_SETUP">
-<term>DATASRC_SQLITE_SETUP setting up SQLite database</term>
-<listitem><para>
-The database for SQLite data source was found empty. It is assumed this is the
-first run and it is being initialized with current schema. It'll still contain
-no data, but it will be ready for use.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_STATIC_CLASS_NOT_CH">
-<term>DATASRC_STATIC_CLASS_NOT_CH static data source can handle CH class only</term>
-<listitem><para>
-An error message indicating that a query requesting a RR for a class other
-that CH was sent to the static data source (which only handles CH queries).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_STATIC_CREATE">
-<term>DATASRC_STATIC_CREATE creating the static datasource</term>
-<listitem><para>
-Debug information. The static data source (the one holding stuff like
-version.bind) is being created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_STATIC_FIND">
-<term>DATASRC_STATIC_FIND looking for '%1/%2'</term>
-<listitem><para>
-Debug information. This resource record set is being looked up in the static
-data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_UNEXPECTED_QUERY_STATE">
-<term>DATASRC_UNEXPECTED_QUERY_STATE unexpected query state</term>
-<listitem><para>
-This indicates a programming error. An internal task of unknown type was
-generated.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_CC_SESSION_ERROR">
-<term>DDNS_CC_SESSION_ERROR error reading from cc channel: %1</term>
-<listitem><para>
-There was a problem reading from the command and control channel. The
-most likely cause is that the msgq process is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_CC_SESSION_TIMEOUT_ERROR">
-<term>DDNS_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</term>
-<listitem><para>
-There was a problem reading a response from another module over the
-command and control channel. The most likely cause is that the
-configuration manager b10-cfgmgr is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_CONFIG_ERROR">
-<term>DDNS_CONFIG_ERROR error found in configuration data: %1</term>
-<listitem><para>
-The ddns process encountered an error when installing the configuration at
-startup time. Details of the error are included in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_MODULECC_SESSION_ERROR">
-<term>DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</term>
-<listitem><para>
-There was a problem in the lower level module handling configuration and
-control commands. This could happen for various reasons, but the most likely
-cause is that the configuration database contains a syntax error and ddns
-failed to start at initialization. A detailed error message from the module
-will also be displayed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_RECEIVED_SHUTDOWN_COMMAND">
-<term>DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
-<listitem><para>
-The ddns process received a shutdown command from the command channel
-and will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_RUNNING">
-<term>DDNS_RUNNING ddns server is running and listening for updates</term>
-<listitem><para>
-The ddns process has successfully started and is now ready to receive commands
-and updates.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_SHUTDOWN">
-<term>DDNS_SHUTDOWN ddns server shutting down</term>
-<listitem><para>
-The ddns process is shutting down. It will no longer listen for new commands
-or updates. Any command or update that is being addressed at this moment will
-be completed, after which the process will exit.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_STOPPED">
-<term>DDNS_STOPPED ddns server has stopped</term>
-<listitem><para>
-The ddns process has successfully stopped and is no longer listening for or
-handling commands or updates, and will now exit.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_STOPPED_BY_KEYBOARD">
-<term>DDNS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the ddns process. The
-process will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DDNS_UNCAUGHT_EXCEPTION">
-<term>DDNS_UNCAUGHT_EXCEPTION uncaught exception of type %1: %2</term>
-<listitem><para>
-The b10-ddns process encountered an uncaught exception and will now shut
-down. This is indicative of a programming error and should not happen under
-normal circumstances. The exception type and message are printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LIBXFRIN_DIFFERENT_TTL">
-<term>LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (%1, %2) on %3/%4/%5. Adjusting %2 -> %1.</term>
-<listitem><para>
-The xfrin module received an update containing multiple rdata changes for the
-same RRset. But the TTLs of these don't match each other. As we combine them
-together, the latter one gets overwritten to the earlier one in the sequence.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LIBXFRIN_NO_JOURNAL">
-<term>LIBXFRIN_NO_JOURNAL disabled journaling for updates to %1 on %2</term>
-<listitem><para>
-An attempt was made to create a Diff object with journaling enabled, but
-the underlying data source didn't support journaling (while still allowing
-updates) and so the created object has it disabled. At a higher level this
-means that the updates will be applied to the zone but subsequent IXFR requests
-will result in a full zone transfer (i.e., an AXFR-style IXFR). Unless the
-overhead of the full transfer is an issue this message can be ignored;
-otherwise you may want to check why the journaling wasn't allowed on the
-data source and either fix the issue or use a different type of data source.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOGIMPL_ABOVE_MAX_DEBUG">
-<term>LOGIMPL_ABOVE_MAX_DEBUG debug level of %1 is too high and will be set to the maximum of %2</term>
-<listitem><para>
-A message from the interface to the underlying logger implementation reporting
-that the debug level (as set by an internally-created string DEBUGn, where n
-is an integer, e.g. DEBUG22) is above the maximum allowed value and has
-been reduced to that value. The appearance of this message may indicate
-a programming error - please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOGIMPL_BAD_DEBUG_STRING">
-<term>LOGIMPL_BAD_DEBUG_STRING debug string '%1' has invalid format</term>
-<listitem><para>
-A message from the interface to the underlying logger implementation
-reporting that an internally-created string used to set the debug level
-is not of the correct format (it should be of the form DEBUGn, where n
-is an integer, e.g. DEBUG22). The appearance of this message indicates
-a programming error - please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOGIMPL_BELOW_MIN_DEBUG">
-<term>LOGIMPL_BELOW_MIN_DEBUG debug level of %1 is too low and will be set to the minimum of %2</term>
-<listitem><para>
-A message from the interface to the underlying logger implementation reporting
-that the debug level (as set by an internally-created string DEBUGn, where n
-is an integer, e.g. DEBUG22) is below the minimum allowed value and has
-been increased to that value. The appearance of this message may indicate
-a programming error - please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_BAD_DESTINATION">
-<term>LOG_BAD_DESTINATION unrecognized log destination: %1</term>
-<listitem><para>
-A logger destination value was given that was not recognized. The
-destination should be one of "console", "file", or "syslog".
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_BAD_SEVERITY">
-<term>LOG_BAD_SEVERITY unrecognized log severity: %1</term>
-<listitem><para>
-A logger severity value was given that was not recognized. The severity
-should be one of "DEBUG", "INFO", "WARN", "ERROR", "FATAL" or "NONE".
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_BAD_STREAM">
-<term>LOG_BAD_STREAM bad log console output stream: %1</term>
-<listitem><para>
-Logging has been configured so that output is written to the terminal
-(console) but the stream on which it is to be written is not recognised.
-Allowed values are "stdout" and "stderr".
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_DUPLICATE_MESSAGE_ID">
-<term>LOG_DUPLICATE_MESSAGE_ID duplicate message ID (%1) in compiled code</term>
-<listitem><para>
-During start-up, BIND 10 detected that the given message identification
-had been defined multiple times in the BIND 10 code. This indicates a
-programming error; please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_DUPLICATE_NAMESPACE">
-<term>LOG_DUPLICATE_NAMESPACE line %1: duplicate $NAMESPACE directive found</term>
-<listitem><para>
-When reading a message file, more than one $NAMESPACE directive was found.
-(This directive is used to set a C++ namespace when generating header
-files during software development.) Such a condition is regarded as an
-error and the read will be abandoned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_INPUT_OPEN_FAIL">
-<term>LOG_INPUT_OPEN_FAIL unable to open message file %1 for input: %2</term>
-<listitem><para>
-The program was not able to open the specified input message file for
-the reason given.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_INVALID_MESSAGE_ID">
-<term>LOG_INVALID_MESSAGE_ID line %1: invalid message identification '%2'</term>
-<listitem><para>
-An invalid message identification (ID) has been found during the read of
-a message file. Message IDs should comprise only alphanumeric characters
-and the underscore, and should not start with a digit.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_NAMESPACE_EXTRA_ARGS">
-<term>LOG_NAMESPACE_EXTRA_ARGS line %1: $NAMESPACE directive has too many arguments</term>
-<listitem><para>
-The $NAMESPACE directive in a message file takes a single argument, a
-namespace in which all the generated symbol names are placed. This error
-is generated when the compiler finds a $NAMESPACE directive with more
-than one argument.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_NAMESPACE_INVALID_ARG">
-<term>LOG_NAMESPACE_INVALID_ARG line %1: $NAMESPACE directive has an invalid argument ('%2')</term>
-<listitem><para>
-The $NAMESPACE argument in a message file should be a valid C++ namespace.
-This message is output if the simple check on the syntax of the string
-carried out by the reader fails.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_NAMESPACE_NO_ARGS">
-<term>LOG_NAMESPACE_NO_ARGS line %1: no arguments were given to the $NAMESPACE directive</term>
-<listitem><para>
-The $NAMESPACE directive in a message file takes a single argument,
-a C++ namespace in which all the generated symbol names are placed.
-This error is generated when the compiler finds a $NAMESPACE directive
-with no arguments.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_NO_MESSAGE_ID">
-<term>LOG_NO_MESSAGE_ID line %1: message definition line found without a message ID</term>
-<listitem><para>
-Within a message file, message are defined by lines starting with a "%".
-The rest of the line should comprise the message ID and text describing
-the message. This error indicates the message compiler found a line in
-the message file comprising just the "%" and nothing else.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_NO_MESSAGE_TEXT">
-<term>LOG_NO_MESSAGE_TEXT line %1: line found containing a message ID ('%2') and no text</term>
-<listitem><para>
-Within a message file, message are defined by lines starting with a "%".
-The rest of the line should comprise the message ID and text describing
-the message. This error indicates the message compiler found a line
-in the message file comprising just the "%" and message identification,
-but no text.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_NO_SUCH_MESSAGE">
-<term>LOG_NO_SUCH_MESSAGE could not replace message text for '%1': no such message</term>
-<listitem><para>
-During start-up a local message file was read. A line with the listed
-message identification was found in the file, but the identification is
-not one contained in the compiled-in message dictionary. This message
-may appear a number of times in the file, once for every such unknown
-message identification.
-</para><para>
-There may be several reasons why this message may appear:
-</para><para>
-- The message ID has been mis-spelled in the local message file.
-</para><para>
-- The program outputting the message may not use that particular message
-(e.g. it originates in a module not used by the program.)
-</para><para>
-- The local file was written for an earlier version of the BIND 10 software
-and the later version no longer generates that message.
-</para><para>
-Whatever the reason, there is no impact on the operation of BIND 10.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_OPEN_OUTPUT_FAIL">
-<term>LOG_OPEN_OUTPUT_FAIL unable to open %1 for output: %2</term>
-<listitem><para>
-Originating within the logging code, the program was not able to open
-the specified output file for the reason given.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_PREFIX_EXTRA_ARGS">
-<term>LOG_PREFIX_EXTRA_ARGS line %1: $PREFIX directive has too many arguments</term>
-<listitem><para>
-Within a message file, the $PREFIX directive takes a single argument,
-a prefix to be added to the symbol names when a C++ file is created.
-This error is generated when the compiler finds a $PREFIX directive with
-more than one argument.
-</para><para>
-Note: the $PREFIX directive is deprecated and will be removed in a future
-version of BIND 10.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_PREFIX_INVALID_ARG">
-<term>LOG_PREFIX_INVALID_ARG line %1: $PREFIX directive has an invalid argument ('%2')</term>
-<listitem><para>
-Within a message file, the $PREFIX directive takes a single argument,
-a prefix to be added to the symbol names when a C++ file is created.
-As such, it must adhere to restrictions on C++ symbol names (e.g. may
-only contain alphanumeric characters or underscores, and may nor start
-with a digit). A $PREFIX directive was found with an argument (given
-in the message) that violates those restrictions.
-</para><para>
-Note: the $PREFIX directive is deprecated and will be removed in a future
-version of BIND 10.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_READING_LOCAL_FILE">
-<term>LOG_READING_LOCAL_FILE reading local message file %1</term>
-<listitem><para>
-This is an informational message output by BIND 10 when it starts to read
-a local message file. (A local message file may replace the text of
-one of more messages; the ID of the message will not be changed though.)
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_READ_ERROR">
-<term>LOG_READ_ERROR error reading from message file %1: %2</term>
-<listitem><para>
-The specified error was encountered reading from the named message file.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_UNRECOGNISED_DIRECTIVE">
-<term>LOG_UNRECOGNISED_DIRECTIVE line %1: unrecognised directive '%2'</term>
-<listitem><para>
-Within a message file, a line starting with a dollar symbol was found
-(indicating the presence of a directive) but the first word on the line
-(shown in the message) was not recognised.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="LOG_WRITE_ERROR">
-<term>LOG_WRITE_ERROR error writing to %1: %2</term>
-<listitem><para>
-The specified error was encountered by the message compiler when writing
-to the named output file.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_DATASRC_ACCESS_FAILURE">
-<term>NOTIFY_OUT_DATASRC_ACCESS_FAILURE failed to get access to data source: %1</term>
-<listitem><para>
-notify_out failed to get access to one of configured data sources.
-Detailed error is shown in the log message. This can be either a
-configuration error or installation setup failure.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_DATASRC_ZONE_NOT_FOUND">
-<term>NOTIFY_OUT_DATASRC_ZONE_NOT_FOUND Zone %1 is not found</term>
-<listitem><para>
-notify_out attempted to get slave information of a zone but the zone
-isn't found in the expected data source. This shouldn't happen,
-because notify_out first identifies a list of available zones before
-this process. So this means some critical inconsistency in the data
-source or software bug.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_INVALID_ADDRESS">
-<term>NOTIFY_OUT_INVALID_ADDRESS invalid address %1#%2: %3</term>
-<listitem><para>
-The notify_out library tried to send a notify message to the given
-address, but it appears to be an invalid address. The configuration
-for secondary nameservers might contain a typographic error, or a
-different BIND 10 module has forgotten to validate its data before
-sending this module a notify command. As such, this should normally
-not happen, and points to an oversight in a different module.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_REPLY_BAD_OPCODE">
-<term>NOTIFY_OUT_REPLY_BAD_OPCODE bad opcode in notify reply from %1#%2: %3</term>
-<listitem><para>
-The notify_out library sent a notify message to the nameserver at
-the given address, but the response did not have the opcode set to
-NOTIFY. The opcode in the response is printed. Since there was a
-response, no more notifies will be sent to this server for this
-notification event.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_REPLY_BAD_QID">
-<term>NOTIFY_OUT_REPLY_BAD_QID bad QID in notify reply from %1#%2: got %3, should be %4</term>
-<listitem><para>
-The notify_out library sent a notify message to the nameserver at
-the given address, but the query id in the response does not match
-the one we sent. Since there was a response, no more notifies will
-be sent to this server for this notification event.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_REPLY_BAD_QUERY_NAME">
-<term>NOTIFY_OUT_REPLY_BAD_QUERY_NAME bad query name in notify reply from %1#%2: got %3, should be %4</term>
-<listitem><para>
-The notify_out library sent a notify message to the nameserver at
-the given address, but the query name in the response does not match
-the one we sent. Since there was a response, no more notifies will
-be sent to this server for this notification event.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_REPLY_QR_NOT_SET">
-<term>NOTIFY_OUT_REPLY_QR_NOT_SET QR flags set to 0 in reply to notify from %1#%2</term>
-<listitem><para>
-The notify_out library sent a notify message to the namesever at the
-given address, but the reply did not have the QR bit set to one.
-Since there was a response, no more notifies will be sent to this
-server for this notification event.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_REPLY_UNCAUGHT_EXCEPTION">
-<term>NOTIFY_OUT_REPLY_UNCAUGHT_EXCEPTION uncaught exception: %1</term>
-<listitem><para>
-There was an uncaught exception in the handling of a notify reply
-message, either in the message parser, or while trying to extract data
-from the parsed message. The error is printed, and notify_out will
-treat the response as a bad message, but this does point to a
-programming error, since all exceptions should have been caught
-explicitly. Please file a bug report. Since there was a response,
-no more notifies will be sent to this server for this notification
-event.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_RETRY_EXCEEDED">
-<term>NOTIFY_OUT_RETRY_EXCEEDED notify to %1#%2: number of retries (%3) exceeded</term>
-<listitem><para>
-The maximum number of retries for the notify target has been exceeded.
-Either the address of the secondary nameserver is wrong, or it is not
-responding.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_SENDING_NOTIFY">
-<term>NOTIFY_OUT_SENDING_NOTIFY sending notify to %1#%2</term>
-<listitem><para>
-A notify message is sent to the secondary nameserver at the given
-address.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_SOCKET_ERROR">
-<term>NOTIFY_OUT_SOCKET_ERROR socket error sending notify to %1#%2: %3</term>
-<listitem><para>
-There was a network error while trying to send a notify message to
-the given address. The address might be unreachable. The socket
-error is printed and should provide more information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_SOCKET_RECV_ERROR">
-<term>NOTIFY_OUT_SOCKET_RECV_ERROR socket error reading notify reply from %1#%2: %3</term>
-<listitem><para>
-There was a network error while trying to read a notify reply
-message from the given address. The socket error is printed and should
-provide more information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_TIMEOUT">
-<term>NOTIFY_OUT_TIMEOUT retry notify to %1#%2</term>
-<listitem><para>
-The notify message to the given address (noted as address#port) has
-timed out, and the message will be resent until the max retry limit
-is reached.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_ZONE_BAD_SOA">
-<term>NOTIFY_OUT_ZONE_BAD_SOA Zone %1 is invalid in terms of SOA</term>
-<listitem><para>
-This is a warning issued when the notify_out module finds a zone that
-doesn't have an SOA RR or has multiple SOA RRs. Notify message won't
-be sent to such a zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NOTIFY_OUT_ZONE_NO_NS">
-<term>NOTIFY_OUT_ZONE_NO_NS Zone %1 doesn't have NS RR</term>
-<listitem><para>
-This is a warning issued when the notify_out module finds a zone that
-doesn't have an NS RR. Notify message won't be sent to such a zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_EMPTY_RESPONSE">
-<term>NSAS_EMPTY_RESPONSE response to query for %1 returned an empty answer section</term>
-<listitem><para>
-The NSAS (nameserver address store - part of the resolver) made a query
-for information it needed. The query completed successfully but the
-answer section in the response was empty.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_ERROR_RESPONSE">
-<term>NSAS_ERROR_RESPONSE error response of %1 returned in query for %2</term>
-<listitem><para>
-The NSAS (nameserver address store - part of the resolver) made a query
-for information it needed. The query completed successfully but the
-RCODE in the response was something other than NOERROR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_FIND_NS_ADDRESS">
-<term>NSAS_FIND_NS_ADDRESS asking resolver to obtain A and AAAA records for %1</term>
-<listitem><para>
-A debug message issued when the NSAS (nameserver address store - part
-of the resolver) is making a callback into the resolver to retrieve the
-address records for the specified nameserver.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_FOUND_ADDRESS">
-<term>NSAS_FOUND_ADDRESS found address %1 for %2</term>
-<listitem><para>
-A debug message issued when the NSAS (nameserver address store - part
-of the resolver) has retrieved the given address for the specified
-nameserver through an external query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_LOOKUP_CANCEL">
-<term>NSAS_LOOKUP_CANCEL lookup for zone %1 has been canceled</term>
-<listitem><para>
-A debug message issued when an NSAS (nameserver address store - part of
-the resolver) lookup for a zone has been canceled.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_NS_LOOKUP_FAIL">
-<term>NSAS_NS_LOOKUP_FAIL failed to lookup any %1 for %2</term>
-<listitem><para>
-A debug message issued when the NSAS (nameserver address store - part of
-the resolver) has been unable to retrieve the specified resource record
-for the specified nameserver. This is not necessarily a problem - the
-nameserver may be unreachable, in which case the NSAS will try other
-nameservers in the zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_NULL_RESPONSE">
-<term>NSAS_NULL_RESPONSE got null message in success callback for query for %1</term>
-<listitem><para>
-The NSAS (nameserver address store - part of the resolver) made a query
-for information it needed. The query completed successfully, but the
-message passed to the callback was null.
-</para><para>
-This message indicates an internal error in the NSAS. Please raise a
-bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_SEARCH_ZONE_NS">
-<term>NSAS_SEARCH_ZONE_NS searching NSAS for nameservers for zone %1</term>
-<listitem><para>
-A debug message output when a call is made to the NSAS (nameserver
-address store - part of the resolver) to obtain the nameservers for
-the specified zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_UPDATE_RTT">
-<term>NSAS_UPDATE_RTT update RTT for %1: was %2 ms, is now %3 ms</term>
-<listitem><para>
-A NSAS (nameserver address store - part of the resolver) debug message
-reporting the update of a round-trip time (RTT) for a query made to the
-specified nameserver. The RTT has been updated using the value given
-and the new RTT is displayed. (The RTT is subject to a calculation that
-damps out sudden changes. As a result, the new RTT used by the NSAS in
-future decisions of which nameserver to use is not necessarily equal to
-the RTT reported.)
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="NSAS_WRONG_ANSWER">
-<term>NSAS_WRONG_ANSWER queried for %1 RR of type/class %2/%3, received response %4/%5</term>
-<listitem><para>
-A NSAS (nameserver address store - part of the resolver) made a query for
-a resource record of a particular type and class, but instead received
-an answer with a different given type and class.
-</para><para>
-This message indicates an internal error in the NSAS. Please raise a
-bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_ANSWER">
-<term>RESLIB_ANSWER answer received in response to query for <%1></term>
-<listitem><para>
-A debug message reporting that an answer has been received to an upstream
-query for the specified question. Previous debug messages will have
-indicated the server to which the question was sent.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_CNAME">
-<term>RESLIB_CNAME CNAME received in response to query for <%1></term>
-<listitem><para>
-A debug message recording that CNAME response has been received to an
-upstream query for the specified question. Previous debug messages will
-have indicated the server to which the question was sent.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_DEEPEST">
-<term>RESLIB_DEEPEST did not find <%1> in cache, deepest delegation found is %2</term>
-<listitem><para>
-A debug message, a cache lookup did not find the specified <name,
-class, type> tuple in the cache; instead, the deepest delegation found
-is indicated.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_EMPTY_RESPONSE">
-<term>RESLIB_EMPTY_RESPONSE empty response received to query for <%1></term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver did not contain anything in the answer or authority sections,
-although in all other respects it was a valid response. A SERVFAIL will
-be returned to the system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_ERROR_RESPONSE">
-<term>RESLIB_ERROR_RESPONSE unspecified error received in response to query for <%1></term>
-<listitem><para>
-A debug message, the response to the specified query to an upstream
-nameserver indicated that the response was classified as an erroneous
-response, but that the nature of the error cannot be identified.
-A SERVFAIL will be returned to the system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_EXTRADATA_RESPONSE">
-<term>RESLIB_EXTRADATA_RESPONSE extra data in response to query for <%1></term>
-<listitem><para>
-A debug message indicating that the response to the specified query
-from an upstream nameserver contained too much data. This can happen if
-an ANY query was sent and the answer section in the response contained
-multiple RRs with different names. A SERVFAIL will be returned to the
-system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_FOLLOW_CNAME">
-<term>RESLIB_FOLLOW_CNAME following CNAME chain to <%1></term>
-<listitem><para>
-A debug message, a CNAME response was received and another query is
-being issued for the <name, class, type> tuple.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_INVALID_NAMECLASS_RESPONSE">
-<term>RESLIB_INVALID_NAMECLASS_RESPONSE invalid name or class in response to query for <%1></term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) contained either
-an answer not matching the query name or an answer having a different
-class to that queried for. A SERVFAIL will be returned to the system
-making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_INVALID_QNAME_RESPONSE">
-<term>RESLIB_INVALID_QNAME_RESPONSE invalid name or class in response to query for <%1></term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) contained a name
-in the question section that did not match that of the query. A SERVFAIL
-will be returned to the system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_INVALID_TYPE_RESPONSE">
-<term>RESLIB_INVALID_TYPE_RESPONSE invalid name or class in response to query for <%1></term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) contained an
-invalid type field. A SERVFAIL will be returned to the system making
-the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_LONG_CHAIN">
-<term>RESLIB_LONG_CHAIN CNAME received in response to query for <%1>: CNAME chain length exceeded</term>
-<listitem><para>
-A debug message recording that a CNAME response has been received to an upstream
-query for the specified question (Previous debug messages will have indicated
-the server to which the question was sent). However, receipt of this CNAME
-has meant that the resolver has exceeded the CNAME chain limit (a CNAME chain
-is where on CNAME points to another) and so an error is being returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_MULTIPLE_CLASS_RESPONSE">
-<term>RESLIB_MULTIPLE_CLASS_RESPONSE response to query for <%1> contained multiple RRsets with different classes</term>
-<listitem><para>
-A debug message reporting that the response to an upstream query for
-the specified name contained multiple RRsets in the answer and not all
-were of the same class. This is a violation of the standard and so a
-SERVFAIL will be returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_NOTSINGLE_RESPONSE">
-<term>RESLIB_NOTSINGLE_RESPONSE response to query for <%1> was not a response</term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver was a CNAME that had mutiple RRs in the RRset. This is
-an invalid response according to the standards so a SERVFAIL will be
-returned to the system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_NOT_ONE_QNAME_RESPONSE">
-<term>RESLIB_NOT_ONE_QNAME_RESPONSE not one question in response to query for <%1></term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) did not contain
-one name in the question section as required by the standard. A SERVFAIL
-will be returned to the system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_NOT_RESPONSE">
-<term>RESLIB_NOT_RESPONSE response to query for <%1> was not a response</term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver (as identified by the ID of the response) did not have the QR
-bit set (thus indicating that the packet was a query, not a response).
-A SERVFAIL will be returned to the system making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_NO_NS_RRSET">
-<term>RESLIB_NO_NS_RRSET no NS RRSet in referral response received to query for <%1></term>
-<listitem><para>
-A debug message, this indicates that a response was received for the specified
-query and was categorized as a referral. However, the received message did
-not contain any NS RRsets. This may indicate a programming error in the
-response classification code.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_NSAS_LOOKUP">
-<term>RESLIB_NSAS_LOOKUP looking up nameserver for zone %1 in the NSAS</term>
-<listitem><para>
-A debug message, the RunningQuery object is querying the NSAS for the
-nameservers for the specified zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_NXDOM_NXRR">
-<term>RESLIB_NXDOM_NXRR NXDOMAIN/NXRRSET received in response to query for <%1></term>
-<listitem><para>
-A debug message recording that either a NXDOMAIN or an NXRRSET response has
-been received to an upstream query for the specified question. Previous debug
-messages will have indicated the server to which the question was sent.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_OPCODE_RESPONSE">
-<term>RESLIB_OPCODE_RESPONSE response to query for <%1> did not have query opcode</term>
-<listitem><para>
-A debug message, the response to the specified query from an upstream
-nameserver was a response that did not have the opcode set to that of
-a query. According to the standards, this is an invalid response to
-the query that was made, so a SERVFAIL will be returned to the system
-making the original query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_PROTOCOL">
-<term>RESLIB_PROTOCOL protocol error in answer for %1: %3</term>
-<listitem><para>
-A debug message indicating that a protocol error was received. As there
-are no retries left, an error will be reported.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_PROTOCOL_RETRY">
-<term>RESLIB_PROTOCOL_RETRY protocol error in answer for %1: %2 (retries left: %3)</term>
-<listitem><para>
-A debug message indicating that a protocol error was received and that
-the resolver is repeating the query to the same nameserver. After this
-repeated query, there will be the indicated number of retries left.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RCODE_ERROR">
-<term>RESLIB_RCODE_ERROR response to query for <%1> returns RCODE of %2</term>
-<listitem><para>
-A debug message, the response to the specified query indicated an error
-that is not covered by a specific code path. A SERVFAIL will be returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RECQ_CACHE_FIND">
-<term>RESLIB_RECQ_CACHE_FIND found <%1> in the cache (resolve() instance %2)</term>
-<listitem><para>
-This is a debug message and indicates that a RecursiveQuery object found the
-the specified <name, class, type> tuple in the cache. The instance number
-at the end of the message indicates which of the two resolve() methods has
-been called.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RECQ_CACHE_NO_FIND">
-<term>RESLIB_RECQ_CACHE_NO_FIND did not find <%1> in the cache, starting RunningQuery (resolve() instance %2)</term>
-<listitem><para>
-This is a debug message and indicates that the look in the cache made by the
-RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery
-object has been created to resolve the question. The instance number at
-the end of the message indicates which of the two resolve() methods has
-been called.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_REFERRAL">
-<term>RESLIB_REFERRAL referral received in response to query for <%1></term>
-<listitem><para>
-A debug message recording that a referral response has been received to an
-upstream query for the specified question. Previous debug messages will
-have indicated the server to which the question was sent.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_REFER_ZONE">
-<term>RESLIB_REFER_ZONE referred to zone %1</term>
-<listitem><para>
-A debug message indicating that the last referral message was to the specified
-zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RESOLVE">
-<term>RESLIB_RESOLVE asked to resolve <%1> (resolve() instance %2)</term>
-<listitem><para>
-A debug message, the RecursiveQuery::resolve method has been called to resolve
-the specified <name, class, type> tuple. The first action will be to lookup
-the specified tuple in the cache. The instance number at the end of the
-message indicates which of the two resolve() methods has been called.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RRSET_FOUND">
-<term>RESLIB_RRSET_FOUND found single RRset in the cache when querying for <%1> (resolve() instance %2)</term>
-<listitem><para>
-A debug message, indicating that when RecursiveQuery::resolve queried the
-cache, a single RRset was found which was put in the answer. The instance
-number at the end of the message indicates which of the two resolve()
-methods has been called.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RTT">
-<term>RESLIB_RTT round-trip time of last query calculated as %1 ms</term>
-<listitem><para>
-A debug message giving the round-trip time of the last query and response.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RUNQ_CACHE_FIND">
-<term>RESLIB_RUNQ_CACHE_FIND found <%1> in the cache</term>
-<listitem><para>
-This is a debug message and indicates that a RunningQuery object found
-the specified <name, class, type> tuple in the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RUNQ_CACHE_LOOKUP">
-<term>RESLIB_RUNQ_CACHE_LOOKUP looking up up <%1> in the cache</term>
-<listitem><para>
-This is a debug message and indicates that a RunningQuery object has made
-a call to its doLookup() method to look up the specified <name, class, type>
-tuple, the first action of which will be to examine the cache.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RUNQ_FAIL">
-<term>RESLIB_RUNQ_FAIL failure callback - nameservers are unreachable</term>
-<listitem><para>
-A debug message indicating that a RunningQuery's failure callback has been
-called because all nameservers for the zone in question are unreachable.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_RUNQ_SUCCESS">
-<term>RESLIB_RUNQ_SUCCESS success callback - sending query to %1</term>
-<listitem><para>
-A debug message indicating that a RunningQuery's success callback has been
-called because a nameserver has been found, and that a query is being sent
-to the specified nameserver.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_TCP_TRUNCATED">
-<term>RESLIB_TCP_TRUNCATED TCP response to query for %1 was truncated</term>
-<listitem><para>
-This is a debug message logged when a response to the specified query to an
-upstream nameserver returned a response with the TC (truncation) bit set. This
-is treated as an error by the code.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_TEST_SERVER">
-<term>RESLIB_TEST_SERVER setting test server to %1(%2)</term>
-<listitem><para>
-This is a warning message only generated in unit tests. It indicates
-that all upstream queries from the resolver are being routed to the
-specified server, regardless of the address of the nameserver to which
-the query would normally be routed. If seen during normal operation,
-please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_TEST_UPSTREAM">
-<term>RESLIB_TEST_UPSTREAM sending upstream query for <%1> to test server at %2</term>
-<listitem><para>
-This is a debug message and should only be seen in unit tests. A query for
-the specified <name, class, type> tuple is being sent to a test nameserver
-whose address is given in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_TIMEOUT">
-<term>RESLIB_TIMEOUT query <%1> to %2 timed out</term>
-<listitem><para>
-A debug message indicating that the specified upstream query has timed out and
-there are no retries left.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_TIMEOUT_RETRY">
-<term>RESLIB_TIMEOUT_RETRY query <%1> to %2 timed out, re-trying (retries left: %3)</term>
-<listitem><para>
-A debug message indicating that the specified query has timed out and that
-the resolver is repeating the query to the same nameserver. After this
-repeated query, there will be the indicated number of retries left.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_TRUNCATED">
-<term>RESLIB_TRUNCATED response to query for <%1> was truncated, re-querying over TCP</term>
-<listitem><para>
-A debug message, this indicates that the response to the specified query was
-truncated and that the resolver will be re-querying over TCP. There are
-various reasons why responses may be truncated, so this message is normal and
-gives no cause for concern.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESLIB_UPSTREAM">
-<term>RESLIB_UPSTREAM sending upstream query for <%1> to %2</term>
-<listitem><para>
-A debug message indicating that a query for the specified <name, class, type>
-tuple is being sent to a nameserver whose address is given in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_AXFR_TCP">
-<term>RESOLVER_AXFR_TCP AXFR request received over TCP</term>
-<listitem><para>
-This is a debug message output when the resolver received a request for
-an AXFR (full transfer of a zone) over TCP. Only authoritative servers
-are able to handle AXFR requests, so the resolver will return an error
-message to the sender with the RCODE set to NOTIMP.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_AXFR_UDP">
-<term>RESOLVER_AXFR_UDP AXFR request received over UDP</term>
-<listitem><para>
-This is a debug message output when the resolver received a request for
-an AXFR (full transfer of a zone) over UDP. Only authoritative servers
-are able to handle AXFR requests (and in any case, an AXFR request should
-be sent over TCP), so the resolver will return an error message to the
-sender with the RCODE set to NOTIMP.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_CLIENT_TIME_SMALL">
-<term>RESOLVER_CLIENT_TIME_SMALL client timeout of %1 is too small</term>
-<listitem><para>
-During the update of the resolver's configuration parameters, the value
-of the client timeout was found to be too small. The configuration
-update was abandoned and the parameters were not changed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_CONFIG_CHANNEL">
-<term>RESOLVER_CONFIG_CHANNEL configuration channel created</term>
-<listitem><para>
-This is a debug message output when the resolver has successfully
-established a connection to the configuration channel.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_CONFIG_ERROR">
-<term>RESOLVER_CONFIG_ERROR error in configuration: %1</term>
-<listitem><para>
-An error was detected in a configuration update received by the
-resolver. This may be in the format of the configuration message (in
-which case this is a programming error) or it may be in the data supplied
-(in which case it is a user error). The reason for the error, included
-in the message, will give more details. The configuration update is
-not applied and the resolver parameters were not changed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_CONFIG_LOADED">
-<term>RESOLVER_CONFIG_LOADED configuration loaded</term>
-<listitem><para>
-This is a debug message output when the resolver configuration has been
-successfully loaded.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_CONFIG_UPDATED">
-<term>RESOLVER_CONFIG_UPDATED configuration updated: %1</term>
-<listitem><para>
-This is a debug message output when the resolver configuration is being
-updated with the specified information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_CREATED">
-<term>RESOLVER_CREATED main resolver object created</term>
-<listitem><para>
-This is a debug message indicating that the main resolver object has
-been created.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_DNS_MESSAGE_RECEIVED">
-<term>RESOLVER_DNS_MESSAGE_RECEIVED DNS message received: %1</term>
-<listitem><para>
-This is a debug message from the resolver listing the contents of a
-received DNS message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_DNS_MESSAGE_SENT">
-<term>RESOLVER_DNS_MESSAGE_SENT DNS message of %1 bytes sent: %2</term>
-<listitem><para>
-This is a debug message containing details of the response returned by
-the resolver to the querying system.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_FAILED">
-<term>RESOLVER_FAILED resolver failed, reason: %1</term>
-<listitem><para>
-This is an error message output when an unhandled exception is caught
-by the resolver. After this, the resolver will shut itself down.
-Please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_FORWARD_ADDRESS">
-<term>RESOLVER_FORWARD_ADDRESS setting forward address %1(%2)</term>
-<listitem><para>
-If the resolver is running in forward mode, this message will appear
-during startup to list the forward address. If multiple addresses are
-specified, it will appear once for each address.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_FORWARD_QUERY">
-<term>RESOLVER_FORWARD_QUERY processing forward query</term>
-<listitem><para>
-This is a debug message indicating that a query received by the resolver
-has passed a set of checks (message is well-formed, it is allowed by the
-ACL, it is a supported opcode, etc.) and is being forwarded to upstream
-servers.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_HEADER_ERROR">
-<term>RESOLVER_HEADER_ERROR message received, exception when processing header: %1</term>
-<listitem><para>
-This is a debug message from the resolver noting that an exception
-occurred during the processing of a received packet. The packet has
-been dropped.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_IXFR">
-<term>RESOLVER_IXFR IXFR request received</term>
-<listitem><para>
-This is a debug message indicating that the resolver received a request
-for an IXFR (incremental transfer of a zone). Only authoritative servers
-are able to handle IXFR requests, so the resolver will return an error
-message to the sender with the RCODE set to NOTIMP.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_LOOKUP_TIME_SMALL">
-<term>RESOLVER_LOOKUP_TIME_SMALL lookup timeout of %1 is too small</term>
-<listitem><para>
-During the update of the resolver's configuration parameters, the value
-of the lookup timeout was found to be too small. The configuration
-update will not be applied.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_MESSAGE_ERROR">
-<term>RESOLVER_MESSAGE_ERROR error parsing received message: %1 - returning %2</term>
-<listitem><para>
-This is a debug message noting that parsing of the body of a received
-message by the resolver failed due to some error (although the parsing of
-the header succeeded). The message parameters give a textual description
-of the problem and the RCODE returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_NEGATIVE_RETRIES">
-<term>RESOLVER_NEGATIVE_RETRIES negative number of retries (%1) specified in the configuration</term>
-<listitem><para>
-This error is issued when a resolver configuration update has specified
-a negative retry count: only zero or positive values are valid. The
-configuration update was abandoned and the parameters were not changed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_NON_IN_PACKET">
-<term>RESOLVER_NON_IN_PACKET non-IN class request received, returning REFUSED message</term>
-<listitem><para>
-This debug message is issued when resolver has received a DNS packet that
-was not IN (Internet) class. The resolver cannot handle such packets,
-so is returning a REFUSED response to the sender.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_NORMAL_QUERY">
-<term>RESOLVER_NORMAL_QUERY processing normal query</term>
-<listitem><para>
-This is a debug message indicating that the query received by the resolver
-has passed a set of checks (message is well-formed, it is allowed by the
-ACL, it is a supported opcode, etc.) and is being processed by the resolver.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_NOTIFY_RECEIVED">
-<term>RESOLVER_NOTIFY_RECEIVED NOTIFY arrived but server is not authoritative</term>
-<listitem><para>
-The resolver has received a NOTIFY message. As the server is not
-authoritative it cannot process it, so it returns an error message to
-the sender with the RCODE set to NOTAUTH.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_NOT_ONE_QUESTION">
-<term>RESOLVER_NOT_ONE_QUESTION query contained %1 questions, exactly one question was expected</term>
-<listitem><para>
-This debug message indicates that the resolver received a query that
-contained the number of entries in the question section detailed in
-the message. This is a malformed message, as a DNS query must contain
-only one question. The resolver will return a message to the sender
-with the RCODE set to FORMERR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_NO_ROOT_ADDRESS">
-<term>RESOLVER_NO_ROOT_ADDRESS no root addresses available</term>
-<listitem><para>
-A warning message issued during resolver startup, this indicates that
-no root addresses have been set. This may be because the resolver will
-get them from a priming query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_PARSE_ERROR">
-<term>RESOLVER_PARSE_ERROR error parsing received message: %1 - returning %2</term>
-<listitem><para>
-This is a debug message noting that the resolver received a message and
-the parsing of the body of the message failed due to some non-protocol
-related reason (although the parsing of the header succeeded).
-The message parameters give a textual description of the problem and
-the RCODE returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_PRINT_COMMAND">
-<term>RESOLVER_PRINT_COMMAND print message command, arguments are: %1</term>
-<listitem><para>
-This debug message is logged when a "print_message" command is received
-by the resolver over the command channel.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_PROTOCOL_ERROR">
-<term>RESOLVER_PROTOCOL_ERROR protocol error parsing received message: %1 - returning %2</term>
-<listitem><para>
-This is a debug message noting that the resolver received a message and
-the parsing of the body of the message failed due to some protocol error
-(although the parsing of the header succeeded). The message parameters
-give a textual description of the problem and the RCODE returned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_QUERY_ACCEPTED">
-<term>RESOLVER_QUERY_ACCEPTED query accepted: '%1/%2/%3' from %4</term>
-<listitem><para>
-This debug message is produced by the resolver when an incoming query
-is accepted in terms of the query ACL. The log message shows the query
-in the form of <query name>/<query type>/<query class>, and the client
-that sends the query in the form of <Source IP address>#<source port>.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_QUERY_DROPPED">
-<term>RESOLVER_QUERY_DROPPED query dropped: '%1/%2/%3' from %4</term>
-<listitem><para>
-This is an informational message that indicates an incoming query has
-been dropped by the resolver because of the query ACL. Unlike the
-RESOLVER_QUERY_REJECTED case, the server does not return any response.
-The log message shows the query in the form of <query name>/<query
-type>/<query class>, and the client that sends the query in the form of
-<Source IP address>#<source port>.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_QUERY_REJECTED">
-<term>RESOLVER_QUERY_REJECTED query rejected: '%1/%2/%3' from %4</term>
-<listitem><para>
-This is an informational message that indicates an incoming query has
-been rejected by the resolver because of the query ACL. This results
-in a response with an RCODE of REFUSED. The log message shows the query
-in the form of <query name>/<query type>/<query class>, and the client
-that sends the query in the form of <Source IP address>#<source port>.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_QUERY_SETUP">
-<term>RESOLVER_QUERY_SETUP query setup</term>
-<listitem><para>
-This is a debug message noting that the resolver is creating a
-RecursiveQuery object.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_QUERY_SHUTDOWN">
-<term>RESOLVER_QUERY_SHUTDOWN query shutdown</term>
-<listitem><para>
-This is a debug message noting that the resolver is destroying a
-RecursiveQuery object.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_QUERY_TIME_SMALL">
-<term>RESOLVER_QUERY_TIME_SMALL query timeout of %1 is too small</term>
-<listitem><para>
-During the update of the resolver's configuration parameters, the value
-of the query timeout was found to be too small. The configuration
-parameters were not changed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_RECEIVED_MESSAGE">
-<term>RESOLVER_RECEIVED_MESSAGE resolver has received a DNS message</term>
-<listitem><para>
-This is a debug message indicating that the resolver has received a
-DNS message. Depending on the debug settings, subsequent log output
-will indicate the nature of the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_RECURSIVE">
-<term>RESOLVER_RECURSIVE running in recursive mode</term>
-<listitem><para>
-This is an informational message that appears at startup noting that
-the resolver is running in recursive mode.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_SERVICE_CREATED">
-<term>RESOLVER_SERVICE_CREATED service object created</term>
-<listitem><para>
-This debug message is output when resolver creates the main service object
-(which handles the received queries).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_SET_PARAMS">
-<term>RESOLVER_SET_PARAMS query timeout: %1, client timeout: %2, lookup timeout: %3, retry count: %4</term>
-<listitem><para>
-This debug message lists the parameters being set for the resolver. These are:
-query timeout: the timeout (in ms) used for queries originated by the resolver
-to upstream servers. Client timeout: the interval to resolve a query by
-a client: after this time, the resolver sends back a SERVFAIL to the client
-whilst continuing to resolve the query. Lookup timeout: the time at which the
-resolver gives up trying to resolve a query. Retry count: the number of times
-the resolver will retry a query to an upstream server if it gets a timeout.
-</para><para>
-The client and lookup timeouts require a bit more explanation. The
-resolution of the client query might require a large number of queries to
-upstream nameservers. Even if none of these queries timeout, the total time
-taken to perform all the queries may exceed the client timeout. When this
-happens, a SERVFAIL is returned to the client, but the resolver continues
-with the resolution process; data received is added to the cache. However,
-there comes a time - the lookup timeout - when even the resolver gives up.
-At this point it will wait for pending upstream queries to complete or
-timeout and drop the query.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_SET_QUERY_ACL">
-<term>RESOLVER_SET_QUERY_ACL query ACL is configured</term>
-<listitem><para>
-This debug message is generated when a new query ACL is configured for
-the resolver.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_SET_ROOT_ADDRESS">
-<term>RESOLVER_SET_ROOT_ADDRESS setting root address %1(%2)</term>
-<listitem><para>
-This message gives the address of one of the root servers used by the
-resolver. It is output during startup and may appear multiple times,
-once for each root server address.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_SHUTDOWN">
-<term>RESOLVER_SHUTDOWN resolver shutdown complete</term>
-<listitem><para>
-This informational message is output when the resolver has shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_STARTED">
-<term>RESOLVER_STARTED resolver started</term>
-<listitem><para>
-This informational message is output by the resolver when all initialization
-has been completed and it is entering its main loop.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_STARTING">
-<term>RESOLVER_STARTING starting resolver with command line '%1'</term>
-<listitem><para>
-An informational message, this is output when the resolver starts up.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_UNEXPECTED_RESPONSE">
-<term>RESOLVER_UNEXPECTED_RESPONSE received unexpected response, ignoring</term>
-<listitem><para>
-This is a debug message noting that the resolver received a DNS response
-packet on the port on which is it listening for queries. The packet
-has been ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="RESOLVER_UNSUPPORTED_OPCODE">
-<term>RESOLVER_UNSUPPORTED_OPCODE opcode %1 not supported by the resolver</term>
-<listitem><para>
-This is debug message output when the resolver received a message with an
-unsupported opcode (it can only process QUERY opcodes). It will return
-a message to the sender with the RCODE set to NOTIMP.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SOCKETREQUESTOR_CREATED">
-<term>SOCKETREQUESTOR_CREATED Socket requestor created</term>
-<listitem><para>
-Debug message. A socket requesor (client of the socket creator) is created
-for the corresponding application. Normally this should happen at most
-one time throughout the lifetime of the application.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SOCKETREQUESTOR_DESTROYED">
-<term>SOCKETREQUESTOR_DESTROYED Socket requestor destoryed</term>
-<listitem><para>
-Debug message. The socket requestor created at SOCKETREQUESTOR_CREATED
-has been destroyed. This event is generally unexpected other than in
-test cases.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SOCKETREQUESTOR_GETSOCKET">
-<term>SOCKETREQUESTOR_GETSOCKET Received a %1 socket for [%2]:%3, FD=%4, token=%5, path=%6</term>
-<listitem><para>
-Debug message. The socket requestor for the corresponding application
-has requested a socket for a set of address, port and protocol (shown
-in the log message) and successfully got it from the creator. The
-corresponding file descriptor and the associated "token" (an internal
-ID used between the creator and requestor) are shown in the log
-message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SOCKETREQUESTOR_RELEASESOCKET">
-<term>SOCKETREQUESTOR_RELEASESOCKET Released a socket of token %1</term>
-<listitem><para>
-Debug message. The socket requestor has released a socket passed by
-the creator. The associated token of the socket is shown in the
-log message. If the corresponding SOCKETREQUESTOR_GETSOCKET was logged
-more detailed information of the socket can be identified by matching
-the token.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_ADDRESSES_NOT_LIST">
-<term>SRVCOMM_ADDRESSES_NOT_LIST the address and port specification is not a list in %1</term>
-<listitem><para>
-This points to an error in configuration. What was supposed to be a list of
-IP address - port pairs isn't a list at all but something else.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_ADDRESS_FAIL">
-<term>SRVCOMM_ADDRESS_FAIL failed to listen on addresses (%1)</term>
-<listitem><para>
-The server failed to bind to one of the address/port pair it should according
-to configuration, for reason listed in the message (usually because that pair
-is already used by other service or missing privileges). The server will try
-to recover and bind the address/port pairs it was listening to before (if any).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_ADDRESS_MISSING">
-<term>SRVCOMM_ADDRESS_MISSING address specification is missing "address" or "port" element in %1</term>
-<listitem><para>
-This points to an error in configuration. An address specification in the
-configuration is missing either an address or port and so cannot be used. The
-specification causing the error is given in the message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_ADDRESS_TYPE">
-<term>SRVCOMM_ADDRESS_TYPE address specification type is invalid in %1</term>
-<listitem><para>
-This points to an error in configuration. An address specification in the
-configuration malformed. The specification causing the error is given in the
-message. A valid specification contains an address part (which must be a string
-and must represent a valid IPv4 or IPv6 address) and port (which must be an
-integer in the range valid for TCP/UDP ports on your system).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_ADDRESS_UNRECOVERABLE">
-<term>SRVCOMM_ADDRESS_UNRECOVERABLE failed to recover original addresses also (%1)</term>
-<listitem><para>
-The recovery of old addresses after SRVCOMM_ADDRESS_FAIL also failed for
-the reason listed.
-</para><para>
-The condition indicates problems with the server and/or the system on
-which it is running. The server will continue running to allow
-reconfiguration, but will not be listening on any address or port until
-an administrator does so.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_ADDRESS_VALUE">
-<term>SRVCOMM_ADDRESS_VALUE address to set: %1#%2</term>
-<listitem><para>
-Debug message. This lists one address and port value of the set of
-addresses we are going to listen on (eg. there will be one log message
-per pair). This appears only after SRVCOMM_SET_LISTEN, but might
-be hidden, as it has higher debug level.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_KEYS_DEINIT">
-<term>SRVCOMM_KEYS_DEINIT deinitializing TSIG keyring</term>
-<listitem><para>
-Debug message indicating that the server is deinitializing the TSIG keyring.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_KEYS_INIT">
-<term>SRVCOMM_KEYS_INIT initializing TSIG keyring</term>
-<listitem><para>
-Debug message indicating that the server is initializing the global TSIG
-keyring. This should be seen only at server start.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_KEYS_UPDATE">
-<term>SRVCOMM_KEYS_UPDATE updating TSIG keyring</term>
-<listitem><para>
-Debug message indicating new keyring is being loaded from configuration (either
-on startup or as a result of configuration update).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_PORT_RANGE">
-<term>SRVCOMM_PORT_RANGE port out of valid range (%1 in %2)</term>
-<listitem><para>
-This points to an error in configuration. The port in an address
-specification is outside the valid range of 0 to 65535.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="SRVCOMM_SET_LISTEN">
-<term>SRVCOMM_SET_LISTEN setting addresses to listen to</term>
-<listitem><para>
-Debug message, noting that the server is about to start listening on a
-different set of IP addresses and ports than before.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_BAD_OPTION_VALUE">
-<term>STATHTTPD_BAD_OPTION_VALUE bad command line argument: %1</term>
-<listitem><para>
-The stats-httpd module was called with a bad command-line argument
-and will not start.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_CC_SESSION_ERROR">
-<term>STATHTTPD_CC_SESSION_ERROR error connecting to message bus: %1</term>
-<listitem><para>
-The stats-httpd module was unable to connect to the BIND 10 command
-and control bus. A likely problem is that the message bus daemon
-(b10-msgq) is not running. The stats-httpd module will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_CLOSING">
-<term>STATHTTPD_CLOSING closing %1#%2</term>
-<listitem><para>
-The stats-httpd daemon will stop listening for requests on the given
-address and port number.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_CLOSING_CC_SESSION">
-<term>STATHTTPD_CLOSING_CC_SESSION stopping cc session</term>
-<listitem><para>
-Debug message indicating that the stats-httpd module is disconnecting
-from the command and control bus.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_HANDLE_CONFIG">
-<term>STATHTTPD_HANDLE_CONFIG reading configuration: %1</term>
-<listitem><para>
-The stats-httpd daemon has received new configuration data and will now
-process it. The (changed) data is printed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_RECEIVED_SHUTDOWN_COMMAND">
-<term>STATHTTPD_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
-<listitem><para>
-A shutdown command was sent to the stats-httpd module, and it will
-now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_RECEIVED_STATUS_COMMAND">
-<term>STATHTTPD_RECEIVED_STATUS_COMMAND received command to return status</term>
-<listitem><para>
-A status command was sent to the stats-httpd module, and it will
-respond with 'Stats Httpd is up.' and its PID.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_RECEIVED_UNKNOWN_COMMAND">
-<term>STATHTTPD_RECEIVED_UNKNOWN_COMMAND received unknown command: %1</term>
-<listitem><para>
-An unknown command has been sent to the stats-httpd module. The
-stats-httpd module will respond with an error, and the command will
-be ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_SERVER_DATAERROR">
-<term>STATHTTPD_SERVER_DATAERROR HTTP server data error: %1</term>
-<listitem><para>
-An internal error occurred while handling an HTTP request. An HTTP 404
-response will be sent back, and the specific error is printed. This
-is an error condition that likely points the specified data
-corresponding to the requested URI is incorrect.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_SERVER_ERROR">
-<term>STATHTTPD_SERVER_ERROR HTTP server error: %1</term>
-<listitem><para>
-An internal error occurred while handling an HTTP request. An HTTP 500
-response will be sent back, and the specific error is printed. This
-is an error condition that likely points to a module that is not
-responding correctly to statistic requests.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_SERVER_INIT_ERROR">
-<term>STATHTTPD_SERVER_INIT_ERROR HTTP server initialization error: %1</term>
-<listitem><para>
-There was a problem initializing the HTTP server in the stats-httpd
-module upon receiving its configuration data. The most likely cause
-is a port binding problem or a bad configuration value. The specific
-error is printed in the message. The new configuration is ignored,
-and an error is sent back.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_SHUTDOWN">
-<term>STATHTTPD_SHUTDOWN shutting down</term>
-<listitem><para>
-The stats-httpd daemon is shutting down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_STARTED">
-<term>STATHTTPD_STARTED listening on %1#%2</term>
-<listitem><para>
-The stats-httpd daemon will now start listening for requests on the
-given address and port number.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_STARTING_CC_SESSION">
-<term>STATHTTPD_STARTING_CC_SESSION starting cc session</term>
-<listitem><para>
-Debug message indicating that the stats-httpd module is connecting to
-the command and control bus.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_START_SERVER_INIT_ERROR">
-<term>STATHTTPD_START_SERVER_INIT_ERROR HTTP server initialization error: %1</term>
-<listitem><para>
-There was a problem initializing the HTTP server in the stats-httpd
-module upon startup. The most likely cause is that it was not able
-to bind to the listening port. The specific error is printed, and the
-module will shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_STOPPED_BY_KEYBOARD">
-<term>STATHTTPD_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the stats-httpd
-daemon. The daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATHTTPD_UNKNOWN_CONFIG_ITEM">
-<term>STATHTTPD_UNKNOWN_CONFIG_ITEM unknown configuration item: %1</term>
-<listitem><para>
-The stats-httpd daemon received a configuration update from the
-configuration manager. However, one of the items in the
-configuration is unknown. The new configuration is ignored, and an
-error is sent back. As possible cause is that there was an upgrade
-problem, and the stats-httpd version is out of sync with the rest of
-the system.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_BAD_OPTION_VALUE">
-<term>STATS_BAD_OPTION_VALUE bad command line argument: %1</term>
-<listitem><para>
-The stats module was called with a bad command-line argument and will
-not start.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_CC_SESSION_ERROR">
-<term>STATS_CC_SESSION_ERROR error connecting to message bus: %1</term>
-<listitem><para>
-The stats module was unable to connect to the BIND 10 command and
-control bus. A likely problem is that the message bus daemon
-(b10-msgq) is not running. The stats module will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_NEW_CONFIG">
-<term>STATS_RECEIVED_NEW_CONFIG received new configuration: %1</term>
-<listitem><para>
-This debug message is printed when the stats module has received a
-configuration update from the configuration manager.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND">
-<term>STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND received command to show all statistics schema</term>
-<listitem><para>
-The stats module received a command to show all statistics schemas of all modules.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND">
-<term>STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND received command to show statistics schema for %1</term>
-<listitem><para>
-The stats module received a command to show the specified statistics schema of the specified module.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_SHOW_ALL_COMMAND">
-<term>STATS_RECEIVED_SHOW_ALL_COMMAND received command to show all statistics</term>
-<listitem><para>
-The stats module received a command to show all statistics that it has
-collected.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_SHOW_NAME_COMMAND">
-<term>STATS_RECEIVED_SHOW_NAME_COMMAND received command to show statistics for %1</term>
-<listitem><para>
-The stats module received a command to show the statistics that it has
-collected for the given item.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_SHUTDOWN_COMMAND">
-<term>STATS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
-<listitem><para>
-A shutdown command was sent to the stats module and it will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_STATUS_COMMAND">
-<term>STATS_RECEIVED_STATUS_COMMAND received command to return status</term>
-<listitem><para>
-A status command was sent to the stats module. It will return a
-response indicating that it is running normally.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_RECEIVED_UNKNOWN_COMMAND">
-<term>STATS_RECEIVED_UNKNOWN_COMMAND received unknown command: %1</term>
-<listitem><para>
-An unknown command has been sent to the stats module. The stats module
-will respond with an error and the command will be ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_SEND_REQUEST_BOSS">
-<term>STATS_SEND_REQUEST_BOSS requesting boss to send statistics</term>
-<listitem><para>
-This debug message is printed when a request is sent to the boss module
-to send its data to the stats module.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_STARTING">
-<term>STATS_STARTING starting</term>
-<listitem><para>
-The stats module will be now starting.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_START_ERROR">
-<term>STATS_START_ERROR stats module error: %1</term>
-<listitem><para>
-An internal error occurred while starting the stats module. The stats
-module will be now shutting down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_STOPPED_BY_KEYBOARD">
-<term>STATS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the stats module. The
-daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="STATS_UNKNOWN_COMMAND_IN_SPEC">
-<term>STATS_UNKNOWN_COMMAND_IN_SPEC unknown command in specification file: %1</term>
-<listitem><para>
-The specification file for the stats module contains a command that
-is unknown in the implementation. The most likely cause is an
-installation problem, where the specification file stats.spec is
-from a different version of BIND 10 than the stats module itself.
-Please check your installation.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_AXFR_INCONSISTENT_SOA">
-<term>XFRIN_AXFR_INCONSISTENT_SOA AXFR SOAs are inconsistent for %1: %2 expected, %3 received</term>
-<listitem><para>
-The serial fields of the first and last SOAs of AXFR (including AXFR-style
-IXFR) are not the same. According to RFC 5936 these two SOAs must be the
-"same" (not only for the serial), but it is still not clear what the
-receiver should do if this condition does not hold. There was a discussion
-about this at the IETF dnsext wg:
-http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
-and the general feeling seems that it would be better to reject the
-transfer if a mismatch is detected. On the other hand, also as noted
-in that email thread, neither BIND 9 nor NSD performs any comparison
-on the SOAs. For now, we only check the serials (ignoring other fields)
-and only leave a warning log message when a mismatch is found. If it
-turns out to happen with a real world primary server implementation
-and that server actually feeds broken data (e.g. mixed versions of
-zone), we can consider a stricter action.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_BAD_MASTER_ADDR_FORMAT">
-<term>XFRIN_BAD_MASTER_ADDR_FORMAT bad format for master address: %1</term>
-<listitem><para>
-The given master address is not a valid IP address.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_BAD_MASTER_PORT_FORMAT">
-<term>XFRIN_BAD_MASTER_PORT_FORMAT bad format for master port: %1</term>
-<listitem><para>
-The master port as read from the configuration is not a valid port number.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_BAD_TSIG_KEY_STRING">
-<term>XFRIN_BAD_TSIG_KEY_STRING bad TSIG key string: %1</term>
-<listitem><para>
-The TSIG key string as read from the configuration does not represent
-a valid TSIG key.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_BAD_ZONE_CLASS">
-<term>XFRIN_BAD_ZONE_CLASS Invalid zone class: %1</term>
-<listitem><para>
-The zone class as read from the configuration is not a valid DNS class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_CC_SESSION_ERROR">
-<term>XFRIN_CC_SESSION_ERROR error reading from cc channel: %1</term>
-<listitem><para>
-There was a problem reading from the command and control channel. The
-most likely cause is that xfrin the msgq daemon is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_COMMAND_ERROR">
-<term>XFRIN_COMMAND_ERROR error while executing command '%1': %2</term>
-<listitem><para>
-There was an error while the given command was being processed. The
-error is given in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_CONNECT_MASTER">
-<term>XFRIN_CONNECT_MASTER error connecting to master at %1: %2</term>
-<listitem><para>
-There was an error opening a connection to the master. The error is
-shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_GOT_INCREMENTAL_RESP">
-<term>XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1</term>
-<listitem><para>
-In an attempt of IXFR processing, the begenning SOA of the first difference
-(following the initial SOA that specified the final SOA for all the
-differences) was found. This means a connection for xfrin tried IXFR
-and really aot a response for incremental updates.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_GOT_NONINCREMENTAL_RESP">
-<term>XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1</term>
-<listitem><para>
-Non incremental transfer was detected at the "first data" of a transfer,
-which is the RR following the initial SOA. Non incremental transfer is
-either AXFR or AXFR-style IXFR. In the latter case, it means that
-in a response to IXFR query the first data is not SOA or its SOA serial
-is not equal to the requested SOA serial.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_IMPORT_DNS">
-<term>XFRIN_IMPORT_DNS error importing python DNS module: %1</term>
-<listitem><para>
-There was an error importing the python DNS module pydnspp. The most
-likely cause is a PYTHONPATH problem.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_IXFR_UPTODATE">
-<term>XFRIN_IXFR_UPTODATE IXFR requested serial for %1 is %2, master has %3, not updating</term>
-<listitem><para>
-The first SOA record in an IXFR response indicates the zone's serial
-at the primary server is not newer than the client's. This is
-basically unexpected event because normally the client first checks
-the SOA serial by an SOA query, but can still happen if the transfer
-is manually invoked or (although unlikely) there is a rapid change at
-the primary server between the SOA and IXFR queries. The client
-implementation confirms the whole response is this single SOA, and
-aborts the transfer just like a successful case.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_MSGQ_SEND_ERROR">
-<term>XFRIN_MSGQ_SEND_ERROR error while contacting %1 and %2</term>
-<listitem><para>
-There was a problem sending a message to the xfrout module or the
-zone manager. This most likely means that the msgq daemon has quit or
-was killed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER">
-<term>XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER error while contacting %1</term>
-<listitem><para>
-There was a problem sending a message to the zone manager. This most
-likely means that the msgq daemon has quit or was killed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_NOTIFY_UNKNOWN_MASTER">
-<term>XFRIN_NOTIFY_UNKNOWN_MASTER got notification to retransfer zone %1 from %2, expected %3</term>
-<listitem><para>
-The system received a notify for the given zone, but the address it came
-from does not match the master address in the Xfrin configuration. The notify
-is ignored. This may indicate that the configuration for the master is wrong,
-that a wrong machine is sending notifies, or that fake notifies are being sent.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_RETRANSFER_UNKNOWN_ZONE">
-<term>XFRIN_RETRANSFER_UNKNOWN_ZONE got notification to retransfer unknown zone %1</term>
-<listitem><para>
-There was an internal command to retransfer the given zone, but the
-zone is not known to the system. This may indicate that the configuration
-for xfrin is incomplete, or there was a typographical error in the
-zone name in the configuration.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_STARTING">
-<term>XFRIN_STARTING starting resolver with command line '%1'</term>
-<listitem><para>
-An informational message, this is output when the resolver starts up.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_STOPPED_BY_KEYBOARD">
-<term>XFRIN_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the xfrin daemon. The
-daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_UNKNOWN_ERROR">
-<term>XFRIN_UNKNOWN_ERROR unknown error: %1</term>
-<listitem><para>
-An uncaught exception was raised while running the xfrin daemon. The
-exception message is printed in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_OTHER_FAILURE">
-<term>XFRIN_XFR_OTHER_FAILURE %1 transfer of zone %2 failed: %3</term>
-<listitem><para>
-The XFR transfer for the given zone has failed due to a problem outside
-of the xfrin module. Possible reasons are a broken DNS message or failure
-in database connection. The error is shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_PROCESS_FAILURE">
-<term>XFRIN_XFR_PROCESS_FAILURE %1 transfer of zone %2/%3 failed: %4</term>
-<listitem><para>
-An XFR session failed outside the main protocol handling. This
-includes an error at the data source level at the initialization
-phase, unexpected failure in the network connection setup to the
-master server, or even more unexpected failure due to unlikely events
-such as memory allocation failure. Details of the error are shown in
-the log message. In general, these errors are not really expected
-ones, and indicate an installation error or a program bug. The
-session handler thread tries to clean up all intermediate resources
-even on these errors, but it may be incomplete. So, if this log
-message continuously appears, system resource consumption should be
-checked, and you may even want to disable the corresponding transfers.
-You may also want to file a bug report if this message appears so
-often.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_TRANSFER_FAILURE">
-<term>XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 with %3 failed: %4</term>
-<listitem><para>
-The XFR transfer for the given zone has failed due to an internal error.
-The error is shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_TRANSFER_FALLBACK">
-<term>XFRIN_XFR_TRANSFER_FALLBACK falling back from IXFR to AXFR for %1</term>
-<listitem><para>
-The IXFR transfer of the given zone failed. This might happen in many cases,
-such that the remote server doesn't support IXFR, we don't have the SOA record
-(or the zone at all), we are out of sync, etc. In many of these situations,
-AXFR could still work. Therefore we try that one in case it helps.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_TRANSFER_PROTOCOL_ERROR">
-<term>XFRIN_XFR_TRANSFER_PROTOCOL_ERROR %1 transfer of zone %2 with %3 failed: %4</term>
-<listitem><para>
-The XFR transfer for the given zone has failed due to a protocol
-error, such as an unexpected response from the primary server. The
-error is shown in the log message. It may be because the primary
-server implementation is broken or (although less likely) there was
-some attack attempt, but it can also happen due to configuration
-mismatch such as the remote server does not have authority for the
-zone any more but the local configuration hasn't been updated. So it
-is recommended to check the primary server configuration.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_TRANSFER_STARTED">
-<term>XFRIN_XFR_TRANSFER_STARTED %1 transfer of zone %2 started</term>
-<listitem><para>
-A connection to the master server has been made, the serial value in
-the SOA record has been checked, and a zone transfer has been started.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_XFR_TRANSFER_SUCCESS">
-<term>XFRIN_XFR_TRANSFER_SUCCESS %1 transfer of zone %2 succeeded</term>
-<listitem><para>
-The XFR transfer of the given zone was successfully completed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_ZONE_CREATED">
-<term>XFRIN_ZONE_CREATED Zone %1 not found in the given data source, newly created</term>
-<listitem><para>
-On starting an xfrin session, it is identified that the zone to be
-transferred is not found in the data source. This can happen if a
-secondary DNS server first tries to perform AXFR from a primary server
-without creating the zone image beforehand (e.g. by b10-loadzone). As
-of this writing the xfrin process provides backward compatible
-behavior to previous versions: creating a new one in the data source
-not to surprise existing users too much. This is probably not a good
-idea, however, in terms of who should be responsible for managing
-zones at a higher level. In future it is more likely that a separate
-zone management framework is provided, and the situation where the
-given zone isn't found in xfrout will be treated as an error.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_ZONE_MULTIPLE_SOA">
-<term>XFRIN_ZONE_MULTIPLE_SOA Zone %1 has %2 SOA RRs</term>
-<listitem><para>
-On starting an xfrin session, it is identified that the zone to be
-transferred has multiple SOA RRs. Such a zone is broken, but could be
-accidentally configured especially in a data source using "non
-captive" backend database. The implementation ignores entire SOA RRs
-and tries to continue processing as if the zone were empty. This
-means subsequent AXFR can succeed and possibly replace the zone with
-valid content, but an IXFR attempt will fail.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_ZONE_NO_SOA">
-<term>XFRIN_ZONE_NO_SOA Zone %1 does not have SOA</term>
-<listitem><para>
-On starting an xfrin session, it is identified that the zone to be
-transferred does not have an SOA RR in the data source. This is not
-necessarily an error; if a secondary DNS server first tries to perform
-transfer from a primary server, the zone can be empty, and therefore
-doesn't have an SOA. Subsequent AXFR will fill in the zone; if the
-attempt is IXFR it will fail in query creation.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_ZONE_SERIAL_AHEAD">
-<term>XFRIN_ZONE_SERIAL_AHEAD Serial number (%1) for %2 received from master %3 < ours (%4)</term>
-<listitem><para>
-The response to an SOA query prior to xfr indicated that the zone's
-SOA serial at the primary server is smaller than that of the xfrin
-client. This is not necessarily an error especially if that
-particular primary server is another secondary server which hasn't got
-the latest version of the zone. But if the primary server is known to
-be the real source of the zone, some unexpected inconsistency may have
-happened, and you may want to take a closer look. In this case xfrin
-doesn't perform subsequent zone transfer.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_BAD_TSIG_KEY_STRING">
-<term>XFROUT_BAD_TSIG_KEY_STRING bad TSIG key string: %1</term>
-<listitem><para>
-The TSIG key string as read from the configuration does not represent
-a valid TSIG key.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_CC_SESSION_ERROR">
-<term>XFROUT_CC_SESSION_ERROR error reading from cc channel: %1</term>
-<listitem><para>
-There was a problem reading from the command and control channel. The
-most likely cause is that the msgq daemon is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_CC_SESSION_TIMEOUT_ERROR">
-<term>XFROUT_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</term>
-<listitem><para>
-There was a problem reading a response from another module over the
-command and control channel. The most likely cause is that the
-configuration manager b10-cfgmgr is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_CONFIG_ERROR">
-<term>XFROUT_CONFIG_ERROR error found in configuration data: %1</term>
-<listitem><para>
-The xfrout process encountered an error when installing the configuration at
-startup time. Details of the error are included in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_FETCH_REQUEST_ERROR">
-<term>XFROUT_FETCH_REQUEST_ERROR socket error while fetching a request from the auth daemon</term>
-<listitem><para>
-There was a socket error while contacting the b10-auth daemon to
-fetch a transfer request. The auth daemon may have shutdown.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_HANDLE_QUERY_ERROR">
-<term>XFROUT_HANDLE_QUERY_ERROR error while handling query: %1</term>
-<listitem><para>
-There was a general error handling an xfrout query. The error is shown
-in the message. In principle this error should not appear, and points
-to an oversight catching exceptions in the right place. However, to
-ensure the daemon keeps running, this error is caught and reported.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IMPORT">
-<term>XFROUT_IMPORT error importing python module: %1</term>
-<listitem><para>
-There was an error importing a python module. One of the modules needed
-by xfrout could not be found. This suggests that either some libraries
-are missing on the system, or the PYTHONPATH variable is not correct.
-The specific place where this library needs to be depends on your
-system and your specific installation.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IXFR_MULTIPLE_SOA">
-<term>XFROUT_IXFR_MULTIPLE_SOA IXFR client %1: authority section has multiple SOAs</term>
-<listitem><para>
-An IXFR request was received with more than one SOA RRs in the authority
-section. The xfrout daemon rejects the request with an RCODE of
-FORMERR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IXFR_NO_JOURNAL_SUPPORT">
-<term>XFROUT_IXFR_NO_JOURNAL_SUPPORT IXFR client %1, %2: journaling not supported in the data source, falling back to AXFR</term>
-<listitem><para>
-An IXFR request was received but the underlying data source did
-not support journaling. The xfrout daemon fell back to AXFR-style
-IXFR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IXFR_NO_SOA">
-<term>XFROUT_IXFR_NO_SOA IXFR client %1: missing SOA</term>
-<listitem><para>
-An IXFR request was received with no SOA RR in the authority section.
-The xfrout daemon rejects the request with an RCODE of FORMERR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IXFR_NO_VERSION">
-<term>XFROUT_IXFR_NO_VERSION IXFR client %1, %2: version (%3 to %4) not in journal, falling back to AXFR</term>
-<listitem><para>
-An IXFR request was received, but the requested range of differences
-were not found in the data source. The xfrout daemon fell back to
-AXFR-style IXFR.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IXFR_NO_ZONE">
-<term>XFROUT_IXFR_NO_ZONE IXFR client %1, %2: zone not found with journal</term>
-<listitem><para>
-The requested zone in IXFR was not found in the data source
-even though the xfrout daemon sucessfully found the SOA RR of the zone
-in the data source. This can happen if the administrator removed the
-zone from the data source within the small duration between these
-operations, but it's more likely to be a bug or broken data source.
-Unless you know why this message was logged, and especially if it
-happens often, it's advisable to check whether the data source is
-valid for this zone. The xfrout daemon considers it a possible,
-though unlikely, event, and returns a response with an RCODE of
-NOTAUTH.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_IXFR_UPTODATE">
-<term>XFROUT_IXFR_UPTODATE IXFR client %1, %2: client version is new enough (theirs=%3, ours=%4)</term>
-<listitem><para>
-An IXFR request was received, but the client's SOA version is the same as
-or newer than that of the server. The xfrout server responds to the
-request with the answer section being just one SOA of that version.
-Note: as of this wrting the 'newer version' cannot be identified due to
-the lack of support for the serial number arithmetic. This will soon
-be implemented.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_MODULECC_SESSION_ERROR">
-<term>XFROUT_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</term>
-<listitem><para>
-There was a problem in the lower level module handling configuration and
-control commands. This could happen for various reasons, but the most likely
-cause is that the configuration database contains a syntax error and xfrout
-failed to start at initialization. A detailed error message from the module
-will also be displayed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_NEW_CONFIG">
-<term>XFROUT_NEW_CONFIG Update xfrout configuration</term>
-<listitem><para>
-New configuration settings have been sent from the configuration
-manager. The xfrout daemon will now apply them.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_NEW_CONFIG_DONE">
-<term>XFROUT_NEW_CONFIG_DONE Update xfrout configuration done</term>
-<listitem><para>
-The xfrout daemon is now done reading the new configuration settings
-received from the configuration manager.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_NOTIFY_COMMAND">
-<term>XFROUT_NOTIFY_COMMAND received command to send notifies for %1/%2</term>
-<listitem><para>
-The xfrout daemon received a command on the command channel that
-NOTIFY packets should be sent for the given zone.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_PARSE_QUERY_ERROR">
-<term>XFROUT_PARSE_QUERY_ERROR error parsing query: %1</term>
-<listitem><para>
-There was a parse error while reading an incoming query. The parse
-error is shown in the log message. A remote client sent a packet we
-do not understand or support. The xfrout request will be ignored.
-In general, this should only occur for unexpected problems like
-memory allocation failures, as the query should already have been
-parsed by the b10-auth daemon, before it was passed here.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_PROCESS_REQUEST_ERROR">
-<term>XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %2</term>
-<listitem><para>
-There was an error processing a transfer request. The error is included
-in the log message, but at this point no specific information other
-than that could be given. This points to incomplete exception handling
-in the code.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_QUERY_DROPPED">
-<term>XFROUT_QUERY_DROPPED %1 client %2: request to transfer %3 dropped</term>
-<listitem><para>
-The xfrout process silently dropped a request to transfer zone to
-given host. This is required by the ACLs. The %2 represents the IP
-address and port of the peer requesting the transfer, and the %3
-represents the zone name and class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_QUERY_QUOTA_EXCCEEDED">
-<term>XFROUT_QUERY_QUOTA_EXCCEEDED %1 client %2: request denied due to quota (%3)</term>
-<listitem><para>
-The xfr request was rejected because the server was already handling
-the maximum number of allowable transfers as specified in the transfers_out
-configuration parameter, which is also shown in the log message. The
-request was immediately responded and terminated with an RCODE of REFUSED.
-This can happen for a busy xfrout server, and you may want to increase
-this parameter; if the server is being too busy due to requests from
-unexpected clients you may want to restrict the legitimate clients
-with ACL.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_QUERY_REJECTED">
-<term>XFROUT_QUERY_REJECTED %1 client %2: request to transfer %3 rejected</term>
-<listitem><para>
-The xfrout process rejected (by REFUSED rcode) a request to transfer zone to
-given host. This is because of ACLs. The %2 represents the IP
-address and port of the peer requesting the transfer, and the %3
-represents the zone name and class.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_RECEIVED_SHUTDOWN_COMMAND">
-<term>XFROUT_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
-<listitem><para>
-The xfrout daemon received a shutdown command from the command channel
-and will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR">
-<term>XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR error receiving the file descriptor for an XFR connection</term>
-<listitem><para>
-There was an error receiving the file descriptor for the transfer
-request. Normally, the request is received by b10-auth, and passed on
-to the xfrout daemon, so it can answer directly. However, there was a
-problem receiving this file descriptor. The request will be ignored.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR">
-<term>XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR error removing unix socket file %1: %2</term>
-<listitem><para>
-The unix socket file xfrout needs for contact with the auth daemon
-already exists, and needs to be removed first, but there is a problem
-removing it. It is likely that we do not have permission to remove
-this file. The specific error is show in the log message. The xfrout
-daemon will shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_REMOVE_UNIX_SOCKET_FILE_ERROR">
-<term>XFROUT_REMOVE_UNIX_SOCKET_FILE_ERROR error clearing unix socket file %1: %2</term>
-<listitem><para>
-When shutting down, the xfrout daemon tried to clear the unix socket
-file used for communication with the auth daemon. It failed to remove
-the file. The reason for the failure is given in the error message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_SOCKET_SELECT_ERROR">
-<term>XFROUT_SOCKET_SELECT_ERROR error while calling select() on request socket: %1</term>
-<listitem><para>
-There was an error while calling select() on the socket that informs
-the xfrout daemon that a new xfrout request has arrived. This should
-be a result of rare local error such as memory allocation failure and
-shouldn't happen under normal conditions. The error is included in the
-log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_STOPPED_BY_KEYBOARD">
-<term>XFROUT_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
-<listitem><para>
-There was a keyboard interrupt signal to stop the xfrout daemon. The
-daemon will now shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_STOPPING">
-<term>XFROUT_STOPPING the xfrout daemon is shutting down</term>
-<listitem><para>
-The current transfer is aborted, as the xfrout daemon is shutting down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_UNIX_SOCKET_FILE_IN_USE">
-<term>XFROUT_UNIX_SOCKET_FILE_IN_USE another xfrout process seems to be using the unix socket file %1</term>
-<listitem><para>
-While starting up, the xfrout daemon tried to clear the unix domain
-socket needed for contacting the b10-auth daemon to pass requests
-on, but the file is in use. The most likely cause is that another
-xfrout daemon process is still running. This xfrout daemon (the one
-printing this message) will not start.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_XFR_TRANSFER_CHECK_ERROR">
-<term>XFROUT_XFR_TRANSFER_CHECK_ERROR %1 client %2: check for transfer of %3 failed: %4</term>
-<listitem><para>
-Pre-response check for an incomding XFR request failed unexpectedly.
-The most likely cause of this is that some low level error in the data
-source, but it may also be other general (more unlikely) errors such
-as memory shortage. Some detail of the error is also included in the
-message. The xfrout server tries to return a SERVFAIL response in this case.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_XFR_TRANSFER_DONE">
-<term>XFROUT_XFR_TRANSFER_DONE %1 client %2: transfer of %3 complete</term>
-<listitem><para>
-The transfer of the given zone has been completed successfully, or was
-aborted due to a shutdown event.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_XFR_TRANSFER_ERROR">
-<term>XFROUT_XFR_TRANSFER_ERROR %1 client %2: error transferring zone %3: %4</term>
-<listitem><para>
-An uncaught exception was encountered while sending the response to
-an AXFR query. The error message of the exception is included in the
-log message, but this error most likely points to incomplete exception
-handling in the code.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_XFR_TRANSFER_FAILED">
-<term>XFROUT_XFR_TRANSFER_FAILED %1 client %2: transfer of %3 failed, rcode: %4</term>
-<listitem><para>
-A transfer out for the given zone failed. An error response is sent
-to the client. The given rcode is the rcode that is set in the error
-response. This is either NOTAUTH (we are not authoritative for the
-zone), SERVFAIL (our internal database is missing the SOA record for
-the zone), or REFUSED (the limit of simultaneous outgoing AXFR
-transfers, as specified by the configuration value
-Xfrout/max_transfers_out, has been reached).
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFROUT_XFR_TRANSFER_STARTED">
-<term>XFROUT_XFR_TRANSFER_STARTED %1 client %2: transfer of zone %3 has started</term>
-<listitem><para>
-A transfer out of the given zone has started.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_CCSESSION_ERROR">
-<term>ZONEMGR_CCSESSION_ERROR command channel session error: %1</term>
-<listitem><para>
-An error was encountered on the command channel. The message indicates
-the nature of the error.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_JITTER_TOO_BIG">
-<term>ZONEMGR_JITTER_TOO_BIG refresh_jitter is too big, setting to 0.5</term>
-<listitem><para>
-The value specified in the configuration for the refresh jitter is too large
-so its value has been set to the maximum of 0.5.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_KEYBOARD_INTERRUPT">
-<term>ZONEMGR_KEYBOARD_INTERRUPT exiting zonemgr process as result of keyboard interrupt</term>
-<listitem><para>
-An informational message output when the zone manager was being run at a
-terminal and it was terminated via a keyboard interrupt signal.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_LOAD_ZONE">
-<term>ZONEMGR_LOAD_ZONE loading zone %1 (class %2)</term>
-<listitem><para>
-This is a debug message indicating that the zone of the specified class
-is being loaded.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_NO_MASTER_ADDRESS">
-<term>ZONEMGR_NO_MASTER_ADDRESS internal BIND 10 command did not contain address of master</term>
-<listitem><para>
-A command received by the zone manager from the Auth module did not
-contain the address of the master server from which a NOTIFY message
-was received. This may be due to an internal programming error; please
-submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_NO_SOA">
-<term>ZONEMGR_NO_SOA zone %1 (class %2) does not have an SOA record</term>
-<listitem><para>
-When loading the named zone of the specified class the zone manager
-discovered that the data did not contain an SOA record. The load has
-been abandoned.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_NO_TIMER_THREAD">
-<term>ZONEMGR_NO_TIMER_THREAD trying to stop zone timer thread but it is not running</term>
-<listitem><para>
-An attempt was made to stop the timer thread (used to track when zones
-should be refreshed) but it was not running. This may indicate an
-internal program error. Please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_NO_ZONE_CLASS">
-<term>ZONEMGR_NO_ZONE_CLASS internal BIND 10 command did not contain class of zone</term>
-<listitem><para>
-A command received by the zone manager from another BIND 10 module did
-not contain the class of the zone on which the zone manager should act.
-This may be due to an internal programming error; please submit a
-bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_NO_ZONE_NAME">
-<term>ZONEMGR_NO_ZONE_NAME internal BIND 10 command did not contain name of zone</term>
-<listitem><para>
-A command received by the zone manager from another BIND 10 module did
-not contain the name of the zone on which the zone manager should act.
-This may be due to an internal programming error; please submit a
-bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_RECEIVE_NOTIFY">
-<term>ZONEMGR_RECEIVE_NOTIFY received NOTIFY command for zone %1 (class %2)</term>
-<listitem><para>
-This is a debug message indicating that the zone manager has received a
-NOTIFY command over the command channel. The command is sent by the Auth
-process when it is acting as a slave server for the zone and causes the
-zone manager to record the master server for the zone and start a timer;
-when the timer expires, the master will be polled to see if it contains
-new data.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_RECEIVE_SHUTDOWN">
-<term>ZONEMGR_RECEIVE_SHUTDOWN received SHUTDOWN command</term>
-<listitem><para>
-This is a debug message indicating that the zone manager has received
-a SHUTDOWN command over the command channel from the Boss process.
-It will act on this command and shut down.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_RECEIVE_UNKNOWN">
-<term>ZONEMGR_RECEIVE_UNKNOWN received unknown command '%1'</term>
-<listitem><para>
-This is a warning message indicating that the zone manager has received
-the stated command over the command channel. The command is not known
-to the zone manager and although the command is ignored, its receipt
-may indicate an internal error. Please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_RECEIVE_XFRIN_FAILED">
-<term>ZONEMGR_RECEIVE_XFRIN_FAILED received XFRIN FAILED command for zone %1 (class %2)</term>
-<listitem><para>
-This is a debug message indicating that the zone manager has received
-an XFRIN FAILED command over the command channel. The command is sent
-by the Xfrin process when a transfer of zone data into the system has
-failed, and causes the zone manager to schedule another transfer attempt.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_RECEIVE_XFRIN_SUCCESS">
-<term>ZONEMGR_RECEIVE_XFRIN_SUCCESS received XFRIN SUCCESS command for zone %1 (class %2)</term>
-<listitem><para>
-This is a debug message indicating that the zone manager has received
-an XFRIN SUCCESS command over the command channel. The command is sent
-by the Xfrin process when the transfer of zone data into the system has
-succeeded, and causes the data to be loaded and served by BIND 10.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_REFRESH_ZONE">
-<term>ZONEMGR_REFRESH_ZONE refreshing zone %1 (class %2)</term>
-<listitem><para>
-The zone manager is refreshing the named zone of the specified class
-with updated information.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_SELECT_ERROR">
-<term>ZONEMGR_SELECT_ERROR error with select(): %1</term>
-<listitem><para>
-An attempt to wait for input from a socket failed. The failing operation
-is a call to the operating system's select() function, which failed for
-the given reason.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_SEND_FAIL">
-<term>ZONEMGR_SEND_FAIL failed to send command to %1, session has been closed</term>
-<listitem><para>
-The zone manager attempted to send a command to the named BIND 10 module,
-but the send failed. The session between the modules has been closed.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_SESSION_ERROR">
-<term>ZONEMGR_SESSION_ERROR unable to establish session to command channel daemon</term>
-<listitem><para>
-The zonemgr process was not able to be started because it could not
-connect to the command channel daemon. The most usual cause of this
-problem is that the daemon is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_SESSION_TIMEOUT">
-<term>ZONEMGR_SESSION_TIMEOUT timeout on session to command channel daemon</term>
-<listitem><para>
-The zonemgr process was not able to be started because it timed out when
-connecting to the command channel daemon. The most usual cause of this
-problem is that the daemon is not running.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_SHUTDOWN">
-<term>ZONEMGR_SHUTDOWN zone manager has shut down</term>
-<listitem><para>
-A debug message, output when the zone manager has shut down completely.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_STARTING">
-<term>ZONEMGR_STARTING zone manager starting</term>
-<listitem><para>
-A debug message output when the zone manager starts up.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_TIMER_THREAD_RUNNING">
-<term>ZONEMGR_TIMER_THREAD_RUNNING trying to start timer thread but one is already running</term>
-<listitem><para>
-This message is issued when an attempt is made to start the timer
-thread (which keeps track of when zones need a refresh) but one is
-already running. It indicates either an error in the program logic or
-a problem with stopping a previous instance of the timer. Please submit
-a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_UNKNOWN_ZONE_FAIL">
-<term>ZONEMGR_UNKNOWN_ZONE_FAIL zone %1 (class %2) is not known to the zone manager</term>
-<listitem><para>
-An XFRIN operation has failed but the zone that was the subject of the
-operation is not being managed by the zone manager. This may indicate
-an error in the program (as the operation should not have been initiated
-if this were the case). Please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_UNKNOWN_ZONE_NOTIFIED">
-<term>ZONEMGR_UNKNOWN_ZONE_NOTIFIED notified zone %1 (class %2) is not known to the zone manager</term>
-<listitem><para>
-A NOTIFY was received but the zone that was the subject of the operation
-is not being managed by the zone manager. This may indicate an error
-in the program (as the operation should not have been initiated if this
-were the case). Please submit a bug report.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="ZONEMGR_UNKNOWN_ZONE_SUCCESS">
-<term>ZONEMGR_UNKNOWN_ZONE_SUCCESS zone %1 (class %2) is not known to the zone manager</term>
-<listitem><para>
-An XFRIN operation has succeeded but the zone received is not being
-managed by the zone manager. This may indicate an error in the program
-(as the operation should not have been initiated if this were the case).
-Please submit a bug report.
-</para></listitem>
-</varlistentry>
- </variablelist>
- </para>
- </chapter>
-</book>
diff --git a/src/bin/auth/b10-auth.8 b/src/bin/auth/b10-auth.8
deleted file mode 100644
index 56b1732..0000000
--- a/src/bin/auth/b10-auth.8
+++ /dev/null
@@ -1,202 +0,0 @@
-'\" t
-.\" Title: b10-auth
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: December 28, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-AUTH" "8" "December 28, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-auth \- Authoritative DNS server
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-auth\fR\ 'u
-\fBb10\-auth\fR [\fB\-n\fR] [\fB\-v\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-auth\fR
-daemon provides the BIND 10 authoritative DNS server\&. Normally it is started by the
-\fBbind10\fR(8)
-boss process\&.
-.PP
-This daemon communicates with other BIND 10 components over a
-\fBb10-msgq\fR(8)
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-auth\fR
-will exit\&.
-It receives its configurations from
-\fBb10-cfgmgr\fR(8)\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-n\fR
-.RS 4
-Do not cache answers in memory\&. The default is to use the cache for faster responses\&. The cache keeps the most recent 30,000 answers (positive and negative) in memory for 30 seconds (instead of querying the data source, such as SQLite3 database, each time)\&.
-.RE
-.PP
-\fB\-v\fR
-.RS 4
-Enabled verbose mode\&. This enables diagnostic messages to STDERR\&.
-.RE
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable settings are:
-.PP
-
-\fIdatabase_file\fR
-defines the path to the SQLite3 zone file when using the sqlite datasource\&. The default is
-/usr/local/var/bind10\-devel/zone\&.sqlite3\&.
-.PP
-
-\fIdatasources\fR
-configures data sources\&. The list items include:
-\fItype\fR
-to optionally choose the data source type (such as
-\(lqmemory\(rq);
-\fIclass\fR
-to optionally select the class (it defaults to
-\(lqIN\(rq); and
-\fIzones\fR
-to define the
-\fIfile\fR
-path name and the
-\fIorigin\fR
-(default domain)\&. By default, this is empty\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.sp
-In this development version, 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 \fBnamed\-compilezone \-D\fR\&.
-.sp .5v
-.RE
-.PP
-
-\fIlisten_on\fR
-is a list of addresses and ports for
-\fBb10\-auth\fR
-to listen on\&. The list items are the
-\fIaddress\fR
-string and
-\fIport\fR
-number\&. By default,
-\fBb10\-auth\fR
-listens on port 53 on the IPv6 (::) and IPv4 (0\&.0\&.0\&.0) wildcard addresses\&.
-.PP
-
-\fIstatistics\-interval\fR
-is the timer interval in seconds for
-\fBb10\-auth\fR
-to share its statistics information to
-\fBb10-stats\fR(8)\&. Statistics updates can be disabled by setting this to 0\&. The default is 60\&.
-.PP
-The configuration commands are:
-.PP
-
-\fBloadzone\fR
-tells
-\fBb10\-auth\fR
-to load or reload a zone file\&. The arguments include:
-\fIclass\fR
-which optionally defines the class (it defaults to
-\(lqIN\(rq);
-\fIorigin\fR
-is the domain name of the zone; and
-\fIdatasrc\fR
-optionally defines the type of datasource (it defaults to
-\(lqmemory\(rq)\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.sp
-In this development version, currently this only supports the IN class and the memory data source\&.
-.sp .5v
-.RE
-.PP
-
-\fBsendstats\fR
-tells
-\fBb10\-auth\fR
-to send its statistics data to
-\fBb10-stats\fR(8)
-immediately\&.
-.PP
-
-\fBshutdown\fR
-exits
-\fBb10\-auth\fR\&. (Note that the BIND 10 boss process will restart this service\&.)
-.SH "STATISTICS DATA"
-.PP
-The statistics data collected by the
-\fBb10\-stats\fR
-daemon include:
-.PP
-auth\&.queries\&.tcp
-.RS 4
-Total count of queries received by the
-\fBb10\-auth\fR
-server over TCP since startup\&.
-.RE
-.PP
-auth\&.queries\&.udp
-.RS 4
-Total count of queries received by the
-\fBb10\-auth\fR
-server over UDP since startup\&.
-.RE
-.SH "FILES"
-.PP
-
-/usr/local/var/bind10\-devel/zone\&.sqlite3
-\(em Location for the SQLite3 zone database when
-\fIdatabase_file\fR
-configuration is not defined\&.
-.SH "SEE ALSO"
-.PP
-
-\fBb10-cfgmgr\fR(8),
-\fBb10-loadzone\fR(8),
-\fBb10-msgq\fR(8),
-\fBb10-stats\fR(8),
-\fBb10-zonemgr\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-auth\fR
-daemon was first coded in October 2009\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/bind10/bind10.8 b/src/bin/bind10/bind10.8
deleted file mode 100644
index c2e44e7..0000000
--- a/src/bin/bind10/bind10.8
+++ /dev/null
@@ -1,343 +0,0 @@
-'\" t
-.\" Title: bind10
-.\" Author: [see the "AUTHORS" section]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: November 23, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "BIND10" "8" "November 23, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-bind10 \- BIND 10 boss process
-.SH "SYNOPSIS"
-.HP \w'\fBbind10\fR\ 'u
-\fBbind10\fR [\fB\-c\ \fR\fB\fIconfig\-filename\fR\fR] [\fB\-m\ \fR\fB\fIfile\fR\fR] [\fB\-n\fR] [\fB\-p\ \fR\fB\fIdata_path\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-w\ \fR\fB\fIwait_time\fR\fR] [\fB\-\-cmdctl\-port\fR\ \fIport\fR] [\fB\-\-config\-file\fR\ \fIconfig\-filename\fR] [\fB\-\-data\-path\fR\ \fIdirectory\fR] [\fB\-\-msgq\-socket\-file\ \fR\fB\fIfile\fR\fR] [\fB\-\-no\-cache\fR] [\fB\-\-pid\-file\fR\ \fIfilename\fR] [\fB\-\-pretty\-name\ \fR\fB\fIname\fR\fR] [\fB\-\-user\ \fR\fB\fIuser\fR\fR] [\fB\-\-verbose\fR] [\fB\-\-wait\ \fR\fB\fIwait_time\fR\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBbind10\fR
-daemon starts up other BIND 10 required daemons\&. It handles restarting of exiting programs and also the shutdown of all managed daemons\&.
-.SH "ARGUMENTS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-c\fR \fIconfig\-filename\fR, \fB\-\-config\-file\fR \fIconfig\-filename\fR
-.RS 4
-The configuration filename to use\&. Can be either absolute or relative to data path\&. In case it is absolute, value of data path is not considered\&.
-.sp
-Defaults to b10\-config\&.db\&.
-.RE
-.PP
-\fB\-\-cmdctl\-port\fR \fIport\fR
-.RS 4
-The
-\fBb10\-cmdctl\fR
-daemon will listen on this port\&. (See
-b10\-cmdctl(8)
-for the default\&.)
-.RE
-.PP
-\fB\-p\fR \fIdirectory\fR, \fB\-\-data\-path\fR \fIdirectory\fR
-.RS 4
-The path where BIND 10 programs look for various data files\&. Currently only b10\-cfgmgr uses it to locate the configuration file, but the usage might be extended for other programs and other types of files\&.
-.RE
-.PP
-\fB\-m\fR \fIfile\fR, \fB\-\-msgq\-socket\-file\fR \fIfile\fR
-.RS 4
-The UNIX domain socket file for the
-\fBb10-msgq\fR(8)
-daemon to use\&. The default is
-/usr/local/var/bind10\-devel/msg_socket\&.
-.RE
-.PP
-\fB\-n\fR, \fB\-\-no\-cache\fR
-.RS 4
-Disables the hot\-spot caching used by the
-\fBb10-auth\fR(8)
-daemon\&.
-.RE
-.PP
-\fB\-u\fR \fIuser\fR, \fB\-\-user\fR \fIname\fR
-.RS 4
-The username for
-\fBbind10\fR
-to run as\&.
-
-\fBbind10\fR
-must be initially ran as the root user to use this option\&. The default is to run as the current user\&.
-.RE
-.PP
-\fB\-\-pid\-file\fR \fIfilename\fR
-.RS 4
-If defined, the PID of the
-\fBbind10\fR
-is stored in this file\&. This is used for testing purposes\&.
-.RE
-.PP
-\fB\-\-pretty\-name \fR\fB\fIname\fR\fR
-.RS 4
-The name this process should have in tools like
-\fBps\fR
-or
-\fBtop\fR\&. This is handy if you have multiple versions/installations of
-\fBbind10\fR\&.
-.RE
-.PP
-\fB\-v\fR, \fB\-\-verbose\fR
-.RS 4
-Display more about what is going on for
-\fBbind10\fR
-and its child processes\&.
-.RE
-.PP
-\fB\-w\fR \fIwait_time\fR, \fB\-\-wait\fR \fIwait_time\fR
-.RS 4
-Sets the amount of time that BIND 10 will wait for the configuration manager (a key component of BIND 10) to initialize itself before abandoning the start up and terminating with an error\&. The wait_time is specified in seconds and has a default value of 10\&.
-.RE
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configuration provides settings for components for
-\fBbind10\fR
-to manage under
-\fI/Boss/components/\fR\&. The default elements are:
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-auth\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-cmdctl\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/setuid\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-stats\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-stats\-httpd\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-xfrin\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-xfrout\fR
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fI/Boss/components/b10\-zonemgr\fR
-.RE
-.PP
-(Note that the startup of
-\fBb10\-sockcreator\fR,
-\fBb10\-cfgmgr\fR, and
-\fBb10\-msgq\fR
-is not configurable\&. It is hardcoded and
-\fBbind10\fR
-will not run without them\&.)
-.PP
-These named sets (listed above) contain the following settings:
-.PP
-\fIaddress\fR
-.RS 4
-The name used for communicating to it on the message bus\&.
-.RE
-.PP
-\fIkind\fR
-.RS 4
-This defines how required a component is\&. The possible settings for
-\fIkind\fR
-are:
-\fIcore\fR
-(system won\'t start if it won\'t start and
-\fBbind10\fR
-will shutdown if a
-\(lqcore\(rq
-component crashes),
-\fIdispensable\fR
-(\fBbind10\fR
-will restart failing component), and
-\fIneeded\fR
-(\fBbind10\fR
-will shutdown if component won\'t initially start, but if crashes later, it will attempt to restart)\&. This setting is required\&.
-.RE
-.PP
-\fIpriority\fR
-.RS 4
-This is an integer\&.
-\fBbind10\fR
-will start the components with largest priority numbers first\&.
-.RE
-.PP
-\fIprocess\fR
-.RS 4
-This is the filename of the executable to be started\&. If not defined, then
-\fBbind10\fR
-will use the component name instead\&.
-.RE
-.PP
-\fIspecial\fR
-.RS 4
-This defines if the component is started a special way\&.
-.RE
-.PP
-The
-\fIBoss\fR
-configuration commands are:
-.PP
-
-\fBgetstats\fR
-tells
-\fBbind10\fR
-to send its statistics data to the
-\fBb10\-stats\fR
-daemon\&. This is an internal command and not exposed to the administrator\&.
-
-.PP
-
-\fBping\fR
-is used to check the connection with the
-\fBbind10\fR
-daemon\&. It returns the text
-\(lqpong\(rq\&.
-.PP
-
-\fBsendstats\fR
-tells
-\fBbind10\fR
-to send its statistics data to the
-\fBb10\-stats\fR
-daemon immediately\&.
-.PP
-
-\fBshow_processes\fR
-lists the current processes managed by
-\fBbind10\fR\&. The output is an array in JSON format containing the process ID and the name for each\&.
-
-
-.PP
-
-\fBshutdown\fR
-tells
-\fBbind10\fR
-to shutdown the BIND 10 servers\&. It will tell each process it manages to shutdown and, when complete,
-\fBbind10\fR
-will exit\&.
-.SH "STATISTICS DATA"
-.PP
-The statistics data collected by the
-\fBb10\-stats\fR
-daemon include:
-.PP
-bind10\&.boot_time
-.RS 4
-The date and time that the
-\fBbind10\fR
-process started\&. This is represented in ISO 8601 format\&.
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBbindctl\fR(1),
-\fBb10-auth\fR(8),
-\fBb10-cfgmgr\fR(8),
-\fBb10-cmdctl\fR(8),
-\fBb10-msgq\fR(8),
-\fBb10-xfrin\fR(8),
-\fBb10-xfrout\fR(8),
-\fBb10-zonemgr\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The development of
-\fBbind10\fR
-was started in October 2009\&.
-.SH "AUTHORS"
-.PP
-The
-\fBbind10\fR
-daemon was initially designed by Shane Kerr of ISC\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/bindctl/bindctl.1 b/src/bin/bindctl/bindctl.1
deleted file mode 100644
index 97700d6..0000000
--- a/src/bin/bindctl/bindctl.1
+++ /dev/null
@@ -1,149 +0,0 @@
-'\" t
-.\" Title: bindctl
-.\" Author: [see the "AUTHORS" section]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: December 23, 2010
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "BINDCTL" "1" "December 23, 2010" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-bindctl \- control and configure BIND 10
-.SH "SYNOPSIS"
-.HP \w'\fBbindctl\fR\ 'u
-\fBbindctl\fR [\fB\-a\ \fR\fB\fIaddress\fR\fR] [\fB\-h\fR] [\fB\-c\ \fR\fB\fIfile\fR\fR] [\fB\-p\ \fR\fB\fInumber\fR\fR] [\fB\-\-address\ \fR\fB\fIaddress\fR\fR] [\fB\-\-help\fR] [\fB\-\-certificate\-chain\ \fR\fB\fIfile\fR\fR] [\fB\-\-csv\-file\-dir\fR\fB\fIfile\fR\fR] [\fB\-\-port\ \fR\fB\fInumber\fR\fR] [\fB\-\-version\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBbindctl\fR
-tool is a user interface to the BIND 10 services\&. The program can be used to control the components and configure the BIND 10 options\&. The options may be specified
-via its interactive command interpreter\&.
-.PP
-
-\fBbindctl\fR
-communicates over a HTTPS REST\-ful interface provided by
-\fBb10-cmdctl\fR(8)\&. The
-\fBb10-cfgmgr\fR(8)
-daemon stores the configurations and defines the commands\&.
-.SH "ARGUMENTS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-a\fR \fIaddress\fR, \fB\-\-address\fR \fIaddress\fR
-.RS 4
-The IPv4 or IPv6 address to use to connect to the running
-\fBb10-cmdctl\fR(8)
-daemon\&. The default is 127\&.0\&.0\&.1\&.
-.RE
-.PP
-\fB\-c\fR \fIfile\fR, \fB\-\-certificate\-chain\fR \fIfile\fR
-.RS 4
-The PEM formatted server certificate validation chain file\&.
-.RE
-.PP
-\fB\-\-csv\-file\-dir\fR\fIfile\fR
-.RS 4
-The directory name in which the user/password CSV file is stored (see AUTHENTICATION)\&. By default this option doesn\'t have any value, in which case the "\&.bind10" directory under the user\'s home directory will be used\&.
-.RE
-.PP
-\fB\-h\fR, \fB\-\-help\fR
-.RS 4
-Display command usage\&.
-.RE
-.PP
-\fB\-p\fR \fInumber\fR, \fB\-\-port\fR \fInumber\fR
-.RS 4
-The port number to use to connect to the running
-\fBb10-cmdctl\fR(8)
-daemon\&. The default is 8080\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-This default port number may change\&.
-.sp .5v
-.RE
-.RE
-.PP
-\fB\-\-version\fR
-.RS 4
-Display the version number and exit\&.
-.RE
-.SH "AUTHENTICATION"
-.PP
-The tool will authenticate using a username and password\&. On the first successful login, it will save the details to a comma\-separated\-value (CSV) file which will be used for later uses of
-\fBbindctl\fR\&. The file name is
-default_user\&.csv
-located under the directory specified by the \-\-csv\-file\-dir option\&.
-.SH "USAGE"
-.PP
-The
-\fBbindctl\fR
-prompt shows
-\(lq> \(rq\&. The prompt will also display the location if changed\&. The options are based on the module in use\&. The usage is:
-\fBmodule\fR
-\fBcommand\fR
-\fIparam1 = value1 , \fR\fI\fIparam2 = value2\fR\fR
-.PP
-
-\fBbindctl\fR\'s interactive interface provides command\-line completion and hints\&. Press the Tab key to get a hint for the module, command, and/or parameters\&.
-The arrow keys and Emacs\-style editing keys may be used to edit and recall previous lines\&.
-.PP
-You can use the
-\fBhelp\fR
-keyword to receive usage assistance for a module or a module\'s command\&.
-.PP
-The
-\fBquit\fR
-command is used to exit
-\fBbindctl\fR
-(and doesn\'t stop the BIND 10 services)\&.
-.PP
-The following module is available by default:
-\fBconfig\fR
-for Configuration commands\&.
-Additional modules may be available, such as
-\fBBoss\fR,
-\fBXfrin\fR, and
-\fBAuth\fR\&.
-.SH "SEE ALSO"
-.PP
-
-\fBb10-auth\fR(8),
-\fBb10-cfgmgr\fR(8),
-\fBb10-cmdctl\fR(8),
-\fBb10-xfrin\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "AUTHORS"
-.PP
-The
-\fBbindctl\fR
-tool and library were initially coded by Zhang Likun of CNNIC for the BIND 10 project\&. The initial manual page was written by Jeremy C\&. Reed of ISC\&.
-.SH "HISTORY"
-.PP
-The initial version (with internal name of
-\fBBigTool\fR) was started in October 2009\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/cfgmgr/b10-cfgmgr.8 b/src/bin/cfgmgr/b10-cfgmgr.8
deleted file mode 100644
index 719f4c6..0000000
--- a/src/bin/cfgmgr/b10-cfgmgr.8
+++ /dev/null
@@ -1,81 +0,0 @@
-'\" t
-.\" Title: b10-cfgmgr
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: March 10, 2010
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-CFGMGR" "8" "March 10, 2010" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-cfgmgr \- Configuration manager
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-cfgmgr\fR\ 'u
-\fBb10\-cfgmgr\fR [\fB\-c\fR\fB\fIconfig\-filename\fR\fR] [\fB\-p\fR\fB\fIdata_path\fR\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-cfgmgr\fR
-daemon handles all BIND 10 system configuration\&. It provides persistent storage for configuration, and notifies running BIND 10 modules of configuration changes\&.
-.PP
-The
-\fBbindctl\fR
-can be used to talk to this configuration manager via a
-\fBb10\-cmdctl\fR
-connection\&.
-.PP
-This daemon communicates over a
-\fBb10\-msgq\fR
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-cfgmgr\fR
-will exit\&.
-.PP
-The daemon may be cleanly stopped by sending the SIGTERM signal to the process\&. This shutdown does not notify the subscribers\&.
-.PP
-When it exits, it saves its current configuration to
-/usr/local/var/bind10\-devel/b10\-config\&.db\&.
-
-.SH "ARGUMENTS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-c\fR\fIconfig\-filename\fR, \fB\-\-config\-filename\fR \fIconfig\-filename\fR
-.RS 4
-The configuration database filename to use\&. Can be either absolute or relative to data path\&.
-.sp
-Defaults to b10\-config\&.db
-.RE
-.PP
-\fB\-p\fR\fIdata\-path\fR, \fB\-\-data\-path\fR \fIdata\-path\fR
-.RS 4
-The path where BIND 10 looks for files\&. The configuration file is looked for here, if it is relative\&. If it is absolute, the path is ignored\&.
-.RE
-.SH "FILES"
-.PP
-/usr/local/var/bind10\-devel/b10\-config\&.db
-\(em Configuration storage file\&.
-.SH "SEE ALSO"
-.PP
-
-\fBbind10\fR(8),
-\fBmsgq\fR(8)\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-cfgmgr\fR
-daemon and configuration specification were initially designed by Jelte Jansen of ISC\&. Its development began in October 2009\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/cmdctl/b10-cmdctl.8 b/src/bin/cmdctl/b10-cmdctl.8
deleted file mode 100644
index c8c938b..0000000
--- a/src/bin/cmdctl/b10-cmdctl.8
+++ /dev/null
@@ -1,97 +0,0 @@
-'\" t
-.\" Title: b10-cmdctl
-.\" Author: [see the "AUTHORS" section]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: March 9, 2010
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-CMDCTL" "8" "March 9, 2010" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-cmdctl \- BIND 10 remote control daemon
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-cmdctl\fR\ 'u
-\fBb10\-cmdctl\fR [\fB\-a\ \fR\fB\fIstring\fR\fR] [\fB\-h\fR] [\fB\-i\ \fR\fB\fInumber\fR\fR] [\fB\-p\ \fR\fB\fInumber\fR\fR] [\fB\-v\fR] [\fB\-\-address\ \fR\fB\fIstring\fR\fR] [\fB\-\-help\fR] [\fB\-\-idle\-timeout\ \fR\fB\fInumber\fR\fR] [\fB\-\-port\ \fR\fB\fInumber\fR\fR] [\fB\-\-verbose\fR] [\fB\-\-version\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-cmdctl\fR
-daemon provides an entry for commands sent to the BIND 10 services\&. For example, the
-\fBbindctl\fR
-user interface communicates via
-\fBb10\-cmdctl\fR\&.
-.PP
-It is a lightweight HTTPS server with HTTP Digest Authentication (username and password validation)\&. It offers a RESTful style interface\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-a \fR\fB\fIstring\fR\fR, \fB\-\-address \fR\fB\fIstring\fR\fR
-.RS 4
-The IP address that
-\fBb10\-cmdctl\fR
-will listen on\&. The default is 127\&.0\&.0\&.1\&.
-.RE
-.PP
-\fB\-h\fR, \fB\-\-help\fR
-.RS 4
-Display command usage\&.
-.RE
-.PP
-\fB\-i \fR\fB\fInumber\fR\fR, \fB\-\-idle\-timeout \fR\fB\fInumber\fR\fR
-.RS 4
-The socket idle timeout for the HTTPS connection in seconds\&. The default is 1200 seconds\&.
-.RE
-.PP
-\fB\-p \fR\fB\fInumber\fR\fR, \fB\-\-port \fR\fB\fInumber\fR\fR
-.RS 4
-The port number
-\fBb10\-cmdctl\fR
-will listen on\&. The default is 8080\&.
-.RE
-.PP
-\fB\-v\fR, \fB\-\-verbose\fR
-.RS 4
-Enable verbose mode\&.
-.RE
-.PP
-\fB\-\-version\fR
-.RS 4
-Display the version number and exit\&.
-.RE
-.SH "FILES"
-.PP
-/usr/local/etc/bind10\-devel/cmdctl\-accounts\&.csv
-\(em account database containing the name, hashed password, and the salt\&.
-.PP
-/usr/local/etc/bind10\-devel/cmdctl\-keyfile\&.pem
-\(em contains the Private key\&.
-.PP
-/usr/local/etc/bind10\-devel/cmdctl\-certfile\&.pem
-\(em contains the Certificate\&.
-.SH "SEE ALSO"
-.PP
-
-\fBb10-cfgmgr\fR(8),
-\fBbind10\fR(8),
-\fBbindctl\fR(1)\&.
-.SH "AUTHORS"
-.PP
-The
-\fBb10\-cmdctl\fR
-daemon was initially designed and coded by Zhang Likun of CNNIC\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/ddns/b10-ddns.8 b/src/bin/ddns/b10-ddns.8
deleted file mode 100644
index 67a5059..0000000
--- a/src/bin/ddns/b10-ddns.8
+++ /dev/null
@@ -1,102 +0,0 @@
-'\" t
-.\" Title: b10-ddns
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: December 9, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-DDNS" "8" "December 9, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-ddns \- Dynamic DNS update service
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-ddns\fR\ 'u
-\fBb10\-ddns\fR [\fB\-v\fR | \fB\-\-verbose\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-ddns\fR
-daemon provides the BIND 10 Dynamic Update (DDNS) service, as specified in RFC 2136\&. Normally it is started by the
-\fBbind10\fR(8)
-boss process\&. When the
-\fBb10\-auth\fR
-DNS server receives a DDNS update,
-\fBb10\-ddns\fR
-updates the zone in the BIND 10 zone data store\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.PP
-Currently installed is a dummy component\&. It does not provide any functionality\&. It is a skeleton implementation that will be expanded later\&.
-.sp .5v
-.RE
-.PP
-This daemon communicates with BIND 10 over a
-\fBb10-msgq\fR(8)
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-ddns\fR
-will exit\&.
-.PP
-
-\fBb10\-ddns\fR
-receives its configurations from
-\fBb10-cfgmgr\fR(8)\&.
-.SH "ARGUMENTS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-v\fR, \fB\-\-verbose\fR
-.RS 4
-This value is ignored at this moment, but is provided for compatibility with the bind10 Boss process
-.RE
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable settings are:
-.PP
-
-\fIzones\fR
-The zones option is a named set of zones that can be updated with DDNS\&. Each entry has one element called update_acl, which is a list of access control rules that define update permissions\&. By default this is empty; DDNS must be explicitely enabled per zone\&.
-.PP
-The module commands are:
-.PP
-
-\fBshutdown\fR
-Exits
-\fBb10\-ddns\fR\&. (Note that the BIND 10 boss process will restart this service\&.)
-.SH "SEE ALSO"
-.PP
-
-\fBb10-auth\fR(8),
-\fBb10-cfgmgr\fR(8),
-\fBb10-msgq\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-ddns\fR
-daemon was first implemented in December 2011 for the ISC BIND 10 project\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/dhcp4/b10-dhcp4.8 b/src/bin/dhcp4/b10-dhcp4.8
deleted file mode 100644
index 97bdeb8..0000000
--- a/src/bin/dhcp4/b10-dhcp4.8
+++ /dev/null
@@ -1,60 +0,0 @@
-'\" t
-.\" Title: b10-dhcp4
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: October 27, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-DHCP4" "8" "October 27, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * Define some portability stuff
-.\" -----------------------------------------------------------------
-.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.\" http://bugs.debian.org/507673
-.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
-.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-dhcp4 \- DHCPv4 server in BIND 10 architecture
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-dhcp4\fR\ 'u
-\fBb10\-dhcp4\fR [\fB\-v\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-dhcp4\fR
-daemon will provide the DHCPv4 server implementation when it becomes functional\&.
-.SH "ARGUMENTS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-v\fR
-.RS 4
-Enable verbose mode\&.
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBbind10\fR(8)\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-dhcp4\fR
-daemon was first coded in November 2011 by Tomek Mrugalski\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/dhcp6/b10-dhcp6.8 b/src/bin/dhcp6/b10-dhcp6.8
deleted file mode 100644
index 1f34a9a..0000000
--- a/src/bin/dhcp6/b10-dhcp6.8
+++ /dev/null
@@ -1,51 +0,0 @@
-'\" t
-.\" Title: b10-dhcp6
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: October 27, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-DHCP6" "8" "October 27, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-dhcp6 \- DHCPv6 server in BIND 10 architecture
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-dhcp6\fR\ 'u
-\fBb10\-dhcp6\fR [\fB\-v\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-dhcp6\fR
-daemon will provide the DHCPv6 server implementation when it becomes functional\&.
-.SH "ARGUMENTS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-v\fR
-.RS 4
-Enable verbose mode\&.
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBbind10\fR(8)\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-dhcp6\fR
-daemon was first coded in June 2011 by Tomek Mrugalski\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/host/b10-host.1 b/src/bin/host/b10-host.1
deleted file mode 100644
index 050f6a3..0000000
--- a/src/bin/host/b10-host.1
+++ /dev/null
@@ -1,118 +0,0 @@
-'\" t
-.\" Title: b10-host
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: May 4, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-HOST" "1" "May 4, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-host \- DNS lookup utility
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-host\fR\ 'u
-\fBb10\-host\fR [\fB\-a\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-d\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-r\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-v\fR] [\fIname\fR] [\fB\fIserver\fR\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-host\fR
-utility does DNS lookups\&. Its initial goal is to be a
-\fBhost\fR(1)
-clone, but also add a few features useful for BIND 10 development testing\&.
-.PP
-By default, it looks up the A, AAAA, and MX record sets for the
-\fIname\fR\&. Optionally, you may select a name server to query against by adding the
-\fIserver\fR
-argument\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-a\fR
-.RS 4
-Enable verbose mode and do a query for type ANY\&. (If the
-\fB\-t\fR
-option is also set, then the ANY query is not done, but it still uses verbose mode\&.)
-.RE
-.PP
-\fB\-c \fR\fB\fIclass\fR\fR
-.RS 4
-Define the class for the query\&. The default is IN (Internet)\&.
-.RE
-.PP
-\fB\-d\fR
-.RS 4
-Enable verbose output mode, including elapsed time in milliseconds\&. Verbose mode shows the header, question, answer, authority, and additional sections (if provided)\&. (Same as
-\fB\-v\fR\&.)
-.RE
-.PP
-\fB\-p \fR\fB\fIport\fR\fR
-.RS 4
-Select an alternative port for the query\&. This may be a number or a service name\&. The default is 53 (domain)\&. This is not a standard feature of
-\fBhost\fR(1)\&.
-.RE
-.PP
-\fB\-r\fR
-.RS 4
-Disable recursive processing by not setting the Recursion Desired flag in the query\&.
-.RE
-.PP
-\fB\-t \fR\fB\fItype\fR\fR
-.RS 4
-Select a specific resource record type for the query\&. By default, it looks up the A, AAAA, and MX record sets\&.
-(This overrides the
-\fB\-a\fR
-option\&.)
-.RE
-.PP
-\fB\-v\fR
-.RS 4
-Same as
-\fB\-d\fR
-option\&.
-.RE
-.SH "COMPATIBILITY / BUGS"
-.PP
-
-\fBb10\-host\fR
-does not do reverse lookups by default yet (by detecting if name is a IPv4 or IPv6 address)\&.
-.PP
-Unknown
-\fB\-c\fR
-class or
-\fB\-t\fR
-type causes
-\fBb10\-host\fR
-to Abort\&.
-.PP
-Not all types are supported yet for formatting\&. Not all switches are supported yet\&.
-.PP
-It doesn\'t use
-/etc/resolv\&.conf
-at this time\&. The default name server used is 127\&.0\&.0\&.1\&.
-.PP
-
-\fB\-p\fR
-is not a standard feature\&.
-.SH "HISTORY"
-.PP
-The C++ version of
-\fBb10\-host\fR
-was started in October 2009 by Jeremy C\&. Reed of ISC\&. Its usage and output were based on the standard
-\fBhost\fR
-command\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/loadzone/b10-loadzone.8 b/src/bin/loadzone/b10-loadzone.8
deleted file mode 100644
index d563ff2..0000000
--- a/src/bin/loadzone/b10-loadzone.8
+++ /dev/null
@@ -1,80 +0,0 @@
-'\" t
-.\" Title: b10-loadzone
-.\" Author: [see the "AUTHORS" section]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: March 8, 2010
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-LOADZONE" "8" "March 8, 2010" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-loadzone \- Load DNS Zone File
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-loadzone\fR\ 'u
-\fBb10\-loadzone\fR [\fB\-d\ \fR\fB\fIdatabase\fR\fR] [\fB\-o\ \fR\fB\fIorigin\fR\fR] [filename]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-loadzone\fR
-utility loads a RFC 1035 style DNS master zone file and stores it in a BIND 10 ready data source format\&. Master files are text files that contain DNS Resource Records in text form\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.sp
-Currently only the SQLITE3 data source is supported\&.
-.sp .5v
-.RE
-.PP
-Some control entries (aka directives) are supported\&. $ORIGIN is followed by a domain name, and sets the the origin that will be used for relative domain names in subsequent records\&. $INCLUDE is followed by a filename to load\&.
-The previous origin is restored after the file is included\&.
-$TTL is followed by a time\-to\-live value which is used by any following records that don\'t specify a TTL\&.
-.PP
-When re\-loading an existing zone, the prior version is completely removed\&. While the new version of the zone is being loaded, the old version remains accessible to queries\&. After the new version is completely loaded, the old version is swapped out and replaced with the new one in a single operation\&.
-.SH "ARGUMENTS"
-.PP
-\-d \fIdatabase\fR
-.RS 4
-Defines the filename for the database\&. The default is
-/usr/local/var/bind10\-devel/zone\&.sqlite3\&.
-.RE
-.PP
-\-o \fIorigin\fR
-.RS 4
-Defines the default origin for the zone file records\&.
-.RE
-.SH "FILES"
-.PP
-.SH "SEE ALSO"
-.PP
-
-\fBb10-auth\fR(8),
-\fBbind10\fR(8)\&.
-.SH "AUTHORS"
-.PP
-The
-\fBb10\-loadzone\fR
-tool was initial written by Evan Hunt of ISC\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/msgq/b10-msgq.8 b/src/bin/msgq/b10-msgq.8
deleted file mode 100644
index 37b5228..0000000
--- a/src/bin/msgq/b10-msgq.8
+++ /dev/null
@@ -1,127 +0,0 @@
-'\" t
-.\" Title: b10-msgq
-.\" Author: [see the "AUTHORS" section]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: August 4, 2010
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-MSGQ" "8" "August 4, 2010" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-msgq \- message routing daemon for the Command Channel
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-msgq\fR\ 'u
-\fBb10\-msgq\fR [\fB\-s\ \fR\fB\fIfile\fR\fR] [\fB\-v\fR] [\fB\-\-socket\-file\ \fR\fB\fIfile\fR\fR] [\fB\-\-verbose\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-msgq\fR
-daemon provides message routing for the Command Channel\&.
-.PP
-The Command Channel is a message bus and subscription manager\&. Programs may subscribe to certain groups to receive messages for that group\&. Every new connection to
-\fBb10\-msgq\fR
-is assigned a unique identifier \-\- this is the local name\&. The commands it handles are:
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fBgetlname\fR
-\(em receive local name\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fBsend\fR
-\(em send a message to defined subscribers\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fBsubscribe\fR
-\(em add a subscription\&. This means it is a listener for messages for a specific group\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
-
-\fBunsubscribe\fR
-\(em remove a subscription\&.
-.RE
-.sp
-.RE
-.PP
-It listens on 127\&.0\&.0\&.1\&.
-.PP
-The
-\fBb10\-msgq\fR
-daemon may be cleanly stopped by sending the SIGTERM signal to the process\&. This shutdown does not notify the subscribers\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-s \fR\fB\fIfile\fR\fR, \fB\-\-socket\-file \fR\fB\fIfile\fR\fR
-.RS 4
-The UNIX domain socket file this daemon will use\&. The default is
-/usr/local/var/bind10\-devel/msg_socket\&.
-.RE
-.PP
-\fB\-v\fR, \fB\-\-verbose\fR
-.RS 4
-Enabled verbose mode\&. This enables diagnostic messages to STDERR\&. Displays more about what
-\fBb10\-msgq\fR
-is doing\&.
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "AUTHORS"
-.PP
-The
-\fBb10\-msgq\fR
-daemon and Control Channel specification were initially designed by Michael Graff of ISC\&.
-.SH "HISTORY"
-.PP
-The python version was first coded in December 2009\&. The C version with now deprecated wire format was coded in September 2009\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/resolver/b10-resolver.8 b/src/bin/resolver/b10-resolver.8
deleted file mode 100644
index 7a4cb6d..0000000
--- a/src/bin/resolver/b10-resolver.8
+++ /dev/null
@@ -1,138 +0,0 @@
-'\" t
-.\" Title: b10-resolver
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: December 28, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-RESOLVER" "8" "December 28, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-resolver \- Recursive DNS server
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-resolver\fR\ 'u
-\fBb10\-resolver\fR [\fB\-v\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-resolver\fR
-daemon provides the BIND 10 recursive DNS server\&. Normally it is started by the
-\fBbind10\fR(8)
-boss process\&.
-.PP
-This daemon communicates with other BIND 10 components over a
-\fBb10-msgq\fR(8)
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-resolver\fR
-will exit\&.
-.PP
-It also receives its configurations from
-\fBb10-cfgmgr\fR(8)\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-v\fR
-.RS 4
-Enable verbose mode\&. This sets logging to the maximum debugging level\&.
-.RE
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable settings are:
-.PP
-
-\fIforward_addresses\fR
-defines the list of addresses and ports that
-\fBb10\-resolver\fR
-should forward queries to\&. Defining this enables forwarding\&.
-.PP
-
-\fIlisten_on\fR
-is a list of addresses and ports for
-\fBb10\-resolver\fR
-to listen on\&. The list items are the
-\fIaddress\fR
-string and
-\fIport\fR
-number\&. The defaults are address ::1 port 53 and address 127\&.0\&.0\&.1 port 53\&.
-.PP
-
-
-
-
-
-
-\fIquery_acl\fR
-is a list of query access control rules\&. The list items are the
-\fIaction\fR
-string and the
-\fIfrom\fR
-or
-\fIkey\fR
-strings\&. The possible actions are ACCEPT, REJECT and DROP\&. The
-\fIfrom\fR
-is a remote (source) IPv4 or IPv6 address or special keyword\&. The
-\fIkey\fR
-is a TSIG key name\&. The default configuration accepts queries from 127\&.0\&.0\&.1 and ::1\&.
-.PP
-
-\fIretries\fR
-is the number of times to retry (resend query) after a query timeout (\fItimeout_query\fR)\&. The default is 3\&.
-.PP
-
-\fIroot_addresses\fR
-is a list of addresses and ports for
-\fBb10\-resolver\fR
-to use directly as root servers to start resolving\&. The list items are the
-\fIaddress\fR
-string and
-\fIport\fR
-number\&. By default, a hardcoded address for l\&.root\-servers\&.net (199\&.7\&.83\&.42 or 2001:500:3::42) is used\&.
-.PP
-
-\fItimeout_client\fR
-is the number of milliseconds to wait before timing out the incoming client query\&. If set to \-1, this timeout is disabled\&. The default is 4000\&. After this timeout, a SERVFAIL is sent back to the client asking the question\&. (The lookup may continue after the timeout, but a later answer is not returned for the now\-past query\&.)
-.PP
-
-\fItimeout_lookup\fR
-is the number of milliseconds before it stops trying the query\&. If set to \-1, this timeout is disabled\&. The default is 30000\&.
-.PP
-
-
-\fItimeout_query\fR
-is the number of milliseconds to wait before it retries a query\&. If set to \-1, this timeout is disabled\&. The default is 2000\&.
-.PP
-The configuration command is:
-.PP
-
-\fBshutdown\fR
-exits
-\fBb10\-resolver\fR\&. (Note that the BIND 10 boss process will restart this service\&.)
-.SH "SEE ALSO"
-.PP
-
-\fBb10-cfgmgr\fR(8),
-\fBb10-cmdctl\fR(8),
-\fBb10-msgq\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-resolver\fR
-daemon was first coded in September 2010\&. The initial implementation only provided forwarding\&. Iteration was introduced in January 2011\&. Caching was implemented in February 2011\&. Access control was introduced in June 2011\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/stats/b10-stats-httpd.8 b/src/bin/stats/b10-stats-httpd.8
deleted file mode 100644
index 1206e1d..0000000
--- a/src/bin/stats/b10-stats-httpd.8
+++ /dev/null
@@ -1,132 +0,0 @@
-'\" t
-.\" Title: b10-stats-httpd
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.76.1 <http://docbook.sf.net/>
-.\" Date: Mar 8, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-STATS\-HTTPD" "8" "Mar 8, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * Define some portability stuff
-.\" -----------------------------------------------------------------
-.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.\" http://bugs.debian.org/507673
-.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
-.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-stats-httpd \- BIND 10 HTTP server for HTTP/XML interface of statistics
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-stats\-httpd\fR\ 'u
-\fBb10\-stats\-httpd\fR [\fB\-v\fR]| [\fB\-\-verbose\fR]
-.SH "DESCRIPTION"
-.PP
-
-\fBb10\-stats\-httpd\fR
-is a standalone HTTP server\&. It is intended for HTTP/XML interface for statistics module\&. This server process runs as a process separated from the process of the BIND 10 Stats daemon (\fBb10\-stats\fR)\&. The server is initially executed by the BIND 10 boss process (\fBbind10\fR) and eventually exited by it\&. The server is intended to be server requests by HTTP clients like web browsers and third\-party modules\&. When the server is asked, it requests BIND 10 statistics data or its schema from
-\fBb10\-stats\fR, and it sends the data back in Python dictionary format and the server converts it into XML format\&. The server sends it to the HTTP client\&. The server can send three types of document, which are XML (Extensible Markup Language), XSD (XML Schema definition) and XSL (Extensible Stylesheet Language)\&. The XML document is the statistics data of BIND 10, The XSD document is the data schema of it, and The XSL document is the style sheet to be showed for the web browsers\&. There is different URL for each document\&. But please note that you would be redirected to the URL of XML document if you request the URL of the root document\&. For example, you would be redirected to http://127\&.0\&.0\&.1:8000/bind10/statistics/xml if you request http://127\&.0\&.0\&.1:8000/\&. Please see the manual and the spec file of
-\fBb10\-stats\fR
-for more details about the items of BIND 10 statistics\&. The server uses CC session in communication with
-\fBb10\-stats\fR\&. CC session is provided by
-\fBb10\-msgq\fR
-which is started by
-\fBbind10\fR
-in advance\&. The server is implemented by HTTP\-server libraries included in Python 3\&. The server obtains the configuration from the config manager (\fBb10\-cfgmgr\fR) in runtime\&. Please see below for more details about this spec file and configuration of the server\&.
-.SH "OPTIONS"
-.PP
-The argument is as follow:
-.PP
-\fB\-v\fR, \fB\-\-verbose\fR
-.RS 4
-
-\fBb10\-stats\-httpd\fR
-switches to verbose mode and sends verbose messages to STDOUT\&.
-.RE
-.SH "FILES"
-.PP
-
-/usr/local/share/bind10\-devel/stats\-httpd\&.spec
-\(em the spec file of
-\fBb10\-stats\-httpd\fR\&. This file contains configurable settings of
-\fBb10\-stats\-httpd\fR\&. This setting can be configured in runtime via
-bindctl(1)\&. Please see the manual of
-bindctl(1)
-about how to configure the settings\&.
-.PP
-
-/usr/local/share/bind10\-devel/stats\-httpd\-xml\&.tpl
-\(em the template file of XML document\&.
-.PP
-
-/usr/local/share/bind10\-devel/stats\-httpd\-xsd\&.tpl
-\(em the template file of XSD document\&.
-.PP
-
-/usr/local/share/bind10\-devel/stats\-httpd\-xsl\&.tpl
-\(em the template file of XSL document\&.
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable setting in
-stats\-httpd\&.spec
-is:
-.PP
-\fIlisten_on\fR
-.RS 4
-a list of pairs of address and port for
-\fBb10\-stats\-httpd\fR
-to listen HTTP requests on\&. The pair consists of the
-\fIaddress\fR
-string and
-\fIport\fR
-number\&. The default setting is the list of address 127\&.0\&.0\&.1 port 8000\&. If the server is started by the default setting being left, for example, the URL for XML document is http://127\&.0\&.0\&.1:8000/bind10/statistics/xml\&. And also IPv6 addresses can be configured and they works in the runtime environment for dual stack\&. You can change the settings through
-bindctl(8)\&.
-.RE
-.PP
-The commands in
-stats\-httpd\&.spec
-are:
-.PP
-\fBstatus\fR
-.RS 4
-shows the status of
-\fBb10\-stats\-httpd\fR
-with its PID\&.
-.RE
-.PP
-\fBshutdown\fR
-.RS 4
-exits the
-\fBb10\-stats\-httpd\fR
-process\&. (Note that the BIND 10 boss process will restart this service\&.)
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBb10-stats\fR(8),
-\fBb10-msgq\fR(8),
-\fBb10-cfgmgr\fR(8),
-\fBbind10\fR(8),
-\fBbindctl\fR(1),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-
-\fBb10\-stats\-httpd\fR
-was designed and implemented by Naoki Kambe of JPRS in Mar 2011\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/stats/b10-stats.8 b/src/bin/stats/b10-stats.8
deleted file mode 100644
index 0204ca1..0000000
--- a/src/bin/stats/b10-stats.8
+++ /dev/null
@@ -1,154 +0,0 @@
-'\" t
-.\" Title: b10-stats
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: August 11, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-STATS" "8" "August 11, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-stats \- BIND 10 statistics module
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-stats\fR\ 'u
-\fBb10\-stats\fR [\fB\-v\fR] [\fB\-\-verbose\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-stats\fR
-is a daemon forked by
-\fBbind10\fR\&. Stats module collects statistics data from each module and reports statistics information via
-\fBbindctl\fR\&. It communicates by using the Command Channel by
-\fBb10\-msgq\fR
-with other modules like
-\fBbind10\fR,
-\fBb10\-auth\fR
-and so on\&. It waits for coming data from other modules, then other modules send data to stats module periodically\&. Other modules send stats data to stats module independently from implementation of stats module, so the frequency of sending data may not be constant\&. Stats module collects data and aggregates it\&.
-\fBb10\-stats\fR
-invokes an internal command for
-\fBbind10\fR
-after its initial starting because it\'s sure to collect statistics data from
-\fBbind10\fR\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-v\fR, \fB\-\-verbose\fR
-.RS 4
-This
-\fBb10\-stats\fR
-switches to verbose mode\&. It sends verbose messages to STDOUT\&.
-.RE
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The
-\fBb10\-stats\fR
-command does not have any configurable settings\&.
-.PP
-The configuration commands are:
-.PP
-
-
-\fBremove\fR
-removes the named statistics name and data\&.
-.PP
-
-
-\fBreset\fR
-will reset all statistics data to default values except for constant names\&. This may re\-add previously removed statistics names\&.
-.PP
-
-\fBset\fR
-.PP
-
-\fBshow\fR
-will send the statistics data in JSON format\&. By default, it outputs all the statistics data it has collected\&. An optional item name may be specified to receive individual output\&.
-.PP
-
-\fBshutdown\fR
-will shutdown the
-\fBb10\-stats\fR
-process\&. (Note that the
-\fBbind10\fR
-parent may restart it\&.)
-.PP
-
-\fBstatus\fR
-simply indicates that the daemon is running\&.
-.SH "STATISTICS DATA"
-.PP
-The
-\fBb10\-stats\fR
-daemon contains these statistics:
-.PP
-report_time
-.RS 4
-The latest report date and time in ISO 8601 format\&.
-.RE
-.PP
-stats\&.boot_time
-.RS 4
-The date and time when this daemon was started in ISO 8601 format\&. This is a constant which can\'t be reset except by restarting
-\fBb10\-stats\fR\&.
-.RE
-.PP
-stats\&.last_update_time
-.RS 4
-The date and time (in ISO 8601 format) when this daemon last received data from another component\&.
-.RE
-.PP
-stats\&.lname
-.RS 4
-This is the name used for the
-\fBb10\-msgq\fR
-command\-control channel\&. (This is a constant which can\'t be reset except by restarting
-\fBb10\-stats\fR\&.)
-.RE
-.PP
-stats\&.start_time
-.RS 4
-This is the date and time (in ISO 8601 format) when this daemon started collecting data\&.
-.RE
-.PP
-stats\&.timestamp
-.RS 4
-The current date and time represented in seconds since UNIX epoch (1970\-01\-01T0 0:00:00Z) with precision (delimited with a period) up to one hundred thousandth of second\&.
-.RE
-.PP
-See other manual pages for explanations for their statistics that are kept track by
-\fBb10\-stats\fR\&.
-.SH "FILES"
-.PP
-/usr/local/share/bind10\-devel/stats\&.spec
-\(em This is a spec file for
-\fBb10\-stats\fR\&. It contains commands for
-\fBb10\-stats\fR\&. They can be invoked via
-bindctl(1)\&.
-.SH "SEE ALSO"
-.PP
-
-\fBb10-stats-httpd\fR(8),
-\fBbind10\fR(8),
-\fBbindctl\fR(1),
-\fBb10-auth\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-stats\fR
-daemon was initially designed and implemented by Naoki Kambe of JPRS in October 2010\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/usermgr/b10-cmdctl-usermgr.8 b/src/bin/usermgr/b10-cmdctl-usermgr.8
deleted file mode 100644
index 874ee8f..0000000
--- a/src/bin/usermgr/b10-cmdctl-usermgr.8
+++ /dev/null
@@ -1,74 +0,0 @@
-'\" t
-.\" Title: b10-cmdctl-usermgr
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: March 17, 2010
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-CMDCTL\-USERMGR" "8" "March 17, 2010" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-cmdctl-usermgr \- cmdctl user maintenance tool
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-cmdctl\-usermgr\fR\ 'u
-\fBb10\-cmdctl\-usermgr\fR [\fB\-f\ \fR\fB\fIfilename\fR\fR] [\fB\-h\fR] [\fB\-v\fR] [\fB\-\-file\ \fR\fB\fIfilename\fR\fR] [\fB\-\-help\fR] [\fB\-\-version\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-cmdctl\-usermgr\fR
-tool may be used to add accounts with passwords for the
-\fBb10-cmdctl\fR(8)
-daemon\&.
-.PP
-By default, the accounts are saved in the
-cmdctl\-accounts\&.csv
-file in the current directory, unless the
-\fB\-\-filename\fR
-switch is used\&. The entry is appended to the file\&.
-.PP
-The tool can\'t remove or replace existing entries\&.
-.SH "OPTIONS"
-.PP
-The arguments are as follows:
-.PP
-\fB\-h\fR, \fB\-\-help\fR
-.RS 4
-Report the usage statement and exit\&.
-.RE
-.PP
-\fB\-f \fR\fB\fIfilename\fR\fR, \fB\-\-file \fR\fB\fIfilename\fR\fR
-.RS 4
-Define the filename to append the account to\&. The default is
-cmdctl\-accounts\&.csv
-in the current directory\&.
-.RE
-.PP
-\fB\-v\fR, \fB\-\-version\fR
-.RS 4
-Report the version and exit\&.
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBb10-cmdctl\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-cmdctl\-usermgr\fR
-tool was implemented in January 2010 by Zhang Likun of CNNIC for the ISC BIND 10 project\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/xfrin/b10-xfrin.8 b/src/bin/xfrin/b10-xfrin.8
deleted file mode 100644
index 056103a..0000000
--- a/src/bin/xfrin/b10-xfrin.8
+++ /dev/null
@@ -1,161 +0,0 @@
-'\" t
-.\" Title: b10-xfrin
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: October 12, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-XFRIN" "8" "October 12, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-xfrin \- Incoming DNS zone transfer service
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-xfrin\fR\ 'u
-\fBb10\-xfrin\fR
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-xfrin\fR
-daemon provides the BIND 10 incoming DNS zone transfer service\&. Normally it is started by the
-\fBbind10\fR(8)
-boss process\&. When triggered it can request and receive a zone transfer and store the zone in a BIND 10 zone data source\&.
-.PP
-The
-\fBb10\-xfrin\fR
-daemon supports both AXFR and IXFR\&. Due to some implementation limitations of the current development release, however, it only tries AXFR by default, and care should be taken to enable IXFR\&. See the BIND 10 Guide for more details\&.
-.PP
-This daemon communicates with BIND 10 over a
-\fBb10-msgq\fR(8)
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-xfrin\fR
-will exit\&.
-.PP
-
-\fBb10\-xfrin\fR
-receives its configurations from
-\fBb10-cfgmgr\fR(8)\&.
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable settings are:
-.PP
-\fItransfers_in\fR
-defines the maximum number of inbound zone transfers that can run concurrently\&. The default is 10\&.
-.PP
-
-\fIzones\fR
-is a list of zones known to the
-\fBb10\-xfrin\fR
-daemon\&. The list items are:
-\fIname\fR
-(the zone name),
-\fIclass\fR
-(defaults to
-\(lqIN\(rq),
-\fImaster_addr\fR
-(the zone master to transfer from),
-\fImaster_port\fR
-(defaults to 53),
-\fIuse_ixfr\fR
-(defaults to false), and
-\fItsig_key\fR
-(optional TSIG key to use)\&. The
-\fItsig_key\fR
-is specified using a full string colon\-delimited name:key:algorithm representation (e\&.g\&.
-\(lqfoo\&.example\&.org:EvABsfU2h7uofnmqaRCrhHunGsd=:hmac\-sha1\(rq)\&.
-.PP
-(The site\-wide
-\fImaster_addr\fR
-and
-\fImaster_port\fR
-configurations are deprecated; use the
-\fIzones\fR
-list configuration instead\&.)
-.PP
-The configuration commands are:
-.PP
-
-\fBnotify\fR
-is sent by
-\fBb10-zonemgr\fR(8)
-when a DNS NOTIFY message is received to initiate a zone transfer\&.
-This is an internal command and not exposed to the administrator\&.
-.PP
-
-\fBrefresh\fR
-triggers the transfer in for a single zone\&. It is the same as
-\fBretransfer\fR
-except it checks the SOA serial first\&.
-This is an internal command and not exposed to the administrator\&.
-
-.PP
-
-\fBrefresh_from_zonemgr\fR
-is sent by
-\fBb10-zonemgr\fR(8)
-according to the SOA\'s REFRESH time to tell
-\fBb10\-xfrin\fR
-that the zone needs to do a zone refresh\&. This is an internal command and not exposed to the administrator\&.
-.PP
-
-\fBretransfer\fR
-triggers the transfer in for a single zone without checking the zone\'s serial number\&. It has the following arguments:
-\fIzone_name\fR
-to define the zone to request,
-\fIzone_class\fR
-to define the class (defaults to
-\(lqIN\(rq),
-\fImaster\fR
-to define the IP address of the authoritative server to transfer from, and
-\fIport\fR
-to define the port number on the authoritative server (defaults to 53)\&. If the address or port is not specified, it will use the value previously defined in the
-\fIzones\fR
-configuration\&.
-.PP
-
-\fBshutdown\fR
-stops all incoming zone transfers and exits
-\fBb10\-xfrin\fR\&. (Note that the BIND 10 boss process will restart this service\&.)
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.PP
-This prototype version uses SQLite3 as its data source backend\&. Future versions will be configurable, supporting multiple data storage types\&.
-.sp .5v
-.RE
-.SH "SEE ALSO"
-.PP
-
-\fBb10-cfgmgr\fR(8),
-\fBb10-msgq\fR(8),
-\fBb10-zonemgr\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-xfrin\fR
-daemon was implemented in March 2010 by Zhang Likun of CNNIC for the ISC BIND 10 project\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010-2011 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/xfrout/b10-xfrout.8 b/src/bin/xfrout/b10-xfrout.8
deleted file mode 100644
index c37198c..0000000
--- a/src/bin/xfrout/b10-xfrout.8
+++ /dev/null
@@ -1,158 +0,0 @@
-'\" t
-.\" Title: b10-xfrout
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: December 15, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-XFROUT" "8" "December 15, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-xfrout \- Outbound DNS zone transfer service
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-xfrout\fR\ 'u
-\fBb10\-xfrout\fR [\fB\-v\fR] [\fB\-\-verbose\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-xfrout\fR
-daemon provides the BIND 10 outgoing DNS zone transfer service using AXFR or IXFR\&. It is also used to send outgoing NOTIFY messages\&. Normally it is started by the
-\fBbind10\fR(8)
-boss process\&. When the
-\fBb10\-auth\fR
-DNS server receives a transfer request,
-\fBb10\-xfrout\fR
-sends the zone as found in the BIND 10 zone data store\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.sp
-Currently IXFR only works if it gets the zone via \fBb10\-xfrin\fR and only on TCP\&.
-.sp .5v
-.RE
-.PP
-This daemon communicates with BIND 10 over a
-\fBb10-msgq\fR(8)
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-xfrout\fR
-will exit\&.
-.PP
-
-\fBb10\-xfrout\fR
-receives its configurations from
-\fBb10-cfgmgr\fR(8)\&.
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable settings are:
-.PP
-
-\fItransfers_out\fR
-defines the maximum number of outgoing zone transfers that can run concurrently\&. The default is 10\&.
-.PP
-
-\fItsig_key_ring\fR
-A list of TSIG keys (each of which is in the form of
-\fIname:base64\-key[:algorithm]\fR) used for access control on transfer requests\&. The default is an empty list\&.
-.PP
-
-\fItransfer_acl\fR
-A list of ACL elements that apply to all transfer requests by default (unless overridden in
-\fIzone_config\fR)\&. See the
-BIND 10 Guide
-for configuration examples\&. The default is an element that allows any transfer requests\&.
-.PP
-
-\fIzone_config\fR
-A list of JSON objects (i\&.e\&. maps) that define per zone configuration concerning
-\fBb10\-xfrout\fR\&. The supported names of each object are "origin" (the origin name of the zone), "class" (the RR class of the zone, optional, default to "IN"), and "transfer_acl" (ACL only applicable to transfer requests for that zone)\&. See the
-BIND 10 Guide
-for configuration examples\&. The default is an empty list, that is, no zone specific configuration\&.
-.PP
-
-\fIlog_name\fR
-.PP
-
-\fIlog_file\fR
-The location of the log file if using a file channel\&. If undefined, then the file channel is closed\&. The default is
-/usr/local/var/bind10\-devel/log/Xfrout\&.log\&.
-.PP
-
-\fIlog_severity\fR
-The default is "debug"\&.
-.PP
-
-\fIlog_versions\fR
-The default is 5\&.
-.PP
-
-\fIlog_max_bytes\fR
-The default is 1048576\&.
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBNote\fR
-.ps -1
-.br
-.sp
-This prototype version uses SQLite3 as its data source backend\&. Future versions will be configurable, supporting multiple data storage types\&.
-.sp .5v
-.RE
-.PP
-The configuration commands are:
-.PP
-
-\fBshutdown\fR
-stops all outbound zone transfers and exits
-\fBb10\-xfrout\fR\&. (Note that the BIND 10 boss process will restart this service\&.)
-.PP
-
-\fBzone_new_data_ready\fR
-is sent from
-\fBb10-xfrin\fR(8)
-to indicate that the zone transferred in successfully\&. This triggers
-\fBb10\-xfrout\fR
-to send NOTIFY message(s)\&. This is an internal command and not exposed to the administrator\&.
-.SH "SEE ALSO"
-.PP
-
-\fBb10-auth\fR(8),
-\fBb10-cfgmgr\fR(8),
-\fBb10-msgq\fR(8),
-\fBb10-xfrin\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-xfrout\fR
-daemon was first implemented in March 2010 by Zhang Likun of CNNIC for the ISC BIND 10 project\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010 Internet Systems Consortium, Inc. ("ISC")
-.br
diff --git a/src/bin/zonemgr/b10-zonemgr.8 b/src/bin/zonemgr/b10-zonemgr.8
deleted file mode 100644
index 1d24bbf..0000000
--- a/src/bin/zonemgr/b10-zonemgr.8
+++ /dev/null
@@ -1,132 +0,0 @@
-'\" t
-.\" Title: b10-zonemgr
-.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: December 8, 2011
-.\" Manual: BIND10
-.\" Source: BIND10
-.\" Language: English
-.\"
-.TH "B10\-ZONEMGR" "8" "December 8, 2011" "BIND10" "BIND10"
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-b10-zonemgr \- BIND 10 Secondary zone manager
-.SH "SYNOPSIS"
-.HP \w'\fBb10\-zonemgr\fR\ 'u
-\fBb10\-zonemgr\fR [\fB\-v\fR] [\fB\-\-verbose\fR]
-.SH "DESCRIPTION"
-.PP
-The
-\fBb10\-zonemgr\fR
-daemon, also known as the BIND 10 secondary manager, keeps track of timers and other information necessary for BIND 10 to act as a DNS slave\&. Normally it is started by the
-\fBbind10\fR(8)
-boss process\&.
-.PP
-This daemon communicates with BIND 10 over a
-\fBb10-msgq\fR(8)
-C\-Channel connection\&. If this connection is not established,
-\fBb10\-zonemgr\fR
-will exit\&.
-.PP
-
-\fBb10\-zonemgr\fR
-receives its configurations from
-\fBb10-cfgmgr\fR(8)\&.
-.SH "CONFIGURATION AND COMMANDS"
-.PP
-The configurable settings are:
-.PP
-
-\fIlowerbound_refresh\fR
-defines the minimum SOA REFRESH time in seconds\&. The default is 10\&.
-.PP
-
-\fIlowerbound_retry\fR
-defines the minimum SOA RETRY time in seconds\&. The default is 5\&.
-.PP
-
-\fIrefresh_jitter\fR
-is used to provide a time range for randomizing the refresh and retry timers to help avoid many zones needing to do a refresh or retry at the same time\&. This value is a real number\&. The maximum amount is 0\&.5 (the new timer will be within half the original time)\&. The default is 0\&.25 (up to a quarter sooner)\&. Set to 0 to disable this jitter\&.
-.PP
-
-\fIreload_jitter\fR
-
-This value is a real number\&. The default is 0\&.75\&.
-.PP
-
-\fImax_transfer_timeout\fR
-defines the maximum amount of time in seconds for a transfer\&.
-The default is 14400 (4 hours)\&.
-.PP
-
-\fIsecondary_zones\fR
-is a list of slave zones that the
-\fBb10\-zonemgr\fR
-should keep timers for\&. The list items include the
-\fIname\fR
-(which defines the zone name) and the
-\fIclass\fR
-(which defaults to
-\(lqIN\(rq)\&.
-.PP
-(A deprecated configuration is
-\fIjitter_scope\fR
-which is superceded by
-\fIrefresh_jitter\fR
-and
-\fIreload_jitter\fR\&.)
-.PP
-The configuration commands are:
-.PP
-
-\fBnotify\fR
-(sent by
-\fBb10-auth\fR(8)) tells
-\fBb10\-zonemgr\fR
-the zone name and class, and the IP address for the master (source of the NOTIFY message)\&. This will set the zone\'s refresh time to now\&.
-This is an internal command and not exposed to the administrator\&.
-.PP
-
-\fBshutdown\fR
-exits
-\fBb10\-zonemgr\fR\&. (Note that the BIND 10 boss process will restart this service\&.)
-.PP
-
-\fBzone_new_data_ready\fR
-is sent from
-\fBb10-xfrin\fR(8)
-to indicate that the zone transferred in successfully\&. This is an internal command and not exposed to the administrator\&.
-.PP
-
-\fBzone_xfrin_failed\fR
-is sent from
-\fBb10-xfrin\fR(8)
-to indicate a failure (such as a transfer\-in was incomplete)\&. The refresh timer for the zone is reset\&.
-This is an internal command and not exposed to the administrator\&.
-.SH "SEE ALSO"
-.PP
-
-\fBb10-auth\fR(8),
-\fBb10-cfgmgr\fR(8),
-\fBb10-msgq\fR(8),
-\fBb10-xfrin\fR(8),
-\fBbind10\fR(8),
-BIND 10 Guide\&.
-.SH "HISTORY"
-.PP
-The
-\fBb10\-zonemgr\fR
-daemon was designed in July 2010 by CNNIC for the ISC BIND 10 project\&.
-.SH "COPYRIGHT"
-.br
-Copyright \(co 2010-2011 Internet Systems Consortium, Inc. ("ISC")
-.br
More information about the bind10-changes
mailing list