mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-31 05:55:28 +00:00
Code Issues Releases Wiki Activity

[1651] Merge branch 'master' into trac1651

Browse Source 
Conflicts:
	ChangeLog
	doc/guide/bind10-guide.html
	src/bin/dhcp4/main.cc
	src/lib/dhcp/tests/iface_mgr_unittest.cc
This commit is contained in:
Tomek Mrugalski
2012-06-21 14:06:24 +02:00
parent 30306192b0 031bfc2897
commit 7e16a5a50d
352 changed files with 20680 additions and 2327 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
doc/guide/Makefile.am
View File

@@ -1,6 +1,7 @@
EXTRA_DIST = bind10-guide.css
EXTRA_DIST += bind10-guide.xml bind10-guide.html bind10-guide.txt
EXTRA_DIST += bind10-messages.xml bind10-messages.html
dist_doc_DATA = bind10-guide.txt
dist_html_DATA = bind10-guide.css bind10-guide.html bind10-messages.html
EXTRA_DIST = bind10-guide.xml bind10-messages.xml
# This is not a "man" manual, but reuse this for now for docbook.
if ENABLE_MAN

460
doc/guide/bind10-guide.html
View File

File diff suppressed because one or more lines are too long

838
doc/guide/bind10-guide.txt
View File

File diff suppressed because it is too large Load Diff

442
doc/guide/bind10-guide.xml
View File

@@ -87,9 +87,10 @@
<section>
<title>Supported Platforms</title>
<para>
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.
BIND 10 builds have been tested on (in no particular order)
Debian GNU/Linux 5 and unstable, Ubuntu 9.10, NetBSD 5,
Solaris 10 and 11, FreeBSD 7 and 8, CentOS Linux 5.3,
MacOS 10.6 and 10.7, and OpenBSD 5.1.
It has been tested on Sparc, i386, and amd64 hardware
platforms.
@@ -127,11 +128,13 @@
</para>
<para>
The <command>b10-xfrin</command>, <command>b10-xfrout</command>,
and <command>b10-zonemgr</command> 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.
The <command>b10-ddns</command>, <command>b10-xfrin</command>,
<command>b10-xfrout</command>, and <command>b10-zonemgr</command>
components require the libpython3 library and the Python
_sqlite3.so module (which is included with Python).
The <command>b10-stats-httpd</command> component uses the
Python pyexpat.so module.
The Python modules need to be built for the corresponding Python 3.
</para>
<!-- TODO: this will change ... -->
@@ -194,6 +197,16 @@
</simpara>
</listitem>
<listitem>
<simpara>
<command>b10-ddns</command> &mdash;
Dynamic DNS update service.
This process is used to handle incoming DNS update
requests to allow granted clients to update zones
for which BIND 10 is serving as a primary server.
</simpara>
</listitem>
<listitem>
<simpara>
<command>b10-msgq</command> &mdash;
@@ -876,7 +889,7 @@ as a dependency earlier -->
message bus. The special components already know their
address, but the usual ones don't. The address is by
convention the thing after <emphasis>b10-</emphasis>, with
the first letter capital (eg. <command>b10-stats</command>
the first letter capitalized (eg. <command>b10-stats</command>
would have <quote>Stats</quote> as its address).
<!-- TODO: this should be simplified so we don't even have to document it -->
</para>
@@ -1321,9 +1334,10 @@ This may be a temporary setting until then.
<varname>class</varname> to optionally select the class
(it defaults to <quote>IN</quote>);
and
<varname>zones</varname> to define the
<varname>file</varname> path name and the
<varname>origin</varname> (default domain).
<varname>zones</varname> to define
the <varname>file</varname> path name,
the <varname>filetype</varname> (e.g., <varname>sqlite3</varname>),
and the <varname>origin</varname> (default domain).
By default, this is empty.
@@ -1333,7 +1347,8 @@ This may be a temporary setting until then.
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 <command>named-compilezone -D</command>.
generated by <command>named-compilezone -D</command>, or
must be an SQLite3 database.
</simpara></note>
</simpara>
@@ -1350,6 +1365,24 @@ This may be a temporary setting until then.
and <varname>port</varname> number.
By default, <command>b10-auth</command> listens on port 53
on the IPv6 (::) and IPv4 (0.0.0.0) wildcard addresses.
<note>
<simpara>
The default configuration is currently not appropriate for a multi-homed host.
In case you have multiple public IP addresses, it is possible the
query UDP packet comes through one interface and the answer goes out
through another. The answer will probably be dropped by the client, as it
has a different source address than the one it sent the query to. The
client would fallback on TCP after several attempts, which works
well in this situation, but is clearly not ideal.
</simpara>
<simpara>
There are plans to solve the problem such that the server handles
it by itself. But until it is actually implemented, it is recommended to
alter the configuration &mdash; remove the wildcard addresses and list all
addresses explicitly. Then the server will answer on the same
interface the request came on, preserving the correct address.
</simpara>
</note>
</simpara>
</listitem>
</varlistentry>
@@ -1478,6 +1511,39 @@ This may be a temporary setting until then.
after it is loaded.
</para>
</section>
<section id="in-memory-datasource-with-sqlite3-backend">
<title>In-memory Data Source With SQLite3 Backend</title>
<para>
<!-- How to configure it. -->
The following commands to <command>bindctl</command>
provide an example of configuring an in-memory data
source containing the <quote>example.org</quote> zone
with a SQLite3 backend file named <quote>example.org.sqlite3</quote>:
<!--
<screen>&gt; <userinput> config set Auth/datasources/ [{"type": "memory", "zones": [{"origin": "example.org", "file": "example.org.sqlite3", "filetype": "sqlite3"}]}]</userinput></screen>
-->
<screen>&gt; <userinput>config add Auth/datasources</userinput>
&gt; <userinput>config set Auth/datasources[1]/type "<option>memory</option>"</userinput>
&gt; <userinput>config add Auth/datasources[1]/zones</userinput>
&gt; <userinput>config set Auth/datasources[1]/zones[0]/origin "<option>example.org</option>"</userinput>
&gt; <userinput>config set Auth/datasources[1]/zones[0]/file "<option>example.org.sqlite3</option>"</userinput>
&gt; <userinput>config set Auth/datasources[1]/zones[0]/filetype "<option>sqlite3</option>"</userinput>
&gt; <userinput>config commit</userinput></screen>
The authoritative server will begin serving it immediately
after it is loaded.
</para>
</section>
<section id="in-memory-datasource-loading">
<title>Reloading an In-memory Data Source</title>
<para>
Use the <command>Auth loadzone</command> command in
<command>bindctl</command> to reload a changed master
@@ -1496,6 +1562,10 @@ This may be a temporary setting until then.
</para>
-->
</section>
<section id="in-memory-datasource-disabling">
<title>Disabling In-memory Data Sources</title>
<para>
By default, the memory data source is disabled; it must be
configured explicitly. To disable all the in-memory zones,
@@ -1628,12 +1698,6 @@ TODO
</para>
<!-- TODO: http://bind10.isc.org/ticket/1279 -->
<note><simpara>
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.
</simpara></note>
<section>
<title>Configuration for Incoming Zone Transfers</title>
<para>
@@ -1753,6 +1817,26 @@ what if a NOTIFY is sent?
</para>
</section>
<section>
<title>Incoming Transfers with In-memory Datasource</title>
<para>
In the case of an incoming zone transfer, the received zone is
first stored in the corresponding BIND 10 datasource. In
case the secondary zone is served by an in-memory datasource
with an SQLite3 backend, <command>b10-auth</command> is
automatically sent a <varname>loadzone</varname> command to
reload the corresponding zone into memory from the backend.
</para>
<para>
The administrator doesn't have to do anything for
<command>b10-auth</command> to serve the new version of the
zone, except for the configuration such as the one described in
<xref linkend="in-memory-datasource-with-sqlite3-backend" />.
</para>
</section>
<!-- TODO: can that retransfer be used to identify a new zone? -->
<!-- TODO: what if doesn't exist at that master IP? -->
@@ -1760,7 +1844,6 @@ what if a NOTIFY is sent?
<chapter id="xfrout">
<title>Outbound Zone Transfers</title>
<para>
The <command>b10-xfrout</command> process is started by
<command>bind10</command>.
@@ -1836,6 +1919,325 @@ what is XfroutClient xfr_client??
</chapter>
<chapter id="ddns">
<title>Dynamic DNS Update</title>
<para>
BIND 10 supports the server side of the Dynamic DNS Update
(DDNS) protocol as defined in RFC 2136.
This service is provided by the <command>b10-ddns</command>
component, which is started by the <command>bind10</command>
process if configured so.
</para>
<para>
When the <command>b10-auth</command> authoritative DNS server
receives an UPDATE request, it internally forwards the request
to <command>b10-ddns</command>, which handles the rest of
request processing.
When the processing is completed <command>b10-ddns</command>
will send a response to the client with the RCODE set to the
value as specified in RFC 2136 (NOERROR for successful update,
REFUSED if rejected due to ACL check, etc).
If the zone has been changed as a result, it will internally
notify <command>b10-xfrout</command> so that other secondary
servers will be notified via the DNS notify protocol.
In addition, if <command>b10-auth</command> serves the updated
zone from its in-memory cache (as described in
<xref linkend="in-memory-datasource-with-sqlite3-backend" />),
<command>b10-ddns</command> will also
notify <command>b10-auth</command> so that <command>b10-auth</command>
will re-cache the updated zone content.
</para>
<para>
The <command>b10-ddns</command> component supports requests over
both UDP and TCP, and both IPv6 and IPv4; for TCP requests,
however, it terminates the TCP connection immediately after
each single request has been processed. Clients cannot reuse the
same TCP connection for multiple requests. (This is a current
implementation limitation of <command>b10-ddns</command>.
While RFC 2136 doesn't specify anything about such reuse of TCP
connection, there is no reason for disallowing it as RFC 1035
generally allows multiple requests sent over a single TCP
connection. BIND 9 supports such reuse.)
</para>
<para>
As of this writing <command>b10-ddns</command> does not support
update forwarding for secondary zones.
If it receives an update request for a secondary zone, it will
immediately return a response with an RCODE of NOTIMP.
<note><simpara>
For feature completeness update forwarding should be
eventually supported. But right now it's considered a lower
priority task and there is no specific plan of implementing
this feature.
<!-- See Trac #2063 -->
</simpara></note>
</para>
<section>
<title>Enabling Dynamic Update</title>
<para>
First off, it must be made sure that a few components on which
<command>b10-ddns</command> depends are configured to run,
which are <command>b10-auth</command>
and <command>b10-zonemgr</command>.
In addition, <command>b10-xfrout</command> should also be
configured to run; otherwise the notification after an update
(see above) will fail with a timeout, suspending the DDNS
service while <command>b10-ddns</command> waits for the
response (see the description of the <ulink
url="bind10-messages.html#DDNS_UPDATE_NOTIFY_FAIL">DDNS_UPDATE_NOTIFY_FAIL</ulink>
log message for further details).
If BIND 10 is already configured to provide authoritative DNS
service they should normally be configured to run already.
</para>
<para>
Second, for the obvious reason dynamic update requires that the
underlying data source storing the zone data be writable.
In the current implementation this means the zone must be stored
in an SQLite3-based data source.
Also, right now, the <command>b10-ddns</command> component
configures itself with the data source referring to the
<quote>database_file</quote> configuration parameter of
<command>b10-auth</command>.
So this information must be configured correctly before starting
<command>b10-ddns</command>.
<note><simpara>
The way to configure data sources is now being revised.
Configuration on the data source for DDNS will be very
likely to be changed in a backward incompatible manner in
a near future version.
</simpara></note>
</para>
<para>
In general, if something goes wrong regarding the dependency
described above, <command>b10-ddns</command> will log the
related event at the warning or error level.
It's advisable to check the log message when you first enable
DDNS or if it doesn't work as you expect to see if there's any
warning or error log message.
</para>
<para>
Next, to enable the DDNS service, <command>b10-ddns</command>
needs to be explicitly configured to run.
It can be done by using the <command>bindctl</command>
utility. For example:
<screen>
&gt; <userinput>config add Boss/components b10-ddns</userinput>
&gt; <userinput>config set Boss/components/b10-ddns/address DDNS</userinput>
&gt; <userinput>config set Boss/components/b10-ddns/kind dispensable</userinput>
&gt; <userinput>config commit</userinput>
</screen>
<note><simpara>
In theory "kind" could be omitted because "dispensable" is its
default. But there's some peculiar behavior (which should
be a bug and should be fixed eventually; see Trac ticket
#2064) with bindctl and you'll still need to specify that explicitly.
Likewise, "address" may look unnecessary because
<command>b10-ddns</command> would start and work without
specifying it. But for it to shutdown gracefully this
parameter should also be specified.
</simpara></note>
</para>
</section>
<section>
<title>Access Control</title>
<para>
By default <command>b10-ddns</command> rejects any update
requests from any clients by returning a response with an RCODE
of REFUSED.
To allow updates to take effect, an access control rule
(called update ACL) with a policy allowing updates must explicitly be
configured.
Update ACL must be configured per zone basis in the
<quote>zones</quote> configuration parameter of
<command>b10-ddns</command>.
This is a list of per-zone configurations regarding DDNS.
Each list element consists of the following parameters:
<variablelist>
<varlistentry>
<term>origin</term>
<listitem>
<simpara>The zone's origin name</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>class</term>
<listitem>
<simpara>The RR class of the zone
(normally <quote>IN</quote>, and in that case
can be omitted in configuration)</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>update_acl</term>
<listitem>
<simpara>List of access control rules (ACL) for the zone</simpara>
</listitem>
</varlistentry>
</variablelist>
The syntax of the ACL is the same as ACLs for other
components.
Specific examples are given below.
</para>
<para>
In general, an update ACL rule that allows an update request
should be configured with a TSIG key.
This is an example update ACL that allows updates to the zone
named <quote>example.org</quote> of RR class <quote>IN</quote>
from clients that send requests signed with a TSIG whose
key name is "key.example.org" (and refuses all others):
<screen>
&gt; <userinput>config add DDNS/zones</userinput>
&gt; <userinput>config set DDNS/zones[0]/origin example.org</userinput>
&gt; <userinput>config set DDNS/zones[0]/class IN</userinput>
(Note: "class" can be omitted)
&gt; <userinput>config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}</userinput>
&gt; <userinput>config commit</userinput>
</screen>
The TSIG key must be configured system wide
(see <xref linkend="xfrout"/>.)
</para>
<para>
Multiple rules can be specified in the ACL, and an ACL rule
can consist of multiple constraints, such as a combination of
IP address and TSIG.
The following configuration sequence will add a new rule to
the ACL created in the above example. This additional rule
allows update requests sent from a client
using TSIG key name of "key.example" (different from the
key used in the previous example) and has an IPv6 address of ::1.
<screen>
&gt; <userinput>config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from": "::1", "key": "key.example"}</userinput>
&gt; <userinput>config show DDNS/zones[0]/update_acl</userinput>
DDNS/zones[0]/update_acl[0] {"action": "ACCEPT", "key": "key.example.org"} any (modified)
DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.example"} any (modified)
&gt; <userinput>config commit</userinput>
</screen>
(Note the "add" in the first line. Before this sequence, we
have had only entry in zones[0]/update_acl. The "add" command
with a value (rule) adds a new entry and sets it to the given rule.
Due to a limitation of the current implementation, it doesn't
work if you first try to just add a new entry and then set it to
a given rule).
</para>
<note><simpara>
The <command>b10-ddns</command> component accepts an ACL
rule that just allows updates from a specific IP address
(i.e., without requiring TSIG), but this is highly
discouraged (remember that requests can be made over UDP and
spoofing the source address of a UDP packet is often pretty
easy).
Unless you know what you are doing and that you can accept
its consequence, any update ACL rule that allows updates
should have a TSIG key in its constraints.
</simpara></note>
<para>
The ACL rules will be checked in the listed order, and the
first matching one will apply.
If none of the rules matches, the default rule will apply,
which is rejecting any requests in the case of
<command>b10-ddns</command>.
</para>
<para>
Other actions than "ACCEPT", namely "REJECT" and "DROP", can be
used, too.
See <xref linkend="resolverserver"/> about their effects.
</para>
<para>
Currently update ACL can only control updates per zone basis;
it's not possible to specify access control with higher
granularity such as for particular domain names or specific
types of RRs.
<!-- See Trac ticket #2065 -->
</para>
<note><simpara>
Contrary to what RFC 2136 (literally) specifies,
<command>b10-ddns</command> checks the update ACL before
checking the prerequisites of the update request.
This is a deliberate implementation decision.
This counter intuitive specification has been repeatedly
discussed among implementers and in the IETF, and it is now
widely agreed that it does not make sense to strictly follow
that part of RFC.
One known specific bad result of following the RFC is that it
could leak information about which name or record exists or does not
exist in the zone as a result of prerequisite checks even if a
zone is somehow configured to reject normal queries from
arbitrary clients.
There have been other troubles that could have been avoided if
the ACL could be checked before the prerequisite check.
</simpara></note>
</section>
<section>
<title>Miscellaneous Operational Issues</title>
<para>
Unlike BIND 9, BIND 10 currently does not support automatic
resigning of DNSSEC-signed zone when it's updated via DDNS.
It could be possible to resign the updated zone afterwards
or make sure the update request also updates related DNSSEC
records, but that will be pretty error-prone operation.
In general, it's not advisable to allow DDNS for a signed zone
at this moment.
</para>
<para>
Also unlike BIND 9, it's currently not possible
to <quote>freeze</quote> a zone temporarily in order to
suspend DDNS while you manually update the zone.
If you need to make manual updates to a dynamic zone,
you'll need to temporarily reject any updates to the zone via
the update ACLs.
</para>
<para>
Dynamic updates are only applicable to primary zones.
In order to avoid updating secondary zones via DDNS requests,
<command>b10-ddns</command> refers to the
<quote>secondary_zones</quote> configuration of
<command>b10-zonemgr</command>. Zones listed in
<quote>secondary_zones</quote> will never be updated via DDNS
regardless of the update ACL configuration;
<command>b10-ddns</command> will return a response with an
RCODE of NOTAUTH as specified in RFC 2136.
If you have a "conceptual" secondary zone whose content is a
copy of some external source but is not updated via the
standard zone transfers and therefore not listed in
<quote>secondary_zones</quote>, be careful not to allow DDNS
for the zone; it would be quite likely to lead to inconsistent
state between different servers.
Normally this should not be a problem because the default
update ACL rejects any update requests, but you may want to
take an extra care about the configuration if you have such
type of secondary zones.
</para>
<para>
The difference of two versions of a zone, before and after a
DDNS transaction, is automatically recorded in the underlying
data source, and can be retrieved in the form of outbound
IXFR.
This is done automatically; it does not require specific
configuration to make this possible.
</para>
</section>
</chapter>
<chapter id="resolverserver">
<title>Recursive Name Server</title>

617
doc/guide/bind10-messages.html
View File

@@ -1,10 +1,10 @@
<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 20120127. 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
20120127.</p></div><div><p class="copyright">Copyright <20> 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
<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 20120405. 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
20120405.</p></div><div><p class="copyright">Copyright <20> 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 20120127.
This is the messages manual for BIND 10 version 20120405.
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>.
@@ -131,6 +131,19 @@ 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_MESSAGE_FORWARD_ERROR"></a><span class="term">AUTH_MESSAGE_FORWARD_ERROR failed to forward %1 request from %2: %3</span></dt><dd><p>
The authoritative server tried to forward some type DNS request
message to a separate process (e.g., forwarding dynamic update
requests to b10-ddns) to handle it, but it failed. The authoritative
server returns SERVFAIL to the client on behalf of the separate
process. The error could be configuration mismatch between b10-auth
and the recipient component, or it may be because the requests are
coming too fast and the receipient process cannot keep up with the
rate, or some system level failure. In either case this means the
BIND 10 system is not working as expected, so the administrator should
look into the cause and address the issue. The log message includes
the client's address (and port), and the error message sent from the
lower layer that detects the failure.
</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
@@ -183,6 +196,17 @@ 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_FAILURE"></a><span class="term">AUTH_RESPONSE_FAILURE exception while building response to query: %1</span></dt><dd><p>
This is a debug message, generated by the authoritative server when an
attempt to create a response to a received DNS packet has failed. The
reason for the failure is given in the log message. A SERVFAIL response
is sent back. The most likely cause of this is an error in the data
source implementation; it is either creating bad responses or raising
exceptions itself.
</p></dd><dt><a name="AUTH_RESPONSE_FAILURE_UNKNOWN"></a><span class="term">AUTH_RESPONSE_FAILURE_UNKNOWN unknown exception while building response to query</span></dt><dd><p>
This debug message is similar to AUTH_RESPONSE_FAILURE, but further
details about the error are unknown, because it was signaled by something
which is not an exception. This is definitely a bug.
</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
@@ -275,7 +299,7 @@ NOTIFY request will not be honored.
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>
</p></dd><dt><a name="BIND10_COMPONENT_FAILED"></a><span class="term">BIND10_COMPONENT_FAILED component %1 (pid %2) failed: %3</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>
@@ -384,6 +408,10 @@ so BIND 10 will now shut down. The specific error is printed.
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_SETGID"></a><span class="term">BIND10_SETGID setting GID to %1</span></dt><dd><p>
The boss switches the process group ID to the given value. This happens
when BIND 10 starts with the -u option, and the group ID will be set to
that of the specified user.
</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>
@@ -585,7 +613,7 @@ 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>
</p></dd><dt><a name="CC_ASYNC_READ_FAILED"></a><span class="term">CC_ASYNC_READ_FAILED asynchronous read failed (error code = %1)</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>
@@ -660,6 +688,11 @@ all messages must contain at least the envelope.
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_BACKED_UP_CONFIG_FILE"></a><span class="term">CFGMGR_BACKED_UP_CONFIG_FILE Config file %1 was removed; a backup was made at %2</span></dt><dd><p>
BIND 10 has been started with the command to clear the configuration
file. The existing file has been backed up (moved) to the given file
name. A new configuration file will be created in the original location
when 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
@@ -669,6 +702,9 @@ 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_CONFIG_FILE"></a><span class="term">CFGMGR_CONFIG_FILE Configuration manager starting with configuration file: %1</span></dt><dd><p>
The configuration manager is starting, reading and saving the configuration
settings to the shown file.
</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
@@ -870,6 +906,33 @@ means no limit.
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_FINDNSEC3"></a><span class="term">DATASRC_DATABASE_FINDNSEC3 Looking for NSEC3 for %1 in %2 mode</span></dt><dd><p>
Debug information. A search in an database data source for NSEC3 that
matches or covers the given name is being started.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_COVER"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_COVER found a covering NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
Debug information. An NSEC3 that covers the given name is found and
being returned. The found NSEC3 RRset is also displayed. When the shown label
count is smaller than that of the given name, the matching NSEC3 is for a
superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH). The
found NSEC3 RRset is also displayed.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_MATCH"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_MATCH found a matching NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
Debug information. An NSEC3 that matches (a possibly superdomain of)
the given name is found and being returned. When the shown label
count is smaller than that of the given name, the matching NSEC3 is
for a superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH).
The found NSEC3 RRset is also displayed.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_TRYHASH"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_TRYHASH looking for NSEC3 for %1 at label count %2 (hash %3)</span></dt><dd><p>
Debug information. In an attempt of finding an NSEC3 for the give name,
(a possibly superdomain of) the name is hashed and searched for in the
NSEC3 name space. When the shown label count is smaller than that of the
shown name, the search tries the superdomain name that share the shown
(higher) label count of the shown name (e.g., for
www.example.com. with shown label count of 3, example.com. is being
tried, as "." is 1 label long).
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_TRYHASH_PREV"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_TRYHASH_PREV looking for previous NSEC3 for %1 at label count %2 (hash %3)</span></dt><dd><p>
Debug information. An exact match on hash (see
DATASRC_DATABASE_FINDNSEC3_TRYHASH) was unsuccessful. We get the previous hash
to that one instead.
</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.
@@ -912,7 +975,7 @@ name and class, but not for the given type.
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>
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_RRSET"></a><span class="term">DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %2</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.
@@ -925,10 +988,12 @@ While iterating through the zone, the program reached end of the data.
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.
While iterating through the zone, the time to live for RRs of the
given RRset were found to be different. Since an RRset cannot have
multiple TTLs, we set it to the lowest value we found (but we don't
modify the database). This is what the client would do when such RRs
were given in a DNS response according to RFC2181. 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
@@ -1009,7 +1074,7 @@ 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>
</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 %2 with RRset %3</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.
@@ -1259,8 +1324,10 @@ not have any DS record. This indicates problem with the provided data.
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.
Debug information. Lookup of domain failed because the datasource
has no zone that contains the domain. Maybe someone sent a query
to the wrong server for some reason. This may also happen when
looking in the datasource for addresses for NS records.
</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>
@@ -1307,6 +1374,16 @@ 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_COMPATIBLE_VERSION"></a><span class="term">DATASRC_SQLITE_COMPATIBLE_VERSION database schema V%1.%2 not up to date (expecting V%3.%4) but is compatible</span></dt><dd><p>
The version of the SQLite3 database schema used to hold the zone data
is not the latest one - the current version of BIND 10 was written
with a later schema version in mind. However, the database is
compatible with the current version of BIND 10, and BIND 10 will run
without any problems.
</p><p>
Consult the release notes for your version of BIND 10. Depending on
the changes made to the database schema, it is possible that improved
performance could result if the database were upgraded.
</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>
@@ -1356,6 +1433,13 @@ 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_INCOMPATIBLE_VERSION"></a><span class="term">DATASRC_SQLITE_INCOMPATIBLE_VERSION database schema V%1.%2 incompatible with version (V%3.%4) expected</span></dt><dd><p>
The version of the SQLite3 database schema used to hold the zone data
is incompatible with the version expected by BIND 10. As a result,
BIND 10 is unable to run using the database file as the data source.
</p><p>
The database should be updated using the means described in the BIND
10 documentation.
</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>
@@ -1389,11 +1473,85 @@ 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="DBUTIL_BACKUP"></a><span class="term">DBUTIL_BACKUP created backup of %1 in %2</span></dt><dd><p>
A backup for the given database file was created. Same of original file and
backup are given in the output message.
</p></dd><dt><a name="DBUTIL_CHECK_ERROR"></a><span class="term">DBUTIL_CHECK_ERROR unable to check database version: %1</span></dt><dd><p>
There was an error while trying to check the current version of the database
schema. The error is shown in the message.
</p></dd><dt><a name="DBUTIL_CHECK_NOCONFIRM"></a><span class="term">DBUTIL_CHECK_NOCONFIRM --noconfirm is not compatible with --check</span></dt><dd><p>
b10-dbutil was called with --check and --noconfirm. --noconfirm only has
meaning with --upgrade, so this is considered an error.
</p></dd><dt><a name="DBUTIL_CHECK_OK"></a><span class="term">DBUTIL_CHECK_OK this is the latest version of the database schema. No upgrade is required</span></dt><dd><p>
The database schema version has been checked, and is up to date.
No action is required.
</p></dd><dt><a name="DBUTIL_CHECK_UPGRADE_NEEDED"></a><span class="term">DBUTIL_CHECK_UPGRADE_NEEDED re-run this program with the --upgrade switch to upgrade</span></dt><dd><p>
The database schema version is not up to date, and an update is required.
Please run the dbutil tool again, with the --upgrade argument.
</p></dd><dt><a name="DBUTIL_COMMAND_NONE"></a><span class="term">DBUTIL_COMMAND_NONE must select one of --check or --upgrade</span></dt><dd><p>
b10-dbutil was called with neither --check nor --upgrade. One action must be
provided.
</p></dd><dt><a name="DBUTIL_COMMAND_UPGRADE_CHECK"></a><span class="term">DBUTIL_COMMAND_UPGRADE_CHECK --upgrade is not compatible with --check</span></dt><dd><p>
b10-dbutil was called with both the commands --upgrade and --check. Only one
action can be performed at a time.
</p></dd><dt><a name="DBUTIL_DATABASE_MAY_BE_CORRUPT"></a><span class="term">DBUTIL_DATABASE_MAY_BE_CORRUPT database file %1 may be corrupt, restore it from backup (%2)</span></dt><dd><p>
The upgrade failed while it was in progress; the database may now be in an
inconsistent state, and it is advised to restore it from the backup that was
created when b10-dbutil started.
</p></dd><dt><a name="DBUTIL_EXECUTE"></a><span class="term">DBUTIL_EXECUTE Executing SQL statement: %1</span></dt><dd><p>
Debug message; the given SQL statement is executed
</p></dd><dt><a name="DBUTIL_FILE"></a><span class="term">DBUTIL_FILE Database file: %1</span></dt><dd><p>
The database file that is being checked.
</p></dd><dt><a name="DBUTIL_NO_FILE"></a><span class="term">DBUTIL_NO_FILE must supply name of the database file to upgrade</span></dt><dd><p>
b10-dbutil was called without a database file. Currently, it cannot find this
file on its own, and it must be provided.
</p></dd><dt><a name="DBUTIL_STATEMENT_ERROR"></a><span class="term">DBUTIL_STATEMENT_ERROR failed to execute %1: %2</span></dt><dd><p>
The given database statement failed to execute. The error is shown in the
message.
</p></dd><dt><a name="DBUTIL_TOO_MANY_ARGUMENTS"></a><span class="term">DBUTIL_TOO_MANY_ARGUMENTS too many arguments to the command, maximum of one expected</span></dt><dd><p>
There were too many command-line arguments to b10-dbutil
</p></dd><dt><a name="DBUTIL_UPGRADE_CANCELED"></a><span class="term">DBUTIL_UPGRADE_CANCELED upgrade canceled; database has not been changed</span></dt><dd><p>
The user aborted the upgrade, and b10-dbutil will now exit.
</p></dd><dt><a name="DBUTIL_UPGRADE_DBUTIL"></a><span class="term">DBUTIL_UPGRADE_DBUTIL please get the latest version of b10-dbutil and re-run</span></dt><dd><p>
A database schema was found that was newer than this version of dbutil, which
is apparently out of date and should be upgraded itself.
</p></dd><dt><a name="DBUTIL_UPGRADE_FAILED"></a><span class="term">DBUTIL_UPGRADE_FAILED upgrade failed: %1</span></dt><dd><p>
While the upgrade was in progress, an unexpected error occurred. The error
is shown in the message.
</p></dd><dt><a name="DBUTIL_UPGRADE_NOT_ATTEMPTED"></a><span class="term">DBUTIL_UPGRADE_NOT_ATTEMPTED database upgrade was not attempted</span></dt><dd><p>
Due to the earlier failure, the database schema upgrade was not attempted,
and b10-dbutil will now exit.
</p></dd><dt><a name="DBUTIL_UPGRADE_NOT_NEEDED"></a><span class="term">DBUTIL_UPGRADE_NOT_NEEDED database already at latest version, no upgrade necessary</span></dt><dd><p>
b10-dbutil was told to upgrade the database schema, but it is already at the
latest version.
</p></dd><dt><a name="DBUTIL_UPGRADE_NOT_POSSIBLE"></a><span class="term">DBUTIL_UPGRADE_NOT_POSSIBLE database at a later version than this utility can support</span></dt><dd><p>
b10-dbutil was told to upgrade the database schema, but it is at a higher
version than this tool currently supports. Please update b10-dbutil and try
again.
</p></dd><dt><a name="DBUTIL_UPGRADE_PREPARATION_FAILED"></a><span class="term">DBUTIL_UPGRADE_PREPARATION_FAILED upgrade preparation failed: %1</span></dt><dd><p>
An unexpected error occurred while b10-dbutil was preparing to upgrade the
database schema. The error is shown in the message
</p></dd><dt><a name="DBUTIL_UPGRADE_SUCCESFUL"></a><span class="term">DBUTIL_UPGRADE_SUCCESFUL database upgrade successfully completed</span></dt><dd><p>
The database schema update was completed successfully.
</p></dd><dt><a name="DBUTIL_UPGRADING"></a><span class="term">DBUTIL_UPGRADING upgrading database from %1 to %2</span></dt><dd><p>
An upgrade is in progress, the versions of the current upgrade action are shown.
</p></dd><dt><a name="DBUTIL_VERSION_CURRENT"></a><span class="term">DBUTIL_VERSION_CURRENT database version %1</span></dt><dd><p>
The current version of the database schema.
</p></dd><dt><a name="DBUTIL_VERSION_HIGH"></a><span class="term">DBUTIL_VERSION_HIGH database is at a later version (%1) than this program can cope with (%2)</span></dt><dd><p>
The database schema is at a higher version than b10-dbutil knows about.
</p></dd><dt><a name="DBUTIL_VERSION_LOW"></a><span class="term">DBUTIL_VERSION_LOW database version %1, latest version is %2.</span></dt><dd><p>
The database schema is not up to date, the current version and the latest
version are in the message.
</p></dd><dt><a name="DDNS_ACCEPT_FAILURE"></a><span class="term">DDNS_ACCEPT_FAILURE error accepting a connection: %1</span></dt><dd><p>
There was a low-level error when we tried to accept an incoming connection
(probably coming from b10-auth). We continue serving on whatever other
connections we already have, but this connection is dropped. The reason
is logged.
</p></dd><dt><a name="DDNS_AUTH_DBFILE_UPDATE"></a><span class="term">DDNS_AUTH_DBFILE_UPDATE updated auth DB file to %1</span></dt><dd><p>
b10-ddns was notified of updates to the SQLite3 DB file that b10-auth
uses for the underlying data source and on which b10-ddns needs to
make updates. b10-ddns then updated its internal setup so further
updates would be made on the new DB.
</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.
@@ -1404,12 +1562,41 @@ 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_CONFIG_HANDLER_ERROR"></a><span class="term">DDNS_CONFIG_HANDLER_ERROR failed to update ddns configuration: %1</span></dt><dd><p>
An update to b10-ddns configuration was delivered but an error was
found while applying them. None of the delivered updates were applied
to the running b10-ddns system, and the server will keep running with
the existing configuration. If this happened in the initial
configuration setup, the server will be running with the default
configurations.
</p></dd><dt><a name="DDNS_DROP_CONN"></a><span class="term">DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2</span></dt><dd><p>
There was an error on a connection with the b10-auth server (or whatever
connects to the ddns daemon). This might be OK, for example when the
authoritative server shuts down, the connection would get closed. It also
can mean the system is busy and can't keep up or that the other side got
confused and sent bad data.
</p></dd><dt><a name="DDNS_GET_REMOTE_CONFIG_FAIL"></a><span class="term">DDNS_GET_REMOTE_CONFIG_FAIL failed to get %1 module configuration %2 times: %3</span></dt><dd><p>
b10-ddns tried to get configuration of some remote modules for its
operation, but it failed. The most likely cause of this is that the
remote module has not fully started up and b10-ddns couldn't get the
configuration in a timely fashion. b10-ddns attempts to retry it a
few times, imposing a short delay, hoping it eventually succeeds if
it's just a timing issue. The number of total failed attempts is also
logged. If it reaches an internal threshold b10-ddns considers it a
fatal error and terminates. Even in that case, if b10-ddns is
configured as a "dispensable" component (which is the default), the
parent bind10 process will restart it, and there will be another
chance of getting the remote configuration successfully. These are
not the optimal behavior, but it's believed to be sufficient in
practice (there would normally be no failure in the first place). If
it really causes an operational trouble other than having a few of
these log messages, please submit a bug report; there can be several
ways to make it more sophisticated. Another, less likely reason for
having this error is because the remote modules are not actually
configured to run. If that's the case fixing the configuration should
solve the problem - either by making sure the remote module will run
or by not running b10-ddns (without these remote modules b10-ddns is
not functional, so there's no point in running it in this case).
</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
@@ -1421,12 +1608,80 @@ Debug message. We received a connection and we are going to start handling
requests from it. The file descriptor number and the address where the request
comes from is logged. The connection is over a unix domain socket and is likely
coming from a b10-auth process.
</p></dd><dt><a name="DDNS_RECEIVED_AUTH_UPDATE"></a><span class="term">DDNS_RECEIVED_AUTH_UPDATE received configuration updates from auth server</span></dt><dd><p>
b10-ddns is notified of updates to b10-auth configuration
(including a report of the initial configuration) that b10-ddns might
be interested in.
</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_RECEIVED_ZONEMGR_UPDATE"></a><span class="term">DDNS_RECEIVED_ZONEMGR_UPDATE received configuration updates from zonemgr</span></dt><dd><p>
b10-ddns is notified of updates to b10-zonemgr's configuration
(including a report of the initial configuration). It may possibly
contain changes to the secondary zones, in which case b10-ddns will
update its internal copy of that configuration.
</p></dd><dt><a name="DDNS_REQUEST_PARSE_FAIL"></a><span class="term">DDNS_REQUEST_PARSE_FAIL failed to parse update request: %1</span></dt><dd><p>
b10-ddns received an update request via b10-auth, but the received
data failed to pass minimum validation: it was either broken wire
format data for a valid DNS message (e.g. it's shorter than the
fixed-length header), or the opcode is not update, or TSIG is included
in the request but it fails to validate. Since b10-auth should have
performed this level of checks, such an error shouldn't be detected at
this stage and should rather be considered an internal bug. This
event is therefore logged at the error level, and the request is
simply dropped. Additional information of the error is also logged.
</p></dd><dt><a name="DDNS_REQUEST_TCP_QUOTA"></a><span class="term">DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running)</span></dt><dd><p>
b10-ddns received a new update request from a client over TCP, but
the number of TCP clients being handled by the server already reached
the configured quota, so the latest client was rejected by closing
the connection. The administrator may want to check the status of
b10-ddns, and if this happens even if the server is not very busy,
the quota may have to be increased. Or, if it's more likely to be
malicious or simply bogus clients that somehow keep the TCP connection
open for a long period, maybe they should be rejected with an
appropriate ACL configuration or some lower layer filtering. The
number of existing TCP clients are shown in the log, which should be
identical to the current quota.
</p></dd><dt><a name="DDNS_RESPONSE_SOCKET_ERROR"></a><span class="term">DDNS_RESPONSE_SOCKET_ERROR failed to send update response to %1: %2</span></dt><dd><p>
Network I/O error happens in sending an update response. The
client's address that caused the error and error details are also
logged.
</p></dd><dt><a name="DDNS_RESPONSE_TCP_SOCKET_ERROR"></a><span class="term">DDNS_RESPONSE_TCP_SOCKET_ERROR failed to complete sending update response to %1 over TCP</span></dt><dd><p>
b10-ddns had tried to send an update response over TCP, and it hadn't
been completed at that time, and a followup attempt to complete the
send operation failed due to some network I/O error. While a network
error can happen any time, this event is quite unexpected for two
reasons. First, since the size of a response to an update request
should be generally small, it's unlikely that the initial attempt
didn't fail but wasn't completed. Second, since the first attempt
succeeded and the TCP connection had been established in the first
place, it's more likely for the subsequent attempt to succeed. In any
case, there may not be able to do anything to fix it at the server
side, but the administrator may want to check the general reachability
with the client address.
</p></dd><dt><a name="DDNS_SECONDARY_ZONES_UPDATE"></a><span class="term">DDNS_SECONDARY_ZONES_UPDATE updated secondary zone list (%1 zones are listed)</span></dt><dd><p>
b10-ddns has successfully updated the internal copy of secondary zones
obtained from b10-zonemgr, based on a latest update to zonemgr's
configuration. The number of newly configured (unique) secondary
zones is logged.
</p></dd><dt><a name="DDNS_SECONDARY_ZONES_UPDATE_FAIL"></a><span class="term">DDNS_SECONDARY_ZONES_UPDATE_FAIL failed to update secondary zone list: %1</span></dt><dd><p>
An error message. b10-ddns was notified of updates to a list of
secondary zones from b10-zonemgr and tried to update its own internal
copy of the list, but it failed. This can happen if the configuration
contains an error, and b10-zonemgr should also reject that update.
Unfortunately, in the current implementation there is no way to ensure
that both zonemgr and ddns have consistent information when an update
contains an error; further, as of this writing zonemgr has a bug that
it could partially update the list of secondary zones if part of the
list has an error (see Trac ticket #2038). b10-ddns still keeps
running with the previous configuration, but it's strongly advisable
to check log messages from zonemgr, and if it indicates there can be
inconsistent state, it's better to restart the entire BIND 10 system
(just restarting b10-ddns wouldn't be enough, because zonemgr can have
partially updated configuration due to bug #2038). The log message
contains an error description, but it's intentionally kept simple as
it's primarily a matter of zonemgr. To know the details of the error,
log messages of zonemgr should be consulted.
</p></dd><dt><a name="DDNS_SESSION"></a><span class="term">DDNS_SESSION session arrived on file descriptor %1</span></dt><dd><p>
A debug message, informing there's some activity on the given file descriptor.
It will be either a request or the file descriptor will be closed. See
@@ -1435,6 +1690,9 @@ following log messages to see what of it.
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_STARTED"></a><span class="term">DDNS_STARTED 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_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.
@@ -1445,6 +1703,212 @@ process will now shut down.
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="DDNS_UPDATE_NOTIFY"></a><span class="term">DDNS_UPDATE_NOTIFY notified %1 of updates to %2</span></dt><dd><p>
Debug message. b10-ddns has made updates to a zone based on an update
request and has successfully notified an external module of the updates.
The notified module will use that information for updating its own
state or any necessary protocol action such as zone reloading or sending
notify messages to secondary servers.
</p></dd><dt><a name="DDNS_UPDATE_NOTIFY_FAIL"></a><span class="term">DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3</span></dt><dd><p>
b10-ddns has made updates to a zone based on an update request and
tried to notify an external component of the updates, but the
notification fails. One possible cause of this is that the external
component is not really running and it times out in waiting for the
response, although it will be less likely to happen in practice
because these components will normally be configured to run when the
server provides the authoritative DNS service; ddns is rather optional
among them. If this happens, however, it will suspend b10-ddns for a
few seconds during which it cannot handle new requests (some may be
delayed, some may be dropped, depending on the volume of the incoming
requests). This is obviously bad, and if this error happens due to
this reason, the administrator should make sure the component in
question should be configured to run. For a longer term, b10-ddns
should be more robust about this case such as by making this
notification asynchronously and/or detecting the existence of the
external components to avoid hopeless notification in the first place.
Severity of this error for the receiving components depends on the
type of the component. If it's b10-xfrout, this means DNS notify
messages won't be sent to secondary servers of the zone. It's
suboptimal, but not necessarily critical as the secondary servers will
try to check the zone's status periodically. If it's b10-auth and the
notification was needed to have it reload the corresponding zone, it's
more serious because b10-auth won't be able to serve the new version
of the zone unless some explicit recovery action is taken. So the
administrator needs to examine this message and takes an appropriate
action. In either case, this notification is generally expected to
succeed; so the fact it fails itself means there's something wrong in
the BIND 10 system, and it would be advisable to check other log
messages.
</p></dd><dt><a name="LIBDDNS_DATASRC_ERROR"></a><span class="term">LIBDDNS_DATASRC_ERROR update client %1 failed due to data source error: %2</span></dt><dd><p>
An update attempt failed due to some error in the corresponding data
source. This is generally an unexpected event, but can still happen
for various reasons such as DB lock contention or a failure of the
backend DB server. The cause of the error is also logged. It's
advisable to check the message, and, if necessary, take an appropriate
action (e.g., restarting the DB server if it dies). If this message
is logged the data source isn't modified due to the
corresponding update request. When used by the b10-ddns, the server
will return a response with an RCODE of SERVFAIL.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR"></a><span class="term">LIBDDNS_PREREQ_FORMERR update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it has a non-zero TTL value.
A FORMERR error response is sent to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_ANY"></a><span class="term">LIBDDNS_PREREQ_FORMERR_ANY update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it either has a non-zero
TTL value, or has rdata fields. A FORMERR error response is sent to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_CLASS"></a><span class="term">LIBDDNS_PREREQ_FORMERR_CLASS update client %1 for zone %2: Format error in prerequisite (%3). Bad class.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, the class of the
prerequisite should either match the class of the zone in the Zone Section,
or it should be ANY or NONE, and it is not. A FORMERR error response is sent
to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_NONE"></a><span class="term">LIBDDNS_PREREQ_FORMERR_NONE update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it either has a non-zero
TTL value, or has rdata fields. A FORMERR error response is sent to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_NAME_IN_USE_FAILED"></a><span class="term">LIBDDNS_PREREQ_NAME_IN_USE_FAILED update client %1 for zone %2: 'Name is in use' prerequisite not satisfied (%3), rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'Name is in use'. From RFC2136:
Name is in use. At least one RR with a specified NAME (in
the zone and class specified by the Zone Section) must exist.
Note that this prerequisite is NOT satisfied by empty
nonterminals.
</p></dd><dt><a name="LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED"></a><span class="term">LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED update client %1 for zone %2: 'Name is not in use' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'Name is not in use'.
From RFC2136:
Name is not in use. No RR of any type is owned by a
specified NAME. Note that this prerequisite IS satisfied by
empty nonterminals.
</p></dd><dt><a name="LIBDDNS_PREREQ_NOTZONE"></a><span class="term">LIBDDNS_PREREQ_NOTZONE update client %1 for zone %2: prerequisite not in zone (%3)</span></dt><dd><p>
A DDNS UPDATE prerequisite has a name that does not appear to be inside
the zone specified in the Zone section of the UPDATE message.
The specific prerequisite is shown. A NOTZONE error response is sent to
the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED update client %1 for zone %2: 'RRset does not exist' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset does not exist'.
From RFC2136:
RRset does not exist. No RRs with a specified NAME and TYPE
(in the zone and class denoted by the Zone Section) can exist.
</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_EXISTS_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_EXISTS_FAILED update client %1 for zone %2: 'RRset exists (value independent)' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset exists (value independent)'.
From RFC2136:
RRset exists (value dependent). A set of RRs with a
specified NAME and TYPE exists and has the same members
with the same RDATAs as the RRset specified here in this
Section.
</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED update client %1 for zone %2: 'RRset exists (value dependent)' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset exists (value dependent)'.
From RFC2136:
RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by
the Zone Section) must exist.
</p></dd><dt><a name="LIBDDNS_UPDATE_ADD_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_ADD_BAD_TYPE update client %1 for zone %2: update addition RR bad type: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a statement
that tries to add a record of an invalid type. Most likely the
record has an RRType that is considered a 'meta' type, which
cannot be zone content data. The specific record is shown.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_APPROVED"></a><span class="term">LIBDDNS_UPDATE_APPROVED update client %1 for zone %2 approved</span></dt><dd><p>
Debug message. An update request was approved in terms of the zone's
update ACL.
</p></dd><dt><a name="LIBDDNS_UPDATE_BAD_CLASS"></a><span class="term">LIBDDNS_UPDATE_BAD_CLASS update client %1 for zone %2: bad class in update RR: %3</span></dt><dd><p>
The Update section of a DDNS update message contains an RRset with
a bad class. The class of the update RRset must be either the same
as the class in the Zone Section, ANY, or NONE.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DATASRC_ERROR"></a><span class="term">LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1</span></dt><dd><p>
An error occured while committing the DDNS update changes to the
datasource. The specific error is printed. A SERVFAIL response is sent
back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_DELETE_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a statement
that tries to delete an rrset of an invalid type. Most likely the
record has an RRType that is considered a 'meta' type, which
cannot be zone content data. The specific record is shown.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_NONZERO_TTL"></a><span class="term">LIBDDNS_UPDATE_DELETE_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a 'delete rrset'
statement with a non-zero TTL. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY"></a><span class="term">LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY update client %1 for zone %2: update deletion RR contains data %3</span></dt><dd><p>
The Update section of a DDNS update message contains a 'delete rrset'
statement with a non-empty RRset. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a statement
that tries to delete one or more rrs of an invalid type. Most
likely the records have an RRType that is considered a 'meta'
type, which cannot be zone content data. The specific record is
shown. A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL"></a><span class="term">LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a 'delete rrs'
statement with a non-zero TTL. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DENIED"></a><span class="term">LIBDDNS_UPDATE_DENIED update client %1 for zone %2 denied</span></dt><dd><p>
Informational message. An update request was denied because it was
rejected by the zone's update ACL. When this library is used by
b10-ddns, the server will respond to the request with an RCODE of
REFUSED as described in Section 3.3 of RFC2136.
</p></dd><dt><a name="LIBDDNS_UPDATE_DROPPED"></a><span class="term">LIBDDNS_UPDATE_DROPPED update client %1 for zone %2 dropped</span></dt><dd><p>
Informational message. An update request was denied because it was
rejected by the zone's update ACL. When this library is used by
b10-ddns, the server will then completely ignore the request; no
response will be sent.
</p></dd><dt><a name="LIBDDNS_UPDATE_ERROR"></a><span class="term">LIBDDNS_UPDATE_ERROR update client %1 for zone %2: %3</span></dt><dd><p>
Debug message. An error is found in processing a dynamic update
request. This log message is used for general errors that are not
normally expected to happen. So, in general, it would mean some
problem in the client implementation or an interoperability issue
with this implementation. The client's address, the zone name and
class, and description of the error are logged.
</p></dd><dt><a name="LIBDDNS_UPDATE_FORWARD_FAIL"></a><span class="term">LIBDDNS_UPDATE_FORWARD_FAIL update client %1 for zone %2: update forwarding not supported</span></dt><dd><p>
Debug message. An update request is sent to a secondary server. This
is not necessarily invalid, but this implementation does not yet
support update forwarding as specified in Section 6 of RFC2136 and it
will simply return a response with an RCODE of NOTIMP to the client.
The client's address and the zone name/class are logged.
</p></dd><dt><a name="LIBDDNS_UPDATE_NOTAUTH"></a><span class="term">LIBDDNS_UPDATE_NOTAUTH update client %1 for zone %2: not authoritative for update zone</span></dt><dd><p>
Debug message. An update request was received for a zone for which
the receiving server doesn't have authority. In theory this is an
unexpected event, but there are client implementations that could send
update requests carelessly, so it may not necessarily be so uncommon
in practice. If possible, you may want to check the implementation or
configuration of those clients to suppress the requests. As specified
in Section 3.1 of RFC2136, the receiving server will return a response
with an RCODE of NOTAUTH.
</p></dd><dt><a name="LIBDDNS_UPDATE_NOTZONE"></a><span class="term">LIBDDNS_UPDATE_NOTZONE update client %1 for zone %2: update RR out of zone %3</span></dt><dd><p>
A DDNS UPDATE record has a name that does not appear to be inside
the zone specified in the Zone section of the UPDATE message.
The specific update record is shown. A NOTZONE error response is
sent to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_PREREQUISITE_FAILED"></a><span class="term">LIBDDNS_UPDATE_PREREQUISITE_FAILED prerequisite failed in update client %1 for zone %2: result code %3</span></dt><dd><p>
The handling of the prerequisite section (RFC2136 Section 3.2) found
that one of the prerequisites was not satisfied. The result code
should give more information on what prerequisite type failed.
If the result code is FORMERR, the prerequisite section was not well-formed.
An error response with the given result code is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION"></a><span class="term">LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION update client %1 for zone %2: uncaught exception while processing update section: %3</span></dt><dd><p>
An uncaught exception was encountered while processing the Update
section of a DDNS message. The specific exception is shown in the log message.
To make sure DDNS service is not interrupted, this problem is caught instead
of reraised; The update is aborted, and a SERVFAIL is sent back to the client.
This is most probably a bug in the DDNS code, but *could* be caused by
the data source.
</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 -&gt; %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
@@ -1502,6 +1966,8 @@ the reason given.
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_LOCK_TEST_MESSAGE"></a><span class="term">LOG_LOCK_TEST_MESSAGE this is a test message.</span></dt><dd><p>
This is a log message used in testing.
</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
@@ -1703,6 +2169,30 @@ 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="PYSERVER_COMMON_AUTH_CONFIG_NAME_PARSER_ERROR"></a><span class="term">PYSERVER_COMMON_AUTH_CONFIG_NAME_PARSER_ERROR Invalid name when parsing Auth configuration: %1</span></dt><dd><p>
There was an invalid name when parsing Auth configuration.
</p></dd><dt><a name="PYSERVER_COMMON_AUTH_CONFIG_RRCLASS_ERROR"></a><span class="term">PYSERVER_COMMON_AUTH_CONFIG_RRCLASS_ERROR Invalid RRClass when parsing Auth configuration: %1</span></dt><dd><p>
There was an invalid RR class when parsing Auth configuration.
</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_DONE"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_DONE completed sending TCP message to %1 (%2 bytes in total)</span></dt><dd><p>
Debug message. A complete DNS message has been successfully
transmitted over a TCP connection, possibly after multiple send
operations. The destination address and the total size of the message
(including the 2-byte length field) are shown in the log message.
</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_ERROR"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_ERROR failed to send TCP message to %1 (%2/%3 bytes sent): %4</span></dt><dd><p>
A DNS message has been attempted to be sent out over a TCP connection,
but it failed due to some network error. Although it's not expected
to happen too often, it can still happen for various reasons. The
administrator may want to examine the cause of the failure, which is
included in the log message, to see if it requires some action to
be taken at the server side. When this message is logged, the
corresponding TCP connection was closed immediately after the error
was detected.
</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_PENDING"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_PENDING sent part TCP message to %1 (up to %2/%3 bytes)</span></dt><dd><p>
Debug message. A part of DNS message has been transmitted over a TCP
connection, and it's suspended because further attempt would block.
The destination address and the total size of the message that has
been transmitted so far (including the 2-byte length field) are shown
in the log message.
</p></dd><dt><a name="PYSERVER_COMMON_TSIG_KEYRING_DEINIT"></a><span class="term">PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring</span></dt><dd><p>
A debug message noting that the global TSIG keyring is being removed from
memory. Most programs don't do that, they just exit, which is OK.
@@ -2064,7 +2554,7 @@ 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_SHUTDOWN%20(1)"></a><span class="term">RESOLVER_SHUTDOWN (1) asked to shut down, doing so</span></dt><dd><p>
</p></dd><dt><a name="RESOLVER_SHUTDOWN_RECEIVED"></a><span class="term">RESOLVER_SHUTDOWN_RECEIVED received command to shut down</span></dt><dd><p>
A debug message noting that the server was asked to terminate and is
complying to the request.
</p></dd><dt><a name="RESOLVER_STARTED"></a><span class="term">RESOLVER_STARTED resolver started</span></dt><dd><p>
@@ -2270,6 +2760,10 @@ 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_AUTH_LOADZONE"></a><span class="term">XFRIN_AUTH_LOADZONE sending Auth loadzone for origin=%1, class=%2, datasrc=%3</span></dt><dd><p>
There was a successful zone transfer, and the zone is served by b10-auth
in the in-memory data source using sqlite3 as a backend. We send the
"loadzone" command for the zone to b10-auth.
</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
@@ -2317,6 +2811,30 @@ 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_TRANSFER_SUCCESS"></a><span class="term">XFRIN_IXFR_TRANSFER_SUCCESS incremental IXFR transfer of zone %1 succeeded (messages: %2, changesets: %3, deletions: %4, additions: %5, bytes: %6, run time: %7 seconds, %8 bytes/second)</span></dt><dd><p>
The IXFR transfer for the given zone was successful.
The provided information contains the following values:
</p><p>
messages: Number of overhead DNS messages in the transfer.
</p><p>
changesets: Number of difference sequences.
</p><p>
deletions: Number of Resource Records deleted by all the changesets combined,
including the SOA records.
</p><p>
additions: Number of Resource Records added by all the changesets combined,
including the SOA records.
</p><p>
bytes: Full size of the transfer data on the wire.
</p><p>
run time: Time (in seconds) the complete ixfr took.
</p><p>
bytes/second: Transfer speed.
</p><p>
Note that there is no cross-checking of additions and deletions; if the same
RR gets added and deleted in multiple changesets, it is counted each time;
therefore, for each changeset, there should at least be 1 deletion and 1
addition (the updated SOA record).
</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
@@ -2330,6 +2848,9 @@ aborts the transfer just like a successful case.
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_AUTH"></a><span class="term">XFRIN_MSGQ_SEND_ERROR_AUTH error while contacting %1</span></dt><dd><p>
There was a problem sending a message to b10-auth. 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.
@@ -2343,11 +2864,26 @@ 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_STARTED"></a><span class="term">XFRIN_STARTED xfrin started</span></dt><dd><p>
This informational message is output by xfrin when all initialization
has been completed and it is entering its main loop.
</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_TRANSFER_SUCCESS"></a><span class="term">XFRIN_TRANSFER_SUCCESS full %1 transfer of zone %2 succeeded (messages: %3, records: %4, bytes: %5, run time: %6 seconds, %7 bytes/second)</span></dt><dd><p>
The AXFR transfer of the given zone was successful.
The provided information contains the following values:
</p><p>
messages: Number of overhead DNS messages in the transfer
</p><p>
records: Number of Resource Records in the full transfer, excluding the
final SOA record that marks the end of the AXFR.
</p><p>
bytes: Full size of the transfer data on the wire.
</p><p>
run time: Time (in seconds) the complete axfr took
</p><p>
bytes/second: Transfer speed
</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.
@@ -2389,8 +2925,6 @@ 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
@@ -2509,11 +3043,15 @@ 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_PROCESS_REQUEST_ERROR"></a><span class="term">XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %1</span></dt><dd><p>
There was an error in receiving a transfer request from b10-auth.
This is generally an unexpected event, but is possible when, for
example, b10-auth terminates in the middle of forwarding the request.
When this happens it's unlikely to be recoverable with the same
communication session with b10-auth, so b10-xfrout drops it and
waits for a new session. In any case, this error indicates that
there's something very wrong in the system, so it's advisable to check
the over all status of the BIND 10 system.
</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
@@ -2538,9 +3076,16 @@ 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.
request from b10-auth. There can be several reasons for this, but
the most likely cause is that b10-auth terminates for some reason
(maybe it's a bug of b10-auth, maybe it's an intentional restart by
the administrator), so depending on how this happens it may or may not
be a serious error. But in any case this is not expected to happen
frequently, and it's advisable to figure out how this happened if
this message is logged. Even if this error happens xfrout will reset
its internal state and will keep receiving further requests. So
if it's just a temporary restart of b10-auth the administrator does
not have to do anything.
</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
@@ -2557,6 +3102,9 @@ 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_STARTED"></a><span class="term">XFROUT_STARTED xfrout started</span></dt><dd><p>
This informational message is output by xfrout when all initialization
has been completed and it is entering its main loop.
</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.
@@ -2673,6 +3221,9 @@ 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_STARTED"></a><span class="term">ZONEMGR_STARTED zonemgr started</span></dt><dd><p>
This informational message is output by zonemgr when all initialization
has been completed and it is entering its main loop.
</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>
@@ -2683,9 +3234,11 @@ 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.
operation is not being managed by the zone manager. This can be either the
result of a bindctl command to transfer in a currently unknown (or mistyped)
zone, or, if this error appears without the administrator giving transfer
commands, it can indicate an error in the program, as it should not have
initiated transfers of unknown zones on its own.
</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

796
doc/guide/bind10-messages.xml
View File

@@ -303,6 +303,24 @@ discovered that the memory data source is enabled for the given class.
</para></listitem>
</varlistentry>
<varlistentry id="AUTH_MESSAGE_FORWARD_ERROR">
<term>AUTH_MESSAGE_FORWARD_ERROR failed to forward %1 request from %2: %3</term>
<listitem><para>
The authoritative server tried to forward some type DNS request
message to a separate process (e.g., forwarding dynamic update
requests to b10-ddns) to handle it, but it failed. The authoritative
server returns SERVFAIL to the client on behalf of the separate
process. The error could be configuration mismatch between b10-auth
and the recipient component, or it may be because the requests are
coming too fast and the receipient process cannot keep up with the
rate, or some system level failure. In either case this means the
BIND 10 system is not working as expected, so the administrator should
look into the cause and address the issue. The log message includes
the client's address (and port), and the error message sent from the
lower layer that detects the failure.
</para></listitem>
</varlistentry>
<varlistentry id="AUTH_NOTIFY_QUESTIONS">
<term>AUTH_NOTIFY_QUESTIONS invalid number of questions (%1) in incoming NOTIFY</term>
<listitem><para>
@@ -882,6 +900,15 @@ The boss module is sending a SIGTERM signal to the given process.
</para></listitem>
</varlistentry>
<varlistentry id="BIND10_SETGID">
<term>BIND10_SETGID setting GID to %1</term>
<listitem><para>
The boss switches the process group ID to the given value. This happens
when BIND 10 starts with the -u option, and the group ID will be set to
that of the specified user.
</para></listitem>
</varlistentry>
<varlistentry id="BIND10_SETUID">
<term>BIND10_SETUID setting UID to %1</term>
<listitem><para>
@@ -1399,7 +1426,7 @@ Debug message. The RRset is updating its data with this given RRset.
</varlistentry>
<varlistentry id="CC_ASYNC_READ_FAILED">
<term>CC_ASYNC_READ_FAILED asynchronous read failed</term>
<term>CC_ASYNC_READ_FAILED asynchronous read failed (error code = %1)</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.
@@ -1588,6 +1615,16 @@ are now applied, and no action from the administrator is necessary.
</para></listitem>
</varlistentry>
<varlistentry id="CFGMGR_BACKED_UP_CONFIG_FILE">
<term>CFGMGR_BACKED_UP_CONFIG_FILE Config file %1 was removed; a backup was made at %2</term>
<listitem><para>
BIND 10 has been started with the command to clear the configuration
file. The existing file has been backed up (moved) to the given file
name. A new configuration file will be created in the original location
when 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>
@@ -1607,6 +1644,14 @@ system. The most likely cause is that msgq is not running.
</para></listitem>
</varlistentry>
<varlistentry id="CFGMGR_CONFIG_FILE">
<term>CFGMGR_CONFIG_FILE Configuration manager starting with configuration file: %1</term>
<listitem><para>
The configuration manager is starting, reading and saving the configuration
settings to the shown file.
</para></listitem>
</varlistentry>
<varlistentry id="CFGMGR_DATA_READ_ERROR">
<term>CFGMGR_DATA_READ_ERROR error reading configuration database from disk: %1</term>
<listitem><para>
@@ -1639,15 +1684,6 @@ configuration is not stored.
</para></listitem>
</varlistentry>
<varlistentry id="CFGMGR_RENAMED_CONFIG_FILE">
<term>CFGMGR_RENAMED_CONFIG_FILE renamed configuration file %1 to %2, will create new %1</term>
<listitem><para>
BIND 10 has been started with the command to clear the configuration file.
The existing file is backed up to the given file name, so that data is not
immediately lost if this was done by accident.
</para></listitem>
</varlistentry>
<varlistentry id="CFGMGR_STOPPED_BY_KEYBOARD">
<term>CFGMGR_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
<listitem><para>
@@ -2057,6 +2093,58 @@ in the answer as a result.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_DATABASE_FINDNSEC3">
<term>DATASRC_DATABASE_FINDNSEC3 Looking for NSEC3 for %1 in %2 mode</term>
<listitem><para>
Debug information. A search in an database data source for NSEC3 that
matches or covers the given name is being started.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_DATABASE_FINDNSEC3_COVER">
<term>DATASRC_DATABASE_FINDNSEC3_COVER found a covering NSEC3 for %1 at label count %2: %3</term>
<listitem><para>
Debug information. An NSEC3 that covers the given name is found and
being returned. The found NSEC3 RRset is also displayed. When the shown label
count is smaller than that of the given name, the matching NSEC3 is for a
superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH). The
found NSEC3 RRset is also displayed.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_DATABASE_FINDNSEC3_MATCH">
<term>DATASRC_DATABASE_FINDNSEC3_MATCH found a matching NSEC3 for %1 at label count %2: %3</term>
<listitem><para>
Debug information. An NSEC3 that matches (a possibly superdomain of)
the given name is found and being returned. When the shown label
count is smaller than that of the given name, the matching NSEC3 is
for a superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH).
The found NSEC3 RRset is also displayed.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_DATABASE_FINDNSEC3_TRYHASH">
<term>DATASRC_DATABASE_FINDNSEC3_TRYHASH looking for NSEC3 for %1 at label count %2 (hash %3)</term>
<listitem><para>
Debug information. In an attempt of finding an NSEC3 for the give name,
(a possibly superdomain of) the name is hashed and searched for in the
NSEC3 name space. When the shown label count is smaller than that of the
shown name, the search tries the superdomain name that share the shown
(higher) label count of the shown name (e.g., for
www.example.com. with shown label count of 3, example.com. is being
tried, as "." is 1 label long).
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_DATABASE_FINDNSEC3_TRYHASH_PREV">
<term>DATASRC_DATABASE_FINDNSEC3_TRYHASH_PREV looking for previous NSEC3 for %1 at label count %2 (hash %3)</term>
<listitem><para>
Debug information. An exact match on hash (see
DATASRC_DATABASE_FINDNSEC3_TRYHASH) was unsuccessful. We get the previous hash
to that one instead.
</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>
@@ -2155,7 +2243,7 @@ has been requested and returned.
</varlistentry>
<varlistentry id="DATASRC_DATABASE_FOUND_RRSET">
<term>DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %5</term>
<term>DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %2</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
@@ -2189,10 +2277,12 @@ The name and RRtype of the RRset is indicated in the message.
<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.
While iterating through the zone, the time to live for RRs of the
given RRset were found to be different. Since an RRset cannot have
multiple TTLs, we set it to the lowest value we found (but we don't
modify the database). This is what the client would do when such RRs
were given in a DNS response according to RFC2181. The data in
database should be checked and fixed.
</para></listitem>
</varlistentry>
@@ -2352,7 +2442,7 @@ namespace but has no RRs assopciated with it). This will produce NXRRSET.
</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>
<term>DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %2 with RRset %3</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
@@ -3096,6 +3186,21 @@ Debug information. The SQLite data source is closing the database file.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_SQLITE_COMPATIBLE_VERSION">
<term>DATASRC_SQLITE_COMPATIBLE_VERSION database schema V%1.%2 not up to date (expecting V%3.%4) but is compatible</term>
<listitem><para>
The version of the SQLite3 database schema used to hold the zone data
is not the latest one - the current version of BIND 10 was written
with a later schema version in mind. However, the database is
compatible with the current version of BIND 10, and BIND 10 will run
without any problems.
</para><para>
Consult the release notes for your version of BIND 10. Depending on
the changes made to the database schema, it is possible that improved
performance could result if the database were upgraded.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_SQLITE_CONNCLOSE">
<term>DATASRC_SQLITE_CONNCLOSE Closing sqlite database</term>
<listitem><para>
@@ -3235,6 +3340,18 @@ But it doesn't contain that zone.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_SQLITE_INCOMPATIBLE_VERSION">
<term>DATASRC_SQLITE_INCOMPATIBLE_VERSION database schema V%1.%2 incompatible with version (V%3.%4) expected</term>
<listitem><para>
The version of the SQLite3 database schema used to hold the zone data
is incompatible with the version expected by BIND 10. As a result,
BIND 10 is unable to run using the database file as the data source.
</para><para>
The database should be updated using the means described in the BIND
10 documentation.
</para></listitem>
</varlistentry>
<varlistentry id="DATASRC_SQLITE_NEWCONN">
<term>DATASRC_SQLITE_NEWCONN SQLite3Database is being initialized</term>
<listitem><para>
@@ -3517,6 +3634,16 @@ is logged.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_AUTH_DBFILE_UPDATE">
<term>DDNS_AUTH_DBFILE_UPDATE updated auth DB file to %1</term>
<listitem><para>
b10-ddns was notified of updates to the SQLite3 DB file that b10-auth
uses for the underlying data source and on which b10-ddns needs to
make updates. b10-ddns then updated its internal setup so further
updates would be made on the new DB.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_CC_SESSION_ERROR">
<term>DDNS_CC_SESSION_ERROR error reading from cc channel: %1</term>
<listitem><para>
@@ -3542,6 +3669,18 @@ startup time. Details of the error are included in the log message.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_CONFIG_HANDLER_ERROR">
<term>DDNS_CONFIG_HANDLER_ERROR failed to update ddns configuration: %1</term>
<listitem><para>
An update to b10-ddns configuration was delivered but an error was
found while applying them. None of the delivered updates were applied
to the running b10-ddns system, and the server will keep running with
the existing configuration. If this happened in the initial
configuration setup, the server will be running with the default
configurations.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_DROP_CONN">
<term>DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2</term>
<listitem><para>
@@ -3553,6 +3692,33 @@ confused and sent bad data.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_GET_REMOTE_CONFIG_FAIL">
<term>DDNS_GET_REMOTE_CONFIG_FAIL failed to get %1 module configuration %2 times: %3</term>
<listitem><para>
b10-ddns tried to get configuration of some remote modules for its
operation, but it failed. The most likely cause of this is that the
remote module has not fully started up and b10-ddns couldn't get the
configuration in a timely fashion. b10-ddns attempts to retry it a
few times, imposing a short delay, hoping it eventually succeeds if
it's just a timing issue. The number of total failed attempts is also
logged. If it reaches an internal threshold b10-ddns considers it a
fatal error and terminates. Even in that case, if b10-ddns is
configured as a "dispensable" component (which is the default), the
parent bind10 process will restart it, and there will be another
chance of getting the remote configuration successfully. These are
not the optimal behavior, but it's believed to be sufficient in
practice (there would normally be no failure in the first place). If
it really causes an operational trouble other than having a few of
these log messages, please submit a bug report; there can be several
ways to make it more sophisticated. Another, less likely reason for
having this error is because the remote modules are not actually
configured to run. If that's the case fixing the configuration should
solve the problem - either by making sure the remote module will run
or by not running b10-ddns (without these remote modules b10-ddns is
not functional, so there's no point in running it in this case).
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_MODULECC_SESSION_ERROR">
<term>DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</term>
<listitem><para>
@@ -3574,6 +3740,15 @@ coming from a b10-auth process.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_RECEIVED_AUTH_UPDATE">
<term>DDNS_RECEIVED_AUTH_UPDATE received configuration updates from auth server</term>
<listitem><para>
b10-ddns is notified of updates to b10-auth configuration
(including a report of the initial configuration) that b10-ddns might
be interested in.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_RECEIVED_SHUTDOWN_COMMAND">
<term>DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
<listitem><para>
@@ -3582,11 +3757,105 @@ and will now shut down.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_RUNNING">
<term>DDNS_RUNNING ddns server is running and listening for updates</term>
<varlistentry id="DDNS_RECEIVED_ZONEMGR_UPDATE">
<term>DDNS_RECEIVED_ZONEMGR_UPDATE received configuration updates from zonemgr</term>
<listitem><para>
The ddns process has successfully started and is now ready to receive commands
and updates.
b10-ddns is notified of updates to b10-zonemgr's configuration
(including a report of the initial configuration). It may possibly
contain changes to the secondary zones, in which case b10-ddns will
update its internal copy of that configuration.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_REQUEST_PARSE_FAIL">
<term>DDNS_REQUEST_PARSE_FAIL failed to parse update request: %1</term>
<listitem><para>
b10-ddns received an update request via b10-auth, but the received
data failed to pass minimum validation: it was either broken wire
format data for a valid DNS message (e.g. it's shorter than the
fixed-length header), or the opcode is not update, or TSIG is included
in the request but it fails to validate. Since b10-auth should have
performed this level of checks, such an error shouldn't be detected at
this stage and should rather be considered an internal bug. This
event is therefore logged at the error level, and the request is
simply dropped. Additional information of the error is also logged.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_REQUEST_TCP_QUOTA">
<term>DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running)</term>
<listitem><para>
b10-ddns received a new update request from a client over TCP, but
the number of TCP clients being handled by the server already reached
the configured quota, so the latest client was rejected by closing
the connection. The administrator may want to check the status of
b10-ddns, and if this happens even if the server is not very busy,
the quota may have to be increased. Or, if it's more likely to be
malicious or simply bogus clients that somehow keep the TCP connection
open for a long period, maybe they should be rejected with an
appropriate ACL configuration or some lower layer filtering. The
number of existing TCP clients are shown in the log, which should be
identical to the current quota.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_RESPONSE_SOCKET_ERROR">
<term>DDNS_RESPONSE_SOCKET_ERROR failed to send update response to %1: %2</term>
<listitem><para>
Network I/O error happens in sending an update response. The
client's address that caused the error and error details are also
logged.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_RESPONSE_TCP_SOCKET_ERROR">
<term>DDNS_RESPONSE_TCP_SOCKET_ERROR failed to complete sending update response to %1 over TCP</term>
<listitem><para>
b10-ddns had tried to send an update response over TCP, and it hadn't
been completed at that time, and a followup attempt to complete the
send operation failed due to some network I/O error. While a network
error can happen any time, this event is quite unexpected for two
reasons. First, since the size of a response to an update request
should be generally small, it's unlikely that the initial attempt
didn't fail but wasn't completed. Second, since the first attempt
succeeded and the TCP connection had been established in the first
place, it's more likely for the subsequent attempt to succeed. In any
case, there may not be able to do anything to fix it at the server
side, but the administrator may want to check the general reachability
with the client address.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_SECONDARY_ZONES_UPDATE">
<term>DDNS_SECONDARY_ZONES_UPDATE updated secondary zone list (%1 zones are listed)</term>
<listitem><para>
b10-ddns has successfully updated the internal copy of secondary zones
obtained from b10-zonemgr, based on a latest update to zonemgr's
configuration. The number of newly configured (unique) secondary
zones is logged.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_SECONDARY_ZONES_UPDATE_FAIL">
<term>DDNS_SECONDARY_ZONES_UPDATE_FAIL failed to update secondary zone list: %1</term>
<listitem><para>
An error message. b10-ddns was notified of updates to a list of
secondary zones from b10-zonemgr and tried to update its own internal
copy of the list, but it failed. This can happen if the configuration
contains an error, and b10-zonemgr should also reject that update.
Unfortunately, in the current implementation there is no way to ensure
that both zonemgr and ddns have consistent information when an update
contains an error; further, as of this writing zonemgr has a bug that
it could partially update the list of secondary zones if part of the
list has an error (see Trac ticket #2038). b10-ddns still keeps
running with the previous configuration, but it's strongly advisable
to check log messages from zonemgr, and if it indicates there can be
inconsistent state, it's better to restart the entire BIND 10 system
(just restarting b10-ddns wouldn't be enough, because zonemgr can have
partially updated configuration due to bug #2038). The log message
contains an error description, but it's intentionally kept simple as
it's primarily a matter of zonemgr. To know the details of the error,
log messages of zonemgr should be consulted.
</para></listitem>
</varlistentry>
@@ -3608,6 +3877,14 @@ be completed, after which the process will exit.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_STARTED">
<term>DDNS_STARTED 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_STOPPED">
<term>DDNS_STOPPED ddns server has stopped</term>
<listitem><para>
@@ -3633,6 +3910,362 @@ normal circumstances. The exception type and message are printed.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_UPDATE_NOTIFY">
<term>DDNS_UPDATE_NOTIFY notified %1 of updates to %2</term>
<listitem><para>
Debug message. b10-ddns has made updates to a zone based on an update
request and has successfully notified an external module of the updates.
The notified module will use that information for updating its own
state or any necessary protocol action such as zone reloading or sending
notify messages to secondary servers.
</para></listitem>
</varlistentry>
<varlistentry id="DDNS_UPDATE_NOTIFY_FAIL">
<term>DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3</term>
<listitem><para>
b10-ddns has made updates to a zone based on an update request and
tried to notify an external component of the updates, but the
notification fails. One possible cause of this is that the external
component is not really running and it times out in waiting for the
response, although it will be less likely to happen in practice
because these components will normally be configured to run when the
server provides the authoritative DNS service; ddns is rather optional
among them. If this happens, however, it will suspend b10-ddns for a
few seconds during which it cannot handle new requests (some may be
delayed, some may be dropped, depending on the volume of the incoming
requests). This is obviously bad, and if this error happens due to
this reason, the administrator should make sure the component in
question should be configured to run. For a longer term, b10-ddns
should be more robust about this case such as by making this
notification asynchronously and/or detecting the existence of the
external components to avoid hopeless notification in the first place.
Severity of this error for the receiving components depends on the
type of the component. If it's b10-xfrout, this means DNS notify
messages won't be sent to secondary servers of the zone. It's
suboptimal, but not necessarily critical as the secondary servers will
try to check the zone's status periodically. If it's b10-auth and the
notification was needed to have it reload the corresponding zone, it's
more serious because b10-auth won't be able to serve the new version
of the zone unless some explicit recovery action is taken. So the
administrator needs to examine this message and takes an appropriate
action. In either case, this notification is generally expected to
succeed; so the fact it fails itself means there's something wrong in
the BIND 10 system, and it would be advisable to check other log
messages.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_DATASRC_ERROR">
<term>LIBDDNS_DATASRC_ERROR update client %1 failed due to data source error: %2</term>
<listitem><para>
An update attempt failed due to some error in the corresponding data
source. This is generally an unexpected event, but can still happen
for various reasons such as DB lock contention or a failure of the
backend DB server. The cause of the error is also logged. It's
advisable to check the message, and, if necessary, take an appropriate
action (e.g., restarting the DB server if it dies). If this message
is logged the data source isn't modified due to the
corresponding update request. When used by the b10-ddns, the server
will return a response with an RCODE of SERVFAIL.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_FORMERR">
<term>LIBDDNS_PREREQ_FORMERR update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL.</term>
<listitem><para>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it has a non-zero TTL value.
A FORMERR error response is sent to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_FORMERR_ANY">
<term>LIBDDNS_PREREQ_FORMERR_ANY update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</term>
<listitem><para>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it either has a non-zero
TTL value, or has rdata fields. A FORMERR error response is sent to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_FORMERR_CLASS">
<term>LIBDDNS_PREREQ_FORMERR_CLASS update client %1 for zone %2: Format error in prerequisite (%3). Bad class.</term>
<listitem><para>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, the class of the
prerequisite should either match the class of the zone in the Zone Section,
or it should be ANY or NONE, and it is not. A FORMERR error response is sent
to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_FORMERR_NONE">
<term>LIBDDNS_PREREQ_FORMERR_NONE update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</term>
<listitem><para>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it either has a non-zero
TTL value, or has rdata fields. A FORMERR error response is sent to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_NAME_IN_USE_FAILED">
<term>LIBDDNS_PREREQ_NAME_IN_USE_FAILED update client %1 for zone %2: 'Name is in use' prerequisite not satisfied (%3), rcode: %4</term>
<listitem><para>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'Name is in use'. From RFC2136:
Name is in use. At least one RR with a specified NAME (in
the zone and class specified by the Zone Section) must exist.
Note that this prerequisite is NOT satisfied by empty
nonterminals.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED">
<term>LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED update client %1 for zone %2: 'Name is not in use' (%3) prerequisite not satisfied, rcode: %4</term>
<listitem><para>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'Name is not in use'.
From RFC2136:
Name is not in use. No RR of any type is owned by a
specified NAME. Note that this prerequisite IS satisfied by
empty nonterminals.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_NOTZONE">
<term>LIBDDNS_PREREQ_NOTZONE update client %1 for zone %2: prerequisite not in zone (%3)</term>
<listitem><para>
A DDNS UPDATE prerequisite has a name that does not appear to be inside
the zone specified in the Zone section of the UPDATE message.
The specific prerequisite is shown. A NOTZONE error response is sent to
the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED">
<term>LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED update client %1 for zone %2: 'RRset does not exist' (%3) prerequisite not satisfied, rcode: %4</term>
<listitem><para>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset does not exist'.
From RFC2136:
RRset does not exist. No RRs with a specified NAME and TYPE
(in the zone and class denoted by the Zone Section) can exist.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_RRSET_EXISTS_FAILED">
<term>LIBDDNS_PREREQ_RRSET_EXISTS_FAILED update client %1 for zone %2: 'RRset exists (value independent)' (%3) prerequisite not satisfied, rcode: %4</term>
<listitem><para>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset exists (value independent)'.
From RFC2136:
RRset exists (value dependent). A set of RRs with a
specified NAME and TYPE exists and has the same members
with the same RDATAs as the RRset specified here in this
Section.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED">
<term>LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED update client %1 for zone %2: 'RRset exists (value dependent)' (%3) prerequisite not satisfied, rcode: %4</term>
<listitem><para>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset exists (value dependent)'.
From RFC2136:
RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by
the Zone Section) must exist.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_ADD_BAD_TYPE">
<term>LIBDDNS_UPDATE_ADD_BAD_TYPE update client %1 for zone %2: update addition RR bad type: %3</term>
<listitem><para>
The Update section of a DDNS update message contains a statement
that tries to add a record of an invalid type. Most likely the
record has an RRType that is considered a 'meta' type, which
cannot be zone content data. The specific record is shown.
A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_APPROVED">
<term>LIBDDNS_UPDATE_APPROVED update client %1 for zone %2 approved</term>
<listitem><para>
Debug message. An update request was approved in terms of the zone's
update ACL.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_BAD_CLASS">
<term>LIBDDNS_UPDATE_BAD_CLASS update client %1 for zone %2: bad class in update RR: %3</term>
<listitem><para>
The Update section of a DDNS update message contains an RRset with
a bad class. The class of the update RRset must be either the same
as the class in the Zone Section, ANY, or NONE.
A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DATASRC_ERROR">
<term>LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1</term>
<listitem><para>
An error occured while committing the DDNS update changes to the
datasource. The specific error is printed. A SERVFAIL response is sent
back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DELETE_BAD_TYPE">
<term>LIBDDNS_UPDATE_DELETE_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</term>
<listitem><para>
The Update section of a DDNS update message contains a statement
that tries to delete an rrset of an invalid type. Most likely the
record has an RRType that is considered a 'meta' type, which
cannot be zone content data. The specific record is shown.
A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DELETE_NONZERO_TTL">
<term>LIBDDNS_UPDATE_DELETE_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</term>
<listitem><para>
The Update section of a DDNS update message contains a 'delete rrset'
statement with a non-zero TTL. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY">
<term>LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY update client %1 for zone %2: update deletion RR contains data %3</term>
<listitem><para>
The Update section of a DDNS update message contains a 'delete rrset'
statement with a non-empty RRset. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE">
<term>LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</term>
<listitem><para>
The Update section of a DDNS update message contains a statement
that tries to delete one or more rrs of an invalid type. Most
likely the records have an RRType that is considered a 'meta'
type, which cannot be zone content data. The specific record is
shown. A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL">
<term>LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</term>
<listitem><para>
The Update section of a DDNS update message contains a 'delete rrs'
statement with a non-zero TTL. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DENIED">
<term>LIBDDNS_UPDATE_DENIED update client %1 for zone %2 denied</term>
<listitem><para>
Informational message. An update request was denied because it was
rejected by the zone's update ACL. When this library is used by
b10-ddns, the server will respond to the request with an RCODE of
REFUSED as described in Section 3.3 of RFC2136.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_DROPPED">
<term>LIBDDNS_UPDATE_DROPPED update client %1 for zone %2 dropped</term>
<listitem><para>
Informational message. An update request was denied because it was
rejected by the zone's update ACL. When this library is used by
b10-ddns, the server will then completely ignore the request; no
response will be sent.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_ERROR">
<term>LIBDDNS_UPDATE_ERROR update client %1 for zone %2: %3</term>
<listitem><para>
Debug message. An error is found in processing a dynamic update
request. This log message is used for general errors that are not
normally expected to happen. So, in general, it would mean some
problem in the client implementation or an interoperability issue
with this implementation. The client's address, the zone name and
class, and description of the error are logged.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_FORWARD_FAIL">
<term>LIBDDNS_UPDATE_FORWARD_FAIL update client %1 for zone %2: update forwarding not supported</term>
<listitem><para>
Debug message. An update request is sent to a secondary server. This
is not necessarily invalid, but this implementation does not yet
support update forwarding as specified in Section 6 of RFC2136 and it
will simply return a response with an RCODE of NOTIMP to the client.
The client's address and the zone name/class are logged.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_NOTAUTH">
<term>LIBDDNS_UPDATE_NOTAUTH update client %1 for zone %2: not authoritative for update zone</term>
<listitem><para>
Debug message. An update request was received for a zone for which
the receiving server doesn't have authority. In theory this is an
unexpected event, but there are client implementations that could send
update requests carelessly, so it may not necessarily be so uncommon
in practice. If possible, you may want to check the implementation or
configuration of those clients to suppress the requests. As specified
in Section 3.1 of RFC2136, the receiving server will return a response
with an RCODE of NOTAUTH.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_NOTZONE">
<term>LIBDDNS_UPDATE_NOTZONE update client %1 for zone %2: update RR out of zone %3</term>
<listitem><para>
A DDNS UPDATE record has a name that does not appear to be inside
the zone specified in the Zone section of the UPDATE message.
The specific update record is shown. A NOTZONE error response is
sent to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_PREREQUISITE_FAILED">
<term>LIBDDNS_UPDATE_PREREQUISITE_FAILED prerequisite failed in update client %1 for zone %2: result code %3</term>
<listitem><para>
The handling of the prerequisite section (RFC2136 Section 3.2) found
that one of the prerequisites was not satisfied. The result code
should give more information on what prerequisite type failed.
If the result code is FORMERR, the prerequisite section was not well-formed.
An error response with the given result code is sent back to the client.
</para></listitem>
</varlistentry>
<varlistentry id="LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION">
<term>LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION update client %1 for zone %2: uncaught exception while processing update section: %3</term>
<listitem><para>
An uncaught exception was encountered while processing the Update
section of a DDNS message. The specific exception is shown in the log message.
To make sure DDNS service is not interrupted, this problem is caught instead
of reraised; The update is aborted, and a SERVFAIL is sent back to the client.
This is most probably a bug in the DDNS code, but *could* be caused by
the data source.
</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 -&gt; %1.</term>
<listitem><para>
@@ -3750,6 +4383,13 @@ and the underscore, and should not start with a digit.
</para></listitem>
</varlistentry>
<varlistentry id="LOG_LOCK_TEST_MESSAGE">
<term>LOG_LOCK_TEST_MESSAGE this is a test message.</term>
<listitem><para>
This is a log message used in testing.
</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>
@@ -4141,6 +4781,55 @@ bug report.
</para></listitem>
</varlistentry>
<varlistentry id="PYSERVER_COMMON_AUTH_CONFIG_NAME_PARSER_ERROR">
<term>PYSERVER_COMMON_AUTH_CONFIG_NAME_PARSER_ERROR Invalid name when parsing Auth configuration: %1</term>
<listitem><para>
There was an invalid name when parsing Auth configuration.
</para></listitem>
</varlistentry>
<varlistentry id="PYSERVER_COMMON_AUTH_CONFIG_RRCLASS_ERROR">
<term>PYSERVER_COMMON_AUTH_CONFIG_RRCLASS_ERROR Invalid RRClass when parsing Auth configuration: %1</term>
<listitem><para>
There was an invalid RR class when parsing Auth configuration.
</para></listitem>
</varlistentry>
<varlistentry id="PYSERVER_COMMON_DNS_TCP_SEND_DONE">
<term>PYSERVER_COMMON_DNS_TCP_SEND_DONE completed sending TCP message to %1 (%2 bytes in total)</term>
<listitem><para>
Debug message. A complete DNS message has been successfully
transmitted over a TCP connection, possibly after multiple send
operations. The destination address and the total size of the message
(including the 2-byte length field) are shown in the log message.
</para></listitem>
</varlistentry>
<varlistentry id="PYSERVER_COMMON_DNS_TCP_SEND_ERROR">
<term>PYSERVER_COMMON_DNS_TCP_SEND_ERROR failed to send TCP message to %1 (%2/%3 bytes sent): %4</term>
<listitem><para>
A DNS message has been attempted to be sent out over a TCP connection,
but it failed due to some network error. Although it's not expected
to happen too often, it can still happen for various reasons. The
administrator may want to examine the cause of the failure, which is
included in the log message, to see if it requires some action to
be taken at the server side. When this message is logged, the
corresponding TCP connection was closed immediately after the error
was detected.
</para></listitem>
</varlistentry>
<varlistentry id="PYSERVER_COMMON_DNS_TCP_SEND_PENDING">
<term>PYSERVER_COMMON_DNS_TCP_SEND_PENDING sent part TCP message to %1 (up to %2/%3 bytes)</term>
<listitem><para>
Debug message. A part of DNS message has been transmitted over a TCP
connection, and it's suspended because further attempt would block.
The destination address and the total size of the message that has
been transmitted so far (including the 2-byte length field) are shown
in the log message.
</para></listitem>
</varlistentry>
<varlistentry id="PYSERVER_COMMON_TSIG_KEYRING_DEINIT">
<term>PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring</term>
<listitem><para>
@@ -5388,6 +6077,15 @@ Please check your installation.
</para></listitem>
</varlistentry>
<varlistentry id="XFRIN_AUTH_LOADZONE">
<term>XFRIN_AUTH_LOADZONE sending Auth loadzone for origin=%1, class=%2, datasrc=%3</term>
<listitem><para>
There was a successful zone transfer, and the zone is served by b10-auth
in the in-memory data source using sqlite3 as a backend. We send the
"loadzone" command for the zone to b10-auth.
</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>
@@ -5542,6 +6240,14 @@ was killed.
</para></listitem>
</varlistentry>
<varlistentry id="XFRIN_MSGQ_SEND_ERROR_AUTH">
<term>XFRIN_MSGQ_SEND_ERROR_AUTH error while contacting %1</term>
<listitem><para>
There was a problem sending a message to b10-auth. 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>
@@ -5570,10 +6276,11 @@ zone name in the configuration.
</para></listitem>
</varlistentry>
<varlistentry id="XFRIN_STARTING">
<term>XFRIN_STARTING starting resolver with command line '%1'</term>
<varlistentry id="XFRIN_STARTED">
<term>XFRIN_STARTED xfrin started</term>
<listitem><para>
An informational message, this is output when the resolver starts up.
This informational message is output by xfrin when all initialization
has been completed and it is entering its main loop.
</para></listitem>
</varlistentry>
@@ -5909,12 +6616,16 @@ parsed by the b10-auth daemon, before it was passed here.
</varlistentry>
<varlistentry id="XFROUT_PROCESS_REQUEST_ERROR">
<term>XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %2</term>
<term>XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %1</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.
There was an error in receiving a transfer request from b10-auth.
This is generally an unexpected event, but is possible when, for
example, b10-auth terminates in the middle of forwarding the request.
When this happens it's unlikely to be recoverable with the same
communication session with b10-auth, so b10-xfrout drops it and
waits for a new session. In any case, this error indicates that
there's something very wrong in the system, so it's advisable to check
the over all status of the BIND 10 system.
</para></listitem>
</varlistentry>
@@ -5964,9 +6675,16 @@ and will now shut down.
<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.
request from b10-auth. There can be several reasons for this, but
the most likely cause is that b10-auth terminates for some reason
(maybe it's a bug of b10-auth, maybe it's an intentional restart by
the administrator), so depending on how this happens it may or may not
be a serious error. But in any case this is not expected to happen
frequently, and it's advisable to figure out how this happened if
this message is logged. Even if this error happens xfrout will reset
its internal state and will keep receiving further requests. So
if it's just a temporary restart of b10-auth the administrator does
not have to do anything.
</para></listitem>
</varlistentry>
@@ -6001,6 +6719,14 @@ log message.
</para></listitem>
</varlistentry>
<varlistentry id="XFROUT_STARTED">
<term>XFROUT_STARTED xfrout started</term>
<listitem><para>
This informational message is output by xfrout when all initialization
has been completed and it is entering its main loop.
</para></listitem>
</varlistentry>
<varlistentry id="XFROUT_STOPPED_BY_KEYBOARD">
<term>XFROUT_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
<listitem><para>
@@ -6257,6 +6983,14 @@ A debug message, output when the zone manager has shut down completely.
</para></listitem>
</varlistentry>
<varlistentry id="ZONEMGR_STARTED">
<term>ZONEMGR_STARTED zonemgr started</term>
<listitem><para>
This informational message is output by zonemgr when all initialization
has been completed and it is entering its main loop.
</para></listitem>
</varlistentry>
<varlistentry id="ZONEMGR_STARTING">
<term>ZONEMGR_STARTING zone manager starting</term>
<listitem><para>