Improve DNS handling?

[DimitriPapadopoulos]

Rationale

Setting DNS parameters has been raising different issues:

• race condition between openfortivpn itself and pppd in earlier versions of openfortivpn prior to allow to use resolvconf instead of resolv.conf #486 and version 1.12.0
• race condition between openfortivpn and NetworkManager (see for example Setting DNS parameters on Fedora #590)
• mechanisms for setting DNS might be available at build-time but not run-time, or at run-time but not build-time (for example resolvectl from systemd is often available at run-time on Fedora machines but is not available at build-time by default)
• mechanisms for setting DNS might be available but not working (for example resolvconf from systemd does not work as expected on Fedora as seen in openfortivpn 1.12 / DNS configuration problems #555)

Especially Fedora and CentOS have been challenging so far. Short of interacting with NetworkManager directly when NetworkManager is installed and used, I suspect the official way to modify DNS parameters on CentOS >= 8 and Fedora is running resolvectl which has been part of the systemd package since CentOS >= 8 (not CentOS 7 which is probably why busctl is used in #615).

Proposal for setting DNS parameters

Is it worth trying to further improve the DNS configuration mechanism when --set-dns=1? Perhaps using the following mechanisms and other ones you can think of?

1. If NetworkManager is installed and in use (how to detect that?) interact with NetworkManager directly? Perhaps through nmcli?
2. If resolvectl from systemd is available run it to modify DNS parameters.
3. If resolvconf is available and works properly (either openresolv or resolvconf but not resolvectl), run it to modify DNS parameters.
4. Fall back on modifying /etc/resolv.conf directly.

NetworkManager is a special case: I am not sure about supporting NetworkManager because NetworkManager already supports openfortivpn through NetworkManager-fortisslvpn. It's the other way round.

Documentation

Man pages:

• nmcli(1) from NetworkManager
• resolvectl(1) from systemd
• resolvconf(8) from Debian
• resolvconf(8) from openresolv

Hopefully we can get some info from this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1815605

[DimitriPapadopoulos]

Additionally I believe we need to always support all of resolvectl, resolvconf and modifying /etc/resolv.conf directly. openfortivpn should decide at run-time and not build-time. At least this looks like the only way to support snaps because DNS management is distribution-specific on Linux while snaps are distribution-neutral so they have to support all distributions. See #597 (comment).

[DimitriPapadopoulos]

I have tried to create a list of resolvectl and resolvconf executables on different Linux distributions based on my own experience and pkgs.org:

executables (or lack of)	packages
ALT Linux Sisyphus
shell function resolvectl?	systemd
/sbin/resolvconf	openresolv
Arch Linux
/usr/bin/resolvectl	systemd
/usr/bin/resolvconf	resolvconf
/usr/bin/resolvconf	openresolv
CentOS 8
/usr/bin/resolvectl	systemd
/usr/sbin/resolvconf	systemd
CentOS 7
	systemd
CentOS 6
/sbin/resolvconf	openresolv
Debian 10
/usr/bin/resolvectl	systemd
/sbin/resolvconf	resolvconf
/sbin/resolvconf	openresolv
Debian 9
	systemd
/sbin/resolvconf	resolvconf
/sbin/resolvconf	openresolv
Debian 8
	systemd
/sbin/resolvconf	resolvconf
Fedora 32
/usr/bin/resolvectl	systemd
/usr/sbin/resolvconf	systemd
Fedora 31
/usr/bin/resolvectl	systemd
/usr/sbin/resolvconf	systemd
Fedora 30
/usr/bin/resolvectl	systemd
/usr/sbin/resolvconf	systemd
FreeBSD 13
	systemd
/usr/local/sbin/resolvconf	openresolv
OpenMandriva 4.1
/usr/bin/resolvectl	systemd
/sbin/resolvconf	systemd
OpenMandriva 3.0
	systemd
OpenSuSE Ports Leap 15.2
	systemd
/usr/sbin/resolvconf	resolvconf
OpenSuSE Ports Leap 15.1
	systemd
/usr/sbin/resolvconf	resolvconf
Slackware 14.2
/usr/sbin/resolvconf	openresolv
Slackware 14.1
/usr/sbin/resolvconf	openresolv
PCLinuxOS
/sbin/resolvconf	resolvconf
Solus
/usr/bin/resolvectl	systemd
/usr/sbin/resolvconf	systemd
Ubuntu 20.04
/usr/bin/resolvectl	systemd
/sbin/resolvconf	resolvconf
/sbin/resolvconf	openresolv
Ubuntu 18.04
	systemd
/sbin/resolvconf	resolvconf
/sbin/resolvconf	openresolv
Ubuntu 16.04
	systemd
/sbin/resolvconf	resolvconf
/sbin/resolvconf	openresolv

Most notably resolvectl has been gaining momentum on most distributions, especially Debian 10 and Ubuntu 20.04. Hence if --set-dns=1 we should by order of preference:

1. use resolvectl from systemd if available,
2. else use resolvconf if available, the one from resolvconf or openresolv and certainly not the broken resolvectl alias from systemd,
3. else modify /etc/resolv.conf directly.

[mrbaseman]

Supporting resolvectl surely is something which we should integrate somehow in the near future.

I'm a bit hesitating about the movement of the decision from configure time to the runtime. Programs running with elevated privileges should call other programs with an absolute path. If this decision can not be detected at configure time, we may end up with checking several possibilities at runtime and expectations e.g. about how trustworthy directories below /usr or /usr/local are, may also depend on the distribution.

So, shall we check a couple of locations which we think are safe at runtime? Or shall we rely on a mechanism of the OS to locate the right executable (use $PATH and sanitize it somehow), anything else? Whatever we chose, it should also be portable.

One could argue, openfortivpn needs to run as root anyway, so the user who is allowed to use it must be trustworthy in some sense, but I'm sure some admins provide their users with sudo privileges, the privilege to control network manager, or a systemd service that opens the vpn tunnel on request by the otherwise less trusted employee. I feel a bit uncomfortable with the idea of putting too much automatism to runtime.

[DimitriPapadopoulos]

I absolutely agree, we should not let openfortivpn search the PATH or anything else to find a way to modify DNS parameters. Paths need to be hardcoded. That's why I have researched the location of the executables for various distributions. Therefore by default we should attempt to run only the following executables in directories controlled by the system:

1. /usr/bin/resolvectl is the standard location for resolvectl from systemd across distributions.
2. /sbin/resolvconf and /usr/sbin/resolvconf look like standard locations for resolvconf/openresolv across distributions. Perhaps add /usr/bin/resolvconf for Arch Linux and /usr/local/sbin/resolvconf for FreeBSD, but the last one can and should be configured at build-time.

Note that the broken systemd alias /sbin/resolvconf or /usr/sbin/resolvconf seems to be "hidden" by /usr/bin/resolvectl in all cases, provided we attempt to run resolvectl before resolvconf.

We should also allow for additional/alternative paths to these executables at build-time, for obscure distributions that use different paths or end-users who build & install themselves in different locations.

Finally we should examine the exit status of the executables to catch errors. Will have to experiment with exit status values a little bit.

[DimitriPapadopoulos]

A relevant pull request has just appeared: #615

@da-x Can you please help understand the pull request and comment with respect to other solutions above?

• If I understand the pull request correctly, you're calling busctl instead of resolvectl. Can you comment on that? Perhaps because busctl is available on more distributions than resolvectl (Ubuntu 16.04 and 18.04, Debian 8 and 9, CentOS 7)?
• We already link with systemd libraries. I'm wondering whether we could call systemd functions directly from C instead of running the external script.
• I've been struggling to find the "right way" to modify DNS settings from a program such as openfortivpn. Can you confirm that systemd is the way to go on systems with systemd (so all systems listed above except CentOS 6 and SlackWare), whether using resolvectl, busctl or direct systemd function calls from C? Can you point me to some external publication to support that (I'm convinced but I would like to read a little bit about it)?
• All recent distributions that ship some form of resolvconf also ship systemd, see table above. If systemd is the way to go, I suspect the suggestion to support resolvconf (allow to use resolvconf instead of resolv.conf #486) was a bad idea. Your opinion?

[DimitriPapadopoulos]

Here are the services provided by systemd-resolved:
https://www.freedesktop.org/wiki/Software/systemd/resolved/

@da-x You seem to be calling methods SetLinkDNS, SetLinkDomainsand also SetLinkDNSSEC. Is the last one required? I'm not very familiar with DNSSEC

[da-x]

@DimitriPapadopoulos this bash script code is based on code from https://github.com/jonathanio/update-systemd-resolved, which does similar stuff but for OpenVPN. You can check with them. Now, there's also a hidden assumption that systemd-resolved is enabled on the system, and that /etc/nsswitch.conf is configured for it, which I think is not yet true by default for some distribution versions. I, for one, use it, because I have a home DNS server and a work DNS server, and resolving via system-resolved works well when I try to resolve hostnames from either networks.

[DimitriPapadopoulos]

@da-x Right, on Fedora systemd-resolved is not enabled by default as far as I can tell. Is your script able to detect that?

[da-x]

@DimitriPapadopoulos No, there's an assumption that it's enabled and /etc/nsswitch.conf is configured for it.

[DimitriPapadopoulos]

@da-x Then I suspect it might be much better to rewrite the script directly in C (since openfortivpn is already linked with systemd). Then:

1. Hopefully the C systemd function calls will return an error status if systemd-resolved is not enabled. By the way, if the C function calls fail, I suspect running resolvectl is useless since systemd-resolved is the only supported backend, isn't it?
2. If systemd is not linked in, or the C function calls fail, then we can fall back on resolvconf on systems that have the script (the real resolvconf/openresolve resolvconf script and not the systemd resolveclt alias).
3. If all else fail we fall back on directly modifying /etc/resolv.conf (for example on CentOS 6).