2

I'm trying to launch a container with systemd-nspawn (from the systemd-container package, version 241), but the container is not able to resolve host names. The host environment is PureOS 9.0, which is Debian-like and based on Ubuntu.

The container image was created using debootstrap and has systemd-container installed:

debootstrap \
    --components main,restricted,universe \
    --include systemd-container \
    bionic /var/lib/machines/bionic http://archive.ubuntu.com/ubuntu/
echo bionic > /var/lib/machines/bionic/etc/hostname

I'm launching the container from the image directory:

systemd-nspawn -qbD /var/lib/machines/bionic

From inside the container, I can access the host network:

root@bionic:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=130 ms

But DNS resolution is failing:

root@bionic:~# ping google.com
ping: google.com: Temporary failure in name resolution

The container resolv.conf is what I would expect; it looks like a pretty standard local DNS resolver, which should be provided by the host systemd-resolved.

nameserver 127.0.0.53

I see the DNS resolver listening on the host:

root@host:~$ lsof -i -Pn | grep LISTEN | grep 53
systemd-r  6957 systemd-network   13u  IPv4 5300137      0t0  TCP 127.0.0.53:53 (LISTEN)
systemd-r  7252 systemd-resolve   12u  IPv4 5313025      0t0  TCP *:5355 (LISTEN)
systemd-r  7252 systemd-resolve   14u  IPv6 5313028      0t0  TCP *:5355 (LISTEN)

This is similar to a setup I was using before on Ubuntu without problem. I don't have any reason to believe this shouldn't work on PureOS or on my version of systemd. I'm guessing something is different in the host networking configuration, but I'm not sure what to check.

I found that my host was not running systemd-resolved or systemd-networkd by default. I started those services manually with no change in behavior. I also stopped NetworkManager, thinking it might be interfering, but no luck there either.

Rich Remer
  • 205
  • 1
  • 7
  • 1
    I'm hitting the same or similar issue myself with DNS failing in nspawn containers. One thing I noticed is that ipv4 traffic works, but ipv6 doesn't. You can test this with something like `curl -4 google.com` which succeeds for me when a normal curl or a `curl -6` fails. Further I found that the `gethostbyname` system call works correctly, but `getaddrinfo` fails. I'm still not sure what this means, but hopefully it's helpful to someone – Michael Dec 23 '20 at 20:37

1 Answers1

0

I had this issue while trying to use a commercial VPN on Linux. I was using a Systemd container with Debootstrap like you. I did some research and found out that Systemd containers have a lot of issues with DNS for two big reasons, writing code without writing documentation. Deploying something without testing on a network.

I also read some articles that were very telling by searching Google for “systemd container and vpn dns issues”. It turns out there are several things you should examine, but there is a right way of doing everything and that right way works. Check out some of my reading...

In this article the author views the DNS cache entry and finds an update has changed the symbolic link for resolv.conf.

How to view DNS cache entries with the new systemd-resolved resolver

In this article they talk about the issue and how it is caused in the scenario of split DNS.

systemd-resolved: introduction to split DNS

How to fix it on Kubernetes 1.10 and earlier.

Solving Kubernetes DNS issues on systemd servers

An even easier solution is to remove Systemd or use a Linux distro without Systemd, but creating a Chroot or container other than a Systemd container is no easy way out. Of course, all the other considerations apply, but the real point of failure comes connecting and disconnecting to the nameserver. Systemd will use its own nameserver in resolv.conf. The real solution in my case of using a VPN was to create a kill switch that ensures if the connection to the DNS nameserver is lost, it is no longer trying to resolve DNS.

What is a VPN Killswitch and How Does it Work?

This sort of problematic behavior is not exclusively related to Systemd containers, but occurs also in WSL2 in a similar fashion...

Fix DNS resolution in WSL2

Another worthy read!