[Kea-users] DDNS subsequent failure after successful CHG_ADD
mrobti at insiberia.net
Wed Feb 6 20:26:12 UTC 2019
On 2019-02-06 20:02, Jason Guy wrote:
> The override-* options are more about honoring the client's wishes in
> terms of DDNS, as explained in this section of the docs .
I understand the docs, but due to the error I showed, my question was,
maybe client is not requesting DNS update but my override settings force
the DNS update anyway which cause the error. Though I think probably it
is not this and Kea DDNS server is making the duplicate DNSUPDATE
request which is failing (cuz it already exists?). I'm looking for
advice if I should ignore the error or if it's caused by my settings or
if it's a Kea bug.
>> kea-dhcp4 follows the behavior prescribed for DHCP servers in RFC
>> 4702 . It is important to keep in mind that kea-dhcp4 provides
>> the initial decision making of when and what to update and forwards
>> that information to D2 in the form of NCRs. Carrying out the actual
>> DNS updates and dealing with such things as conflict resolution are
>> within the purview of D2 itself (Chapter 12, _The DHCP-DDNS Server_
>> ). This section describes when kea-dhcp4 will generate NCRs and
>> the configuration parameters that can be used to influence this
>> decision. It assumes that the ENABLE-UPDATES parameter is true.
>> ...the DHCP client states that it intends to do the forward DNS
>> updates and the server should do the reverse updates. By default,
>> kea-dhcp4 will honor the client's wishes and generate a DDNS request
>> to the D2 server to update only reverse DNS data.
>> - The parameter OVERRIDE-CLIENT-UPDATE can be used to instruct the
>> server to override client delegation requests. When this parameter
>> is true, kea-dhcp4 will disregard requests for client delegation and
>> generate a DDNS request to update both forward and reverse DNS data.
>> - The parameter, OVERRIDE-NO-UPDATE, can be used to instruct the
>> server to disregard the client's wishes. When this parameter is
>> true, kea-dhcp4 will generate DDNS update requests to kea-dhcp-ddns
>> even if the client requests that no updates be done.
> Hope this is more clear,
> On Wed, Feb 6, 2019 at 12:14 PM MRob <mrobti at insiberia.net> wrote:
>>> I just commented on your other thread.
>> Thank you, our version of pdns is quite old (from repo) so I hope
>> upgrading it is the solution. I will report back.
>>> Does the PDNS record you are
>>> trying to update already exist, and does the DHCID record match
>>> one in the PDNS records?
>> Yes, the first CHG_ADD has populated DHCID and correct forward and
>> reverse entries. Thats why I ask, maybe I can ignore this error. I
>> wasn't sure if setting override-*-update was too aggressive
>>>> Initial forward and reverse DNSUPDATE commands succeed:
>>>> DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID xxx: successfully
>>>> DNS mapping addition for this request: Type: 0 (CHG_ADD)
>>>> But Kea does another CHG_ADD only a minute later and it fails:
>>>> DHCP_DDNS_FORWARD_REPLACE_REJECTED DNS Request ID yyy: Server,
>>>> 10.10.1.254 port:5353, rejected a DNS update request to replace
>>>> address mapping for FQDN, wkst7.lan., with an RCODE: 8
>>>> DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID yyy: Transaction
>>>> Status: Failed, Event: UPDATE_FAILED_EVT, Forward change:
>>>> Reverse change: failed, request: Type: 0 (CHG_ADD)
>>>> Is this a problem or can it be ignored? Is it due to setting
>>>> "override-no-update": true and "override-client-update": true?
>>>> Kea-users mailing list
>>>> Kea-users at lists.isc.org
>> Kea-users mailing list
>> Kea-users at lists.isc.org
>  http://tools.ietf.org/html/rfc4702
More information about the Kea-users