Thanks for the response, Rick. I increased the logging of Kea and I can confirm that Kea is seeing the FQDN (81) option as partial as you suspected.
Jan 15 13:53:40 d1 kea-dhcp4[612798]: options: Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=012, len=010: "win11-test" (string) Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=050, len=004: 192.168.100.60 (ipv4-address) Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=053, len=001: 3 (uint8) Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=054, len=004: 192.168.100.50 (ipv4-address) Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=055, len=014: 1(uint8) 3(uint8) 6(uint8) 15(uint8) 31(uint8) 33(uint8) 43(uint8) 44(uint8) 46(uint8) 47(uint8) 119(uint8) 121(uint8) 249(uint8) 252(uint8) Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=060, len=008: "MSFT 5.0" (string) Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=061, len=007: 01:52:54:00:b1:c6:7d Jan 15 13:53:40 d1 kea-dhcp4[612798]: type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0), domain-name='win11-test.win-domain.com' (partial) Here's a summary of the DORA flow - The initial DHCPDISCOVER address from the Windows client only contains the Hostname (12), in this case, "win11-test". When crafting the DHCPOFFER, Kea updates the hostname to include the configured hostname set in Kea. The DHCPOFFER now contains a Hostname (12) of "win11-test.win-test.com". When the Windows client sends the DHCPREQUEST, the Hostname (12) is the name of the client "win11-test" but now the FQDN (81) option is included with the active directory domain "win11-test.win-domain.com" (without a zero-length label). Kea then fully qualifies the incoming FQDN as it sees it as partial. The FQDN of the DHCPACK is now "win11-test.win-domain.com.win-test.com". I was looking around for Gitlab issues and came across https://gitlab.isc.org/isc-projects/kea/-/issues/1989. On the issue, it states that the DDNS tuning hook should be able to violate the RFC and select a preferred option. "that you can actually do now with DDNS tuning hook" Unfortunately the DDNS tuning hook is a paid hook and I am unable to test if that is a valid workaround unless I commit to purchasing the hook. [https://gitlab.isc.org/uploads/-/system/project/avatar/26/kea-logo-100x70.png]<https://gitlab.isc.org/isc-projects/kea/-/issues/1989> Issues with qualifying suffix when clients use a combination of Hostname and Client FQDN option (#1989) · Issues · ISC Open Source Projects / Kea · GitLab<https://gitlab.isc.org/isc-projects/kea/-/issues/1989> A client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of... gitlab.isc.org ________________________________ From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Rick Frey <grib...@gmail.com> Sent: Monday, January 8, 2024 10:48 PM To: Kea user's list <kea-users@lists.isc.org> Subject: [External] - Re: [Kea-users] DDNS remove domain included in fqdn option Per Kea docs, I believe kea will prefer the FQDN (81) option over the Hostname (12) option if both are provided from client. Once name is derived from either option, Kea then determines if name is fully qualified or a partial. In your case, it seems that Kea determines the value in FQDN (81) is a partial name so it appends the ddns-qualifying-suffix. Per https://datatracker.ietf.org/doc/html/rfc4702#section-2.3, the domain name portion of the FQDN option can be a fully qualified domain name or a partial name that is not fully qualified. Where “To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label. To send a partial name, the Domain Name field is set to the DNS encoded domain name without the terminating zero-length label.”. Would need a packet capture to verify, but assuming your Windows clients are not terminating the FQDN value with a terminating zero-length label since Kea looks to be determining that the value is a partial name. Guessing that the Windows clients may be misconfigured where they are not using a fully qualified domain name or Windows client is not honoring RFC4702 (or Kea not properly parsing FQDN option 81). With that said, I don’t see a means to configure Kea to ignore the FQDN (81) option if Hostname (12) is also provided. Others may have some ideas if there is means to configure Kea to ignore/replace the FQDN value when processing DDNS updates. On Jan 8, 2024, at 10:58 AM, Isaac Brummel <ibrum...@xes-inc.com> wrote: Hello, I'm setting up Kea in a Test environment and ran across an issue with DDNS domain names. I have a couple of Windows servers that are domain joined. The domain is different than the domain used by the Kea DDNS service. So when a Windows servers requests a lease an odd record is generated for the client. The windows domain name is "win-domain.com<http://win-domain.com/>" and the domain used by DDNS is "win-test.com<http://win-test.com/>". Here are the hostname specific options received by a tcpdump when the Windows servers requests a lease. Hostname (12), length 21: "win11" FQDN (81), length 33: "win11.win-domain.com<http://win11.win-domain.com/>" This combination results in the DDNS service creating a recording containing "win-domain.com<http://win-domain.com/>" that I assume is because it's not the Kea DDNS domain and doesn't know how to handle it. The record that gets generated looks like this: "win11.win-domain.com.win-test.com<http://win11.win-domain.com.win-test.com/>". In the Kea DHCP4 config, I have the following for the DDNS suffix. "ddns-qualifying-suffix": "win-test.com<http://win-test.com/>", Looking at the documentation for DDNS there is the "ddns-replace-client-name" option but in my testing it seems that it can't use the value from the incoming packet's option 12 (hostname) and requires statically setting something. Is there a way to work around this issue, removing "win-domain.com<http://win-domain.com/>" from the DDNS record, or having DDNS ignore the FQDN (81) option all together? Would the "ddns-tuning" hook work for this? Thanks, Isaac -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org<mailto:Kea-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/kea-users CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
-- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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
