From: Thomas Markwalder Date: Mon, 5 Jun 2023 17:58:30 +0000 (-0400) Subject: [#2276] Updated the ARM X-Git-Tag: Kea-2.5.0~47 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=00fa013ca3881bf2fb4f92822f9869f2f83af1b4;p=thirdparty%2Fkea.git [#2276] Updated the ARM modified: doc/sphinx/arm/dhcp4-srv.rst doc/sphinx/arm/dhcp6-srv.rst --- diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst index 34fcfcb812..4319fcc68e 100644 --- a/doc/sphinx/arm/dhcp4-srv.rst +++ b/doc/sphinx/arm/dhcp4-srv.rst @@ -3441,7 +3441,7 @@ DDNS-related parameters are split into two groups: - ``ddns-generated-prefix`` - ``ddns-qualifying-suffix`` - ``ddns-update-on-renew`` - - ``ddns-use-conflict-resolution`` + - ``ddns-conflict-resolution-mode`` - ``ddns-ttl-percent`` - ``hostname-char-set`` - ``hostname-char-replacement`` @@ -3481,7 +3481,7 @@ The default configuration and values would appear as follows: "ddns-generated-prefix": "myhost", "ddns-qualifying-suffix": "", "ddns-update-on-renew": false, - "ddns-use-conflict-resolution": true, + "ddns-conflict-resolution-mode": "check-with-dhcid", "hostname-char-set": "", "hostname-char-replacement": "", ... @@ -3527,18 +3527,45 @@ to add DNS entries or they were somehow lost by the DNS server. Setting ``ddns-update-on-renew`` to ``true`` may impact performance, especially for servers with numerous clients that renew often. -The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. -The value of this parameter is passed by :iscman:`kea-dhcp4` to D2 with each DNS update -request. When ``true`` (the default value), D2 employs conflict resolution, -as described in `RFC 4703 `__, when -attempting to fulfill the update request. When ``false``, D2 simply attempts -to update the DNS entries per the request, regardless of whether they -conflict with existing entries owned by other DHCPv4 clients. +The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. This +boolean parameter was passed through to D2 and enabled or disabled conflict resolution +as described in `RFC 4703 `__. Beginning with +Kea 2.4.0, it is deprecated and replaced by ``ddns-conflict-resolution-mode`` which +offers four modes of conflict resolution-related behavior: + + - ``check-with-dhcid`` - The default mode, it instructs D2 to carry out RFC + 4703-compliant conflict resolution. Existing DNS entries may only be + overwritten if they have a DHCID record and it matches the client's DHCID. + This is equivalent to ``ddns-use-conflict-resolution``: true; + + - ``no-check-with-dhcid`` - Existing DNS entries may be overwritten by any + client, whether or not those entries include a DHCID record. The new entries + will include a DHCID record for the client to whom they belong. + This is equivalent to ``ddns-use-conflict-resolution``: false; + + - ``check-exists-with-dhcid`` - Existing DNS entries may only be overwritten + if they have a DHCID record. The DHCID record need not match the client's DHCID. + This mode provides a way to protect static DNS entries (those that do not have + a DHCID record) while allowing dynamic entries (those that do have a DHCID + record) to be overwritten by any client. This behavior was not supported + prior to Kea 2.4.0. + + - ``no-check-without-dhcid`` - Existing DNS entries may be overwritten by + any client. New entries will not include DHCID records. This behavior was + not supported prior to Kea 2.4.0. .. note:: - Setting ``ddns-use-conflict-resolution`` to ``false`` disables the overwrite - safeguards that the rules of conflict resolution (from + For backward compatibility, ddns-use-conflict-resolution is still accepted in + JSON configuration. The server will replace the value internally, with the + ``ddns-conflict-resolution-mode`` and an appropriate vavlue: ` + `check-with-dhcid`` for ``true`` and ``no-check-with-dhcid`` for ``false``. + +.. note:: + + Setting ``ddns-conflict-resolution-mode`` to any value other than + ``check-with-dhcid`` disables the one or more overwrite safeguards + that the rules of conflict resolution (from `RFC 4703 `__) are intended to prevent. This means that existing entries for an FQDN or an IP address made for Client-A can be deleted or replaced by entries diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst index d3529c4890..adb0764f3c 100644 --- a/doc/sphinx/arm/dhcp6-srv.rst +++ b/doc/sphinx/arm/dhcp6-srv.rst @@ -3034,7 +3034,7 @@ DDNS-related parameters are split into two groups: - ``ddns-generated-prefix`` - ``ddns-qualifying-suffix`` - ``ddns-update-on-renew`` - - ``ddns-use-conflict-resolution`` + - ``ddns-conflict-resolution-mode`` - ``ddns-ttl-percent`` - ``hostname-char-set`` - ``hostname-char-replacement`` @@ -3074,7 +3074,7 @@ The default configuration and values would appear as follows: "ddns-generated-prefix": "myhost", "ddns-qualifying-suffix": "", "ddns-update-on-renew": false, - "ddns-use-conflict-resolution": true, + "ddns-conflict-resolution-mode": "check-with-dhcid", "hostname-char-set": "", "hostname-char-replacement": "", ... @@ -3120,23 +3120,50 @@ to add DNS entries or they were somehow lost by the DNS server. Setting ``ddns-update-on-renew`` to ``true`` may impact performance, especially for servers with numerous clients that renew often. -The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. -The value of this parameter is passed by :iscman:`kea-dhcp6` to D2 with each DNS update -request. When ``true`` (the default value), D2 employs conflict resolution, -as described in `RFC 4703 `__, when -attempting to fulfill the update request. When ``false``, D2 simply attempts -to update the DNS entries per the request, regardless of whether they -conflict with existing entries owned by other DHCPv6 clients. +The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. This +boolean parameter was passed through to D2 and enabled or disabled conflict resolution +as described in `RFC 4703 `__. Beginning with +Kea 2.4.0, it is deprecated and replaced by ``ddns-conflict-resolution-mode`` which +offers four modes of conflict resolution-related behavior: + + - ``check-with-dhcid`` - The default mode, it instructs D2 to carry out RFC + 4703-compliant conflict resolution. Existing DNS entries may only be + overwritten if they have a DHCID record and it matches the client's DHCID. + This is equivalent to ``ddns-use-conflict-resolution``: true; + + - ``no-check-with-dhcid`` - Existing DNS entries may be overwritten by any + client, whether or not those entries include a DHCID record. The new entries + will include a DHCID record for the client to whom they belong. + This is equivalent to ``ddns-use-conflict-resolution``: false; + + - ``check-exists-with-dhcid`` - Existing DNS entries may only be overwritten + if they have a DHCID record. The DHCID record need not match the client's DHCID. + This mode provides a way to protect static DNS entries (those that do not have + a DHCID record) while allowing dynamic entries (those that do have a DHCID + record) to be overwritten by any client. This behavior was not supported + prior to Kea 2.4.0. + + - ``no-check-without-dhcid`` - Existing DNS entries may be overwritten by + any client. New entries will not include DHCID records. This behavior was + not supported prior to Kea 2.4.0. .. note:: - Setting ``ddns-use-conflict-resolution`` to ``false`` disables the overwrite - safeguards that the rules of conflict resolution (from + For backward compatibility, ddns-use-conflict-resolution is still accepted in + JSON configuration. The server will replace the value internally, with the + ``ddns-conflict-resolution-mode`` and an appropriate vavlue: ` + `check-with-dhcid`` for ``true`` and ``no-check-with-dhcid`` for ``false``. + +.. note:: + + Setting ``ddns-conflict-resolution-mode`` to any value other than + ``check-with-dhcid`` disables the one or more overwrite safeguards + that the rules of conflict resolution (from `RFC 4703 `__) are intended to prevent. This means that existing entries for an FQDN or an IP address made for Client-A can be deleted or replaced by entries for Client-B. Furthermore, there are two scenarios by which entries - for multiple clients for the same key (e.g. FQDN or IP) can be created. + for multiple clients for the same key (e.g. FQDN or IP) can be created 1. Client-B uses the same FQDN as Client-A but a different IP address. In this case, the forward DNS entries (AAAA and DHCID RRs) for