BIND 10 Messages Manual

A debug message, this records that the upstream fetch (a query made by the resolver on behalf of its client) to the specified address has completed.

An external component has requested the halting of an upstream fetch. This is an allowed operation, and the message should only appear if debug is enabled.

The asynchronous I/O code encountered an error when trying to open a socket of the specified protocol in order to send a message to the target address. The number of the system error that caused the problem is given in the message.

The asynchronous I/O code encountered an error when trying to read data from the specified address on the given protocol. The number of the system error that caused 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 to send data to the specified address on the given protocol. The number of the system error that caused the problem is given in the message.

An internal consistency check on the origin of a message from the asynchronous I/O module failed. This may indicate an internal error; please submit a bug report.

An internal error indicating that the termination method of the resolver's upstream fetch class was called with an unknown result code (which is given in the message). Please submit a bug report.

This is a debug message produced by the authoritative server when it has encountered an error processing an AXFR request. The message gives the reason for the error, and the server will return a SERVFAIL code to the sender.

This is a debug message output when the authoritative server has received an AXFR query over UDP. Use of UDP for AXFRs is not permitted by the protocol, so the server will return a FORMERR error to the sender.

Execution of the specified command by the authoritative server failed. The message contains the reason for the failure.

This is a debug message indicating that authoritative server has created the channel to the configuration manager. It is issued during server startup is an indication that the initialization is proceeding normally.

This is a debug message indicating that authoritative server has established communication the configuration manager over the previously-created channel. It is issued during server startup is an indication that the initialization is proceeding normally.

This is a debug message, issued when the authoritative server has posted a request to be notified when new configuration information is available. It is issued during server startup is an indication that the initialization is proceeding normally.

An attempt to configure the server with information from the configuration database during the startup sequence has failed. (The reason for the failure is given in the message.) The server will continue its initialization although it may not be configured in the desired way.

At attempt to update the configuration the server with information from the configuration database has failed, the reason being given in the message.

This is a debug message produced by the authoritative server when it accesses a datebase data source, listing the file that is being accessed.

This is a debug message indicating that the component that will handling incoming queries for the authoritative server (DNSServices) has been successfully created. It is issued during server startup is an indication that the initialization is proceeding normally.

This is a debug message, generated by the authoritative server when an attempt to parse the header of a received DNS packet has failed. (The reason for the failure is given in the message.) The server will drop the packet.

This is a debug message indicating that the authoritative server has requested the keyring holding TSIG keys from the configuration database. It is issued during server startup is an indication that the initialization is proceeding normally.

This debug message is issued during the processing of the 'loadzone' command when the authoritative server has successfully loaded the named zone of the named class.

This is a debug message reporting that the authoritative server has discovered that the memory data source is disabled for the given class.

This is a debug message reporting that the authoritative server has discovered that the memory data source is enabled for the given class.

This debug message is logged by the authoritative server when it receives a NOTIFY packet that contains zero or more than one question. (A valid NOTIFY packet contains one question.) The server will return a FORMERR error to the sender.

This debug message is logged by the authoritative server when it receives a NOTIFY packet that an RR type of something other than SOA in the question section. (The RR type received is included in the message.) The server will return a FORMERR error to the sender.

The authoritative server had no session with the statistics module at the time it attempted to send it data: the attempt has been abandoned. This could be an error in configuration.

This is a debug message produced by the authoritative server when it receives a NOTIFY packet but the XFRIN process is not running. The packet will be dropped and nothing returned to the sender.

This is a debug message, generated by the authoritative server when an attempt to parse a received DNS packet has failed due to something other than a protocol error. The reason for the failure is given in the message; the server will return a SERVFAIL error code to the sender.

This is a debug message, generated by the authoritative server when an attempt to parse a received DNS packet has failed due to a protocol error. The reason for the failure is given in the message, as is the error code that will be returned to the sender.

This is a debug message output by the authoritative server when it receives a valid DNS packet.

Note: This message includes the packet received, rendered in the form of multiple lines of text. For this reason, it is suggested that this log message not be routed to the syslog file, where the multiple lines could confuse programs that expect a format of one message per line.

This message is generated by the authoritative server when it has encountered an internal error whilst processing a received packet: the cause of the error is included in the message.

The server will return a SERVFAIL error code to the sender of the packet. This message indicates a potential error in the server. Please open a bug ticket for this issue.

This is a debug message issued when the authoritative server has received a command on the command channel.

This is a debug message issued when the authoritative server has received a command from the statistics module to send it data. The 'sendstats' command is handled differently to other commands, which is why the debug message associated with it has its own code.

This is a debug message, this is output if the authoritative server receives a DNS packet with the QR bit set, i.e. a DNS response. The server ignores the packet as it only responds to question packets.

This is a debug message recording that the authoritative server is sending an error response to the originator of the query. A previous message will have recorded details of the failure.

Note: This message includes the packet sent, rendered in the form of multiple lines of text. For this reason, it is suggested that this log message not be routed to the syslog file, where the multiple lines could confuse programs that expect a format of one message per line.

This is a debug message recording that the authoritative server is sending a response to the originator of a query.

Note: This message includes the packet sent, rendered in the form of multiple lines of text. For this reason, it is suggested that this log message not be routed to the syslog file, where the multiple lines could confuse programs that expect a format of one message per line.

An informational message indicating that the authoritative server process has been created and is initializing. The AUTH_SERVER_STARTED message will be output when initialization has successfully completed and the server starts accepting queries.

The authoritative server has encountered a fatal error and is terminating. The reason for the failure is included in the message.

Initialization of the authoritative server has completed successfully and it is entering the main loop, waiting for queries to arrive.

This is a debug message indicating that the authoritative server has found that the data source it is loading is an SQLite3 data source, so no further validation is needed.

This is a debug message indicating that the authoritative server has created a channel to the statistics process. It is issued during server startup is an indication that the initialization is proceeding normally.

This is a debug message indicating that the authoritative server has established communication over the previously created statistics channel. It is issued during server startup is an indication that the initialization is proceeding normally.

An error was encountered when the authoritative server tried to send data to the statistics daemon. The message includes additional information describing the reason for the failure.

The authoritative server sent data to the statistics daemon but received no acknowledgement within the specified time. The message includes additional information describing the reason for the failure.

This is a debug message indicating that the statistics timer has been disabled in the authoritative server and no statistics information is being produced.

This is a debug message indicating that the statistics timer has been enabled and that the authoritative server will produce statistics data at the specified interval.

This is a debug message, produced when a received DNS packet being processed by the authoritative server has been found to contain an unsupported opcode. (The opcode is included in the message.) The server will return an error code of NOTIMPL to the sender.

This is a debug message indicating that the authoritative server has created a channel to the XFRIN (Transfer-in) process. It is issued during server startup is an indication that the initialization is proceeding normally.

This is a debug message indicating that the authoritative server has established communication over the previously-created channel to the XFRIN (Transfer-in) process. It is issued during server startup is an indication that the initialization is proceeding normally.

This is a debug message output during the processing of a NOTIFY request. An error (listed in the message) has been encountered whilst communicating with the zone manager. The NOTIFY request will not be honored.

This is a debug message output during the processing of a NOTIFY request. The zone manager component has been informed of the request, but has returned an error response (which is included in the message). The NOTIFY request will not be honored.

The boss process is starting up and will now check if the message bus daemon is already running. If so, it will not be able to start, as it needs a dedicated message bus.

This message shows whether or not the authoritative server should be started according to the configuration.

This message shows whether or not the resolver should be started according to the configuration.

The boss process was started with the -u option, to drop root privileges and continue running as the specified user, but the user is unknown.

The boss module was not able to start every process it needed to start during startup, and will now kill the processes that did get started.

The boss module is sending a kill signal to process with the given name, as part of the process of killing all started processes during a failed startup, as described for BIND10_KILLING_ALL_PROCESSES

There already appears to be a message bus daemon running. Either an old process was not shut down correctly, and needs to be killed, or another instance of BIND10, with the same msgq domain socket, is running, which needs to be stopped.

The message bus daemon has died. This is a fatal error, since it may leave the system in an inconsistent state. BIND10 will now shut down.

While listening on the message bus channel for messages, it suddenly disappeared. The msgq daemon may have died. This might lead to an inconsistent state of the system, and BIND 10 will now shut down.

The given process ended unexpectedly, but no exit status is available. See BIND10_PROCESS_ENDED_WITH_EXIT_STATUS for a longer description.

The given process ended unexpectedly with the given exit status. Depending on which module it was, it may simply be restarted, or it may be a problem that will cause the boss module to shut down too. The latter happens if it was the message bus daemon, which, if it has died suddenly, may leave the system in an inconsistent state. BIND10 will also shut down now if it has been run with --brittle.

The boss process is starting up, and will now process the initial configuration, as received from the configuration manager.

The boss module received a command and shall now process it. The command is printed.

The boss module received a configuration update and is going to apply it now. The new configuration is printed.

The boss module received the given signal.

The given process has been restarted successfully, and is now running with the given process id.

The given process has ended unexpectedly, and is now restarted.

There was a fatal error in the call to select(), used to see if a child process has ended or if there is a message on the message bus. This should not happen under normal circumstances and is considered fatal, so BIND 10 will now shut down. The specific error is printed.

The boss module is sending a SIGKILL signal to the given process.

The boss module is sending a SIGTERM signal to the given process.

The boss process received a command or signal telling it to shut down. It will send a shutdown command to each process. The processes that do not shut down will then receive a SIGTERM signal. If that doesn't work, it shall send SIGKILL signals to the processes still alive.

All child processes have been stopped, and the boss process will now stop itself.

The socket creator reported an error when creating a socket. But the function which failed is unknown (not one of 'S' for socket or 'B' for bind).

The boss requested a socket from the creator, but the answer is unknown. This looks like a programmer error.

The socket creator terminated unexpectedly. It is not possible to restart it (because the boss already gave up root privileges), so the system is going to terminate.

There should be more data from the socket creator, but it closed the socket. It probably crashed.

The boss module initializes routines for parsing the socket creator protocol.

The socket creator is being terminated the aggressive way, by sending it sigkill. This should not happen usually.

The boss module sends a request to terminate to the socket creator.

Either sending or receiving data from the socket creator failed with the given error. The creator probably crashed or some serious OS-level problem happened, as the communication happens only on local host.

The socket creator successfully created and sent a requested socket, it has the given file number.

The socket creator failed to create the requested socket. It failed on the indicated OS API function with given error.

The boss forwards a request for a socket to the socket creator.

The given process has successfully been started.

The given process has successfully been started, and has the given PID.

Informational message on startup that shows the full version.

The boss module is starting the given process.

The boss module is starting the given process, which will listen on the given port number.

The boss module is starting the given process, which will listen on the given address and port number (written as <address>#<port>).

All modules have been successfully started, and BIND 10 is now running.

There was a fatal error when BIND10 was trying to start. The error is shown, and BIND10 will now shut down.

The given module is being started or restarted without root privileges. If the module needs these privileges, it may have problems starting. Note that this issue should be resolved by the pending 'socket-creator' process; once that has been implemented, modules should not need root privileges anymore. See tickets #800 and #801 for more information.

The boss module is sending a shutdown command to the given module over the message channel.

An unknown child process has exited. The PID is printed, but no further action will be taken by the boss process.

The cache tried to generate the complete answer message. It knows the structure of the message, but some of the RRsets to be put there are not in cache (they probably expired already). Therefore it pretends the message was not found.

Debug message, noting that the requested data was successfully found in the local zone data of the cache.

Debug message. The requested data was not found in the local zone data.

Debug message issued when there's update to the local zone section of cache.

Debug message. It is issued when the server deinitializes the message cache.

Debug message. The requested data was found in the message cache, but it already expired. Therefore the cache removes the entry and pretends it found nothing.

Debug message. We found the whole message in the cache, so it can be returned to user without any other lookups.

Debug message issued when a new message cache is issued. It lists the class of messages it can hold and the maximum size of the cache.

Debug message. This may follow CACHE_MESSAGES_UPDATE and indicates that, while updating, the old instance is being removed prior of inserting a new one.

Debug message, noting that the given message can not be cached. This is because there's no SOA record in the message. See RFC 2308 section 5 for more information.

Debug message. The message cache didn't find any entry for the given key.

Debug message issued when the message cache is being updated with a new message. Either the old instance is removed or, if none is found, new one is created.

Debug message. The resolver cache is looking up the deepest known nameserver, so the resolution doesn't have to start from the root.

Debug message. The resolver cache is being created for this given class.

Debug message, the resolver cache is being created for this given class. The difference from CACHE_RESOLVER_INIT is only in different format of passed information, otherwise it does the same.

Debug message. The resolver cache found a complete message for the user query in the zone data.

Debug message. The resolver cache found a requested RRset in the local zone data.

Debug message. The resolver cache is trying to find a message to answer the user query.

Debug message. The resolver cache is trying to find an RRset (which usually originates as internally from resolver).

The cache tried to fill in found data into the response message. But it discovered the message contains no question section, which is invalid. This is likely a programmer error, please submit a bug report.

Debug message. While trying to lookup a message in the resolver cache, it was discovered there's no cache for this class at all. Therefore no message is found.

Debug message. While trying to lookup an RRset in the resolver cache, it was discovered there's no cache for this class at all. Therefore no data is found.

Debug message. The resolver is updating a message in the cache.

Debug message. The resolver is updating an RRset in the cache.

Debug message. While trying to insert a message into the cache, it was discovered that there's no cache for the class of message. Therefore the message will not be cached.

Debug message. While trying to insert an RRset into the cache, it was discovered that there's no cache for the class of the RRset. Therefore the message will not be cached.

Debug message. The requested data was found in the RRset cache. However, it is expired, so the cache removed it and is going to pretend nothing was found.

Debug message. The RRset cache to hold at most this many RRsets for the given class is being created.

Debug message. The resolver is trying to look up data in the RRset cache.

Debug message which can follow CACHE_RRSET_LOOKUP. This means the data is not in the cache.

Debug message which can follow CACHE_RRSET_UPDATE. During the update, the cache removed an old instance of the RRset to replace it with the new one.

Debug message which can follow CACHE_RRSET_UPDATE. The cache already holds the same RRset, but from more trusted source, so the old one is kept and new one ignored.

Debug message. The RRset is updating its data with this given RRset.

This marks a low level error, we tried to read data from the message queue daemon asynchronously, but the ASIO library returned an error.

It is impossible to reach the message queue daemon for the reason given. It is unlikely there'll be reason for whatever program this currently is to continue running, as the communication with the rest of BIND 10 is vital for the components.

The library is disconnecting from the message queue daemon. This debug message indicates that the program is trying to shut down gracefully.

This debug message indicates that the command channel library is about to connect to the message queue daemon, which should be listening on the UNIX-domain socket listed in the output.

This debug message indicates that the connection was successfully made, this should follow CC_ESTABLISH.

Debug message, noting that a message is expected to come over the command channel.

Debug message, noting that we successfully received a message (its envelope and payload listed). This follows CC_GROUP_RECEIVE, but might happen some time later, depending if we waited for it or just polled.

Debug message, we're about to send a message over the command channel.

This happens when garbage comes over the command channel or some kind of confusion happens in the program. The data received from the socket make no sense if we interpret it as lengths of message. The first one is total length of the message; the second is the length of the header. The header and its length (2 bytes) is counted in the total length.

There should be data representing the length of message on the socket, but it is not there.

The program polled for incoming messages, but there was no message waiting. This is a debug message which may happen only after CC_GROUP_RECEIVE.

It isn't possible to connect to the message queue daemon, for reason listed. It is unlikely any program will be able continue without the communication.

A low level error happened when the library tried to read data from the command channel socket. The reason is listed.

We received an exception while trying to read data from the command channel socket. The reason is listed.

Debug message, noting we're sending a response to the original message with the given envelope.

Debug message. A timeout for which the program is willing to wait for a reply is being set.

Debug message. From now on, when a message (or command) comes, it'll wake the program and the library will automatically pass it over to correct place.

Debug message. The program wants to receive messages addressed to this group.

The program waited too long for data from the command channel (usually when it sent a query to different program and it didn't answer for whatever reason).

Debug message. The program no longer wants to receive messages addressed to this group.

A low level error happened when the library tried to write data to the command channel socket.

The library received a message length being zero, which makes no sense, since all messages must contain at least the envelope.

An older version of the configuration database has been found, from which there was an automatic upgrade path to the current version. These changes are now applied, and no action from the administrator is necessary.

The configuration manager sent a configuration update to a module, but the module responded with an answer that could not be parsed. The answer message appears to be invalid JSON data, or not decodable to a string. This is likely to be a problem in the module in question. The update is assumed to have failed, and will not be stored.

The configuration manager daemon was unable to connect to the messaging system. The most likely cause is that msgq is not running.

There was a problem reading the persistent configuration data as stored on disk. The file may be corrupted, or it is of a version from where there is no automatic upgrade path. The file needs to be repaired or removed. The configuration manager daemon will now shut down.

There was an IO error from the system while the configuration manager was trying to write the configuration database to disk. The specific error is given. The most likely cause is that the directory where the file is stored does not exist, or is not writable. The updated configuration is not stored.

There was an OS error from the system while the configuration manager was trying to write the configuration database to disk. The specific error is given. The most likely cause is that the system does not have write access to the configuration database file. The updated configuration is not stored.

There was a keyboard interrupt signal to stop the cfgmgr daemon. The daemon will now shut down.

There was an error reading the updated configuration data. The specific error is printed.

A login attempt was made to b10-cmdctl, but the password was wrong. Users can be managed with the tool b10-cmdctl-usermgr.

There was a problem reading from the command and control channel. The most likely cause is that the message bus daemon is not running.

A timeout occurred when waiting for essential data from the cc session. This usually occurs when b10-cfgmgr is not running or not responding. Since we are waiting for essential information, this is a fatal error, and the cmdctl daemon will now shut down.

An error was encountered sending the given command to the given module. Either there was a communication problem with the module, or the module was not able to process the command, and sent back an error. The specific error is printed in the message.

This debug message indicates that the given command has been sent to the given module.

A login attempt was made to b10-cmdctl, but the username was not known. Users can be added with the tool b10-cmdctl-usermgr.

The b10-cmdctl daemon was unable to find any user data in the user database file. Either it was unable to read the file (in which case this message follows a message CMDCTL_USER_DATABASE_READ_ERROR containing a specific error), or the file was empty. Users can be added with the tool b10-cmdctl-usermgr.

This debug message indicates that the given command is being sent to the given module.

The user was denied because the SSL connection could not successfully be set up. The specific error is given in the log message. Possible causes may be that the ssl request itself was bad, or the local key or certificate file could not be read.

There was a keyboard interrupt signal to stop the cmdctl daemon. The daemon will now shut down.

The b10-cmdctl daemon 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 message is printed.

The b10-cmdctl daemon was unable to read the user database file. The file may be unreadable for the daemon, or it may be corrupted. In the latter case, it can be recreated with b10-cmdctl-usermgr. The specific error is printed in the log message.

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, details of which are appended to the message. The module will continue to run, but will not send back an answer.

The most likely cause of this error is a programming error. Please raise a bug report.

The configuration manager returned an error when this module requested the configuration. The full error message answer from the configuration manager is appended to the log error. The most likely cause is that the module is of a different (command specification) version than the running configuration manager.

The configuration manager returned an error response when the module requested its configuration. The full error message answer from the configuration manager is appended to the log error.

There was an error parsing the JSON file. The given file does not appear to be in valid JSON format. Please verify that the filename is correct and that the contents are valid JSON.

There was a logging configuration update, but the internal validator for logging configuration found that it contained errors. The errors are shown, and the update is ignored.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found an entry for the named logger that matches the logger specification for the program. The logging configuration for the program will be updated with the information.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found an entry for the named logger. As this does not match the logger specification for the program, it has been ignored.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found the named wildcard entry (one containing the "*" character) that matched a logger already matched by an explicitly named entry. The configuration is ignored.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found the named wildcard entry (one containing the "*" character) that matches a logger specification in the program. The logging configuration for the program will be updated with the information.

The given file does not appear to be a valid specification file: details are included in the message. Please verify that the filename is correct and that its contents are a valid BIND10 module specification.

The specification file for this module was rejected by the configuration manager. The full error message answer from the configuration manager is appended to the log error. The most likely cause is that the module is of a different (specification file) version than the running configuration manager.

There was an error opening the given file. The reason for the failure is included in the message.

This is a debug message issued during startup when the hotspot cache is created.

Debug information. The hotspot cache is being destroyed.

A debug message issued when the hotspot cache is disabled.

A debug message issued when the hotspot cache is enabled.

A debug message issued when a hotspot cache lookup located the item but it had expired. The item was removed and the program proceeded as if the item had not been found.

Debug information. An item was successfully located 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.

A debug message indicating that a new item is being inserted into the hotspot cache.

A debug message issued when hotspot cache was searched for the specified item but it was not found.

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 will 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.

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.

Debug information. The database data source is looking up records with the given name and type in the database.

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.

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.

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.

When searching for a domain, the program met a delegation to a different zone at the given domain name. It will return that one instead.

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. It will return the NS record instead.

When searching for a domain, the program met a DNAME redirection to a different place in the domain space at the given domain name. It will return that one instead.

The data returned by the database backend did not contain any data for the given domain name, class and type.

The data returned by the database backend contained data for the given domain name and class, but not for the given type.

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 returned is printed.

A debug message indicating that a query for the given name and RR type is being processed.

Debug information. An RRset is being added to the in-memory data source.

This is a debug message issued during the processing of a wildcard name. The internal domain name tree is scanned and some nodes are specially marked to allow the wildcard lookup to succeed.

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 other data to CNAME.

Someone or something tried to add a CNAME into a domain that already contains some other data. But the protocol forbids coexistence of CNAME with anything (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.

A request was made 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) and 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.

This is a debug message issued during startup or reconfiguration. Another data source is being added into the meta data source.

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.

A CNAME chain was being followed and an entry was found that pointed to a domain name that had no RRsets associated with it. As a result, the query cannot be answered. This indicates a problem with supplied data.

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 and a SERVFAIL will be returned to the querying system.

Debug information. The domain is a CNAME (or a DNAME and a CNAME for it has already been created) and the search is following this chain.

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 a query for glue addresses.

Debug information. The last DO_QUERY is a query for addresses that are not glue.

Debug information. The last DO_QUERY is a 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.

This is a debug message. While answering a query, a DNAME was encountered. The DNAME itself will be returned, along with a synthesized CNAME for clients that do not understand the DNAME RR.

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.

The database file is no longer needed and is being closed.

The database file is being opened so it can start providing data.

Debug information. An instance of SQLite data source is being created.

Debug information. An instance of SQLite data source is being destroyed.

The object around a database connection 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.

A wrapper object to hold database connection is being initialized.

Debug information. The SQLite data source is loading an SQLite database in the provided file.

This is a debug message. The name given was not found, so the program is searching for the next name higher up the hierarchy (e.g. if www.example.com were queried for and not found, the software searches for the "previous" name, example.com).

The name given was not found, so the program is searching for the next name higher up the hierarchy (e.g. if www.example.com were queried for and not found, the software searches for the "previous" name, example.com). However, this name is not contained in any zone in the data source. This is an error since it indicates a problem in the earlier processing of the query.

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.

An error message indicating that a query requesting a RR for a class other that CH was sent to the static data source (which only handles CH queries).

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 interface to the underlying logger implementation reporting that the debug level (as set by an internally-created string DEBUGn, where n is an integer, e.g. DEBUG22) is above the maximum allowed value and has been reduced to that value. The appearance of this message may indicate a programming error - please submit a bug report.

A message from the interface to the underlying logger implementation reporting that an internally-created string used to set the debug level is not of the correct format (it should be of the form DEBUGn, where n is an integer, e.g. DEBUG22). The appearance of this message indicates a programming error - please submit a bug report.

A message from the interface to the underlying logger implementation reporting that the debug level (as set by an internally-created string DEBUGn, where n is an integer, e.g. DEBUG22) is below the minimum allowed value and has been increased to that value. The appearance of this message may indicate a programming error - please submit a bug report.

A logger destination value was given that was not recognized. The destination should be one of "console", "file", or "syslog".

A logger severity value was given that was not recognized. The severity should be one of "DEBUG", "INFO", "WARN", "ERROR", "FATAL" or "NONE".

Logging has been configured so that output is written to the terminal (console) but the stream on which it is to be written is not recognised. Allowed values are "stdout" and "stderr".

During start-up, BIND 10 detected that the given message identification had been defined multiple times in the BIND 10 code. This indicates a programming error; please submit a bug report.

When reading a message file, more than one $NAMESPACE directive was found. (This directive is used to set a C++ namespace when generating header files during software development.) Such a condition is regarded as an error and the read will be abandoned.

The program was not able to open the specified input message file for the reason given.

An invalid message identification (ID) has been found during the read of a message file. Message IDs should comprise only alphanumeric characters and the underscore, and should not start with a digit.

The $NAMESPACE directive in a message file takes a single argument, a namespace in which all the generated symbol names are placed. This error is generated when the compiler finds a $NAMESPACE directive with more than one argument.

The $NAMESPACE argument in a message file should be a valid C++ namespace. This message is output if the simple check on the syntax of the string carried out by the reader fails.

The $NAMESPACE directive in a message file takes a single argument, a C++ namespace in which all the generated symbol names are placed. This error is generated when the compiler finds a $NAMESPACE directive with no arguments.

Within a message file, message are defined by lines starting with a "%". The rest of the line should comprise the message ID and text describing the message. This error indicates the message compiler found a line in the message file comprising just the "%" and nothing else.

Within a message file, message are defined by lines starting with a "%". The rest of the line should comprise the message ID and text describing the message. This error indicates the message compiler found a line in the message file comprising just the "%" and message identification, but no text.

During start-up a local message file was read. A line with the listed message identification was found in the file, but the identification is not one contained in the compiled-in message dictionary. This message may appear a number of times in the file, once for every such unknown message identification.

There may be several reasons why this message may appear:

- The message ID has been mis-spelled in the local message file.

- The program outputting the message may not use that particular message (e.g. it originates in a module not used by the program.)

- The local file was written for an earlier version of the BIND 10 software and the later version no longer generates that message.

Whatever the reason, there is no impact on the operation of BIND 10.

Originating within the logging code, the program was not able to open the specified output file for the reason given.

Within a message file, the $PREFIX directive takes a single argument, a prefix to be added to the symbol names when a C++ file is created. This error is generated when the compiler finds a $PREFIX directive with more than one argument.

Note: the $PREFIX directive is deprecated and will be removed in a future version of BIND 10.

Within a message file, the $PREFIX directive takes a single argument, a prefix to be added to the symbol names when a C++ file is created. As such, it must adhere to restrictions on C++ symbol names (e.g. may only contain alphanumeric characters or underscores, and may nor start with a digit). A $PREFIX directive was found with an argument (given in the message) that violates those restrictions.

Note: the $PREFIX directive is deprecated and will be removed in a future version of BIND 10.

This is an informational message output by BIND 10 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.

Within a message file, a line starting with a dollar symbol was found (indicating the presence of a directive) but the first word on the line (shown in the message) was not recognised.

The specified error was encountered by the message compiler when writing to the named output file.

The notify_out library tried to send a notify message to the given address, but it appears to be an invalid address. The configuration for secondary nameservers might contain a typographic error, or a different BIND 10 module has forgotten to validate its data before sending this module a notify command. As such, this should normally not happen, and points to an oversight in a different module.

The notify_out library sent a notify message to the nameserver at the given address, but the response did not have the opcode set to NOTIFY. The opcode in the response is printed. Since there was a response, no more notifies will be sent to this server for this notification event.

The notify_out library sent a notify message to the nameserver at the given address, but the query id in the response does not match the one we sent. Since there was a response, no more notifies will be sent to this server for this notification event.

The notify_out library sent a notify message to the nameserver at the given address, but the query name in the response does not match the one we sent. Since there was a response, no more notifies will be sent to this server for this notification event.

The notify_out library sent a notify message to the namesever at the given address, but the reply did not have the QR bit set to one. Since there was a response, no more notifies will be sent to this server for this notification event.

There was an uncaught exception in the handling of a notify reply message, either in the message parser, or while trying to extract data from the parsed message. The error is printed, and notify_out will treat the response as a bad message, but this does point to a programming error, since all exceptions should have been caught explicitly. Please file a bug report. Since there was a response, no more notifies will be sent to this server for this notification event.

The maximum number of retries for the notify target has been exceeded. Either the address of the secondary nameserver is wrong, or it is not responding.

A notify message is sent to the secondary nameserver at the given address.

There was a network error while trying to send a notify message to the given address. The address might be unreachable. The socket error is printed and should provide more information.

There was a network error while trying to read a notify reply message from the given address. The socket error is printed and should provide more information.

The notify message to the given address (noted as address#port) has timed out, and the message will be resent until the max retry limit is reached.

A debug message issued when the NSAS (nameserver address store - part of the resolver) is making a callback into the resolver to retrieve the address records for the specified nameserver.

A debug message issued when the NSAS (nameserver address store - part of the resolver) has retrieved the given address for the specified nameserver through an external query.

The NSAS (nameserver address store - part of the resolver) made a query for a RR for the specified nameserver but received an invalid response. Either the success function was called without a DNS message or the message was invalid on some way. (In the latter case, the error should have been picked up elsewhere in the processing logic, hence the raising of the error here.)

This message indicates an internal error in the NSAS. Please raise a bug report.

A debug message issued when an NSAS (nameserver address store - part of the resolver) lookup for a zone has been canceled.

A debug message issued when the NSAS (nameserver address store - part of the resolver) has been unable to retrieve the specified resource record for the specified nameserver. This is not necessarily a problem - the nameserver may be unreachable, in which case the NSAS will try other nameservers in the zone.

A debug message output when a call is made to the NSAS (nameserver address store - part of the resolver) to obtain the nameservers for the specified zone.

A NSAS (nameserver address store - part of the resolver) debug message reporting the update of a round-trip time (RTT) for a query made to the specified nameserver. The RTT has been updated using the value given and the new RTT is displayed. (The RTT is subject to a calculation that damps out sudden changes. As a result, the new RTT used by the NSAS in future decisions of which nameserver to use is not necessarily equal to the RTT reported.)

A NSAS (nameserver address store - part of the resolver) made a query for a resource record of a particular type and class, but instead received an answer with a different given type and class.

This message indicates an internal error in the NSAS. Please raise a bug report.

A debug message recording that an answer has been received to an upstream query for the specified question. Previous debug messages will have indicated 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 categorized as a referral. However, the received message did not contain any NS RRsets. This may indicate a programming error in the response classification code.

A debug message, the RunningQuery object is querying the NSAS for the nameservers for the specified zone.

A debug message recording that either a NXDOMAIN or an NXRRSET response has been received to an upstream query for the specified question. Previous debug messages will have indicated the server to which the question was sent.

A debug message indicating that a protocol error was received. As there are no retries left, an error will be reported.

A debug message indicating that a protocol error was received and that the resolver is repeating the query to the same nameserver. After this repeated query, there will be the indicated number of retries left.

A debug message, the response to the specified query indicated an error that is not covered by a specific code path. A SERVFAIL will be returned.

This is a debug message and indicates that a RecursiveQuery object found the the specified <name, class, type> tuple in the cache. The instance number at the end of the message indicates which of the two resolve() methods has been called.

This is a debug message and indicates that the look in the cache made by the RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery object has been created to resolve the question. The instance number at the end of the message indicates which of the two resolve() methods has been called.

A debug message recording that a referral response has been received to an upstream query for the specified question. Previous debug messages will have indicated the server to which the question was sent.

A debug message indicating that the last referral message was to the specified zone.

A debug message, the RecursiveQuery::resolve method has been called to resolve the specified <name, class, type> tuple. The first action will be to lookup the specified tuple in the cache. The instance number at the end of the message indicates which of the two resolve() methods has been called.

A debug message, indicating that when RecursiveQuery::resolve queried the cache, a single RRset was found which was put in the answer. The instance number at the end of the message indicates which of the two resolve() methods has been called.

A debug message giving the round-trip time of the last query and response.

This is a debug message and indicates that a RunningQuery object found the specified <name, class, type> tuple in the cache.

This is a debug message and indicates that a RunningQuery object has made a call to its doLookup() method to look up the specified <name, class, type> tuple, the first action of which will be to examine the cache.

A debug message indicating that a RunningQuery's failure callback has been called because all nameservers for the zone in question are unreachable.

A debug message indicating that a RunningQuery's success callback has been called because a nameserver has been found, and that a query is being sent to the specified nameserver.

This is a warning message 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. If seen during normal operation, please submit a bug report.

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 upstream query has timed out and there are no retries left.

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.

This is a debug message output when the resolver received a request for an AXFR (full transfer of a zone) over TCP. Only authoritative servers are able to handle AXFR requests, so the resolver will return an error message to the sender with the RCODE set to NOTIMP.

This is a debug message output when the resolver received a request for an AXFR (full transfer of a zone) over UDP. Only authoritative servers are able to handle AXFR requests (and in any case, an AXFR request should be sent over TCP), so the resolver will return an error message to the sender with the RCODE set to NOTIMP.

During the update of the resolver's configuration parameters, the value of the client timeout was found to be too small. The configuration update was abandoned and the parameters were not changed.

This is 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, included in the message, will give more details. The configuration update is not applied and the resolver parameters were not changed.

This is a debug message output when the resolver configuration has been successfully loaded.

This is a debug message output when the resolver configuration is being updated with the specified information.

This is a debug message indicating that the main resolver object has been created.

This is a debug message from the resolver listing the contents of a received DNS message.

This is a debug message containing details of the response returned by the resolver to the querying system.

This is an error message output when an unhandled exception is caught by the resolver. After this, the resolver will shut itself down. Please submit a bug report.

If the resolver is running in forward mode, this message will appear during startup to list the forward address. If multiple addresses are specified, it will appear once for each address.

This is a debug message indicating that a query received by the resolver has passed a set of checks (message is well-formed, it is allowed by the ACL, it is a supported opcode, etc.) and is being forwarded to upstream servers.

This is a debug message from the resolver noting that an exception occurred during the processing of a received packet. The packet has been dropped.

This is a debug message indicating that the resolver received a request for an IXFR (incremental transfer of a zone). Only authoritative servers are able to handle IXFR requests, so the resolver will return an error message to the sender with the RCODE set to NOTIMP.

During the update of the resolver's configuration parameters, the value of the lookup timeout was found to be too small. The configuration update will not be applied.

This is a debug message noting that parsing of the body of a received message by the resolver failed due to some error (although the parsing of the header succeeded). The message parameters give a textual description of the problem and the RCODE returned.

This error is issued when a resolver configuration update has specified a negative retry count: only zero or positive values are valid. The configuration update was abandoned and the parameters were not changed.

This debug message is issued when resolver has received a DNS packet that was not IN (Internet) class. The resolver cannot handle such packets, so is returning a REFUSED response to the sender.

This is a debug message indicating that the query received by the resolver has passed a set of checks (message is well-formed, it is allowed by the ACL, it is a supported opcode, etc.) and is being processed by the resolver.

The resolver has 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.

This debug message indicates that the resolver received a query that contained the number of entries 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 warning message issued during resolver startup, this indicates that no root addresses have been set. This may be because the resolver will get them from a priming query.

This is 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 debug message is logged when a "print_message" command is received by the resolver over the command channel.

This is 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.

This debug message is produced by the resolver when an incoming query is accepted in terms of the query ACL. The log message shows the query in the form of <query name>/<query type>/<query class>, and the client that sends the query in the form of <Source IP address>#<source port>.

This is an informational message that indicates an incoming query has been dropped by the resolver because of the query ACL. Unlike the RESOLVER_QUERY_REJECTED case, the server does not return any response. The log message shows the query in the form of <query name>/<query type>/<query class>, and the client that sends the query in the form of <Source IP address>#<source port>.

This is an informational message that indicates an incoming query has been rejected by the resolver because of the query ACL. This results in a response with an RCODE of REFUSED. The log message shows the query in the form of <query name>/<query type>/<query class>, and the client that sends the query in the form of <Source IP address>#<source port>.

This is a debug message noting that the resolver is creating a RecursiveQuery object.

This is a debug message noting that the resolver is destroying a RecursiveQuery object.

During the update of the resolver's configuration parameters, the value of the query timeout was found to be too small. The configuration parameters were not changed.

This is a debug message indicating that the resolver has received a DNS message. Depending on the debug settings, subsequent log output will indicate the nature of the message.

This is an informational message that appears at startup noting that the resolver is running in recursive mode.

This debug message is output when resolver creates the main service object (which handles the received queries).

This debug message lists the parameters being set for the resolver. These are: query timeout: the timeout (in ms) used for queries originated by the resolver to upstream servers. Client timeout: the interval to resolve a query by a client: after this time, the resolver sends back a SERVFAIL to the client whilst continuing to resolve 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 client query might require a large number of queries to upstream nameservers. Even if none of these queries timeout, the total time taken to perform all the queries may exceed the client timeout. When this happens, a SERVFAIL is returned to the client, but the resolver continues with the resolution process; data received is added to the cache. However, there comes a time - the lookup timeout - when even the resolver gives up. At this point it will wait for pending upstream queries to complete or timeout and drop the query.

This debug message is generated when a new query ACL is configured for the resolver.

This message gives the address of one of the root servers used by the resolver. It is output during startup and may appear multiple times, once for each root server address.

This informational 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.

This is a debug message noting that the resolver received a DNS response packet on the port on which is it listening for queries. The packet has been ignored.

This is debug message output when 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.

This points to an error in configuration. What was supposed to be a list of IP address - port pairs isn't a list at all but something else.

The server failed to bind to one of the address/port pair it should according to configuration, for reason listed in the message (usually because that pair is already used by other service or missing privileges). The server will try to recover and bind the address/port pairs it was listening to before (if any).

This points to an error in configuration. An address specification in the configuration is missing either an address or port and so cannot be used. The specification causing the error is given in the message.

This points to an error in configuration. An address specification in the configuration malformed. The specification causing the error is given in the message. A valid specification contains an address part (which must be a string and must represent a valid IPv4 or IPv6 address) and port (which must be an integer in the range valid for TCP/UDP ports on your system).

The recovery of old addresses after SRVCOMM_ADDRESS_FAIL also failed for the reason listed.

The condition indicates problems with the server and/or the system on which it is running. The server will continue running to allow reconfiguration, but will not be listening on any address or port until an administrator does so.

Debug message. This lists one address and port value of the set of addresses we are going to listen on (eg. there will be one log message per pair). This appears only after SRVCOMM_SET_LISTEN, but might be hidden, as it has higher debug level.

Debug message indicating that the server is deinitializing the TSIG keyring.

Debug message indicating that the server is initializing the global TSIG keyring. This should be seen only at server start.

Debug message indicating new keyring is being loaded from configuration (either on startup or as a result of configuration update).

This points to an error in configuration. The port in an address specification is outside the valid range of 0 to 65535.

Debug message, noting that the server is about to start listening on a different set of IP addresses and ports than before.

The stats-httpd module was called with a bad command-line argument and will not start.

The stats-httpd module was unable to connect to the BIND 10 command and control bus. A likely problem is that the message bus daemon (b10-msgq) is not running. The stats-httpd module will now shut down.

The stats-httpd daemon will stop listening for requests on the given address and port number.

Debug message indicating that the stats-httpd module is disconnecting from the command and control bus.

The stats-httpd daemon has received new configuration data and will now process it. The (changed) data is printed.

A shutdown command was sent to the stats-httpd module, and it will now shut down.

A status command was sent to the stats-httpd module, and it will respond with 'Stats Httpd is up.' and its PID.

An unknown command has been sent to the stats-httpd module. The stats-httpd module will respond with an error, and the command will be ignored.

An internal error occurred while handling an HTTP request. An HTTP 500 response will be sent back, and the specific error is printed. This is an error condition that likely points to a module that is not responding correctly to statistic requests.

There was a problem initializing the HTTP server in the stats-httpd module upon receiving its configuration data. The most likely cause is a port binding problem or a bad configuration value. The specific error is printed in the message. The new configuration is ignored, and an error is sent back.

The stats-httpd daemon is shutting down.

The stats-httpd daemon will now start listening for requests on the given address and port number.

Debug message indicating that the stats-httpd module is connecting to the command and control bus.

There was a problem initializing the HTTP server in the stats-httpd module upon startup. The most likely cause is that it was not able to bind to the listening port. The specific error is printed, and the module will shut down.

There was a keyboard interrupt signal to stop the stats-httpd daemon. The daemon will now shut down.

The stats-httpd daemon received a configuration update from the configuration manager. However, one of the items in the configuration is unknown. The new configuration is ignored, and an error is sent back. As possible cause is that there was an upgrade problem, and the stats-httpd version is out of sync with the rest of the system.

The stats module was called with a bad command-line argument and will not start.

The stats module was unable to connect to the BIND 10 command and control bus. A likely problem is that the message bus daemon (b10-msgq) is not running. The stats module will now shut down.

This debug message is printed when the stats module has received a configuration update from the configuration manager.

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 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 all statistics that it has collected.

The stats module received a command to show the statistics that it has collected for the given item.

A shutdown command was sent to the stats module and it will now shut down.

A status command was sent to the stats module. It will return a response indicating that it is running normally.

An unknown command has been sent to the stats module. The stats module will respond with an error and the command will be ignored.

This debug message is printed when a request is sent to the boss module to send its data to the stats module.

There was a keyboard interrupt signal to stop the stats module. The daemon will now shut down.

The specification file for the stats module contains a command that is unknown in the implementation. The most likely cause is an installation problem, where the specification file stats.spec is from a different version of BIND 10 than the stats module itself. Please check your installation.

The AXFR transfer for the given zone has failed due to a database problem. The error is shown in the log message.

The AXFR transfer for the given zone has failed due to an internal problem in the bind10 python wrapper library. The error is shown in the log message.

The AXFR transfer for the given zone has failed due to a protocol error. The error is shown in the log message.

A connection to the master server has been made, the serial value in the SOA record has been checked, and a zone transfer has been started.

The AXFR transfer of the given zone was successfully completed.

The given master address is not a valid IP address.

The master port as read from the configuration is not a valid port number.

The TSIG key string as read from the configuration does not represent a valid TSIG key.

The zone class as read from the configuration is not a valid DNS class.

There was a problem reading from the command and control channel. The most likely cause is that xfrin the msgq daemon is not running.

There was an error while the given command was being processed. The error is given in the log message.

There was an error opening a connection to the master. The error is shown in the log message.

There was an error importing the python DNS module pydnspp. The most likely cause is a PYTHONPATH problem.

There was a problem sending a message to the xfrout module or the zone manager. This most likely means that the msgq daemon has quit or was killed.

There was a problem sending a message to the zone manager. This most likely means that the msgq daemon has quit or was killed.

There was an internal command to retransfer the given zone, but the zone is not known to the system. This may indicate that the configuration for xfrin is incomplete, or there was a typographical error in the zone name in the configuration.

An informational message, this is output when the resolver starts up.

There was a keyboard interrupt signal to stop the xfrin daemon. The daemon will now shut down.

An uncaught exception was raised while running the xfrin daemon. The exception message is printed in the log message.

The transfer of the given zone has been completed successfully, or was aborted due to a shutdown event.

An uncaught exception was encountered while sending the response to an AXFR query. The error message of the exception is included in the log message, but this error most likely points to incomplete exception handling in the code.

A transfer out for the given zone failed. An error response is sent to the client. The given rcode is the rcode that is set in the error response. This is either NOTAUTH (we are not authoritative for the zone), SERVFAIL (our internal database is missing the SOA record for the zone), or REFUSED (the limit of simultaneous outgoing AXFR transfers, as specified by the configuration value Xfrout/max_transfers_out, has been reached).

A transfer out of the given zone has started.

The TSIG key string as read from the configuration does not represent a valid TSIG key.

There was a problem reading from the command and control channel. The most likely cause is that the msgq daemon is not running.

There was a problem reading a response from another module over the command and control channel. The most likely cause is that the configuration manager b10-cfgmgr is not running.

There was a socket error while contacting the b10-auth daemon to fetch a transfer request. The auth daemon may have shutdown.

There was a general error handling an xfrout query. The error is shown in the message. In principle this error should not appear, and points to an oversight catching exceptions in the right place. However, to ensure the daemon keeps running, this error is caught and reported.

There was an error importing a python module. One of the modules needed by xfrout could not be found. This suggests that either some libraries are missing on the system, or the PYTHONPATH variable is not correct. The specific place where this library needs to be depends on your system and your specific installation.

New configuration settings have been sent from the configuration manager. The xfrout daemon will now apply them.

The xfrout daemon is now done reading the new configuration settings received from the configuration manager.

The xfrout daemon received a command on the command channel that NOTIFY packets should be sent for the given zone.

There was a parse error while reading an incoming query. The parse error is shown in the log message. A remote client sent a packet we do not understand or support. The xfrout request will be ignored. In general, this should only occur for unexpected problems like memory allocation failures, as the query should already have been parsed by the b10-auth daemon, before it was passed here.

There was an error processing a transfer request. The error is included in the log message, but at this point no specific information other than that could be given. This points to incomplete exception handling in the code.

The xfrout process silently dropped a request to transfer zone to given host. This is required by the ACLs. The %1 and %2 represent the zone name and class, the %3 and %4 the IP address and port of the peer requesting the transfer.

The xfrout process rejected (by REFUSED rcode) a request to transfer zone to given host. This is because of ACLs. The %1 and %2 represent the zone name and class, the %3 and %4 the IP address and port of the peer requesting the transfer.

The xfrout daemon received a shutdown command from the command channel and will now shut down.

There was an error receiving the file descriptor for the transfer request. Normally, the request is received by b10-auth, and passed on to the xfrout daemon, so it can answer directly. However, there was a problem receiving this file descriptor. The request will be ignored.

The unix socket file xfrout needs for contact with the auth daemon already exists, and needs to be removed first, but there is a problem removing it. It is likely that we do not have permission to remove this file. The specific error is show in the log message. The xfrout daemon will shut down.

When shutting down, the xfrout daemon tried to clear the unix socket file used for communication with the auth daemon. It failed to remove the file. The reason for the failure is given in the error message.

There was an error while calling select() on the socket that informs the xfrout daemon that a new xfrout request has arrived. This should be a result of rare local error such as memory allocation failure and shouldn't happen under normal conditions. The error is included in the log message.

There was a keyboard interrupt signal to stop the xfrout daemon. The daemon will now shut down.

The current transfer is aborted, as the xfrout daemon is shutting down.

While starting up, the xfrout daemon tried to clear the unix domain socket needed for contacting the b10-auth daemon to pass requests on, but the file is in use. The most likely cause is that another xfrout daemon process is still running. This xfrout daemon (the one printing this message) will not start.

An error was encountered on the command channel. The message indicates the nature of the error.

The value specified in the configuration for the refresh jitter is too large so its value has been set to the maximum of 0.5.

An informational message output when the zone manager was being run at a terminal and it was terminated via a keyboard interrupt signal.

This is a debug message indicating that the zone of the specified class is being loaded.

A command received by the zone manager from the Auth module did not contain the address of the master server from which a NOTIFY message was received. This may be due to an internal programming error; please submit a bug report.

When loading the named zone of the specified class the zone manager discovered that the data did not contain an SOA record. The load has been abandoned.

An attempt was made to stop the timer thread (used to track when zones should be refreshed) but it was not running. This may indicate an internal program error. Please submit a bug report.

A command received by the zone manager from another BIND 10 module did not contain the class of the zone on which the zone manager should act. This may be due to an internal programming error; please submit a bug report.

A command received by the zone manager from another BIND 10 module did not contain the name of the zone on which the zone manager should act. This may be due to an internal programming error; please submit a bug report.

This is a debug message indicating that the zone manager has received a NOTIFY command over the command channel. The command is sent by the Auth process when it is acting as a slave server for the zone and causes the zone manager to record the master server for the zone and start a timer; when the timer expires, the master will be polled to see if it contains new data.

This is a debug message indicating that the zone manager has received a SHUTDOWN command over the command channel from the Boss process. It will act on this command and shut down.

This is a warning message indicating that the zone manager has received the stated command over the command channel. The command is not known to the zone manager and although the command is ignored, its receipt may indicate an internal error. Please submit a bug report.

This is a debug message indicating that the zone manager has received an XFRIN FAILED command over the command channel. The command is sent by the Xfrin process when a transfer of zone data into the system has failed, and causes the zone manager to schedule another transfer attempt.

This is a debug message indicating that the zone manager has received an XFRIN SUCCESS command over the command channel. The command is sent by the Xfrin process when the transfer of zone data into the system has succeeded, and causes the data to be loaded and served by BIND 10.

The zone manager is refreshing the named zone of the specified class with updated information.

An attempt to wait for input from a socket failed. The failing operation is a call to the operating system's select() function, which failed for the given reason.

The zone manager attempted to send a command to the named BIND 10 module, but the send failed. The session between the modules has been closed.

The zonemgr process was not able to be started because it could not connect to the command channel daemon. The most usual cause of this problem is that the daemon is not running.

The zonemgr process was not able to be started because it timed out when connecting to the command channel daemon. The most usual cause of this problem is that the daemon is not running.

A debug message, output when the zone manager has shut down completely.

A debug message output when the zone manager starts up.

This message is issued when an attempt is made to start the timer thread (which keeps track of when zones need a refresh) but one is already running. It indicates either an error in the program logic or a problem with stopping a previous instance of the timer. Please submit a bug report.

An XFRIN operation has failed but the zone that was the subject of the operation is not being managed by the zone manager. This may indicate an error in the program (as the operation should not have been initiated if this were the case). Please submit a bug report.

A NOTIFY was received but the zone that was the subject of the operation is not being managed by the zone manager. This may indicate an error in the program (as the operation should not have been initiated if this were the case). Please submit a bug report.

An XFRIN operation has succeeded but the zone received is not being managed by the zone manager. This may indicate an error in the program (as the operation should not have been initiated if this were the case). Please submit a bug report.