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 <mro...@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@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/kea-users > _______________________________________________ > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users >
_______________________________________________ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users