0

For context: I am using (rootful) Podman containers on my host, which is also connected to a Tailscale VPN. The host's DNS is configured via systemd-resolved.

Since yesterday I have been struggling with my Roundcube (web mail client) container being extremely slow to connect to my mail server container, every action (logging in, listing folders, opening a message) would load at least 5 seconds. Then I realized that every container's /etc/resolv.conf will begin with the following lines whenever the container is started while Tailscale is enabled:

search headscale.ts.net nameserver 100.100.100.100 ...

I assume that's why the Roundcube container first tries to resolve the mail server's domain name via Tailscale which takes a while and then fails, before he finally resolves the domain correctly using the other DNS servers.

As soon as I turn off Tailscale and restart the container, everything works perfectly fine and the /etc/resolv.conf does not contain the Tailscale DNS server anymore.

I'm not sure how to solve this, so my question(s) would be:

  1. Is there some way to configure the containers to skip Tailscale DNS resolution for non-Tailscale domains
  2. How could I tell the container not to use the Tailscale DNS servers while still having it enabled on the host
Improve this question

1 Answer 1

Reset to default
0

I actually found the solution in this discussion on Tailscale's GitHub:

The problem was solved by running tailscale up --stateful-filtering=false on my host machine

Now the Tailscale DNS server is still included in the container's resolv.conf but the requests are getting through immediately again. The reason for this issue is explained quite well by this comment:

[..] Docker will by default use resolv.conf from the host, which points at 100.100.100.100 (served by local tailscaled) as the nameserver. Since this IP lands in the tailscale0 interface, DNS request packets become subject to stateful filtering. And because the source IP is not localhost, but something like 172.17.0.2 (from the docker network range), it's interpreted as "incoming request from another host" and thus rejected.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.