|
@@ -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 -> %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>
|