After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 761467 - IPv6 dynamic DNS update no longer working by blocking simple host name
IPv6 dynamic DNS update no longer working by blocking simple host name
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-02-02 17:15 UTC by tangram67
Modified: 2017-05-03 07:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Allow unqualified hostname for fqdn.fqdn (2.84 KB, patch)
2017-04-05 09:46 UTC, Jonas Jonsson
none Details | Review
dhcp: dhclient: Allow unqualified fqdn.fqdn for DHCPv6 (2.90 KB, patch)
2017-04-29 19:08 UTC, Jonas Jonsson
none Details | Review
dhcp: dhclient: Allow unqualified fqdn.fqdn for DHCPv6 (2.58 KB, patch)
2017-04-29 19:11 UTC, Jonas Jonsson
none Details | Review

Description tangram67 2016-02-02 17:15:16 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.
Comment 1 Thomas Haller 2016-02-02 19:17:39 UTC
this is the relevant commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=677cee0f232ac014b805af50e2010680c71f927e including some reasoning for that change.
Comment 2 tangram67 2016-02-02 20:42:46 UTC
(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.
Comment 3 Jonas Jonsson 2017-04-05 09:45:54 UTC
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.
Comment 4 Jonas Jonsson 2017-04-05 09:46:45 UTC
Created attachment 349281 [details] [review]
Allow unqualified hostname for fqdn.fqdn
Comment 5 Beniamino Galvani 2017-04-29 07:35:15 UTC
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?
Comment 6 Jonas Jonsson 2017-04-29 19:05:54 UTC
(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.
Comment 7 Jonas Jonsson 2017-04-29 19:08:18 UTC
Created attachment 350745 [details] [review]
dhcp: dhclient: Allow unqualified fqdn.fqdn for DHCPv6
Comment 8 Jonas Jonsson 2017-04-29 19:11:08 UTC
Created attachment 350746 [details] [review]
dhcp: dhclient: Allow unqualified fqdn.fqdn for DHCPv6
Comment 9 Beniamino Galvani 2017-05-02 09:03:39 UTC
LGTM