GNOME Bugzilla – Bug 758777
Trailing periods are added to search list domains learned from DHCP but not from RAs
Last modified: 2015-12-05 09:12:43 UTC
My OpenWrt-based home gateway advertises the domains "w5.y.home. and "home." using both ICMPv6 RAs, DHCPv4, and DHCPv6. This results in the following line being added to /etc/resolv.conf: search w5.y.home. home. w5.y.home home Note the duplication of the two domains - they occur both with and without the trailing period. This duplication causes a failing hostname lookup to generate twice as many DNS queries, and also makes it take twice as long as it really needed to. I believe that the trailing dot is *not* removed when the domains are learned from DHCPv4 or DHCPv6, but that they are when they are learned from ICMPv6 RAs. I suspect that what's removing the trailing dot is libndp, see: https://github.com/jpirko/libndp/blob/master/libndp/libndp.c#L1553 I don't have any strong opinions on whether or not the trailing dot should be stripped or not, but it should be done consistently regardless of the DNS search list in question having come from RAs or DHCP. If you can confirm that this is a libndp bug, and think that it should be fixed there and not in NM, let me know and I'll submit an issue in the libndp issue tracker on GitHub instead.
Ignore my first analysis. libndp is not at fault here. It is, as I understand it, actually impossible for the search domains to be advertised with a trailing period, because of how they're encoded (RFC1035). Indeed, periods do not appear in the relevant RA/DHCP packets *at all*. It appears that the trailing period comes from the ISC DHCP client, at least a quick test shows that the script is called with new_dhcp6_domain_search='w5.y.home. home.' in its environment. libndp, on the other hand, does not add an explicit trailing period. This disparity prevents NM from seeing that the search list entries from the two sources are redundant, and ends up writing both variants to /etc/resolv.conf. I am at this point not aware if there is any RFC or other standard that states that it should be one way or the other. In practise, I do not think it matters - glibc appears to interpret them the same way. Unless it can be shown that either the ISC DHCP client or libndp is doing something wrong, I think the onus is on NM to provide consistency and prevent redundant search list entries by ensuring that the trailing dot is always added, or never.
I just noticed the same thing, multiple DNS requests tha all fail. I'm also running OpenWRT gateway, advertising the domain lan via RA, DHCPv6 and DHCP. My /etc/resolv.conf becomes search lan lan. Looking at the three requests in Wireshark revels that "lan" comes from DHCP and "lan." comes from RA and DHCPv6. By jumping through some RFC, starting at section 4 of RFC 3646 (https://tools.ietf.org/html/rfc3646#section-4), the following can be found. "Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero." By looking at the packet, the search domain is indeed encoded as two labels, "lan" and the null label, i.e. the root label ".". Both RA and DHCPv6 packet contain the same encoding. I think that NetworkManager should recognize this difference and treat the search domains "lan" and "lan." the same.
It seems that of the 3 DHCP clients that we support: - dhclient adds the trailing dots to search domains - dhcpcd does not - the internal client doesn't support the option altogether (bug 750076) From a quick look at the resolv.conf documentation, the trailing dot appears to have no effect on the behavior of glibc resolver and so I think it would be safe to remove it.
Created attachment 316614 [details] [review] [PATCH] dhcp: strip trailing dot from domain search list [PATCH] dhcp: strip trailing dot from domain search list dhclient adds a trailing dot to domain search list entries received from the server, while the same domains received by other means (dhcpcd on RA) don't have the final dot. The result is that resolv.conf can be populated with duplicated entries. Fix this by stripping the dot when the DHCP domain search list is parsed.
(In reply to Beniamino Galvani from comment #4) > Created attachment 316614 [details] [review] [review] > [PATCH] dhcp: strip trailing dot from domain search list > > [PATCH] dhcp: strip trailing dot from domain search list > > dhclient adds a trailing dot to domain search list entries received > from the server, while the same domains received by other means > (dhcpcd on RA) don't have the final dot. The result is that > resolv.conf can be populated with duplicated entries. > > Fix this by stripping the dot when the DHCP domain search list is > parsed. Should we not fix nm_ip4_config_add_search() to strip the trailing dot? nm_dhcp_utils_ip4_config_from_options() is ~only~ called by two (of 3) dhcp-implementations, but nm_ip4_config_add_search() is where it all comes together. I would keep your change to process_domain_search() -- since you already did it and to be explicit.
Created attachment 316656 [details] [review] [PATCH v2] core: strip trailing dot from domain search list > (In reply to Beniamino Galvani from comment #4) > nm_dhcp_utils_ip4_config_from_options() is ~only~ called by two (of 3) > dhcp-implementations, but nm_ip4_config_add_search() is where it all comes > together. The idea was that every DHCP implementation would remove the dot when creating a IP configuration from the lease. Both dhclient and dhcpcd use that function, while dhcp-systemd at the moment doesn't support the search list and would need to be updated when the feature is implemented. But I see your point, probably the stripping should be done at an upper level so that we strip also static values. Patch updated. > I would keep your change to process_domain_search() -- since you already did > it and to be explicit. Not a strong opinion, but if nm_ip4_config_add_search() already does the check I don't think we should duplicate it also in process_domain_search().
_nm_utils_strv_find_first() or _nm_utils_string_in_list(). Otherwise LGTM
Created attachment 316776 [details] [review] [PATCH v3] core: strip trailing dot from domain search list (In reply to Thomas Haller from comment #7) > _nm_utils_strv_find_first() or _nm_utils_string_in_list(). Changed, thanks.
LGTM
Merged to master: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6e990cf97bf20a27a9be1d1dc4650502ba29c343 and nm-1-0: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-0&id=83f4c1c9bf3f86b1f08a6f3f187df1f3987b103d