path: root/src/bin/ddns/ddns_messages.mes

# 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
# <topsrcdir>/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.