[master] regenerate log messages and guide documents

doc/guide/bind10-messages.xml

@@ -68,6 +68,22 @@
     <para>
       <variablelist>
 
+<varlistentry id="ASIODNS_FD_ADD_TCP">
+<term>ASIODNS_FD_ADD_TCP adding a new TCP server by opened fd %1</term>
+<listitem><para>
+A debug message informing about installing a file descriptor as a server.
+The file descriptor number is noted.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="ASIODNS_FD_ADD_UDP">
+<term>ASIODNS_FD_ADD_UDP adding a new UDP server by opened fd %1</term>
+<listitem><para>
+A debug message informing about installing a file descriptor as a server.
+The file descriptor number is noted.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="ASIODNS_FETCH_COMPLETED">
 <term>ASIODNS_FETCH_COMPLETED upstream fetch to %1(%2) has now completed</term>
 <listitem><para>
@@ -720,6 +736,16 @@ startup, as described for BIND10_KILLING_ALL_PROCESSES
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="BIND10_LOST_SOCKET_CONSUMER">
+<term>BIND10_LOST_SOCKET_CONSUMER consumer %1 of sockets disconnected, considering all its sockets closed</term>
+<listitem><para>
+A connection from one of the applications which requested a socket was
+closed. This means the application has terminated, so all the sockets it was
+using are now closed and bind10 process can release them as well, unless the
+same sockets are used by yet another application.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="BIND10_MSGQ_ALREADY_RUNNING">
 <term>BIND10_MSGQ_ALREADY_RUNNING msgq daemon already running, cannot start</term>
 <listitem><para>
@@ -739,6 +765,15 @@ inconsistent state of the system, and BIND 10 will now shut down.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="BIND10_NO_SOCKET">
+<term>BIND10_NO_SOCKET couldn't send a socket for token %1 because of error: %2</term>
+<listitem><para>
+An error occurred when the bind10 process was asked to send a socket file
+descriptor. The error is mentioned, most common reason is that the request
+is invalid and may not come from bind10 process at all.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="BIND10_PROCESS_ENDED">
 <term>BIND10_PROCESS_ENDED process %2 of %1 ended with status %3</term>
 <listitem><para>
@@ -1943,7 +1978,7 @@ in the answer as a result.
 </varlistentry>
 
 <varlistentry id="DATASRC_DATABASE_FIND_RECORDS">
-<term>DATASRC_DATABASE_FIND_RECORDS looking in datasource %1 for record %2/%3</term>
+<term>DATASRC_DATABASE_FIND_RECORDS looking in datasource %1 for record %2/%3/%4</term>
 <listitem><para>
 Debug information. The database data source is looking up records with the given
 name and type in the database.
@@ -1960,6 +1995,24 @@ database). The data in database should be checked and fixed.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_FOUND_ANY">
+<term>DATASRC_DATABASE_FOUND_ANY search in datasource %1 resulted in returning all records of %2</term>
+<listitem><para>
+The data returned by the database backend contained data for the given domain
+name, so all the RRsets of the domain are returned.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_FOUND_CNAME">
+<term>DATASRC_DATABASE_FOUND_CNAME search in datasource %1 for %2/%3/%4 found CNAME, resulting in %5</term>
+<listitem><para>
+When searching the domain for a name a CNAME was found at that name.
+Even though it was not the RR type being sought, it is returned.  (The
+caller may want to continue the lookup by replacing the query name with
+the canonical name and restarting the query with the original RR type.)
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_FOUND_DELEGATION">
 <term>DATASRC_DATABASE_FOUND_DELEGATION Found delegation at %2 in %1</term>
 <listitem><para>
@@ -1969,7 +2022,7 @@ at the given domain name. It will return that one instead.
 </varlistentry>
 
 <varlistentry id="DATASRC_DATABASE_FOUND_DELEGATION_EXACT">
-<term>DATASRC_DATABASE_FOUND_DELEGATION_EXACT Found delegation at %2 (exact match) in %1</term>
+<term>DATASRC_DATABASE_FOUND_DELEGATION_EXACT search in datasource %1 for %2/%3/%4 found delegation at %5</term>
 <listitem><para>
 The program found the domain requested, but it is a delegation point to a
 different zone, therefore it is not authoritative for this domain name.
@@ -1989,9 +2042,10 @@ instead.
 <varlistentry id="DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL">
 <term>DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL empty non-terminal %2 in %1</term>
 <listitem><para>
-The domain name doesn't have any RRs, so it doesn't exist in the database.
-However, it has a subdomain, so it exists in the DNS address space. So we
-return NXRRSET instead of NXDOMAIN.
+The domain name does not have any RRs associated with it, so it doesn't
+exist in the database.  However, it has a subdomain, so it does exist
+in the DNS address space. This type of domain is known an an "empty
+non-terminal" and so we return NXRRSET instead of NXDOMAIN.
 </para></listitem>
 </varlistentry>
 
@@ -2004,15 +2058,24 @@ domain name, class and type.
 </varlistentry>
 
 <varlistentry id="DATASRC_DATABASE_FOUND_NXRRSET">
-<term>DATASRC_DATABASE_FOUND_NXRRSET search in datasource %1 resulted in NXRRSET for %2/%3/%4</term>
+<term>DATASRC_DATABASE_FOUND_NXRRSET search in datasource %1 for %2/%3/%4 resulted in NXRRSET</term>
 <listitem><para>
 The data returned by the database backend contained data for the given domain
 name and class, but not for the given type.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_FOUND_NXRRSET_NSEC">
+<term>DATASRC_DATABASE_FOUND_NXRRSET_NSEC search in datasource %1 for %2/%3/%4 resulted in RRset %5</term>
+<listitem><para>
+A search in the database for RRs for the specified name, type and class has
+located RRs that match the name and class but not the type.  DNSSEC information
+has been requested and returned.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_FOUND_RRSET">
-<term>DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %2</term>
+<term>DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %5</term>
 <listitem><para>
 The data returned by the database backend contained data for the given domain
 name, and it either matches the type or has a relevant type. The RRset that is
@@ -2097,6 +2160,14 @@ to find any invalid data and fix it.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_NO_MATCH">
+<term>DATASRC_DATABASE_NO_MATCH not match for %2/%3/%4 in %1</term>
+<listitem><para>
+No match (not even a wildcard) was found in the named data source for the given
+name/type/class in the data source.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_UPDATER_COMMIT">
 <term>DATASRC_DATABASE_UPDATER_COMMIT updates committed for '%1/%2' on %3</term>
 <listitem><para>
@@ -2106,6 +2177,15 @@ its class and the database name are printed.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_UPDATER_COMMIT (1)">
+<term>DATASRC_DATABASE_UPDATER_COMMIT (1) updates committed for '%1/%2' on %3</term>
+<listitem><para>
+Debug information.  A set of updates to a zone has been successfully
+committed to the corresponding database backend.  The zone name,
+its class and the database name are printed.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_UPDATER_CREATED">
 <term>DATASRC_DATABASE_UPDATER_CREATED zone updater created for '%1/%2' on %3</term>
 <listitem><para>
@@ -2114,6 +2194,14 @@ the shown zone on the shown backend database.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_UPDATER_CREATED (1)">
+<term>DATASRC_DATABASE_UPDATER_CREATED (1) zone updater created for '%1/%2' on %3</term>
+<listitem><para>
+Debug information.  A zone updater object is created to make updates to
+the shown zone on the shown backend database.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED">
 <term>DATASRC_DATABASE_UPDATER_DESTROYED zone updater destroyed for '%1/%2' on %3</term>
 <listitem><para>
@@ -2123,6 +2211,15 @@ database.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED (1)">
+<term>DATASRC_DATABASE_UPDATER_DESTROYED (1) zone updater destroyed for '%1/%2' on %3</term>
+<listitem><para>
+Debug information.  A zone updater object is destroyed, either successfully
+or after failure of, making updates to the shown zone on the shown backend
+database.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK">
 <term>DATASRC_DATABASE_UPDATER_ROLLBACK zone updates roll-backed for '%1/%2' on %3</term>
 <listitem><para>
@@ -2135,6 +2232,18 @@ the underlying database name are shown in the log message.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK (1)">
+<term>DATASRC_DATABASE_UPDATER_ROLLBACK (1) zone updates roll-backed for '%1/%2' on %3</term>
+<listitem><para>
+A zone updater is being destroyed without committing the changes.
+This would typically mean the update attempt was aborted due to some
+error, but may also be a bug of the application that forgets committing
+the changes.  The intermediate changes made through the updater won't
+be applied to the underlying database.  The zone name, its class, and
+the underlying database name are shown in the log message.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL">
 <term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL failed to roll back zone updates for '%1/%2' on %3: %4</term>
 <listitem><para>
@@ -2152,16 +2261,34 @@ database module are shown in the log message.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="DATASRC_DATABASE_WILDCARD">
-<term>DATASRC_DATABASE_WILDCARD constructing RRset %3 from wildcard %2 in %1</term>
+<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1)">
+<term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1) failed to roll back zone updates for '%1/%2' on %3: %4</term>
 <listitem><para>
-The database doesn't contain directly matching domain, but it does contain a
-wildcard one which is being used to synthesize the answer.
+A zone updater is being destroyed without committing the changes to
+the database, and attempts to rollback incomplete updates, but it
+unexpectedly fails.  The higher level implementation does not expect
+it to fail, so this means either a serious operational error in the
+underlying data source (such as a system failure of a database) or
+software bug in the underlying data source implementation.  In either
+case if this message is logged the administrator should carefully
+examine the underlying data source to see what exactly happens and
+whether the data is still valid.  The zone name, its class, and the
+underlying database name as well as the error message thrown from the
+database module are shown in the log message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD_ANY">
+<term>DATASRC_DATABASE_WILDCARD_ANY search in datasource %1 resulted in wildcard match type ANY on %2</term>
+<listitem><para>
+The database doesn't contain directly matching name.  When searching
+for a wildcard match, a wildcard record matching the name of the query
+containing some RRsets was found. All the RRsets of the node are returned.
 </para></listitem>
 </varlistentry>
 
 <varlistentry id="DATASRC_DATABASE_WILDCARD_CANCEL_NS">
-<term>DATASRC_DATABASE_WILDCARD_CANCEL_NS canceled wildcard match on %2 because %3 contains NS in %1</term>
+<term>DATASRC_DATABASE_WILDCARD_CANCEL_NS canceled wildcard match on %3 because %2 contains NS (data source %1)</term>
 <listitem><para>
 The database was queried to provide glue data and it didn't find direct match.
 It could create it from given wildcard, but matching wildcards is forbidden
@@ -2180,13 +2307,49 @@ discovers it differently).
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_WILDCARD_CNAME">
+<term>DATASRC_DATABASE_WILDCARD_CNAME search in datasource %1 for %2/%3/%4 found wildcard CNAME at %5, resulting in %6</term>
+<listitem><para>
+The database doesn't contain directly matching name.  When searching
+for a wildcard match, a CNAME RR was found at a wildcard record
+matching the name.  This is returned as the result of the search.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_WILDCARD_EMPTY">
-<term>DATASRC_DATABASE_WILDCARD_EMPTY implicit wildcard %2 used to construct %3 in %1</term>
+<term>DATASRC_DATABASE_WILDCARD_EMPTY found subdomains of %2 which is a wildcard match for %3 in %1</term>
 <listitem><para>
-The given wildcard exists implicitly in the domainspace, as empty nonterminal
-(eg. there's something like subdomain.*.example.org, so *.example.org exists
-implicitly, but is empty). This will produce NXRRSET, because the constructed
-domain is empty as well as the wildcard.
+The given wildcard matches the name being sough but it as an empty
+nonterminal (e.g. there's nothing at *.example.com but something like
+subdomain.*.example.org, do exist: so *.example.org exists in the
+namespace but has no RRs assopciated with it). This will produce NXRRSET.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD_MATCH">
+<term>DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %5 with RRset %6</term>
+<listitem><para>
+The database doesn't contain directly matching name.  When searching
+for a wildcard match, a wildcard record matching the name and type of
+the query was found. The data at this point is returned.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD_NS">
+<term>DATASRC_DATABASE_WILDCARD_NS search in datasource %1 for %2/%3/%4 found wildcard delegation at %5, resulting in %6</term>
+<listitem><para>
+The database doesn't contain directly matching name.  When searching
+for a wildcard match, an NS RR was found at a wildcard record matching
+the name.  This is returned as the result of the search.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD_NXRRSET">
+<term>DATASRC_DATABASE_WILDCARD_NXRRSET search in datasource %1 for %2/%3/%4 resulted in wildcard NXRRSET at %5</term>
+<listitem><para>
+The database doesn't contain directly matching name.  When searching
+for a wildcard match, a matching wildcard entry was found but it did
+not contain RRs the requested type.  AN NXRRSET indication is returned.
 </para></listitem>
 </varlistentry>
 
@@ -2410,7 +2573,7 @@ Debug information. The requested record was found.
 <term>DATASRC_MEM_SUPER_STOP stopped at superdomain '%1', domain '%2' is empty</term>
 <listitem><para>
 Debug information. The search stopped at a superdomain of the requested
-domain. The domain is a empty nonterminal, therefore it is treated  as NXRRSET
+domain. The domain is an empty nonterminal, therefore it is treated  as NXRRSET
 case (eg. the domain exists, but it doesn't have the requested record type).
 </para></listitem>
 </varlistentry>
@@ -3069,12 +3232,98 @@ generated.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DDNS_CC_SESSION_ERROR">
+<term>DDNS_CC_SESSION_ERROR error reading from cc channel: %1</term>
+<listitem><para>
+There was a problem reading from the command and control channel. The
+most likely cause is that the msgq process is not running.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_CC_SESSION_TIMEOUT_ERROR">
+<term>DDNS_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</term>
+<listitem><para>
+There was a problem reading a response from another module over the
+command and control channel. The most likely cause is that the
+configuration manager b10-cfgmgr is not running.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_CONFIG_ERROR">
+<term>DDNS_CONFIG_ERROR error found in configuration data: %1</term>
+<listitem><para>
+The ddns process encountered an error when installing the configuration at
+startup time.  Details of the error are included in the log message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_MODULECC_SESSION_ERROR">
+<term>DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</term>
+<listitem><para>
+There was a problem in the lower level module handling configuration and
+control commands.  This could happen for various reasons, but the most likely
+cause is that the configuration database contains a syntax error and ddns
+failed to start at initialization.  A detailed error message from the module
+will also be displayed.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_RECEIVED_SHUTDOWN_COMMAND">
+<term>DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
+<listitem><para>
+The ddns process received a shutdown command from the command channel
+and will now shut down.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_RUNNING">
+<term>DDNS_RUNNING ddns server is running and listening for updates</term>
+<listitem><para>
+The ddns process has successfully started and is now ready to receive commands
+and updates.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_SHUTDOWN">
+<term>DDNS_SHUTDOWN ddns server shutting down</term>
+<listitem><para>
+The ddns process is shutting down. It will no longer listen for new commands
+or updates. Any command or update that is being addressed at this moment will
+be completed, after which the process will exit.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_STOPPED">
+<term>DDNS_STOPPED ddns server has stopped</term>
+<listitem><para>
+The ddns process has successfully stopped and is no longer listening for or
+handling commands or updates, and will now exit.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_STOPPED_BY_KEYBOARD">
+<term>DDNS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
+<listitem><para>
+There was a keyboard interrupt signal to stop the ddns process. The
+process will now shut down.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DDNS_UNCAUGHT_EXCEPTION">
+<term>DDNS_UNCAUGHT_EXCEPTION uncaught exception of type %1: %2</term>
+<listitem><para>
+The b10-ddns process encountered an uncaught exception and will now shut
+down. This is indicative of a programming error and should not happen under
+normal circumstances. The exception type and message are printed.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="LIBXFRIN_DIFFERENT_TTL">
-<term>LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (%1, %2) on %3/%4. Adjusting %2 -&gt; %1.</term>
+<term>LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (%1, %2) on %3/%4/%5. Adjusting %2 -&gt; %1.</term>
 <listitem><para>
 The xfrin module received an update containing multiple rdata changes for the
 same RRset. But the TTLs of these don't match each other. As we combine them
-together, the later one get's overwritten to the earlier one in the sequence.
+together, the latter one gets overwritten to the earlier one in the sequence.
 </para></listitem>
 </varlistentry>
 
@@ -3476,6 +3725,24 @@ doesn't have an NS RR.  Notify message won't be sent to such a zone.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="NSAS_EMPTY_RESPONSE">
+<term>NSAS_EMPTY_RESPONSE response to query for %1 returned an empty answer section</term>
+<listitem><para>
+The NSAS (nameserver address store - part of the resolver) made a query
+for information it needed.  The query completed successfully but the
+answer section in the response was empty.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="NSAS_ERROR_RESPONSE">
+<term>NSAS_ERROR_RESPONSE error response of %1 returned in query for %2</term>
+<listitem><para>
+The NSAS (nameserver address store - part of the resolver) made a query
+for information it needed.  The query completed successfully but the
+RCODE in the response was something other than NOERROR.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="NSAS_FIND_NS_ADDRESS">
 <term>NSAS_FIND_NS_ADDRESS asking resolver to obtain A and AAAA records for %1</term>
 <listitem><para>
@@ -3494,21 +3761,6 @@ nameserver through an external query.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="NSAS_INVALID_RESPONSE">
-<term>NSAS_INVALID_RESPONSE queried for %1 but got invalid response</term>
-<listitem><para>
-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.)
-</para><para>
-This message indicates an internal error in the NSAS.  Please raise a
-bug report.
-</para></listitem>
-</varlistentry>
-
 <varlistentry id="NSAS_LOOKUP_CANCEL">
 <term>NSAS_LOOKUP_CANCEL lookup for zone %1 has been canceled</term>
 <listitem><para>
@@ -3528,6 +3780,18 @@ nameservers in the zone.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="NSAS_NULL_RESPONSE">
+<term>NSAS_NULL_RESPONSE got null message in success callback for query for %1</term>
+<listitem><para>
+The NSAS (nameserver address store - part of the resolver) made a query
+for information it needed.  The query completed successfully, but the
+message passed to the callback was null.
+</para><para>
+This message indicates an internal error in the NSAS.  Please raise a
+bug report.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="NSAS_SEARCH_ZONE_NS">
 <term>NSAS_SEARCH_ZONE_NS searching NSAS for nameservers for zone %1</term>
 <listitem><para>
@@ -3565,34 +3829,97 @@ bug report.
 <varlistentry id="RESLIB_ANSWER">
 <term>RESLIB_ANSWER answer received in response to query for &lt;%1&gt;</term>
 <listitem><para>
-A debug message recording that an answer has been received to an upstream
-query for the specified question.  Previous debug messages will have indicated
-the server to which the question was sent.
+A debug message reporting that an answer has been received to an upstream
+query for the specified question.  Previous debug messages will have
+indicated the server to which the question was sent.
 </para></listitem>
 </varlistentry>
 
 <varlistentry id="RESLIB_CNAME">
 <term>RESLIB_CNAME CNAME received in response to query for &lt;%1&gt;</term>
 <listitem><para>
-A debug message recording that CNAME response has been received to an upstream
-query for the specified question.  Previous debug messages will have indicated
-the server to which the question was sent.
+A debug message recording that CNAME response has been received to an
+upstream query for the specified question.  Previous debug messages will
+have indicated the server to which the question was sent.
 </para></listitem>
 </varlistentry>
 
 <varlistentry id="RESLIB_DEEPEST">
 <term>RESLIB_DEEPEST did not find &lt;%1&gt; in cache, deepest delegation found is %2</term>
 <listitem><para>
-A debug message, a cache lookup did not find the specified &lt;name, class,
-type&gt; tuple in the cache; instead, the deepest delegation found is indicated.
+A debug message, a cache lookup did not find the specified &lt;name,
+class, type&gt; tuple in the cache; instead, the deepest delegation found
+is indicated.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_EMPTY_RESPONSE">
+<term>RESLIB_EMPTY_RESPONSE empty response received to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver did not contain anything in the answer or authority sections,
+although in all other respects it was a valid response.  A SERVFAIL will
+be returned to the system making the original query.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_ERROR_RESPONSE">
+<term>RESLIB_ERROR_RESPONSE unspecified error received in response to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message, the response to the specified query to an upstream
+nameserver indicated that the response was classified as an erroneous
+response, but that the nature of the error cannot be identified.
+A SERVFAIL will be returned to the system making the original query.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_EXTRADATA_RESPONSE">
+<term>RESLIB_EXTRADATA_RESPONSE extra data in response to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message indicating that the response to the specified query
+from an upstream nameserver contained too much data.  This can happen if
+an ANY query was sent and the answer section in the response contained
+multiple RRs with different names.  A SERVFAIL will be returned to the
+system making the original query.
 </para></listitem>
 </varlistentry>
 
 <varlistentry id="RESLIB_FOLLOW_CNAME">
 <term>RESLIB_FOLLOW_CNAME following CNAME chain to &lt;%1&gt;</term>
 <listitem><para>
-A debug message, a CNAME response was received and another query is being issued
-for the &lt;name, class, type&gt; tuple.
+A debug message, a CNAME response was received and another query is
+being issued for the &lt;name, class, type&gt; tuple.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_INVALID_NAMECLASS_RESPONSE">
+<term>RESLIB_INVALID_NAMECLASS_RESPONSE invalid name or class in response to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver (as identified by the ID of the response) contained either
+an answer not matching the query name or an answer having a different
+class to that queried for.  A SERVFAIL will be returned to the system
+making the original query.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_INVALID_QNAME_RESPONSE">
+<term>RESLIB_INVALID_QNAME_RESPONSE invalid name or class in response to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver (as identified by the ID of the response) contained a name
+in the question section that did not match that of the query. A SERVFAIL
+will be returned to the system making the original query.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_INVALID_TYPE_RESPONSE">
+<term>RESLIB_INVALID_TYPE_RESPONSE invalid name or class in response to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver (as identified by the ID of the response) contained an
+invalid type field. A SERVFAIL will be returned to the system making
+the original query.
 </para></listitem>
 </varlistentry>
 
@@ -3607,6 +3934,46 @@ is where on CNAME points to another) and so an error is being returned.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="RESLIB_MULTIPLE_CLASS_RESPONSE">
+<term>RESLIB_MULTIPLE_CLASS_RESPONSE response to query for &lt;%1&gt; contained multiple RRsets with different classes</term>
+<listitem><para>
+A debug message reporting that the response to an upstream query for
+the specified name contained multiple RRsets in the answer and not all
+were of the same class.  This is a violation of the standard and so a
+SERVFAIL will be returned.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_NOTSINGLE_RESPONSE">
+<term>RESLIB_NOTSINGLE_RESPONSE response to query for &lt;%1&gt; was not a response</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver was a CNAME that had mutiple RRs in the RRset.  This is
+an invalid response according to the standards so a SERVFAIL will be
+returned to the system making the original query.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_NOT_ONE_QNAME_RESPONSE">
+<term>RESLIB_NOT_ONE_QNAME_RESPONSE not one question in response to query for &lt;%1&gt;</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver (as identified by the ID of the response) did not contain
+one name in the question section as required by the standard. A SERVFAIL
+will be returned to the system making the original query.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="RESLIB_NOT_RESPONSE">
+<term>RESLIB_NOT_RESPONSE response to query for &lt;%1&gt; was not a response</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver (as identified by the ID of the response) did not have the QR
+bit set (thus indicating that the packet was a query, not a response).
+A SERVFAIL will be returned to the system making the original query.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="RESLIB_NO_NS_RRSET">
 <term>RESLIB_NO_NS_RRSET no NS RRSet in referral response received to query for &lt;%1&gt;</term>
 <listitem><para>
@@ -3634,6 +4001,17 @@ messages will have indicated the server to which the question was sent.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="RESLIB_OPCODE_RESPONSE">
+<term>RESLIB_OPCODE_RESPONSE response to query for &lt;%1&gt; did not have query opcode</term>
+<listitem><para>
+A debug message, the response to the specified query from an upstream
+nameserver was a response that did not have the opcode set to that of
+a query.  According to the standards, this is an invalid response to
+the query that was made, so a SERVFAIL will be returned to the system
+making the original query.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="RESLIB_PROTOCOL">
 <term>RESLIB_PROTOCOL protocol error in answer for %1:  %3</term>
 <listitem><para>
@@ -3651,8 +4029,8 @@ repeated query, there will be the indicated number of retries left.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="RESLIB_RCODE_ERR">
-<term>RESLIB_RCODE_ERR RCODE indicates error in response to query for &lt;%1&gt;</term>
+<varlistentry id="RESLIB_RCODE_ERROR">
+<term>RESLIB_RCODE_ERROR response to query for &lt;%1&gt; returns RCODE of %2</term>
 <listitem><para>
 A debug message, the response to the specified query indicated an error
 that is not covered by a specific code path.  A SERVFAIL will be returned.
@@ -3758,6 +4136,15 @@ to the specified nameserver.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="RESLIB_TCP_TRUNCATED">
+<term>RESLIB_TCP_TRUNCATED TCP response to query for %1 was truncated</term>
+<listitem><para>
+This is a debug message logged when a response to the specified  query to an
+upstream nameserver returned a response with the TC (truncation) bit set.  This
+is treated as an error by the code.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="RESLIB_TEST_SERVER">
 <term>RESLIB_TEST_SERVER setting test server to %1(%2)</term>
 <listitem><para>
@@ -4217,6 +4604,47 @@ a message to the sender with the RCODE set to NOTIMP.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="SOCKETREQUESTOR_CREATED">
+<term>SOCKETREQUESTOR_CREATED Socket requestor created</term>
+<listitem><para>
+Debug message.  A socket requesor (client of the socket creator) is created
+for the corresponding application.  Normally this should happen at most
+one time throughout the lifetime of the application.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="SOCKETREQUESTOR_DESTROYED">
+<term>SOCKETREQUESTOR_DESTROYED Socket requestor destoryed</term>
+<listitem><para>
+Debug message.  The socket requestor created at SOCKETREQUESTOR_CREATED
+has been destroyed.  This event is generally unexpected other than in
+test cases.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="SOCKETREQUESTOR_GETSOCKET">
+<term>SOCKETREQUESTOR_GETSOCKET Received a %1 socket for [%2]:%3, FD=%4, token=%5, path=%6</term>
+<listitem><para>
+Debug message. The socket requestor for the corresponding application
+has requested a socket for a set of address, port and protocol (shown
+in the log message) and successfully got it from the creator.  The
+corresponding file descriptor and the associated "token" (an internal
+ID used between the creator and requestor) are shown in the log
+message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="SOCKETREQUESTOR_RELEASESOCKET">
+<term>SOCKETREQUESTOR_RELEASESOCKET Released a socket of token %1</term>
+<listitem><para>
+Debug message.  The socket requestor has released a socket passed by
+the creator.  The associated token of the socket is shown in the
+log message.  If the corresponding SOCKETREQUESTOR_GETSOCKET was logged
+more detailed information of the socket can be identified by matching
+the token.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="SRVCOMM_ADDRESSES_NOT_LIST">
 <term>SRVCOMM_ADDRESSES_NOT_LIST the address and port specification is not a list in %1</term>
 <listitem><para>
@@ -4256,7 +4684,7 @@ integer in the range valid for TCP/UDP ports on your system).
 </varlistentry>
 
 <varlistentry id="SRVCOMM_ADDRESS_UNRECOVERABLE">
-<term>SRVCOMM_ADDRESS_UNRECOVERABLE failed to recover original addresses also (%2)</term>
+<term>SRVCOMM_ADDRESS_UNRECOVERABLE failed to recover original addresses also (%1)</term>
 <listitem><para>
 The recovery of old addresses after SRVCOMM_ADDRESS_FAIL also failed for
 the reason listed.
@@ -4587,15 +5015,6 @@ Please check your installation.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="XFRIN_AXFR_DATABASE_FAILURE">
-<term>XFRIN_AXFR_DATABASE_FAILURE AXFR transfer of zone %1 failed: %2</term>
-<listitem><para>
-The AXFR transfer for the given zone has failed due to a database problem.
-The error is shown in the log message.  Note: due to the code structure
-this can only happen for AXFR.
-</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>
@@ -4698,6 +5117,20 @@ likely cause is a PYTHONPATH problem.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFRIN_IXFR_UPTODATE">
+<term>XFRIN_IXFR_UPTODATE IXFR requested serial for %1 is %2, master has %3, not updating</term>
+<listitem><para>
+The first SOA record in an IXFR response indicates the zone's serial
+at the primary server is not newer than the client's.  This is
+basically unexpected event because normally the client first checks
+the SOA serial by an SOA query, but can still happen if the transfer
+is manually invoked or (although unlikely) there is a rapid change at
+the primary server between the SOA and IXFR queries.  The client
+implementation confirms the whole response is this single SOA, and
+aborts the transfer just like a successful case.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFRIN_MSGQ_SEND_ERROR">
 <term>XFRIN_MSGQ_SEND_ERROR error while contacting %1 and %2</term>
 <listitem><para>
@@ -4787,9 +5220,9 @@ often.
 </varlistentry>
 
 <varlistentry id="XFRIN_XFR_TRANSFER_FAILURE">
-<term>XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 failed: %3</term>
+<term>XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 with %3 failed: %4</term>
 <listitem><para>
-The XFR transfer for the given zone has failed due to a protocol error.
+The XFR transfer for the given zone has failed due to an internal error.
 The error is shown in the log message.
 </para></listitem>
 </varlistentry>
@@ -4804,6 +5237,20 @@ AXFR could still work. Therefore we try that one in case it helps.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFRIN_XFR_TRANSFER_PROTOCOL_ERROR">
+<term>XFRIN_XFR_TRANSFER_PROTOCOL_ERROR %1 transfer of zone %2 with %3 failed: %4</term>
+<listitem><para>
+The XFR transfer for the given zone has failed due to a protocol
+error, such as an unexpected response from the primary server.  The
+error is shown in the log message.  It may be because the primary
+server implementation is broken or (although less likely) there was
+some attack attempt, but it can also happen due to configuration
+mismatch such as the remote server does not have authority for the
+zone any more but the local configuration hasn't been updated.  So it
+is recommended to check the primary server configuration.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFRIN_XFR_TRANSFER_STARTED">
 <term>XFRIN_XFR_TRANSFER_STARTED %1 transfer of zone %2 started</term>
 <listitem><para>
@@ -4819,6 +5266,62 @@ The XFR transfer of the given zone was successfully completed.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFRIN_ZONE_CREATED">
+<term>XFRIN_ZONE_CREATED Zone %1 not found in the given data source, newly created</term>
+<listitem><para>
+On starting an xfrin session, it is identified that the zone to be
+transferred is not found in the data source.  This can happen if a
+secondary DNS server first tries to perform AXFR from a primary server
+without creating the zone image beforehand (e.g. by b10-loadzone).  As
+of this writing the xfrin process provides backward compatible
+behavior to previous versions: creating a new one in the data source
+not to surprise existing users too much.  This is probably not a good
+idea, however, in terms of who should be responsible for managing
+zones at a higher level.  In future it is more likely that a separate
+zone management framework is provided, and the situation where the
+given zone isn't found in xfrout will be treated as an error.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_ZONE_MULTIPLE_SOA">
+<term>XFRIN_ZONE_MULTIPLE_SOA Zone %1 has %2 SOA RRs</term>
+<listitem><para>
+On starting an xfrin session, it is identified that the zone to be
+transferred has multiple SOA RRs.  Such a zone is broken, but could be
+accidentally configured especially in a data source using "non
+captive" backend database.  The implementation ignores entire SOA RRs
+and tries to continue processing as if the zone were empty.  This
+means subsequent AXFR can succeed and possibly replace the zone with
+valid content, but an IXFR attempt will fail.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_ZONE_NO_SOA">
+<term>XFRIN_ZONE_NO_SOA Zone %1 does not have SOA</term>
+<listitem><para>
+On starting an xfrin session, it is identified that the zone to be
+transferred does not have an SOA RR in the data source.  This is not
+necessarily an error; if a secondary DNS server first tries to perform
+transfer from a primary server, the zone can be empty, and therefore
+doesn't have an SOA.  Subsequent AXFR will fill in the zone; if the
+attempt is IXFR it will fail in query creation.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_ZONE_SERIAL_AHEAD">
+<term>XFRIN_ZONE_SERIAL_AHEAD Serial number (%1) for %2 received from master %3 &lt; ours (%4)</term>
+<listitem><para>
+The response to an SOA query prior to xfr indicated that the zone's
+SOA serial at the primary server is smaller than that of the xfrin
+client.  This is not necessarily an error especially if that
+particular primary server is another secondary server which hasn't got
+the latest version of the zone.  But if the primary server is known to
+be the real source of the zone, some unexpected inconsistency may have
+happened, and you may want to take a closer look.  In this case xfrin
+doesn't perform subsequent zone transfer.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFROUT_BAD_TSIG_KEY_STRING">
 <term>XFROUT_BAD_TSIG_KEY_STRING bad TSIG key string: %1</term>
 <listitem><para>