# Copyright (C) 2011 Internet Systems Consortium, Inc. ("ISC") # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted, provided that the above # copyright notice and this permission notice appear in all copies. # # THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH # REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, # INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM # LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. # No namespace declaration - these constants go in the global namespace # of the ddns messages python module. # When you add a message to this file, it is a good idea to run # /tools/reorder_message_file.py to make sure the # messages are in the correct order. % DDNS_ACCEPT_FAILURE error accepting a connection: %1 There was a low-level error when we tried to accept an incoming connection (probably coming from b10-auth). We continue serving on whatever other connections we already have, but this connection is dropped. The reason is logged. % DDNS_AUTH_DBFILE_UPDATE updated auth DB file to %1 b10-ddns was notified of updates to the SQLite3 DB file that b10-auth uses for the underlying data source and on which b10-ddns needs to make updates. b10-ddns then updated its internal setup so further updates would be made on the new DB. % DDNS_CC_SESSION_ERROR error reading from cc channel: %1 There was a problem reading from the command and control channel. The most likely cause is that the msgq process is not running. % DDNS_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response 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. % DDNS_CONFIG_ERROR error found in configuration data: %1 The ddns process encountered an error when installing the configuration at startup time. Details of the error are included in the log message. % DDNS_CONFIG_HANDLER_ERROR failed to update ddns configuration: %1 An update to b10-ddns configuration was delivered but an error was found while applying them. None of the delivered updates were applied to the running b10-ddns system, and the server will keep running with the existing configuration. If this happened in the initial configuration setup, the server will be running with the default configurations. % DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2 There was an error on a connection with the b10-auth server (or whatever connects to the ddns daemon). This might be OK, for example when the authoritative server shuts down, the connection would get closed. It also can mean the system is busy and can't keep up or that the other side got confused and sent bad data. % DDNS_GET_REMOTE_CONFIG_FAIL failed to get %1 module configuration %2 times: %3 b10-ddns tried to get configuration of some remote modules for its operation, but it failed. The most likely cause of this is that the remote module has not fully started up and b10-ddns couldn't get the configuration in a timely fashion. b10-ddns attempts to retry it a few times, imposing a short delay, hoping it eventually succeeds if it's just a timing issue. The number of total failed attempts is also logged. If it reaches an internal threshold b10-ddns considers it a fatal error and terminates. Even in that case, if b10-ddns is configured as a "dispensable" component (which is the default), the parent ("init") process will restart it, and there will be another chance of getting the remote configuration successfully. These are not the optimal behavior, but it's believed to be sufficient in practice (there would normally be no failure in the first place). If it really causes an operational trouble other than having a few of these log messages, please submit a bug report; there can be several ways to make it more sophisticated. Another, less likely reason for having this error is because the remote modules are not actually configured to run. If that's the case fixing the configuration should solve the problem - either by making sure the remote module will run or by not running b10-ddns (without these remote modules b10-ddns is not functional, so there's no point in running it in this case). % DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1 There was a problem in the lower level module handling configuration and control commands. This could happen for various reasons, but the most likely cause is that the configuration database contains a syntax error and ddns failed to start at initialization. A detailed error message from the module will also be displayed. % DDNS_NEW_CONN new connection on file descriptor %1 from %2 Debug message. We received a connection and we are going to start handling requests from it. The file descriptor number and the address where the request comes from is logged. The connection is over a unix domain socket and is likely coming from a b10-auth process. % DDNS_RECEIVED_AUTH_UPDATE received configuration updates from auth server b10-ddns is notified of updates to b10-auth configuration (including a report of the initial configuration) that b10-ddns might be interested in. % DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received The ddns process received a shutdown command from the command channel and will now shut down. % DDNS_RECEIVED_ZONEMGR_UPDATE received configuration updates from zonemgr b10-ddns is notified of updates to b10-zonemgr's configuration (including a report of the initial configuration). It may possibly contain changes to the secondary zones, in which case b10-ddns will update its internal copy of that configuration. % DDNS_REQUEST_PARSE_FAIL failed to parse update request: %1 b10-ddns received an update request via b10-auth, but the received data failed to pass minimum validation: it was either broken wire format data for a valid DNS message (e.g. it's shorter than the fixed-length header), or the opcode is not update, or TSIG is included in the request but it fails to validate. Since b10-auth should have performed this level of checks, such an error shouldn't be detected at this stage and should rather be considered an internal bug. This event is therefore logged at the error level, and the request is simply dropped. Additional information of the error is also logged. % DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running) b10-ddns received a new update request from a client over TCP, but the number of TCP clients being handled by the server already reached the configured quota, so the latest client was rejected by closing the connection. The administrator may want to check the status of b10-ddns, and if this happens even if the server is not very busy, the quota may have to be increased. Or, if it's more likely to be malicious or simply bogus clients that somehow keep the TCP connection open for a long period, maybe they should be rejected with an appropriate ACL configuration or some lower layer filtering. The number of existing TCP clients are shown in the log, which should be identical to the current quota. % DDNS_RESPONSE_SOCKET_SEND_FAILED failed to send update response to %1: %2 Network I/O error happens in sending an update response. The client's address that caused the error and error details are also logged. % DDNS_RESPONSE_TCP_SOCKET_SEND_FAILED failed to complete sending update response to %1 over TCP b10-ddns had tried to send an update response over TCP, and it hadn't been completed at that time, and a follow-up attempt to complete the send operation failed due to some network I/O error. While a network error can happen any time, this event is quite unexpected for two reasons. First, since the size of a response to an update request should be generally small, it's unlikely that the initial attempt didn't fail but wasn't completed. Second, since the first attempt succeeded and the TCP connection had been established in the first place, it's more likely for the subsequent attempt to succeed. In any case, there may not be able to do anything to fix it at the server side, but the administrator may want to check the general reachability with the client address. % DDNS_SECONDARY_ZONES_UPDATE updated secondary zone list (%1 zones are listed) b10-ddns has successfully updated the internal copy of secondary zones obtained from b10-zonemgr, based on a latest update to zonemgr's configuration. The number of newly configured (unique) secondary zones is logged. % DDNS_SECONDARY_ZONES_UPDATE_FAIL failed to update secondary zone list: %1 An error message. b10-ddns was notified of updates to a list of secondary zones from b10-zonemgr and tried to update its own internal copy of the list, but it failed. This can happen if the configuration contains an error, and b10-zonemgr should also reject that update. Unfortunately, in the current implementation there is no way to ensure that both zonemgr and ddns have consistent information when an update contains an error; further, as of this writing zonemgr has a bug that it could partially update the list of secondary zones if part of the list has an error (see Trac ticket #2038). b10-ddns still keeps running with the previous configuration, but it's strongly advisable to check log messages from zonemgr, and if it indicates there can be inconsistent state, it's better to restart the entire BIND 10 system (just restarting b10-ddns wouldn't be enough, because zonemgr can have partially updated configuration due to bug #2038). The log message contains an error description, but it's intentionally kept simple as it's primarily a matter of zonemgr. To know the details of the error, log messages of zonemgr should be consulted. % DDNS_SESSION session arrived on file descriptor %1 A debug message, informing there's some activity on the given file descriptor. It will be either a request or the file descriptor will be closed. See following log messages to see what of it. % DDNS_SHUTDOWN ddns server shutting down The ddns process is shutting down. It will no longer listen for new commands or updates. Any command or update that is being addressed at this moment will be completed, after which the process will exit. % DDNS_STARTED ddns server is running and listening for updates The ddns process has successfully started and is now ready to receive commands and updates. % DDNS_START_FORWARDER_ERROR Error from b10-auth when requesting DDNS UPDATE forwarding: %1 There was an error response from b10-auth to the command to start forwarding DDNS UPDATE messages to b10-ddns. It is almost certain that DDNS UPDATE messages are not handled now, and that they will be responded to with a NOTIMP error code, even though b10-ddns is running. The error message is printed, and additional information may be found in the b10-auth log output. Since this is an error that is sent by the b10-auth module, it should have more information as to what the actual problem was. % DDNS_START_FORWARDER_FAIL Error sending request for DDNS UPDATE forwarding to b10-auth: %1 There was an error when attempting to send b10-auth the request to forward DDNS UPDATE messages to the b10-ddns module. This points to an internal problem using the inter-module messaging system. This needs to be inspected, as it is almost certain that DDNS UPDATE messages are not handled now. The specific error is printed in the log message. % DDNS_STOPPED ddns server has stopped The ddns process has successfully stopped and is no longer listening for or handling commands or updates, and will now exit. % DDNS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down There was a keyboard interrupt signal to stop the ddns process. The process will now shut down. % DDNS_STOP_FORWARDER_ERROR Error from b10-auth when requesting to stop DDNS UPDATE forwarding: %1 There was an error response from b10-auth to the command to stop forwarding DDNS UPDATE messages to b10-ddns. This specific error may not be fatal; instead of returning NOTIMP for future DDNS UPDATE messages, it will return SERVFAIL. However, this does point to an underlying problem in the messaging system, and should be inspected. The error message is printed, and additional information may be found in the b10-auth log output. % DDNS_STOP_FORWARDER_FAIL Error sending request to stop DDNS UPDATE forwarding to b10-auth: %1 There was an error when attempting to send b10-auth the request to stop forwarding DDNS UPDATE messages to the b10-ddns module. This points to an internal problem using the inter-module messaging system. This specific error may not be fatal; instead of returning NOTIMP for future DDNS UPDATE messages, it will return SERVFAIL. However, this does point to an underlying problem in the messaging system, and should be inspected. The specific error is printed in the log message. % DDNS_UPDATE_NOTIFY notified %1 of updates to %2 Debug message. b10-ddns has made updates to a zone based on an update request and has successfully notified an external module of the updates. The notified module will use that information for updating its own state or any necessary protocol action such as zone reloading or sending notify messages to secondary servers. % DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3 b10-ddns has made updates to a zone based on an update request and tried to notify an external component of the updates, but the notification fails. One possible cause of this is that the external component is not really running, although it will be less likely to happen in practice because these components will normally be configured to run when the server provides the authoritative DNS service; ddns is rather optional among them. Severity of this error for the receiving components depends on the type of the component. If it's b10-xfrout, this means DNS notify messages won't be sent to secondary servers of the zone. It's suboptimal, but not necessarily critical as the secondary servers will try to check the zone's status periodically. If it's b10-auth and the notification was needed to have it reload the corresponding zone, it's more serious because b10-auth won't be able to serve the new version of the zone unless some explicit recovery action is taken. So the administrator needs to examine this message and takes an appropriate action. In either case, this notification is generally expected to succeed; so the fact it fails itself means there's something wrong in the BIND 10 system, and it would be advisable to check other log messages.