|
@@ -16,10 +16,26 @@
|
|
|
# of the libddns_messages python module.
|
|
|
|
|
|
% LIBDDNS_UPDATE_ERROR update client %1 for zone %2: %3
|
|
|
-TBD
|
|
|
+Debug message. An error is found in processing a dynamic update
|
|
|
+request. This log message is used for general errors that are not
|
|
|
+normally expected to happen. So, in general, it would mean some
|
|
|
+problem in the client implementation or an interoperability issue
|
|
|
+with this implementation. The client's address, the zone name and
|
|
|
+class, and description of the error are logged.
|
|
|
|
|
|
% LIBDDNS_UPDATE_FORWARD_FAIL update client %1 for zone %2: update forwarding not supported
|
|
|
-TBD
|
|
|
+Debug message. An update request is sent to a secondary server. This
|
|
|
+is not necessarily mean invalid, but this implementation does not yet
|
|
|
+support update forwarding as specified in Section 6 of RFC2136 and it
|
|
|
+will simply return a response with an RCODE of NOTIMP to the client.
|
|
|
+The client's address and the zone name/class are logged.
|
|
|
|
|
|
% LIBDDNS_UPDATE_NOTAUTH update client %1 for zone %2: not authoritative for update zone
|
|
|
-TBD
|
|
|
+Debug message. An update request for a zone for which the receiving
|
|
|
+server has authority. In theory this is not an unexpected event, but
|
|
|
+there are client implementations that could send update requests
|
|
|
+carelessly, so it may not necessarily be so uncommon in practice. If
|
|
|
+possible, you may want to check the implementation or configuration of
|
|
|
+those clients to suppress the requests. As specified in Section 3.1
|
|
|
+of RFC2136, the receiving server will return a response with an RCODE
|
|
|
+of NOTAUTH.
|