Docker seems to break DNS name resolution on local machine

Greetings everybody - this is my first-ever post on this forum so hello-and-how-are-you! Also, apologies in advance for the long, wordy post.

I've been happily running ZorinOS in various capacities since version 12 and until now have not encountered any trouble I could not easily figure out on my own or else invent a workaround. However, recently I've run into trouble with DNS that I've not been able to push past.

Currently I'm running Zorin 16.1 on several machines on my network, including one that I've been trying to configure as a homeserver and DNS sinkhole. I've managed to successfully configure the machine to run Pi-Hole, Unbound, and Tailscale so as to be able to perform name resolution, DNS filtering, and upstream DNS for all the machines on my network, and I've been able to get these functions working remotely via Tailscale. I'm also able to access files via FileBrowser and can manage the machine with Cockpit, all over the tailnet. All of these functions involve DNS in one way or another and they all work just about perfectly.

However, I keep running into a strange situation: the precise moment I try to install a Docker container, name resolution breaks on the local machine only. All of the network stuff still functions. The Pi-hole keeps Pi-holing, Filebrowser continues working just as before over the Tailnet, upstream DNS duty via Unbound still happens for all the machines on my network, and I can ping the homeserver using its hostname from inside my network as well as out in the world. However, the machine hosting these services cannot do name resolution for itself, meaning I can't update the OS, install software or update packages, or even ping another machine on the local network or the internet using target machine's domain or hostname. I can ping anything I want so long as I have the IP address, but name resolution is right out.

I've encountered this exact breakdown two times previously and each time it has happened I have given up trying to solve the problem on my own and resorted to re-installing everything from scratch. Each time the problem manifests immediately after running Docker.

I'd like to know how to fix this, because there are Docker apps I'd like to be running (namely Quanta and emulatorjs) but not at the expense of breaking my server.

I will show technical infos and terminal output in subsequent posts in this thread, but i wanted to put this out there as a preamble just to see if anyone has encountered anything similar, and to verify that I'm communicating clearly.

Any thoughts as to what might be going on before the copy-pasting begins?

Thanks in advance!

Did not understand a word of that, but I'm new here and to Linux/Zorin, great help on here so good luck!

1 Like

Let's start with some terminal output:

analytic@origin:~$ systemctl status systemd-re> solved.service

yields

 Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendo>
 Active: active (running) since Tue 2022-05-03 15:31:31 CDT; 21h ago
   Docs: man:systemd-resolved.service(8)
         https://www.freedesktop.org/wiki/Software/systemd/resolved
         https://www.freedesktop.org/wiki/Software/systemd/writing-network-co>
         https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-c>

Main PID: 520 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 8702)
Memory: 5.6M
CGroup: /system.slice/systemd-resolved.service
└─520 /lib/systemd/systemd-resolved

May 03 19:47:58 origin systemd-resolved[520]: Flushed all caches.
May 03 19:48:00 origin systemd-resolved[520]: Flushed all caches.
May 03 20:00:13 origin systemd-resolved[520]: Flushed all caches.
May 03 20:00:13 origin systemd-resolved[520]: Flushed all caches.
May 03 20:00:15 origin systemd-resolved[520]: Flushed all caches.
May 03 20:00:16 origin systemd-resolved[520]: Flushed all caches.
May 03 20:01:02 origin systemd-resolved[520]: Flushed all caches.
May 03 20:01:02 origin systemd-resolved[520]: Flushed all caches.
May 03 20:01:03 origin systemd-resolved[520]: Flushed all caches.
May 03 20:01:04 origin systemd-resolved[520]: Flushed all caches.

Looks good to me. Next let's try:

analytic@origin:~$ systemd-resolve --status

This gives us a little more to chew on. See:

Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test

Link 4 (docker0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no

Link 3 (tailscale0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 100.100.100.100
DNS Servers: 100.100.100.100
DNS Domain: tailnet-c74e.ts.net
lilfonky.github.beta.tailscale.net
~.

Link 2 (eno1)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 100.102.134.125
DNS Servers: 100.102.134.125
192.168.0.145
DNS Domain: ~.

I'm not an expert at interpreting these outputs but I'm wondering if the info in Link 4 (docker0) is related to my issue. In particular the

DefaultRoute setting: no

Seems possibly relevant. But then again maybe not. I currently have no running docker images, but Docker appears to have a network up.

The 100.100.100.100 in Link 3 (tailscale0) is I think the loopback for Tailscale, which is how MagicDNS gets its business done.

Current DNS Server: 100.102.134.125

is on 100.x.x.x because I'm resolving DNS over Tailscale.

/etc/resolv.conf looks like this:

nameserver 127.0.0.53
options edns0 trust-ad
search tailnet-c74e.ts.net lilfonky.github.beta.tailscale.net

If I understand correctly the nameserver is in the loopback range because of Pi-hole and/or Unbound, which I think should be normal configuration, but maybe not.

/etc/systemd/resolved.conf looks like this:

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
DNSStubListener=no
#ReadEtcHosts=yes

Which I think is completely stock and unconfigured. I think this is OK but maybe no?

Anything conspicuous in any of this?

Do you have resolvconf installed?

sudo apt install --reinstall resolvconf

Reboot and test.

This is only a First Post Suggestion that may actually work...

Neither am I, but I agree with the track you are on...

Have you done anything with your iptables?
e.g.:

update-alternatives --set iptables /usr/sbin/iptables-legacy

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.