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 734454 - NetworkManager breaks resolvconf's nameserver ordering
NetworkManager breaks resolvconf's nameserver ordering
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
0.9.8
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: nm-patch
 
 
Reported: 2014-08-07 20:29 UTC by robsen
Modified: 2020-11-12 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
re-order DNS resolvers to list IPv6 first (1.75 KB, patch)
2015-04-30 17:53 UTC, Kevin Otte
reviewed Details | Review

Description robsen 2014-08-07 20:29:40 UTC
I am running NetworkManager in a dual stack environment, for both wifi and vpn connections. When checking the content of the /etc/resolv.conf file, I found that, at least for wifi connections, the ipv4 nameserver entry is always listed first, followed by the ipv6 nameserver entry, although it is a common rule to prefer ipv6 over ipv4 if ipv6 is available.

I tried to figure why ipv4 nameserver is listed first, and found that the resolvconf program's configuration indeed prefers ipv6 over ipv4, this behaviour is configured in resolvconf's /etc/resolvconf/interface-order file. But NetworkManager makes use of resolvconf the wrong way. 

To allow resolvconf to manage the order of the nameserver entries in the compiled /etc/resolv.conf file, services are required to call resolvconf with an interface name as the last option. Other services (e.g. openvpn) are doing this the right way by setting this option to something like "eth0.openvpn" or "eth0.inet6.openvpn", which results in separate resolv.conf like files in the /run/resolvconf/interface/ directory, each containing the interface (and protocol) information in its filename. 

But all NetworkManager's nameserver information, regardless where it comes from, goes into a single file /run/resolvconf/interface/NetworkManager, missing all information about interface and protocol and breaking resolvconf's ability to order nameserver information in the compiled /etc/resolv.conf file.

This would not be too bad, if NetworkManager would do the ordering the right way (e.g. preferring vpn over wlan, ipv6 over ipv4, like it is configured for resolvconf in the interface-order file), but it doesn't. There seems to be no way to get ipv6 nameservers preferred over ipv4 nameservers for the same interface if nameserver information is provided by NetworkManager.

I think this is a bug, and NetworkManager's usage of resolvconf should be fixed to follow the common rule and provide interface and protocol information to resolvconf, and let resolvconf decide about the correct order of the nameserves listed in the resulting /etc/resolv.conf file.
Comment 1 Dan Williams 2015-04-30 17:28:39 UTC
I think we can probably re-order the IP addresses, but the interface name thing isn't a great solution.  The reason is that DNS information isn't always tied to a specific network interface, for example in the case of IPSec links, user overrides, or other cases.
Comment 2 Kevin Otte 2015-04-30 17:53:27 UTC
Created attachment 302686 [details] [review]
re-order DNS resolvers to list IPv6 first

Per conversation with dcbw on IRC, I think the basic fix should be simply to iterate the IPv6 servers before the IPv4. This patch is untested.
Comment 3 Dan Williams 2015-06-09 17:58:47 UTC
Review of attachment 302686 [details] [review]:

::: src/dns-manager/nm-dns-manager.c
@@ +680,3 @@
+	if (priv->ip6_device_config)
+		merge_one_ip6_config (&rc, priv->ip6_device_config);
+

We should have a code comment above this block that indicates why IPv6 should be first, and reference this bug #.

@@ +704,1 @@
 		} else

This won't actually produce quite the right result; what we want here is actually two for() loops that are substantially the same, a first one for IPv6 and a second for IPv4.  priv->configs can be mixed, so to ensure Ipv6 is first we'd want to add all those first, then all the IPv4 ones.  I think the flow should probably be:

if (priv->ip6_vpn_config)
    merge it
if (priv->ip6_device_config)
    merge it

for (iter = priv->configs, etc) {
    if (iter->data == priv->ip6_vpn_config || iter->data == priv->ip6_device_config)
        continue
    if (!NM_IS_IP6_CONFIG (iter->data)
        continue
    merge_one_ip6_config (&rc, NM_IP6_CONFIG (iter->data));
}

<repeat for IPv4>

or something like that?
Comment 4 Thomas Berger 2016-04-25 11:20:27 UTC
This "interface name thing" is a must have in multiple environments. Example:

I connect via wireless lan on a public hotspot. DHCP lease time: 300 seconds. I connect via openconnect to my office network and get the internal DNS servers pushed. Every time my DHCP lease gets renewed, i have to reconnect my office VPN to get DNS working again, because NetworkManager puts the DNS servers for the wireless connections before the internal DNS servers of my VPN.

This could not be the expected behavior.
Comment 5 Thomas Haller 2016-04-25 13:43:48 UTC
(In reply to Thomas Berger from comment #4)
> This "interface name thing" is a must have in multiple environments. Example:
> 
> I connect via wireless lan on a public hotspot. DHCP lease time: 300
> seconds. I connect via openconnect to my office network and get the internal
> DNS servers pushed. Every time my DHCP lease gets renewed, i have to
> reconnect my office VPN to get DNS working again, because NetworkManager
> puts the DNS servers for the wireless connections before the internal DNS
> servers of my VPN.
> 
> This could not be the expected behavior.

This scenario would be fixed by https://bugzilla.gnome.org/show_bug.cgi?id=758772#c9
Comment 6 Mike Auty 2018-07-06 11:00:46 UTC
Just to add, the "interface name thing" is important with systemd's resolvconf implementation because it doesn't add non-existant interface DNS servers to the main resolution lookup system, so networkmanager's DNS additions are effectively ignored.

See https://bugzilla.gnome.org/show_bug.cgi?id=796758 for more details.
Comment 7 André Klapper 2020-11-12 14:30:09 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).