Using resolvers other than systemd-resolved

[cerebrate]

Perhaps not everyone wants to use systemd-resolved, though. What would I do if I want to use something else, like unbound?

Originally posted by @xuanruiqi in https://github.com/arkane-systems/genie/issues/130#issuecomment-892090166

[cerebrate]

Quoted from old issue:

@cerebrate :

After installing genie, delete the /usr/lib/genie-stub-resolv.conf file to stop it from replacing resolv.conf with this link.

(I'd have included an option if genie did the job itself, but it doesn't, so. This is just optimizing for the default case, at the moment, figuring that people interested in replacing their resolver with a non-default cause can figure out what to do most easily.)

@esgie :

According to https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html there are in fact four modes of how systemd-resolved can handle /etc/resolv.conf. You can read how they work in the linked documentation, althought in practice they differ only with the target of /etc/resolv.conf link (mode names aren’t defined throughout the document so they are my own proposals).

1) „stub” - /run/systemd/resolve/stub-resolv.conf 2) „stub-static” - /usr/lib/systemd/resolv.conf 3) „legacy” - /run/systemd/resolve/resolv.conf 4) „unmanaged” - in this mode /etc/resolv.conf is handled by „other packages” so /etc/resolv.conf isn’t touched in any way.

I wonder if it is possible to implement such a config option in genie.ini so genie will handle symlinking of /etc/resolv.conf according to user needs.

I would say „unmanaged” should be the default mode after all. The problem of current default behavior („stub”) is that it requires to configure DNS server in /etc/systemd/resolved.conf first, otherwise networking will not work and this is not obvious and may be discouraging for users.

@xuanruiqi :

Using systemd (and systemd networking stack) doesn't mean all functionality have to be used. systemd-resolved isn't enabled by default on Arch, and also isn't really what most Arch users use. Many Arch users prefer unbound, for example. Arch provides out-of-box support for many DNS resolvers with systemd integration, including of course systemd-resolved but also many other resolvers.

That said, I agree with @esgie - "stub" mode shouldn't be the default as many users would rather not use systemd-resolved. It might be a good idea to make this configurable in genie.ini.

[xuanruiqi]

Hmmmmmm, /usr/lib/genie-stub-resolv.conf doesn't exist in my file system...

[cerebrate]

/usr/lib/tmpfiles.d/genie-stub-resolv.conf, sorry.

[PavelSosin-320]

For me the problem is simple: I use Fedora34 from Whitewater and working on the Podman project (RedHat!!!). Without mentioning the role that systemd plays in CGroup management, Podman uses systemd to manage containers lifecycle. OCI networking assumes that Linux network stack is fully functional. Both generated by Polman systemd units and Unit for management of Podman service serving REST API needs fully functional Network stack and Network target reached, Otherwise OCI image management can be hardly possible (communication with repositories). Network dependencies are parts of these units. Without them will be very hard to prevent the false start of the units. Whatever resolver is used it has to serve Podman, Buildah, and Scopeo via D-Bus socket.

[PavelSosin-320]

Back to systemd: If somebody knows how to do it from outside of systemd without completely ruinining all applications functional in the rootless mode, please, explain to me! The systemd manager for the root user and all other rootless users is exactly the same systemd manager. The only difference is the directory/subdirectory where systemd manager searches unit files: "Root"systemd manager reads the unit files with drop-ins from /etc/systemd/ subtree. "User" systemd manager reads them from $HOME/.config/systemd/user/ subtree. $HOME depends on --user username option passed to wsl command. There is only one genie.ini file affecting all users: root and rootless. Linux login (genie -l) or switching user inside Linux switches Systemd manager seamless via logind re-execution. Since systemd has no access to the objects outside VM only initial conditions of systemd initialization (genie -i) can be altered via outer file. This is the red line because thousands of Cluster nodes use systemd. Looking at systemctl status output I see clearly that once system slice is created by systemd for the Linux boot sequence the 1st thing triggered by systemd is the network target execution according to its configuration. It is the only point where Resolved unit link to the Network target can be removed or changed if it is already created by systemd daemon because resolved is wanted by the network target. It will be reproduced after every boot. If somebody wants conditional resolved service start it is possible using systemctl disable systemd-resolved or following . After this point, things are going to be more and more complex. How to use Unbound specifically is described Unbound forwarding DNS. In my Home network I use forwarding DNS running inside my WiFi router and it works because systemd-resolved tolerates many missed security features if DNS is in the local network segment. OpenWRT DNS forwarder supports dual IPV4/IPV6 stack but if RedHat endorses Unbound endorses Unbound I think it supports too - it will work out-of-the-box, don't care.

[xuanruiqi]

I don't understand your point here, frankly.

• Not everyone is using Red Hat or Fedora or CentOS. Many of us are using Debian/Ubuntu, openSUSE, Arch, etc. To put it bluntly, I don't care much about what Red Hat says.
• Many resolvers have full systemd and systemd-networkd integration, handling networking targets, etc., correctly. So there's no problem of "resolvers other than systemd-resolved don't work correctly with systemd. I use unbound but I don't care about what Red Hat says about unbound, b/c I don't use Red Hat. And no, things are not going to be much more complicated.
• systemd-resolved is but an optional component of systemd, like systemd-boot and system-homed. Many systemd-based distributions and users choose not to use it. Ubuntu for example uses BIND by default, IIRC. So I argue that a choice should be provided to users and that's it. Those who prefer systemd-resolved should continue using it, and it should continue to be fully supported. Those who prefer not to use it should have the choice not to use it.

[PavelSosin-320]

@cerebrate Ubuntu does use resolved Ubuntu resolved. OCI-related code is portable between Fedora and Ubuntu, mostly the same. Both are valid Cluster node OS and development platform. Maybe, I'm slightly ahead of Ubuntu with my Podman 3.2 on Fedora 34 distro with genie but I tested Podman 2 with more or less the same configuration and it was OK.

[xuanruiqi]

Of course you can configure Ubuntu to use systemd-resolved, but IIRC the default is bind. Anyways, this is not the topic of the discussion.

[cerebrate]

A setting making the current behavior opt-in has been added to 1.44, upcoming.

[trallnag]

Using dnsmasq works for me. I disabled resolved

---

Disable systemd-resolved because we use dnsmasq:

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo systemctl mask systemd-resolved

Ensure the following setting is set in /etc/wsl.conf:

[network]
generateResolvConf = false

Temporarily hardcode nameserver:

sudo unlink /etc/resolv.conf
sudo sh -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

Install dnsmasq:

sudo apt updatesudo apt install dnsmasq

Configure it /etc/dnsmasq.conf:

interface=lo
no-resolv
# Use internal DNS servers for "*.private.com".
server=/private.com/1.2.3.4
server=/private.com/5.6.7.8
# Use Google for everything else.
server=8.8.8.8

Change nameserver:

sudo sh -c 'echo "nameserver 127.0.0.1" > /etc/resolv.conf'

Ìf you are NOT using Systemd in your WSL (for example with systemd-genie), add the following to whatever rc file that is being run on every login. If you do use Systemd, skip this step.

pgrep dnsmasq >/dev/null || sudo /etc/init.d/dnsmasq start

Logout and restart:

logout
wsl --shutdown Peter
wsl -d Peter

---

Small update: For some reason whenever I restart Windows and start up Peter (the same of my WSL instance using Genie) systemd-resolved is running again despite being disabled and masked previously. So what I did now is outright delete the unit.

systemctl stop [servicename]
systemctl disable [servicename]
rm /etc/systemd/system/[servicename]
rm /etc/systemd/system/[servicename] # and symlinks that might be related
rm /usr/lib/systemd/system/[servicename] 
rm /usr/lib/systemd/system/[servicename] # and symlinks that might be related

systemctl daemon-reload
systemctl reset-failed

---

Edit: Another update. It still does not work properly.

For some reason, whenever I restart my Windows machine the first time I start the WSL instance with genie I get a timeout. The dnsmasq service hangs with the message that the port is already in use. But checking the port it is NOT in use (at least from within WSL). Nothing helps except doing a wsl --shutdown and restarting the instance. Now there is no timeout and dnsmasq runs perfectly fine.