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 729137 - branch review: danw/domain (fix handling of "public suffix" domains)
branch review: danw/domain (fix handling of "public suffix" domains)
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-04-28 18:54 UTC by Dan Winship
Modified: 2014-04-30 08:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2014-04-28 18:54:44 UTC
qv https://bugzilla.redhat.com/show_bug.cgi?id=851521

If you set hostname to example.com, then activate a static connection with no DNS domains specified in it, then "no-such-name.com" will resolve to "no-such-name.com.com" rather than failing to resolve. This was supposed to have been fixed by http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=dfe194ee, but it turns out that it only works right if the connection config includes at least domain/search (whether specified statically or received from DHCP).

Fix in danw/domain. (The first commit is not part of the fix, it's just a drive-by cleanup.)

(I dropped the reference to rh #600407 in the comment because that bug is kind of a mess now, and the comment explains the issue well enough.)
Comment 1 Thomas Haller 2014-04-28 20:33:53 UTC
Hm, I don't understand this.

You check for DOMAIN_IS_VALID() which resolves to:
  (*(domain) && !soup_tld_domain_is_public_suffix (domain))

https://developer.gnome.org/libsoup/unstable/libsoup-2.4-Top-Level-Domain-utils.html#soup-tld-domain-is-public-suffix

Why would you expect hostdomain or priv->hostname to be ".com" or similar?



(also, don't forget to reference this bug id in the commit message).
Comment 2 Dan Winship 2014-04-28 22:02:43 UTC
If priv->hostname is "example.com", then hostdomain would be ".com". It's perfectly legal to have a machine whose canonical hostname is the top level of a DNS domain.

priv->hostname itself is really not likely to be a public suffix; the DOMAIN_IS_VALID() check there is just paranoia/consistency.
Comment 3 Dan Williams 2014-04-28 22:21:18 UTC
Hmm, what if the hostname is a single word, which is somewhat common?  eg if my hostname is "dcbw" then we'll get "search dcbw" in resolv.conf, which seems somewhat useless since that's my hostname, not my domain/FQDN, and I wouldn't expect any other machines on the network to be under the "dcbw" domain.

How about:

else if (hostdomain && DOMAIN_IS_VALID (priv->hostname))

instead, which would wouldn't add anything in this case because there's no '.'.  But for 'example.com', it would preserve the branch's behavior of adding 'search example.com' because the dot exists.
Comment 4 Dan Winship 2014-04-29 14:36:00 UTC
right. repushed with:

+	if (hostdomain) {
+		hostdomain++;
+		if (DOMAIN_IS_VALID (hostdomain))
+			add_string_item (rc.searches, hostdomain);
+		else if (DOMAIN_IS_VALID (priv->hostname))
+			add_string_item (rc.searches, priv->hostname);
+	}
Comment 5 Dan Williams 2014-04-29 18:41:26 UTC
Looks good now.
Comment 6 Thomas Haller 2014-04-30 08:28:22 UTC
For the record:

merged to master as:

50bafeaf2e318f63dd24053440712dee3035fa84 dns-manager: fix the rules for public suffixes and search domains (rh #851521)
93c10a6eead2383ef33d58a065117f10e0d98fd4 dns-manager: don't write "domain" to resolv.conf