The article and the previous discussion here do not cover any modern distribution using glibc and systemd-resolved. /etc/resolv.conf has become legacy and is not even used by most programs anymore. "Taking back control" of something that is not used will not change much...
Modern programs should use getaddrinfo(3). The glibc implementation of that call will first consult the "hosts:" line of /etc/nsswitch.conf. That file will contain a list to determine how host names are resolved:
The first entry is typically "files". That means consult /etc/hosts file.
Next there could be something to consult avahi/autoip, Ubuntu systems typically do that.
There could also be entries "myhostname" and "mymachines". That's systemd's container support, not discussed here.
If the system uses systemd-resolved there will be an entry "resolve". Than means consult systemd-resolved
Typically the last one is "dns". That's the traditional implementation using /etc/resolv.conf. But if systemd-resolved is configured and working we never get here.
Only if you don't have "resolve" before "dns" in your /etc/nsswitch.conf then /etc/resolv.conf is still relevant.
It appears to me that musl does not use /etc/nsswitch.conf at all, so there /etc/resolv.conf is still relevant.
Jesus, I can hardly blame anyone who is confused by the naming conventions there!
"files", oh so all the files get checked first, including "/etc/hosts" and "/etc/resolv.conf", right?
No, only "/etc/hosts".
Well why don't we just write it as "/etc/hosts"? Ok, whatever - next up is "myhostname"... wait, my hostname is already in the "/etc/hosts" file, why is it spelled out again?
No no, that refers to systemd's container support (don't ask).
OK... ah, here we go - "resolve", surely that refers to "/etc/resolv.conf".
Static binaries are fun, but bringing a libc replacement... Can be surprising.
My trouble was with split-horizon networking, and gitlab-runner (which is a nice self-contained go program). But not so nice if your firewall, dns and internal/external ips disagree. Thankfully we could remap some fw rules, so avoided the need for split-horizon host resolution via /etc/hosts (the other alternative being full split-horizon dns).
Any modern distro using a systemd resolver is one meant for the kind of people that don't care about taking back control, because they will be layman users. You are of course correct that this then does not apply to them, but I would argue this is kind of an obvious point.
Debian, Ubuntu and the vast majority of their derivatives use systemd.
Fedora and Red Hat and the vast majority of their derivatives use systemd.
OpenSUSE and SUSE and the vast majority of their derivatives use systemd.
In most production environments bar custom distributions used by Google & co. (and those are a minority), systemd is used, presumably with the systemd resolver.
I'm not sure I'd call all users of commercial Linux distributions "laymen" :)
> Debian, Ubuntu and the vast majority of their derivatives use systemd.
Debian doesn't use nss-resolve(8) by default though. I'd be very surprised if RHEL or any other other distros suitable for a "production environment" were to take that step given systemd-resolved's current level of maturity.
(This is not a knock at systemd-resolved; I use it myself on most of my machines, but unless you want to spend a lot of time debugging weird resolver issues I would not recommend doing so until it has matured a bit more.
I don't want to participate in the discussion whether systemd and systemd-resolved are good or bad or for laymen or not.
My only point was if you want "to take control" of your system you first have to look /etc/nsswitch.conf. If "resolve" is before "dns" your /etc/resolv.conf is mostly unused. Any article discussing /etc/resolv.conf without mentioning /etc/nsswitch.conf is very misleading for many users who happen to have systemd-resolved (probably because the distro decided to install and configure it)
I guess the discussion is a bit heated because distros keep breaking stuff that worked 10 years ago.
It would be fine if overall reliability increased, but it does not. I could write more reliable shell scripts for making WiFi or PPP connections than NetworkManager, which sometimes required a reboot before graciously allowing to connect again. Never happens on the command line.
Thank you for describing the status quo, I'll probably look into Slackware or OpenBSD now.
My suggestion for Linux right now is Void Linux. It's clean and minimalist and eschews systemd for runit. It feels a lot like OpenBSD without ports (although the manpages are sadly Linux-like).
I don’t see any point of leaving resolved behind once both NM and nsswitch are configured to ignore resolved. Disabling resolved pretty much does a half of the trick without modifying a major system config file anyway.
in recent ubuntu releases(18.04,14.04, I don't have 16.04 to check) I failed to see any 'resolve' in nsswitch.conf, so it still uses 'resolv.conf', strange.
And it is probably a bug because that missing setting seems breaking vpn at least:
Interesting, I didn't remember this. It's the same on my 18.04 machine. And according to etckeeper it has been like this since the installation. But systemd-resolved is running, that's not a very consistent system configuration is it? /etc/resolv.conf is a symbolic link to something generated by systemd-resolved. So in this case we can indeed say that systemd-resolved controls /etc/resolv.conf and the latter is really used by the rest of the system. No idea why anybody would intentionally use systemd-resolved this way or whether it is really just a bug. The bug report has been open for nearly a year and it looks like no Ubuntu core developer has commented. Unfortunately all too common in launchpad :(
The root cause for "resolve" not being in /etc/nsswitch.conf is libnss-resolve not being installed. It seems to be completely optional with nothing pulling it in.
In my 16.04 systemd-resolved is not even running. That's what I would have expected.
I always disable and deinstall systemd-resolved. It's unnecessarily convoluted and just always gets in the way. Adding an 127.0.0.53 alias? Why in the world is that even necessary? Dnsmasq is fine, is used by NetworkManager and can be easily set up to query a DNS cache of your choice. On servers, an unbound local resolver is a better alternative and it's used on FreeBSD.
Systemd-resolved has a configuration compiled in. If thats not what you want you can edit /etc/systemd/resolved.conf. It shows what has been compiled in as comments. Actually really editing any systemd configuration or unit file is typically a bad idea. Configuration changes are done preferrably by drop-ins. These are little files to be stored under /etc/systemd/resolved.conf.d/{foo,bar}.conf (Pathnames from memory, typing on my phone, but you should be able to see the naming scheme used. It's quite systematic all over systemd.)
Roughly it works like that (not sure whether distros vary):
primary DNS server address is received from DHCP at runtime
fallback DNS servers are hardwired in the config. I remember at least seeing google 8.8.8.8 there
You can change the primary DNS server not to be set by DHCP, that's probably the first thing may people want to do.
Modern programs should use getaddrinfo(3). The glibc implementation of that call will first consult the "hosts:" line of /etc/nsswitch.conf. That file will contain a list to determine how host names are resolved:
The first entry is typically "files". That means consult /etc/hosts file.
Next there could be something to consult avahi/autoip, Ubuntu systems typically do that.
There could also be entries "myhostname" and "mymachines". That's systemd's container support, not discussed here.
If the system uses systemd-resolved there will be an entry "resolve". Than means consult systemd-resolved
Typically the last one is "dns". That's the traditional implementation using /etc/resolv.conf. But if systemd-resolved is configured and working we never get here.
Only if you don't have "resolve" before "dns" in your /etc/nsswitch.conf then /etc/resolv.conf is still relevant.
It appears to me that musl does not use /etc/nsswitch.conf at all, so there /etc/resolv.conf is still relevant.