Re: DHCPv6 DDNS registration with FQDN

[Dan Williams <dcbw redhat com>]

On Tue, 2015-02-03 at 12:05 +0100, Alexander Groß wrote:
> I have some more findings after several debugging sessions.
>
> According to RFC 4704, section 4.2
> <https://tools.ietf.org/html/rfc4704#section-4.2>:
> The Domain Name part of the option carries all or part of the FQDN of a
> DHCPv6 client. ... A client MAY be configured with a fully qualified domain
> name or with a partial name that is not fully qualified. ... 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.
>
> According to this, Windows clients send a partial host name, e.g. "FOO",
> without a terminating NULL character. dhclient, on the other hand, always
> sends a FQDN including the terminating NULL making the value fully
> qualified. I found a possibly unrelated discussion about this issue here:
> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1088682
>
> As such, send fqdn.fqdn "foo.example.local." must always be a fully
> qualified domain name (as NULL is automatically appended), otherwise the
> DDNS update won't happen in the correct DNS zone.
>
> Any idea how to achieve that given that NM always overwrites fqdn.fqdn
> values found in custom (merged) dhclient6.confs?
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp-manager/nm-dhcp-dhclient-utils.c#n232

So the short answer here is, you're right, NM is doing some wrong stuff
with the DHCPv6 hostname.  It is chopping off the FQDN when using
dhclient, and that's likely a mis-interpretation of how the dhclient
config was supposed to work.  The question is why it was done that way
originally, which I haven't looked into yet but will do.

Dan