[Kea-users] DDNS remove domain included in fqdn option

[Rick Frey]

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 <ibrummel at 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 at lists.isc.org <mailto: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/20240108/46ce4451/attachment.htm>