GNOME Bugzilla – Bug 761467
IPv6 dynamic DNS update no longer working by blocking simple host name
Last modified: 2017-05-03 07:49:26 UTC
I'm using Ubuntu 15.10 (NM 1.0.4) with IPv6 DHCP adresses via ISC dhcpd. For all older Ubuntu and NM versions dynamic DNS updates were working. Since 15.10 simple hostnames are no longer written to the dhclient6 config file as "send fqdn.fqdn <hostname>". The reason is a check in nm-dhcp-dhclient-utils.c: static void add_hostname6 (GString *str, const char *hostname) { /* dhclient only supports the fqdn.fqdn for DHCPv6 and requires a fully- * qualified name for this option, so we must require one here too. */ if (hostname && strchr (hostname, '.')) { ..... } The problem seems to be, that there is no FQDN given when calling add_hostname6(). All older Ubuntu distributions and/or NM verions allow simple host names to be written to the config file. It seem that it is sufficient for DNS updates to use simple hostnames. So it seems that it is save to skip the strchr() check.
this is the relevant commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=677cee0f232ac014b805af50e2010680c71f927e including some reasoning for that change.
(In reply to Thomas Haller from comment #1) > this is the relevant commit > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/ > ?id=677cee0f232ac014b805af50e2010680c71f927e including some reasoning for > that change. Sure, this is correct from the FQDN point of view. But nevertheless that commit breaks working DNS updates in production. The cause of problem might be somewhere else, since add_hostname4/6 is called with a non DNS qualified hostname. So if unqualified names are blocked and will be blocked in the future, a full qualified name should be provided to make sure that DNS updates will be possible again. I'm not sure if the FQND is a misconfiguration in the Ubuntu system or if the caller of add_hostname4/6 can fix that.
ISC dhclient will always send the fqdn.fqdn option as an absolute name with a trailing ".". However, ISC dhcpd will ignore the trailing "." anyway, so if one runs the ISC dhcpd it will still work. A simple workaround is to misuse a bug in NetworkManager. Create a file /etc/dhcp/dhclient6.conf with the following: send fqdn.fqdn = gethostname(); send fqdn.server-update on; Note the two spaces between send and fqdn.fqdn. It's required for NetworkManager to not filter the line when merging the configuration file. Doing this make DDNS work as expected with NetworkManager 1.4.4-3.fc25, dhclient 4.3.5 and dhcpd 4.3.3-5ubuntu12.6. Reading the dhcp-option(5) man page "option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain." So the ISC dhcp documentation suggest that it's perfectly fine to send a single label. Reading the relevant RFC4704 doesn't indicated how the server should behave if it receives the trailing "." or not. Only this: " The server MAY be configured to use the name supplied in the client's Client FQDN option, or it MAY be configured to modify the supplied name or to substitute a different name." This somewhat hints that the server may do whatever it wants with the supplied fqdn.fqdn option, e.g. ignore the trailing ".". I've attached a patch that make NetworkManager send the fqdn.fqdn regardless of the presence of a "." in the hostname. It compiles and the test pass.
Created attachment 349281 [details] [review] Allow unqualified hostname for fqdn.fqdn
Yeah, I think we want to remove the check and accept unqualified names as the RFC allows them. The only concern is that dhclient will add the zero-length terminating label even if the name is unqualified, which is wrong according to RFC; but if DHCP servers ignore the terminating label, then I guess it's not much of a problem. BTW, at the moment the other DHCPv6 backend (the internal one) doesn't support sending the FQDN. When we add support for it, we should do it right and add the terminating label only for names that are not single-label. Regarding the patch, I think we should check that hostname is not NULL in add_hostname6() before adding options? Also, can you add a reference to this bugzilla at the end of the commit message?
(In reply to Beniamino Galvani from comment #5) > Yeah, I think we want to remove the check and accept unqualified names as > the RFC allows them. The only concern is that dhclient will add the > zero-length terminating label even if the name is unqualified, which is > wrong according to RFC; but if DHCP servers ignore the terminating label, > then I guess it's not much of a problem. Yes, I agree that it's wrong according to the RFC but that should be considered a bug in dhclient if anything. If a DHCPv6 can't do DDNS because it's following the RFC then it's the fault of dhclient not NetworkManager. This patch wouldn't change the outcome anyway except for log entry to notify the user of possible issues because of dhclient. > > BTW, at the moment the other DHCPv6 backend (the internal one) doesn't > support sending the FQDN. When we add support for it, we should do it right > and add the terminating label only for names that are not single-label. Yes, it make sense to follow the RFC. > > Regarding the patch, I think we should check that hostname is not NULL in > add_hostname6() before adding options? Also, can you add a reference to this > bugzilla at the end of the commit message? I've updated the patch.
Created attachment 350745 [details] [review] dhcp: dhclient: Allow unqualified fqdn.fqdn for DHCPv6
Created attachment 350746 [details] [review] dhcp: dhclient: Allow unqualified fqdn.fqdn for DHCPv6
LGTM
Applied, thanks! https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f5d29e6f61fd9ff145aaf48f6b804e4b15fb48fb