[master] regenerate XML for various message log changes

doc/guide/bind10-messages.xml

@@ -244,6 +244,14 @@ packet.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="AUTH_INVALID_STATISTICS_DATA">
+<term>AUTH_INVALID_STATISTICS_DATA invalid specification of statistics data specified</term>
+<listitem><para>
+An error was encountered when the authoritiative server specified
+statistics data which is invalid for the auth specification file.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="AUTH_LOAD_TSIG">
 <term>AUTH_LOAD_TSIG loading TSIG keys</term>
 <listitem><para>
@@ -581,6 +589,14 @@ started according to the configuration.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="BIND10_INVALID_STATISTICS_DATA">
+<term>BIND10_INVALID_STATISTICS_DATA invalid specification of statistics data specified</term>
+<listitem><para>
+An error was encountered when the boss module specified
+statistics data which is invalid for the boss specification file.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="BIND10_INVALID_USER">
 <term>BIND10_INVALID_USER invalid user: %1</term>
 <listitem><para>
@@ -1150,7 +1166,7 @@ Debug message. The resolver is trying to look up data in the RRset cache.
 </varlistentry>
 
 <varlistentry id="CACHE_RRSET_NOT_FOUND">
-<term>CACHE_RRSET_NOT_FOUND no RRset found for %1/%2/%3</term>
+<term>CACHE_RRSET_NOT_FOUND no RRset found for %1/%2/%3 in cache</term>
 <listitem><para>
 Debug message which can follow CACHE_RRSET_LOOKUP. This means the data is not
 in the cache.
@@ -1773,13 +1789,12 @@ means no limit.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="DATASRC_DATABASE_FIND_ERROR">
-<term>DATASRC_DATABASE_FIND_ERROR error retrieving data from datasource %1: %2</term>
+<varlistentry id="DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED">
+<term>DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED %1 doesn't support DNSSEC when asked for NSEC data covering %2</term>
 <listitem><para>
-This was an internal error while reading data from a datasource. This can either
-mean the specific data source implementation is not behaving correctly, or the
-data it provides is invalid. The current search is aborted.
-The error message contains specific information about the error.
+The datasource tried to provide an NSEC proof that the named domain does not
+exist, but the database backend doesn't support DNSSEC. No proof is included
+in the answer as a result.
 </para></listitem>
 </varlistentry>
 
@@ -1795,28 +1810,9 @@ name and type in the database.
 <term>DATASRC_DATABASE_FIND_TTL_MISMATCH TTL values differ in %1 for elements of %2/%3/%4, setting to %5</term>
 <listitem><para>
 The datasource backend provided resource records for the given RRset with
-different TTL values. The TTL of the RRSET is set to the lowest value, which
-is printed in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FIND_UNCAUGHT_ERROR">
-<term>DATASRC_DATABASE_FIND_UNCAUGHT_ERROR uncaught general error retrieving data from datasource %1: %2</term>
-<listitem><para>
-There was an uncaught general exception while reading data from a datasource.
-This most likely points to a logic error in the code, and can be considered a
-bug. The current search is aborted. Specific information about the exception is
-printed in this error message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="DATASRC_DATABASE_FIND_UNCAUGHT_ISC_ERROR">
-<term>DATASRC_DATABASE_FIND_UNCAUGHT_ISC_ERROR uncaught error retrieving data from datasource %1: %2</term>
-<listitem><para>
-There was an uncaught ISC exception while reading data from a datasource. This
-most likely points to a logic error in the code, and can be considered a bug.
-The current search is aborted. Specific information about the exception is
-printed in this error message.
+different TTL values. This isn't allowed on the wire and is considered
+an error, so we set it to the lowest value we found (but we don't modify the
+database). The data in database should be checked and fixed.
 </para></listitem>
 </varlistentry>
 
@@ -1846,6 +1842,15 @@ instead.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL">
+<term>DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL empty non-terminal %2 in %1</term>
+<listitem><para>
+The domain name 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.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DATABASE_FOUND_NXDOMAIN">
 <term>DATASRC_DATABASE_FOUND_NXDOMAIN search in datasource %1 resulted in NXDOMAIN for %2/%3/%4</term>
 <listitem><para>
@@ -1871,6 +1876,132 @@ returned is printed.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="DATASRC_DATABASE_ITERATE">
+<term>DATASRC_DATABASE_ITERATE iterating zone %1</term>
+<listitem><para>
+The program is reading the whole zone, eg. not searching for data, but going
+through each of the RRsets there.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_ITERATE_END">
+<term>DATASRC_DATABASE_ITERATE_END iterating zone finished</term>
+<listitem><para>
+While iterating through the zone, the program reached end of the data.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_ITERATE_NEXT">
+<term>DATASRC_DATABASE_ITERATE_NEXT next RRset in zone is %1/%2</term>
+<listitem><para>
+While iterating through the zone, the program extracted next RRset from it.
+The name and RRtype of the RRset is indicated in the message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_ITERATE_TTL_MISMATCH">
+<term>DATASRC_DATABASE_ITERATE_TTL_MISMATCH TTL values differ for RRs of %1/%2/%3, setting to %4</term>
+<listitem><para>
+While iterating through the zone, the time to live for RRs of the given RRset
+were found to be different. This isn't allowed on the wire and is considered
+an error, so we set it to the lowest value we found (but we don't modify the
+database). The data in database should be checked and fixed.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_UPDATER_COMMIT">
+<term>DATASRC_DATABASE_UPDATER_COMMIT updates committed for '%1/%2' on %3</term>
+<listitem><para>
+Debug information.  A set of updates to a zone has been successfully
+committed to the corresponding database backend.  The zone name,
+its class and the database name are printed.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_UPDATER_CREATED">
+<term>DATASRC_DATABASE_UPDATER_CREATED zone updater created for '%1/%2' on %3</term>
+<listitem><para>
+Debug information.  A zone updater object is created to make updates to
+the shown zone on the shown backend database.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED">
+<term>DATASRC_DATABASE_UPDATER_DESTROYED zone updater destroyed for '%1/%2' on %3</term>
+<listitem><para>
+Debug information.  A zone updater object is destroyed, either successfully
+or after failure of, making updates to the shown zone on the shown backend
+database.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK">
+<term>DATASRC_DATABASE_UPDATER_ROLLBACK zone updates roll-backed for '%1/%2' on %3</term>
+<listitem><para>
+A zone updater is being destroyed without committing the changes.
+This would typically mean the update attempt was aborted due to some
+error, but may also be a bug of the application that forgets committing
+the changes.  The intermediate changes made through the updater won't
+be applied to the underlying database.  The zone name, its class, and
+the underlying database name are shown in the log message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL">
+<term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL failed to roll back zone updates for '%1/%2' on %3: %4</term>
+<listitem><para>
+A zone updater is being destroyed without committing the changes to
+the database, and attempts to rollback incomplete updates, but it
+unexpectedly fails.  The higher level implementation does not expect
+it to fail, so this means either a serious operational error in the
+underlying data source (such as a system failure of a database) or
+software bug in the underlying data source implementation.  In either
+case if this message is logged the administrator should carefully
+examine the underlying data source to see what exactly happens and
+whether the data is still valid.  The zone name, its class, and the
+underlying database name as well as the error message thrown from the
+database module are shown in the log message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD">
+<term>DATASRC_DATABASE_WILDCARD constructing RRset %3 from wildcard %2 in %1</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.
+</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>
+<listitem><para>
+The database was queried to provide glue data and it didn't find direct match.
+It could create it from given wildcard, but matching wildcards is forbidden
+under a zone cut, which was found. Therefore the delegation will be returned
+instead.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD_CANCEL_SUB">
+<term>DATASRC_DATABASE_WILDCARD_CANCEL_SUB wildcard %2 can't be used to construct %3 because %4 exists in %1</term>
+<listitem><para>
+The answer could be constructed using the wildcard, but the given subdomain
+exists, therefore this name is something like empty non-terminal (actually,
+from the protocol point of view, it is empty non-terminal, but the code
+discovers it differently).
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="DATASRC_DATABASE_WILDCARD_EMPTY">
+<term>DATASRC_DATABASE_WILDCARD_EMPTY implicit wildcard %2 used to construct %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.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="DATASRC_DO_QUERY">
 <term>DATASRC_DO_QUERY handling query for '%1/%2'</term>
 <listitem><para>
@@ -2750,6 +2881,15 @@ generated.
 </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>
+<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.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="LOGIMPL_ABOVE_MAX_DEBUG">
 <term>LOGIMPL_ABOVE_MAX_DEBUG debug level of %1 is too high and will be set to the maximum of %2</term>
 <listitem><para>
@@ -4103,21 +4243,17 @@ configuration update from the configuration manager.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="STATS_RECEIVED_REMOVE_COMMAND">
-<term>STATS_RECEIVED_REMOVE_COMMAND received command to remove %1</term>
+<varlistentry id="STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND">
+<term>STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND received command to show all statistics schema</term>
 <listitem><para>
-A remove command for the given name was sent to the stats module, and
-the given statistics value will now be removed. It will not appear in
-statistics reports until it appears in a statistics update from a
-module again.
+The stats module received a command to show all statistics schemas of all modules.
 </para></listitem>
 </varlistentry>
 
-<varlistentry id="STATS_RECEIVED_RESET_COMMAND">
-<term>STATS_RECEIVED_RESET_COMMAND received command to reset all statistics</term>
+<varlistentry id="STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND">
+<term>STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND received command to show statistics schema for %1</term>
 <listitem><para>
-The stats module received a command to clear all collected statistics.
-The data is cleared until it receives an update from the modules again.
+The stats module received a command to show the specified statistics schema of the specified module.
 </para></listitem>
 </varlistentry>
 
@@ -4168,6 +4304,21 @@ to send its data to the stats module.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="STATS_STARTING">
+<term>STATS_STARTING starting</term>
+<listitem><para>
+The stats module will be now starting.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="STATS_START_ERROR">
+<term>STATS_START_ERROR stats module error: %1</term>
+<listitem><para>
+An internal error occurred while starting the stats module. The stats
+module will be now shutting down.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="STATS_STOPPED_BY_KEYBOARD">
 <term>STATS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</term>
 <listitem><para>
@@ -4191,39 +4342,28 @@ Please check your installation.
 <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.
+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_INTERNAL_FAILURE">
-<term>XFRIN_AXFR_INTERNAL_FAILURE AXFR transfer of zone %1 failed: %2</term>
+<varlistentry id="XFRIN_AXFR_INCONSISTENT_SOA">
+<term>XFRIN_AXFR_INCONSISTENT_SOA AXFR SOAs are inconsistent for %1: %2 expected, %3 received</term>
 <listitem><para>
-The 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.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_AXFR_TRANSFER_FAILURE">
-<term>XFRIN_AXFR_TRANSFER_FAILURE AXFR transfer of zone %1 failed: %2</term>
-<listitem><para>
-The AXFR transfer for the given zone has failed due to a protocol error.
-The error is shown in the log message.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_AXFR_TRANSFER_STARTED">
-<term>XFRIN_AXFR_TRANSFER_STARTED AXFR transfer of zone %1 started</term>
-<listitem><para>
-A connection to the master server has been made, the serial value in
-the SOA record has been checked, and a zone transfer has been started.
-</para></listitem>
-</varlistentry>
-
-<varlistentry id="XFRIN_AXFR_TRANSFER_SUCCESS">
-<term>XFRIN_AXFR_TRANSFER_SUCCESS AXFR transfer of zone %1 succeeded</term>
-<listitem><para>
-The AXFR transfer of the given zone was successfully completed.
+The serial fields of the first and last SOAs of AXFR (including AXFR-style
+IXFR) are not the same.  According to RFC 5936 these two SOAs must be the
+"same" (not only for the serial), but it is still not clear what the
+receiver should do if this condition does not hold.  There was a discussion
+about this at the IETF dnsext wg:
+http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
+and the general feeling seems that it would be better to reject the
+transfer if a mismatch is detected.  On the other hand, also as noted
+in that email thread, neither BIND 9 nor NSD performs any comparison
+on the SOAs.  For now, we only check the serials (ignoring other fields)
+and only leave a warning log message when a mismatch is found.  If it
+turns out to happen with a real world primary server implementation
+and that server actually feeds broken data (e.g. mixed versions of
+zone), we can consider a stricter action.
 </para></listitem>
 </varlistentry>
 
@@ -4280,6 +4420,27 @@ shown in the log message.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFRIN_GOT_INCREMENTAL_RESP">
+<term>XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1</term>
+<listitem><para>
+In an attempt of IXFR processing, the begenning SOA of the first difference
+(following the initial SOA that specified the final SOA for all the
+differences) was found.  This means a connection for xfrin tried IXFR
+and really aot a response for incremental updates.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_GOT_NONINCREMENTAL_RESP">
+<term>XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1</term>
+<listitem><para>
+Non incremental transfer was detected at the "first data" of a transfer,
+which is the RR following the initial SOA.  Non incremental transfer is
+either AXFR or AXFR-style IXFR.  In the latter case, it means that
+in a response to IXFR query the first data is not SOA or its SOA serial
+is not equal to the requested SOA serial.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFRIN_IMPORT_DNS">
 <term>XFRIN_IMPORT_DNS error importing python DNS module: %1</term>
 <listitem><para>
@@ -4305,6 +4466,16 @@ likely means that the msgq daemon has quit or was killed.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFRIN_NOTIFY_UNKNOWN_MASTER">
+<term>XFRIN_NOTIFY_UNKNOWN_MASTER got notification to retransfer zone %1 from %2, expected %3</term>
+<listitem><para>
+The system received a notify for the given zone, but the address it came
+from does not match the master address in the Xfrin configuration. The notify
+is ignored. This may indicate that the configuration for the master is wrong,
+that a wrong machine is sending notifies, or that fake notifies are being sent.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFRIN_RETRANSFER_UNKNOWN_ZONE">
 <term>XFRIN_RETRANSFER_UNKNOWN_ZONE got notification to retransfer unknown zone %1</term>
 <listitem><para>
@@ -4338,6 +4509,38 @@ exception message is printed in the log message.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFRIN_XFR_OTHER_FAILURE">
+<term>XFRIN_XFR_OTHER_FAILURE %1 transfer of zone %2 failed: %3</term>
+<listitem><para>
+The XFR transfer for the given zone has failed due to a problem outside
+of the xfrin module.  Possible reasons are a broken DNS message or failure
+in database connection.  The error is shown in the log message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_XFR_TRANSFER_FAILURE">
+<term>XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 failed: %3</term>
+<listitem><para>
+The XFR transfer for the given zone has failed due to a protocol error.
+The error is shown in the log message.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_XFR_TRANSFER_STARTED">
+<term>XFRIN_XFR_TRANSFER_STARTED %1 transfer of zone %2 started</term>
+<listitem><para>
+A connection to the master server has been made, the serial value in
+the SOA record has been checked, and a zone transfer has been started.
+</para></listitem>
+</varlistentry>
+
+<varlistentry id="XFRIN_XFR_TRANSFER_SUCCESS">
+<term>XFRIN_XFR_TRANSFER_SUCCESS %1 transfer of zone %2 succeeded</term>
+<listitem><para>
+The XFR transfer of the given zone was successfully completed.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFROUT_AXFR_TRANSFER_DONE">
 <term>XFROUT_AXFR_TRANSFER_DONE transfer of %1/%2 complete</term>
 <listitem><para>
@@ -4401,6 +4604,14 @@ configuration manager b10-cfgmgr is not running.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFROUT_CONFIG_ERROR">
+<term>XFROUT_CONFIG_ERROR error found in configuration data: %1</term>
+<listitem><para>
+The xfrout process encountered an error when installing the configuration at
+startup time.  Details of the error are included in the log message.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFROUT_FETCH_REQUEST_ERROR">
 <term>XFROUT_FETCH_REQUEST_ERROR socket error while fetching a request from the auth daemon</term>
 <listitem><para>
@@ -4430,6 +4641,17 @@ system and your specific installation.
 </para></listitem>
 </varlistentry>
 
+<varlistentry id="XFROUT_MODULECC_SESSION_ERROR">
+<term>XFROUT_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</term>
+<listitem><para>
+There was a problem in the lower level module handling configuration and
+control commands.  This could happen for various reasons, but the most likely
+cause is that the configuration database contains a syntax error and xfrout
+failed to start at initialization.  A detailed error message from the module
+will also be displayed.
+</para></listitem>
+</varlistentry>
+
 <varlistentry id="XFROUT_NEW_CONFIG">
 <term>XFROUT_NEW_CONFIG Update xfrout configuration</term>
 <listitem><para>