[Kea-users] DDNS subsequent failure after successful CHG_ADD

[Jason Guy]

The override-* options are more about honoring the client's wishes in terms
of DDNS, as explained in this section of the docs
<https://ftp.isc.org/isc/kea/1.5.0/doc/kea-guide.html#dhcp4-ddns-config>.
>
> kea-dhcp4 follows the behavior prescribed for DHCP servers in RFC 4702
> <http://tools.ietf.org/html/rfc4702>. 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*
> <https://ftp.isc.org/isc/kea/1.5.0/doc/kea-guide.html#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,
Jason

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 the
> > 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 added
> >> the
> >> 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 the
> >> address mapping for FQDN, wkst7.lan., with an RCODE: 8
> >> DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID yyy: Transaction outcome
> >> Status: Failed, Event: UPDATE_FAILED_EVT,  Forward change: failed,
> >> 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
> >> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20190206/f5a7fab2/attachment.htm>