This is the reference guide for BIND 10 version - 20110519.
Copyright © 2010 Internet Systems Consortium, Inc.
Abstract
BIND 10 is a Domain Name System (DNS) suite managed by +
This is the reference guide for BIND 10 version + 20110705.
Copyright © 2010-2011 Internet Systems Consortium, Inc.
Abstract
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 reference guide for BIND 10 version 20110519. + This is the reference guide for BIND 10 version 20110705. The most up-to-date version of this document, along with - other documents for BIND 10, can be found at http://bind10.isc.org/docs.
Table of Contents
Table of Contents
+ other documents for BIND 10, can be found at http://bind10.isc.org/docs.
Table of Contents
Table of Contents
BIND is the popular implementation of a DNS server, developer interfaces, and DNS tools. BIND 10 is a rewrite of BIND 9. BIND 10 is written in C++ and Python and provides a modular environment for serving and maintaining DNS.
This guide covers the experimental prototype of - BIND 10 version 20110519. + BIND 10 version 20110705.
BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server and a caching recursive name server which also provides forwarding. -
BIND 10 builds have been tested on Debian GNU/Linux 5, Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, and CentOS Linux 5.3. @@ -28,13 +28,15 @@ It is planned for BIND 10 to build, install and run on Windows and standard Unix-type platforms. -
BIND 10 requires Python 3.1. Later versions may work, but Python 3.1 is the minimum version which will work.
BIND 10 uses the Botan crypto library for C++. It requires - at least Botan version 1.8. To build BIND 10, install the - Botan libraries and development include headers. + at least Botan version 1.8. +
+ BIND 10 uses the log4cplus C++ logging library. It requires + at least log4cplus version 1.0.3.
The authoritative server requires SQLite 3.3.9 or newer. The b10-xfrin, b10-xfrout, @@ -136,7 +138,10 @@ and, of course, DNS. These include detailed developer documentation and code examples. -
Table of Contents
+
Table of Contents
+ In addition to the run-time requirements, building BIND 10 + from source code requires various development include headers. +
Some operating systems have split their distribution packages into a run-time and a development package. You will need to install the development package versions, which include header files and @@ -147,6 +152,11 @@
+ To build BIND 10, also install the Botan (at least version + 1.8) and the log4cplus (at least version 1.0.3) + development include headers. +
+ The Python Library and Python _sqlite3 module are required to enable the Xfrout and Xfrin support.
@@ -156,7 +166,7 @@ Building BIND 10 also requires a C++ compiler and standard development headers, make, and pkg-config. BIND 10 builds have been tested with GCC g++ 3.4.3, 4.1.2, - 4.1.3, 4.2.1, 4.3.2, and 4.4.1. + 4.1.3, 4.2.1, 4.3.2, and 4.4.1; Clang++ 2.8; and Sun C++ 5.10.
This quickly covers the standard steps for installing and deploying BIND 10 as an authoritative name server using @@ -192,14 +202,14 @@ the Git code revision control system or as a downloadable tar file. It may also be available in pre-compiled ready-to-use packages from operating system vendors. -
+
Downloading a release tar file is the recommended method to obtain the source code.
The BIND 10 releases are available as tar file downloads from ftp://ftp.isc.org/isc/bind10/. Periodic development snapshots may also be available. -
Downloading this "bleeding edge" code is recommended only for developers or advanced users. Using development code in a production environment is not recommended. @@ -233,7 +243,7 @@ autoheader, automake, and related commands. -
BIND 10 uses the GNU Build System to discover build environment details. To generate the makefiles using the defaults, simply run: @@ -264,16 +274,16 @@
If the configure fails, it may be due to missing or old dependencies. -
After the configure step is complete, to build the executables from the C++ code and prepare the Python scripts, run:
$ make-
To install the BIND 10 executables, support files, and documentation, run:
$ make install-
The install step may require superuser privileges.
The following is the layout of the complete BIND 10 installation:
bin/ —
@@ -490,12 +500,12 @@ shutdown
the details and relays (over a b10-msgq command
channel) the configuration on to the specified module.
-
Table of Contents
+
Table of Contents
The b10-auth is the authoritative DNS server. It supports EDNS0 and DNSSEC. It supports IPv6. Normally it is started by the bind10 master process. -
+
b10-auth is configured via the b10-cfgmgr configuration manager. The module name is “Auth”. @@ -515,7 +525,7 @@ This may be a temporary setting until then.
-
+
For the development prototype release, b10-auth
supports a SQLite3 data source backend and in-memory data source
backend.
@@ -529,7 +539,7 @@ This may be a temporary setting until then.
The default is /usr/local/var/.)
This data file location may be changed by defining the
“database_file” configuration.
-
RFC 1035 style DNS master zone files may imported into a BIND 10 data source by using the b10-loadzone utility. @@ -607,7 +617,7 @@ This may be a temporary setting until then.
Access control (such as allowing notifies) is not yet provided. The primary/secondary service is not yet complete. -
Table of Contents
The b10-resolver process is started by
bind10.
@@ -636,7 +646,7 @@ This may be a temporary setting until then.
> config set Resolver/listen_on [{ "address": "127.0.0.1", "port": 53 }]
> config commit
-
+
To enable forwarding, the upstream address and port must be
configured to forward queries to, such as:
diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml
index 6a4218207a..021c593332 100644
--- a/doc/guide/bind10-guide.xml
+++ b/doc/guide/bind10-guide.xml
@@ -146,7 +146,7 @@
The processes started by the python
.
+ This is not needed on some operating systems.
+ ACCEPT
to allow the incoming query,
+ REJECT
to respond with a DNS REFUSED return
+ code, or DROP
to ignore the query without
+ any response (such as a blackhole). For more information,
+ see the respective debugging messages: any6
(for
+ any IPv6 address) or any4
(for any IPv4
+ address).
+
+ as needed; run
if needed.)Resolver
. This
+ configuration will then be used by the loggers in the
+ Resolver module, and all the libraries used by it.
+ Resolver.nsas
. If
+ there is no entry in Logging for a particular library,
+ it will use the configuration given for the module.
+
+
+
+ Resolver
and severity INFO, and one with
+ the name Resolver.cache
with severity
+ DEBUG. As there are no entries for other libraries (e.g.
+ the nsas), they will use the configuration for the module
+ (Resolver
), so giving the desired behavior.
+
+ *
+ (asterisks), which is interpreted as *.config
+ specifies the configuration library code in whatever
+ module is using it).
+
+ *
and Resolver
, the
+ resolver module — and all libraries it uses —
+ will log messages according to the configuration in the
+ second entry (Resolver
). All other modules
+ will use the configuration of the first entry
+ (*
). If there was also a configuration
+ entry for Resolver.cache
, the cache library
+ within the resolver would use that in preference to the
+ entry for Resolver
.
+
+ Resolver
for the resolver module,
+ Xfrout
for the xfrout module, etc. When
+ the message is logged, the message will include the name
+ of the logger generating the message, but with the module
+ name replaced by the name of the process implementing
+ the module (so for example, a message generated by the
+ Auth.cache
logger will appear in the output
+ with a logger name of b10-auth.cache
).
+
+ Resolver
and
+ Resolver.cache
, and
+ is true in the second, it will write the log messages
+ not only to the destinations specified for
+ Resolver.cache
, but also to the destinations
+ as specified in the in
+ the logger named Resolver
.
+
+
+
+ console
stdout
+ (messages printed to standard output) or
+ stderr
(messages printed to standard
+ error).
+ file
syslog
file
.
+ *
.
+
+
This is the messages manual for BIND 10 version - 20110519.
Copyright © 2011 Internet Systems Consortium, Inc.
Abstract
BIND 10 is a Domain Name System (DNS) suite managed by +
This is the messages manual for BIND 10 version + 20110705.
Copyright © 2011 Internet Systems Consortium, Inc.
Abstract
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 20110519. + This is the messages manual for BIND 10 version 20110705. The most up-to-date version of this document, along with other documents for BIND 10, can be found at http://bind10.isc.org/docs. @@ -26,38 +26,337 @@ For information on configuring and using BIND 10 logging, refer to the BIND 10 Guide.
-
-A debug message, this records the the upstream fetch (a query made by the +
+A debug message, this records that the upstream fetch (a query made by the resolver on behalf of its client) to the specified address has completed. -
+
An external component has requested the halting of an upstream fetch. This is an allowed operation, and the message should only appear if debug is enabled. -
+
The asynchronous I/O code encountered an error when trying to open a socket of the specified protocol in order to send a message to the target address. -The the number of the system error that cause the problem is given in the +The number of the system error that cause the problem is given in the message. -
-The asynchronous I/O code encountered an error when trying read data from -the specified address on the given protocol. The the number of the system +
+The asynchronous I/O code encountered an error when trying to read data from +the specified address on the given protocol. The number of the system error that cause the problem is given in the message. -
+
An upstream fetch from the specified address timed out. This may happen for any number of reasons and is most probably a problem at the remote server or a problem on the network. The message will only appear if debug is enabled. -
+
The asynchronous I/O code encountered an error when trying send data to the specified address on the given protocol. The the number of the system error that cause the problem is given in the message. -
-This message should not appear and indicates an internal error if it does. -Please enter a bug report. -
-The termination method of the resolver's upstream fetch class was called with -an unknown result code (which is given in the message). This message should -not appear and may indicate an internal error. Please enter a bug report. +
+An internal consistency check on the origin of a message from the +asynchronous I/O module failed. This may indicate an internal error; +please submit a bug report. +
+An internal error indicating that the termination method of the resolver's +upstream fetch class was called with an unknown result code (which is +given in the message). Please submit a bug report. +
+This is a debug message produced by the authoritative server when it +has encountered an error processing an AXFR request. The message gives +the reason for the error, and the server will return a SERVFAIL code to +the sender. +
+This is a debug message output when the authoritative server has received +an AXFR query over UDP. Use of UDP for AXFRs is not permitted by the +protocol, so the server will return a FORMERR error to the sender. +
+Execution of the specified command by the authoritative server failed. The +message contains the reason for the failure. +
+This is a debug message indicating that authoritative server has created +the channel to the configuration manager. It is issued during server +startup is an indication that the initialization is proceeding normally. +
+This is a debug message indicating that authoritative server +has established communication the configuration manager over the +previously-created channel. It is issued during server startup is an +indication that the initialization is proceeding normally. +
+This is a debug message, issued when the authoritative server has +posted a request to be notified when new configuration information is +available. It is issued during server startup is an indication that +the initialization is proceeding normally. +
+An attempt to configure the server with information from the configuration +database during the startup sequence has failed. (The reason for +the failure is given in the message.) The server will continue its +initialization although it may not be configured in the desired way. +
+At attempt to update the configuration the server with information +from the configuration database has failed, the reason being given in +the message. +
+This is a debug message produced by the authoritative server when it accesses a +datebase data source, listing the file that is being accessed. +
+This is a debug message indicating that the component that will handling +incoming queries for the authoritiative server (DNSServices) has been +successfully created. It is issued during server startup is an indication +that the initialization is proceeding normally. +
+This is a debug message, generated by the authoritative server when an +attempt to parse the header of a received DNS packet has failed. (The +reason for the failure is given in the message.) The server will drop the +packet. +
+This is a debug message indicating that the authoritiative server +has requested the keyring holding TSIG keys from the configuration +database. It is issued during server startup is an indication that the +initialization is proceeding normally. +
+This debug message is issued during the processing of the 'loadzone' command +when the authoritative server has successfully loaded the named zone of the +named class. +
+This is a debug message reporting that the authoritative server has +discovered that the memory data source is disabled for the given class. +
+This is a debug message reporting that the authoritative server has +discovered that the memory data source is enabled for the given class. +
+This debug message is logged by the authoritative server when it receives +a NOTIFY packet that contains zero or more than one question. (A valid +NOTIFY packet contains one question.) The server will return a FORMERR +error to the sender. +
+This debug message is logged by the authoritative server when it receives +a NOTIFY packet that an RR type of something other than SOA in the +question section. (The RR type received is included in the message.) The +server will return a FORMERR error to the sender. +
+The authoritative server had no session with the statistics module at the +time it attempted to send it data: the attempt has been abandoned. This +could be an error in configuration. +
+This is a debug message produced by the authoritative server when it receives +a NOTIFY packet but the XFRIN process is not running. The packet will be +dropped and nothing returned to the sender. +
+This is a debug message, generated by the authoritative server when an +attempt to parse a received DNS packet has failed due to something other +than a protocol error. The reason for the failure is given in the message; +the server will return a SERVFAIL error code to the sender. +
+This is a debug message, generated by the authoritative server when an +attempt to parse a received DNS packet has failed due to a protocol error. +The reason for the failure is given in the message, as is the error code +that will be returned to the sender. +
+This is a debug message output by the authoritative server when it +receives a valid DNS packet. +
+Note: This message includes the packet received, rendered in the form of +multiple lines of text. For this reason, it is suggested that this log message +not be routed to the syslog file, where the multiple lines could confuse +programs that expect a format of one message per line. +
+This message is generated by the authoritative server when it has +encountered an internal error whilst processing a received packet: +the cause of the error is included in the message. +
+The server will return a SERVFAIL error code to the sender of the packet. +However, this message indicates a potential error in the server. +Please open a bug ticket for this issue. +
+This is a debug message issued when the authoritative server has received +a command on the command channel. +
+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. +
+This is a debug message, this is output if the authoritative server +receives a DNS packet with the QR bit set, i.e. a DNS response. The +server ignores the packet as it only responds to question packets. +
+This is a debug message recording that the authoritative server is sending +an error response to the originator of the query. A previous message will +have recorded details of the failure. +
+Note: This message includes the packet sent, rendered in the form of +multiple lines of text. For this reason, it is suggested that this log message +not be routed to the syslog file, where the multiple lines could confuse +programs that expect a format of one message per line. +
+This is a debug message recording that the authoritative server is sending +a response to the originator of a query. +
+Note: This message includes the packet sent, rendered in the form of +multiple lines of text. For this reason, it is suggested that this log message +not be routed to the syslog file, where the multiple lines could confuse +programs that expect a format of one message per line. +
+An informational message indicating that the authoritative server process has +been created and is initializing. The AUTH_SERVER_STARTED message will be +output when initialization has successfully completed and the server starts +accepting queries. +
+The authoritative server has encountered a fatal error and is terminating. The +reason for the failure is included in the message. +
+Initialization of the authoritative server has completed successfully +and it is entering the main loop, waiting for queries to arrive. +
+This is a debug message indicating that the authoritative server has +found that the data source it is loading is an SQLite3 data source, +so no further validation is needed. +
+This is a debug message indicating that the authoritative server has +created a channel to the statistics process. It is issued during server +startup is an indication that the initialization is proceeding normally. +
+This is a debug message indicating that the authoritative server +has established communication over the previously created statistics +channel. It is issued during server startup is an indication that the +initialization is proceeding normally. +
+An error was encountered when the authoritiative server tried to send data +to the statistics daemon. The message includes additional information +describing the reason for the failure. +
+The authoritative server sent data to the statistics daemon but received +no acknowledgement within the specified time. The message includes +additional information describing the reason for the failure. +
+This is a debug message indicating that the statistics timer has been +disabled in the authoritative server and no statistics information is +being produced. +
+This is a debug message indicating that the statistics timer has been +enabled and that the authoritative server will produce statistics data +at the specified interval. +
+This is a debug message, produced when a received DNS packet being +processed by the authoritative server has been found to contain an +unsupported opcode. (The opcode is included in the message.) The server +will return an error code of NOTIMPL to the sender. +
+This is a debug message indicating that the authoritative server has +created a channel to the XFRIN (Transfer-in) process. It is issued +during server startup is an indication that the initialization is +proceeding normally. +
+This is a debug message indicating that the authoritative server has +established communication over the previously-created channel to the +XFRIN (Transfer-in) process. It is issued during server startup is an +indication that the initialization is proceeding normally. +
+This is a debug message output during the processing of a NOTIFY request. +An error (listed in the message) has been encountered whilst communicating +with the zone manager. The NOTIFY request will not be honored. +
+This is a debug message output during the processing of a NOTIFY +request. The zone manager component has been informed of the request, +but has returned an error response (which is included in the message). The +NOTIFY request will not be honored. +
+This marks a low level error, we tried to read data from the message queue +daemon asynchronously, but the ASIO library returned an error. +
+It is impossible to reach the message queue daemon for the reason given. It +is unlikely there'll be reason for whatever program this currently is to +continue running, as the communication with the rest of BIND 10 is vital +for the components. +
+The library is disconnecting from the message queue daemon. This debug message +indicates that the program is trying to shut down gracefully. +
+This debug message indicates that the command channel library is about to +connect to the message queue daemon, which should be listening on the UNIX-domain +socket listed in the output. +
+This debug message indicates that the connection was successfully made, this +should follow CC_ESTABLISH. +
+Debug message, noting that a message is expected to come over the command +channel. +
+Debug message, noting that we successfully received a message (its envelope and +payload listed). This follows CC_GROUP_RECEIVE, but might happen some time +later, depending if we waited for it or just polled. +
+Debug message, we're about to send a message over the command channel. +
+This happens when garbage comes over the command channel or some kind of +confusion happens in the program. The data received from the socket make no +sense if we interpret it as lengths of message. The first one is total length +of message, the second length of the header. The header and it's length +(2 bytes) is counted in the total length. +
+There should be data representing length of message on the socket, but it +is not there. +
+The program polled for incoming messages, but there was no message waiting. +This is a debug message which may happen only after CC_GROUP_RECEIVE. +
+It isn't possible to connect to the message queue daemon, for reason listed. +It is unlikely any program will be able continue without the communication. +
+A low level error happened when the library tried to read data from the +command channel socket. The reason is listed. +
+We received an exception while trying to read data from the command +channel socket. The reason is listed. +
+Debug message, noting we're sending a response to the original message +with the given envelope. +
+Debug message. A timeout for which the program is willing to wait for a reply +is being set. +
+Debug message. From now on, when a message (or command) comes, it'll wake the +program and the library will automatically pass it over to correct place. +
+Debug message. The program wants to receive messages addressed to this group. +
+The program waited too long for data from the command channel (usually when it +sent a query to different program and it didn't answer for whatever reason). +
+Debug message. The program no longer wants to receive messages addressed to +this group. +
+A low level error happened when the library tried to write data to the command +channel socket. +
+The library received a message length being zero, which makes no sense, since +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. +
+The configuration manager daemon was unable to connect to the messaging +system. The most likely cause is that msgq is not running. +
+There was a problem reading the persistent configuration data as stored +on disk. The file may be corrupted, or it is of a version from where +there is no automatic upgrade path. The file needs to be repaired or +removed. The configuration manager daemon will now shut down. +
+There was an IO error from the system while the configuration manager +was trying to write the configuration database to disk. The specific +error is given. The most likely cause is that the directory where +the file is stored does not exist, or is not writable. The updated +configuration is not stored. +
+There was an OS error from the system while the configuration manager +was trying to write the configuration database to disk. The specific +error is given. The most likely cause is that the system does not have +write access to the configuration database file. The updated +configuration is not stored. +
+There was a keyboard interrupt signal to stop the cfgmgr daemon. The +daemon will now shut down.
There was a problem with an incoming message on the command and control channel. The message does not appear to be a valid command, and is @@ -65,33 +364,36 @@ missing a required element or contains an unknown data format. This most likely means that another BIND10 module is sending a bad message. The message itself is ignored by this module.
-There was an internal problem handling an incoming message on the -command and control channel. An unexpected exception was thrown. This -most likely points to an internal inconsistency in the module code. The -exception message is appended to the log error, and the module will -continue to run, but will not send back an answer. -
-There was an error opening the given file. -
-There was a parse error in the JSON file. The given file does not appear -to be in valid JSON format. Please verify that the filename is correct -and that the contents are valid JSON. -
+There was an internal problem handling an incoming message on the command +and control channel. An unexpected exception was thrown, details of +which are appended to the message. The module will continue to run, +but will not send back an answer. +
+The most likely cause of this error is a programming error. Please raise +a bug report. +
The configuration manager returned an error when this module requested the configuration. The full error message answer from the configuration manager is appended to the log error. The most likely cause is that the module is of a different (command specification) version than the running configuration manager. -
-The module specification file for this module was rejected by the -configuration manager. The full error message answer from the -configuration manager is appended to the log error. The most likely -cause is that the module is of a different (specification file) version -than the running configuration manager. -
-The given file does not appear to be a valid specification file. Please -verify that the filename is correct and that its contents are a valid -BIND10 module specification. +
+There was an error parsing the JSON file. The given file does not appear +to be in valid JSON format. Please verify that the filename is correct +and that the contents are valid JSON. +
+The given file does not appear to be a valid specification file: details +are included in the message. Please verify that the filename is correct +and that its contents are a valid BIND10 module specification. +
+The specification file for this module was rejected by the configuration +manager. The full error message answer from the configuration manager is +appended to the log error. The most likely cause is that the module is of +a different (specification file) version than the running configuration +manager. +
+There was an error opening the given file. The reason for the failure +is included in the message.
Debug information that the hotspot cache was created at startup.
@@ -146,7 +448,7 @@ Debug information. The requested domain is an alias to a different domain, returning the CNAME instead.
This is the same problem as in MEM_CNAME_TO_NONEMPTY, but it happened the -other way around -- adding some outher data to CNAME. +other way around -- adding some other data to CNAME.
Someone or something tried to add a CNAME into a domain that already contains some other data. But the protocol forbids coexistence of CNAME with anything @@ -164,7 +466,7 @@ encountered on the way. This may lead to redirection to a different domain and stop the search.
Debug information. A DNAME was found instead of the requested information. -
+
It was requested for DNAME and NS records to be put into the same domain which is not the apex (the top of the zone). This is forbidden by RFC 2672, section 3. This indicates a problem with provided data. @@ -222,12 +524,12 @@ destroyed. Debug information. A domain above wildcard was reached, but there's something below the requested domain. Therefore the wildcard doesn't apply here. This behaviour is specified by RFC 1034, section 4.3.3 -
+
The software refuses to load DNAME records into a wildcard domain. It isn't explicitly forbidden, but the protocol is ambiguous about how this should behave and BIND 9 refuses that as well. Please describe your intention using different tools. -
+
The software refuses to load NS records into a wildcard domain. It isn't explicitly forbidden, but the protocol is ambiguous about how this should behave and BIND 9 refuses that as well. Please describe your intention using @@ -269,7 +571,7 @@ response message.
Debug information. The software is trying to identify delegation points on the way down to the given domain. -
+
There was an CNAME and it was being followed. But it contains no records, so there's nowhere to go. There will be no answer. This indicates a problem with supplied data. @@ -363,7 +665,7 @@ DNAMEs will be synthesized.
The query subtask failed. The reason should have been reported by the subtask already. The code is 1 for error, 2 for not implemented. -
+
A CNAME led to another CNAME and it led to another, and so on. After 16 CNAMEs, the software gave up. Long CNAME chains are discouraged, and this might possibly be a loop as well. Note that some of the CNAMEs might have @@ -385,15 +687,15 @@ 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.
Debug information. The SQLite data source is closing the database file. -
+
Debug information. An instance of SQLite data source is being created. -
+
Debug information. An instance of SQLite data source is being destroyed.
-Debug information. The SQLite data source is trying to identify, which zone +Debug information. The SQLite data source is trying to identify which zone should hold this domain.
-Debug information. The last SQLITE_ENCLOSURE query was unsuccessful, there's +Debug information. The last SQLITE_ENCLOSURE query was unsuccessful; there's no such zone in our data.
Debug information. The SQLite data source is looking up a resource record @@ -417,7 +719,7 @@ and type in the database. Debug information. The SQLite data source is identifying if this domain is a referral and where it goes.
-The SQLite data source was trying to identify, if there's a referral. But +The SQLite data source was trying to identify if there's a referral. But it contains different class than the query was for.
The SQLite data source was looking up an RRset, but the data source contains @@ -452,142 +754,173 @@ data source.
This indicates a programming error. An internal task of unknown type was generated. -
-A message from the underlying logger implementation code, the debug level -(as set by the string DEBGUGn) is above the maximum allowed value and has -been reduced to that value. -
-The string indicating the extended logging level (used by the underlying -logger implementation code) is not of the stated form. In particular, -it starts DEBUG but does not end with an integer. -
-A message from the underlying logger implementation code, the debug level -(as set by the string DEBGUGn) is below the minimum allowed value and has -been increased to that value. -
+
+A message from the interface to the underlying logger implementation reporting +that the debug level (as set by an internally-created string DEBUGn, where n +is an integer, e.g. DEBUG22) is above the maximum allowed value and has +been reduced to that value. The appearance of this message may indicate +a programming error - please submit a bug report. +
+A message from the interface to the underlying logger implementation +reporting that an internally-created string used to set the debug level +is not of the correct format (it should be of the form DEBUGn, where n +is an integer, e.g. DEBUG22). The appearance of this message indicates +a programming error - please submit a bug report. +
+A message from the interface to the underlying logger implementation reporting +that the debug level (as set by an internally-created string DEBUGn, where n +is an integer, e.g. DEBUG22) is below the minimum allowed value and has +been increased to that value. The appearance of this message may indicate +a programming error - please submit a bug report. +
A logger destination value was given that was not recognized. The destination should be one of "console", "file", or "syslog". -
+
A logger severity value was given that was not recognized. The severity should be one of "DEBUG", "INFO", "WARN", "ERROR", or "FATAL". -
-A log console output stream was given that was not recognized. The -output stream should be one of "stdout", or "stderr" -
-When reading a message file, more than one $NAMESPACE directive was found. In -this version of the code, such a condition is regarded as an error and the -read will be abandoned. -
-Indicative of a programming error, when it started up, BIND10 detected that -the given message ID had been registered by one or more modules. (All message -IDs should be unique throughout BIND10.) This has no impact on the operation -of the server other that erroneous messages may be logged. (When BIND10 loads -the message IDs (and their associated text), if a duplicate ID is found it is -discarded. However, when the module that supplied the duplicate ID logs that -particular message, the text supplied by the module that added the original -ID will be output - something that may bear no relation to the condition being -logged. -
-During start-up a local message file was read. A line with the listed -message identification was found in the file, but the identification is not -one contained in the compiled-in message dictionary. Either the message -identification has been mis-spelled in the file, or the local file was used -for an earlier version of the software and the message with that -identification has been removed. +
+A log console output stream was given that was not recognized. The output +stream should be one of "stdout", or "stderr" +
+During start-up, BIND10 detected that the given message identification had +been defined multiple times in the BIND10 code.
-This message may appear a number of times in the file, once for every such -unknown message identification. -
-The concatenation of the prefix and the message identification is used as -a symbol in the C++ module; as such it may only contain -
-Message definition lines are lines starting with a "%". The rest of the line -should comprise the message ID and text describing the message. This error -indicates the message compiler found a line in the message file comprising -just the "%" and nothing else. -
-Message definition lines are lines starting with a "%". The rest of the line -should comprise the message ID and text describing the message. This error -is generated when a line is found in the message file that contains the -leading "%" and the message identification but no text. -
-The $NAMESPACE directive takes a single argument, a namespace in which all the -generated symbol names are placed. This error is generated when the -compiler finds a $NAMESPACE directive with more than one argument. -
-The $NAMESPACE argument should be a valid C++ namespace. The reader does a -cursory check on its validity, checking that the characters in the namespace -are correct. The error is generated when the reader finds an invalid -character. (Valid are alphanumeric characters, underscores and colons.) -
-The $NAMESPACE directive takes a single argument, a namespace in which all the -generated symbol names are placed. This error is generated when the -compiler finds a $NAMESPACE directive with no arguments. -
-The program was not able to open the specified input message file for the -reason given. -
-The program was not able to open the specified output file for the reason -given. -
-The $PREFIX directive takes a single argument, a prefix to be added to the -symbol names when a C++ .h file is created. This error is generated when the -compiler finds a $PREFIX directive with more than one argument. -
-The $PREFIX argument is used in a symbol name in a C++ header file. As such, -it must adhere to restrictions on C++ symbol names (e.g. may only contain -alphanumeric characters or underscores, and may nor start with a digit). -A $PREFIX directive was found with an argument (given in the message) that -violates those restictions. -
-This is an informational message output by BIND10 when it starts to read a -local message file. (A local message file may replace the text of one of more -messages; the ID of the message will not be changed though.) -
+This has no ill-effects other than the possibility that an erronous +message may be logged. However, as it is indicative of a programming +error, please log a bug report. +
+When reading a message file, more than one $NAMESPACE directive was found. +Such a condition is regarded as an error and the read will be abandoned. +
+The program was not able to open the specified input message file for +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. +
+The $NAMESPACE directive in a message file takes a single argument, a +namespace in which all the generated symbol names are placed. This error +is generated when the compiler finds a $NAMESPACE directive with more +than one argument. +
+The $NAMESPACE argument in a message file should be a valid C++ namespace. +This message is output if the simple check on the syntax of the string +carried out by the reader fails. +
+The $NAMESPACE directive in a message file takes a single argument, +a C++ namespace in which all the generated symbol names are placed. +This error is generated when the compiler finds a $NAMESPACE directive +with no arguments. +
+Within a message file, message are defined by lines starting with a "%". +The rest of the line should comprise the message ID and text describing +the message. This error indicates the message compiler found a line in +the message file comprising just the "%" and nothing else. +
+Within a message file, message are defined by lines starting with a "%". +The rest of the line should comprise the message ID and text describing +the message. This error indicates the message compiler found a line +in the message file comprising just the "%" and message identification, +but no text. +
+During start-up a local message file was read. A line with the listed +message identification was found in the file, but the identification is +not one contained in the compiled-in message dictionary. This message +may appear a number of times in the file, once for every such unknown +message identification. +
+There may be several reasons why this message may appear: +
+- The message ID has been mis-spelled in the local message file. +
+- The program outputting the message may not use that particular message +(e.g. it originates in a module not used by the program.) +
+- The local file was written for an earlier version of the BIND10 software +and the later version no longer generates that message. +
+Whatever the reason, there is no impact on the operation of BIND10. +
+Originating within the logging code, the program was not able to open +the specified output file for the reason given. +
+Within a message file, the $PREFIX directive takes a single argument, +a prefix to be added to the symbol names when a C++ file is created. +This error is generated when the compiler finds a $PREFIX directive with +more than one argument. +
+Note: the $PREFIX directive is deprecated and will be removed in a future +version of BIND10. +
+Within a message file, the $PREFIX directive takes a single argument, +a prefix to be added to the symbol names when a C++ file is created. +As such, it must adhere to restrictions on C++ symbol names (e.g. may +only contain alphanumeric characters or underscores, and may nor start +with a digit). A $PREFIX directive was found with an argument (given +in the message) that violates those restictions. +
+Note: the $PREFIX directive is deprecated and will be removed in a future +version of BIND10. +
+This is an informational message output by BIND10 when it starts to read +a local message file. (A local message file may replace the text of +one of more messages; the ID of the message will not be changed though.) +
The specified error was encountered reading from the named message file. -
-A line starting with a dollar symbol was found, but the first word on the line -(shown in the message) was not a recognised message compiler directive. -
-The specified error was encountered by the message compiler when writing to -the named output file. -
-This message indicates an internal error in the nameserver address store -component (NSAS) of the resolver. The NSAS made a query for a RR for the -specified nameserver but received an invalid response. Either the success -function was called without a DNS message or the message was invalid on some -way. (In the latter case, the error should have been picked up elsewhere in -the processing logic, hence the raising of the error here.) -
-This message indicates an internal error in the nameserver address store -component (NSAS) of the resolver. The NSAS made a query for the given RR -type and class, but instead received an answer with the given type and class. -
-A debug message, this is output when a NSAS (nameserver address store - -part of the resolver) lookup for a zone has been cancelled. -
-A debug message, this is output when a call is made to the nameserver address -store (part of the resolver) to obtain the nameservers for the specified zone. -
-A debug message, the NSAS (nameserver address store - part of the resolver) is -making a callback into the resolver to retrieve the address records for the -specified nameserver. -
-A debug message, the NSAS (nameserver address store - part of the resolver) -has been unable to retrieve the specified resource record for the specified -nameserver. This is not necessarily a problem - the nameserver may be -unreachable, in which case the NSAS will try other nameservers in the zone. -
-A debug message, the NSAS (nameserver address store - part of the resolver) -has retrieved the given address for the specified nameserver through an -external query. -
+
+Within a message file, a line starting with a dollar symbol was found +(indicating the presence of a directive) but the first word on the line +(shown in the message) was not recognised. +
+The specified error was encountered by the message compiler when writing +to the named output file. +
+A debug message issued when the NSAS (nameserver address store - part +of the resolver) is making a callback into the resolver to retrieve the +address records for the specified nameserver. +
+A debug message issued when the NSAS (nameserver address store - part +of the resolver) has retrieved the given address for the specified +nameserver through an external query. +
+The NSAS (nameserver address store - part of the resolver) made a query +for a RR for the specified nameserver but received an invalid response. +Either the success function was called without a DNS message or the +message was invalid on some way. (In the latter case, the error should +have been picked up elsewhere in the processing logic, hence the raising +of the error here.) +
+This message indicates an internal error in the NSAS. Please raise a +bug report. +
+A debug message issued when an NSAS (nameserver address store - part of +the resolver) lookup for a zone has been canceled. +
+A debug message issued when the NSAS (nameserver address store - part of +the resolver) has been unable to retrieve the specified resource record +for the specified nameserver. This is not necessarily a problem - the +nameserver may be unreachable, in which case the NSAS will try other +nameservers in the zone. +
+A debug message output when a call is made to the NSAS (nameserver +address store - part of the resolver) to obtain the nameservers for +the specified zone. +
A NSAS (nameserver address store - part of the resolver) debug message -reporting the round-trip time (RTT) for a query made to the specified -nameserver. The RTT has been updated using the value given and the new RTT is -displayed. (The RTT is subject to a calculation that damps out sudden -changes. As a result, the new RTT is not necessarily equal to the RTT -reported.) +reporting the update of a round-trip time (RTT) for a query made to the +specified nameserver. The RTT has been updated using the value given +and the new RTT is displayed. (The RTT is subject to a calculation that +damps out sudden changes. As a result, the new RTT used by the NSAS in +future decisions of which nameserver to use is not necessarily equal to +the RTT reported.) +
+A NSAS (nameserver address store - part of the resolver) made a query for +a resource record of a particular type and class, but instead received +an answer with a different given type and class. +
+This message indicates an internal error in the NSAS. Please raise a +bug report.
A debug message recording that an answer has been received to an upstream query for the specified question. Previous debug messages will have indicated @@ -599,95 +932,95 @@ the server to which the question was sent.
A debug message, a cache lookup did not find the specified <name, class, type> tuple in the cache; instead, the deepest delegation found is indicated. -
+
A debug message, a CNAME response was received and another query is being issued for the <name, class, type> tuple. -
+
A debug message recording that a CNAME response has been received to an upstream query for the specified question (Previous debug messages will have indicated the server to which the question was sent). However, receipt of this CNAME has meant that the resolver has exceeded the CNAME chain limit (a CNAME chain is where on CNAME points to another) and so an error is being returned. -
+
A debug message, this indicates that a response was received for the specified -query and was categorised as a referral. However, the received message did +query and was categorized as a referral. However, the received message did not contain any NS RRsets. This may indicate a programming error in the response classification code. -
+
A debug message, the RunningQuery object is querying the NSAS for the nameservers for the specified zone. -
+
A debug message recording that either a NXDOMAIN or an NXRRSET response has been received to an upstream query for the specified question. Previous debug messages will have indicated the server to which the question was sent.
A debug message indicating that a protocol error was received. As there are no retries left, an error will be reported. -
+
A debug message indicating that a protocol error was received and that the resolver is repeating the query to the same nameserver. After this repeated query, there will be the indicated number of retries left. -
+
A debug message, the response to the specified query indicated an error that is not covered by a specific code path. A SERVFAIL will be returned. -
-A debug message recording that a referral response has been received to an -upstream query for the specified question. Previous debug messages will -have indicated the server to which the question was sent. -
-A debug message indicating that the last referral message was to the specified -zone. -
+
This is a debug message and indicates that a RecursiveQuery object found the the specified <name, class, type> tuple in the cache. The instance number at the end of the message indicates which of the two resolve() methods has been called. -
+
This is a debug message and indicates that the look in the cache made by the RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery object has been created to resolve the question. The instance number at the end of the message indicates which of the two resolve() methods has been called. +
+A debug message recording that a referral response has been received to an +upstream query for the specified question. Previous debug messages will +have indicated the server to which the question was sent. +
+A debug message indicating that the last referral message was to the specified +zone.
A debug message, the RecursiveQuery::resolve method has been called to resolve the specified <name, class, type> tuple. The first action will be to lookup the specified tuple in the cache. The instance number at the end of the message indicates which of the two resolve() methods has been called. -
+
A debug message, indicating that when RecursiveQuery::resolve queried the cache, a single RRset was found which was put in the answer. The instance number at the end of the message indicates which of the two resolve() methods has been called.
A debug message giving the round-trip time of the last query and response. -
+
This is a debug message and indicates that a RunningQuery object found the specified <name, class, type> tuple in the cache. -
+
This is a debug message and indicates that a RunningQuery object has made a call to its doLookup() method to look up the specified <name, class, type> tuple, the first action of which will be to examine the cache. -
+
A debug message indicating that a RunningQuery's failure callback has been called because all nameservers for the zone in question are unreachable. -
+
A debug message indicating that a RunningQuery's success callback has been called because a nameserver has been found, and that a query is being sent to the specified nameserver. -
+
This is an internal debugging message and is only generated in unit tests. It indicates that all upstream queries from the resolver are being routed to the specified server, regardless of the address of the nameserver to which the query would normally be routed. As it should never be seen in normal operation, it is a warning message instead of a debug message. -
+
This is a debug message and should only be seen in unit tests. A query for the specified <name, class, type> tuple is being sent to a test nameserver whose address is given in the message.
A debug message indicating that the specified query has timed out and as there are no retries left, an error will be reported. -
+
A debug message indicating that the specified query has timed out and that the resolver is repeating the query to the same nameserver. After this repeated query, there will be the indicated number of retries left. @@ -699,118 +1032,134 @@ gives no cause for concern.
A debug message indicating that a query for the specified <name, class, type> tuple is being sent to a nameserver whose address is given in the message. -
+
A debug message, the resolver received a NOTIFY message over TCP. The server cannot process it and will return an error message to the sender with the RCODE set to NOTIMP. -
+
A debug message, the resolver received a NOTIFY message over UDP. The server cannot process it (and in any case, an AXFR request should be sent over TCP) and will return an error message to the sender with the RCODE set to FORMERR. -
+
An error indicating that the configuration value specified for the query timeout is too small. -
+
A debug message, output when the resolver has successfully established a connection to the configuration channel. -
+
An error was detected in a configuration update received by the resolver. This may be in the format of the configuration message (in which case this is a programming error) or it may be in the data supplied (in which case it is a user error). The reason for the error, given as a parameter in the message, will give more details. -
+
A debug message, output when the resolver configuration has been successfully loaded. -
+
A debug message, the configuration has been updated with the specified information.
A debug message, output when the Resolver() object has been created. -
+
A debug message, this always precedes some other logging message and is the formatted contents of the DNS packet that the other message refers to. -
+
A debug message, this contains details of the response sent back to the querying system.
This is an error message output when an unhandled exception is caught by the resolver. All it can do is to shut down. -
+
This message may appear multiple times during startup, and it lists the forward addresses used by the resolver when running in forwarding mode. -
+
The received query has passed all checks and is being forwarded to upstream servers. -
+
A debug message noting that an exception occurred during the processing of a received packet. The packet has been dropped.
The resolver received a NOTIFY message over TCP. The server cannot process it and will return an error message to the sender with the RCODE set to NOTIMP. -
+
An error indicating that the configuration value specified for the lookup timeout is too small. -
-The resolver received a NOTIFY message. As the server is not authoritative it -cannot process it, so it returns an error message to the sender with the RCODE -set to NOTAUTH. -
-The received query has passed all checks and is being processed by the resolver. -
-A warning message during startup, indicates that no root addresses have been -set. This may be because the resolver will get them from a priming query. -
+
+A debug message noting that the resolver received a message and the +parsing of the body of the message failed due to some error (although +the parsing of the header succeeded). The message parameters give a +textual description of the problem and the RCODE returned. +
+An error message indicating that the resolver configuration has specified a +negative retry count. Only zero or positive values are valid. +
A debug message, the resolver has received a DNS packet that was not IN class. The resolver cannot handle such packets, so is returning a REFUSED response to the sender. -
+
+The received query has passed all checks and is being processed by the resolver. +
+The resolver received a NOTIFY message. As the server is not authoritative it +cannot process it, so it returns an error message to the sender with the RCODE +set to NOTAUTH. +
A debug message, the resolver received a query that contained the number of entires in the question section detailed in the message. This is a malformed message, as a DNS query must contain only one question. The resolver will return a message to the sender with the RCODE set to FORMERR. -
-A debug message, the resolver received a message with an unsupported opcode -(it can only process QUERY opcodes). It will return a message to the sender -with the RCODE set to NOTIMP. -
+
+A warning message during startup, indicates that no root addresses have been +set. This may be because the resolver will get them from a priming query. +
A debug message noting that the resolver received a message and the parsing of the body of the message failed due to some non-protocol related reason (although the parsing of the header succeeded). The message parameters give a textual description of the problem and the RCODE returned. -
+
This message is logged when a "print_message" command is received over the command channel. -
+
A debug message noting that the resolver received a message and the parsing of the body of the message failed due to some protocol error (although the parsing of the header succeeded). The message parameters give a textual description of the problem and the RCODE returned. -
+
+A debug message that indicates an incoming query is accepted in terms of +the query ACL. The log message shows the query in the form of +<query name>/<query type>/<query class>, and the client that sends the +query in the form of <Source IP address>#<source port>. +
+An informational message that indicates an incoming query is dropped +in terms of the query ACL. Unlike the RESOLVER_QUERY_REJECTED +case, the server does not return any response. The log message +shows the query in the form of <query name>/<query type>/<query +class>, and the client that sends the query in the form of <Source +IP address>#<source port>. +
+An informational message that indicates an incoming query is rejected +in terms of the query ACL. This results in a response with an RCODE of +REFUSED. The log message shows the query in the form of <query +name>/<query type>/<query class>, and the client that sends the +query in the form of <Source IP address>#<source port>. +
A debug message noting that the resolver is creating a RecursiveQuery object. -
+
A debug message noting that the resolver is destroying a RecursiveQuery object. -
+
An error indicating that the configuration value specified for the query timeout is too small. -
-This is an informational message that appears at startup noting that the -resolver is running in recursive mode. -
+
A debug message indicating that the resolver has received a message. Depending on the debug settings, subsequent log output will indicate the nature of the message. -
-An error message indicating that the resolver configuration has specified a -negative retry count. Only zero or positive values are valid. -
-This message may appear multiple times during startup; it lists the root -addresses used by the resolver. -
+
+This is an informational message that appears at startup noting that the +resolver is running in recursive mode. +
A debug message, output when the main service object (which handles the received queries) is created. -
-A debug message, lists the parameters associated with the message. These are: +
+A debug message, lists the parameters being set for the resolver. These are: query timeout: the timeout (in ms) used for queries originated by the resolver to upstream servers. Client timeout: the interval to resolver a query by a client: after this time, the resolver sends back a SERVFAIL to the client @@ -819,14 +1168,20 @@ resolver gives up trying to resolve a query. Retry count: the number of times the resolver will retry a query to an upstream server if it gets a timeout.
The client and lookup timeouts require a bit more explanation. The -resolution of the clent query might require a large number of queries to +resolution of the client query might require a large number of queries to upstream nameservers. Even if none of these queries timeout, the total time taken to perform all the queries may exceed the client timeout. When this happens, a SERVFAIL is returned to the client, but the resolver continues with the resolution process. Data received is added to the cache. However, -there comes a time - the lookup timeout - when even the resolve gives up. +there comes a time - the lookup timeout - when even the resolver gives up. At this point it will wait for pending upstream queries to complete or timeout and drop the query. +
+A debug message that appears when a new query ACL is configured for the +resolver. +
+This message may appear multiple times during startup; it lists the root +addresses used by the resolver.
This information message is output when the resolver has shut down.
@@ -834,8 +1189,166 @@ This informational message is output by the resolver when all initialization has been completed and it is entering its main loop.
An informational message, this is output when the resolver starts up. -
+
A debug message noting that the server has received a response instead of a query and is ignoring it. +
+A debug message, the resolver received a message with an unsupported opcode +(it can only process QUERY opcodes). It will return a message to the sender +with the RCODE set to NOTIMP. +
+The AXFR transfer for the given zone has failed due to a database problem. +The error is shown in the log message. +
+The AXFR transfer for the given zone has failed due to an internal +problem in the bind10 python wrapper library. +The error is shown in the log message. +
+The AXFR transfer for the given zone has failed due to a protocol error. +The error is shown in the log message. +
+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. +
+The AXFR transfer of the given zone was successfully completed. +
+The given master address is not a valid IP address. +
+The master port as read from the configuration is not a valid port number. +
+The TSIG key string as read from the configuration does not represent +a valid TSIG key. +
+The zone class as read from the configuration is not a valid DNS class. +
+There was a problem reading from the command and control channel. The +most likely cause is that xfrin the msgq daemon is not running. +
+There was an error while the given command was being processed. The +error is given in the log message. +
+There was an error opening a connection to the master. The error is +shown in the log message. +
+There was an error importing the python DNS module pydnspp. The most +likely cause is a PYTHONPATH problem. +
+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. +
+There was a problem sending a message to the zone manager. This most +likely means that the msgq daemon has quit or was killed. +
+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. +
+An informational message, this is output when the resolver starts up. +
+There was a keyboard interrupt signal to stop the xfrin daemon. The +daemon will now shut down. +
+An uncaught exception was raised while running the xfrin daemon. The +exception message is printed in the log message. +
+The transfer of the given zone has been completed successfully, or was +aborted due to a shutdown event. +
+An uncaught exception was encountered while sending the response to +an AXFR query. The error message of the exception is included in the +log message, but this error most likely points to incomplete exception +handling in the code. +
+A transfer out for the given zone failed. An error response is sent +to the client. The given rcode is the rcode that is set in the error +response. This is either NOTAUTH (we are not authoritative for the +zone), SERVFAIL (our internal database is missing the SOA record for +the zone), or REFUSED (the limit of simultaneous outgoing AXFR +transfers, as specified by the configuration value +Xfrout/max_transfers_out, has been reached). +
+A transfer out of the given zone has started. +
+The TSIG key string as read from the configuration does not represent +a valid TSIG key. +
+There was a problem reading from the command and control channel. The +most likely cause is that the msgq daemon is not running. +
+There was a problem reading a response from antoher module over the +command and control channel. The most likely cause is that the +configuration manager b10-cfgmgr is not running. +
+There was a socket error while contacting the b10-auth daemon to +fetch a transfer request. The auth daemon may have shutdown. +
+There was a general error handling an xfrout query. The error is shown +in the message. In principle this error should not appear, and points +to an oversight catching exceptions in the right place. However, to +ensure the daemon keeps running, this error is caught and reported. +
+There was an error importing a python module. One of the modules needed +by xfrout could not be found. This suggests that either some libraries +are missing on the system, or the PYTHONPATH variable is not correct. +The specific place where this library needs to be depends on your +system and your specific installation. +
+New configuration settings have been sent from the configuration +manager. The xfrout daemon will now apply them. +
+The xfrout daemon is now done reading the new configuration settings +received from the configuration manager. +
+The xfrout daemon received a command on the command channel that +NOTIFY packets should be sent for the given zone. +
+There was a parse error while reading an incoming query. The parse +error is shown in the log message. A remote client sent a packet we +do not understand or support. The xfrout request will be ignored. +In general, this should only occur for unexpected problems like +memory allocation failures, as the query should already have been +parsed by the b10-auth daemon, before it was passed here. +
+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. +
+The xfrout daemon received a shutdown command from the command channel +and will now shut down. +
+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. +
+The unix socket file xfrout needs for contact with the auth daemon +already exists, and needs to be removed first, but there is a problem +removing it. It is likely that we do not have permission to remove +this file. The specific error is show in the log message. The xfrout +daemon will shut down. +
+When shutting down, the xfrout daemon tried to clear the unix socket +file used for communication with the auth daemon. It failed to remove +the file. The reason for the failure is given in the error message. +
+There was an error while calling select() on the socket that informs +the xfrout daemon that a new xfrout request has arrived. This should +be a result of rare local error such as memory allocation failure and +shouldn't happen under normal conditions. The error is included in the +log message. +
+There was a keyboard interrupt signal to stop the xfrout daemon. The +daemon will now shut down. +
+The current transfer is aborted, as the xfrout daemon is shutting down. +
+While starting up, the xfrout daemon tried to clear the unix domain +socket needed for contacting the b10-auth daemon to pass requests +on, but the file is in use. The most likely cause is that another +xfrout daemon process is still running. This xfrout daemon (the one +printing this message) will not start.