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 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. 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
This document lists each message that can be logged by the programs in the BIND 10 package. Each entry in this manual is of the form:
IDENTIFICATION message-text
... where "IDENTIFICATION" is the message identification included in each message logged and "message-text" is the accompanying message text. The "message-text" may include placeholders of the form "%1", "%2" etc.; these parameters are replaced by relevant values when the message is logged.
Each entry is also accompanied by a description giving more information about the circumstances that result in the message being logged.
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 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 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 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.
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 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.
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.
Debug information that the hotspot cache was created at startup.
Debug information. The hotspot cache is being destroyed.
The hotspot cache is disabled from now on. It is not going to store information or return anything.
The hotspot cache is enabled from now on.
Debug information. There was an attempt to look up an item in the hotspot cache. And the item was actually there, but it was too old, so it was removed instead and nothing is reported (the external behaviour is the same as with CACHE_NOT_FOUND).
Debug information. An item was successfully looked up in the hotspot cache.
Debug information. After inserting an item into the hotspot cache, the maximum number of items was exceeded, so the least recently used item will be dropped. This should be directly followed by CACHE_REMOVE.
Debug information. It means a new item is being inserted into the hotspot cache.
Debug information. It was attempted to look up an item in the hotspot cache, but it is not there.
Debug information. While inserting an item into the hotspot cache, an older instance of an item with the same name was found. The old instance will be removed. This should be directly followed by CACHE_REMOVE.
Debug information. An item is being removed from the hotspot cache.
The maximum allowed number of items of the hotspot cache is set to the given number. If there are too many, some of them will be dropped. The size of 0 means no limit.
Debug information. We're processing some internal query for given name and type.
Debug information. An RRset is being added to the in-memory data source.
Debug information. Some special marks above each * in wildcard name are needed. They are being added now for this name.
Debug information. A zone is being added into the in-memory data source.
Debug information. The domain was found and an ANY type query is being answered by providing everything found inside the domain.
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.
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 (RFC 1034, section 3.6.2). This indicates a problem with provided data.
Debug information. A representation of a zone for the in-memory data source is being created.
Debug information. A delegation point was found above the requested record.
Debug information. A zone from in-memory data source is being destroyed.
Debug information. While searching for the requested domain, a DNAME was 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.
Debug information. The requested domain exists in the tree of domains, but it is empty. Therefore it doesn't contain the requested resource type.
An RRset is being inserted into in-memory data source for a second time. The original version must be removed first. Note that loading master files where an RRset is split into multiple locations is not supported yet.
Debug information. There's a NS record at the requested domain. This means this zone is not authoritative for the requested domain, but a delegation should be followed. The requested domain is an apex of some zone.
Debug information. A search for the requested RRset is being started.
Debug information. A zone object for this zone is being searched for in the in-memory data source.
Debug information. The content of master file is being loaded into the memory.
Debug information. The requested domain does not exist.
Debug information. While searching for the requested domain, a NS was encountered on the way (a delegation). This may lead to stop of the search.
Debug information. The domain exists, but it doesn't hold any record of the requested type.
It was attempted to add the domain into a zone that shouldn't have it (eg. the domain is not subdomain of the zone origin). This indicates a problem with provided data.
Debug information. A RRset is being generated from a different RRset (most probably a wildcard). So it must be renamed to whatever the user asked for. In fact, it's impossible to rename RRsets with our libraries, so a new one is created and all resource records are copied over.
Some resource types are singletons -- only one is allowed in a domain (for example CNAME or SOA). This indicates a problem with provided data.
Debug information. The requested record was found.
Debug information. The search stopped at a superdomain of the requested domain. The domain is a empty nonterminal, therefore it is treated as NXRRSET case (eg. the domain exists, but it doesn't have the requested record type).
Debug information. The contents of two in-memory zones are being exchanged. This is usual practice to do some manipulation in exception-safe manner -- the new data are prepared in a different zone object and when it works, they are swapped. The old one contains the new data and the other one can be safely 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 different tools.
Debug information. Yet another data source is being added into the meta data source. (probably at startup or reconfiguration)
It was attempted to add a data source into a meta data source. But their classes do not match.
Debug information. A data source is being removed from meta data source.
Debug information. A NSEC record covering this zone is being added.
Debug information. A NSEC3 record for the given zone is being added to the response message.
Debug information. An RRset is being added to the response message.
Debug information. A SOA record of the given zone is being added to the authority section of the response message.
The underlying data source failed to answer the authoritative query. 1 means some error, 2 is not implemented. The data source should have logged the specific error already.
The domain lives in another zone. But it is not possible to generate referral information for it.
Debug information. The requested data were found in the hotspot cache, so no query is sent to the real data source.
Debug information. While processing a query, lookup to the hotspot cache is being made.
Debug information. The whole referral information is being copied into the 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. We tried to follow
During an attempt to synthesize CNAME from this DNAME it was discovered the DNAME is empty (it has no records). This indicates problem with supplied data.
Some subtask of query processing failed. The reason should have been reported already. We are returning SERVFAIL.
Debug information. The domain is a CNAME (or a DNAME and we created a CNAME for it already), so it's being followed.
Debug information. While processing a query, a MX record was met. It references the mentioned address, so A/AAAA records for it are looked up and put it into the additional section.
Debug information. While processing a query, a NS record was met. It references the mentioned address, so A/AAAA records for it are looked up and put it into the additional section.
The underlying data source failed to answer the glue query. 1 means some error, 2 is not implemented. The data source should have logged the specific error already.
This indicates a programmer error. The DO_QUERY was called with unknown operation code.
Debug information. The last DO_QUERY is an auth query.
Debug information. The last DO_QUERY is query for glue addresses.
Debug information. The last DO_QUERY is query for addresses that are not glue.
Debug information. The last DO_QUERY is query for referral information.
Debug information. The last DO_QUERY is a simple query.
This indicates a programming error. A task was found in the internal task queue, but this kind of task wasn't designed to be inside the queue (it should be handled right away, not queued).
NS records should have been put into the authority section. However, this zone has none. This indicates problem with provided data.
The answer should have been a negative one (eg. of nonexistence of something). To do so, a SOA record should be put into the authority section, but the zone does not have one. This indicates problem with provided data.
The underlying data source failed to answer the no-glue query. 1 means some error, 2 is not implemented. The data source should have logged the specific error already.
Debug information. The hotspot cache is ignored for authoritative ANY queries for consistency reasons.
Debug information. The hotspot cache is ignored for ANY queries for consistency reasons.
An attempt to add a NSEC record into the message failed, because the zone does not have any DS record. This indicates problem with the provided data.
An attempt to add a NSEC3 record into the message failed, because the zone does not have any DS record. This indicates problem with the provided data.
Lookup of domain failed because the data have no zone that contain the domain. Maybe someone sent a query to the wrong server for some reason.
Debug information. A sure query is being processed now.
The user wants DNSSEC and we discovered the entity doesn't exist (either domain or the record). But there was an error getting NSEC/NSEC3 record to prove the nonexistence.
The underlying data source failed to answer the query for referral information. 1 means some error, 2 is not implemented. The data source should have logged the specific error already.
The server is unable to answer a direct query for RRSIG type, but was asked to do so.
The underlying data source failed to answer the simple query. 1 means some error, 2 is not implemented. The data source should have logged the specific error already.
Debug information. While answering a query, a DNAME was met. The DNAME itself will be returned, but along with it a CNAME for clients which don't understand 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 been synthesized from DNAMEs. This indicates problem with supplied data.
This indicates a programmer error. The answer of subtask doesn't look like anything known.
Debug information. A direct match wasn't found, so a wildcard covering the domain is being looked for now.
During an attempt to cover the domain by a wildcard an error happened. The exact kind was hopefully already reported.
While processing a wildcard, it wasn't possible to prove nonexistence of the given domain or record. The code is 1 for error and 2 for not implemented.
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 should hold this domain.
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 set.
Debug information. The data source is looking up the addresses for given domain name.
The SQLite data source was looking up A/AAAA addresses, but the data source contains different class than the query was for.
Debug information. The SQLite data source is looking up an exact resource record.
The SQLite data source was looking up an exact RRset, but the data source contains different class than the query was for.
Debug information. The SQLite data source is looking up records of given name 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 it contains different class than the query was for.
The SQLite data source was looking up an RRset, but the data source contains different class than the query was for.
Debug information. We're trying to look up a NSEC3 record in the SQLite data source.
The SQLite data source was asked to provide a NSEC3 record for given zone. But it doesn't contain that zone.
Debug information. The SQLite data source is loading an SQLite database in the provided file.
Debug information. We're trying to look up name preceding the supplied one.
The SQLite data source tried to identify name preceding this one. But this one is not contained in any zone in the data source.
The database for SQLite data source was found empty. It is assumed this is the first run and it is being initialized with current schema. It'll still contain no data, but it will be ready for use.
For some reason, someone asked the static data source a query that is not in the CH class.
Debug information. The static data source (the one holding stuff like version.bind) is being created.
Debug information. This resource record set is being looked up in the static 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 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.
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.)
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.
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.)
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 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, 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 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, 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.
A debug message, this indicates that the response to the specified query was truncated and that the resolver will be re-querying over TCP. There are various reasons why responses may be truncated, so this message is normal and 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, 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.
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 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 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.
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: 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 whilst continuing to resolver the query. Lookup timeout: the time at which the 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 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. At this point it will wait for pending upstream queries to complete or timeout and drop the query.
This information message is output when the resolver has shut down.
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.