[SOLVED] Some containers can resolve names, some cannot

[memilanuk]

So... this started with a default Ubuntu 22.04 LTS container that I couldn't update, because it couldn't 'find' the package repos. I could ping local LAN ip addresses, but not names like 'google.com'.

After further poking around, I found that a default Debian 11 container was able to resolve names, no problem. Ubuntu 22.04 VM... also no problems. Someone suggested the problem might be my gateway (Unifi USG) or it's DHCP server. I also tried with static IPs - no difference.

Later I tried the same containers (and others) inside a separate network (opnsense VM bridging between vmbr0 and vmbr2, with the VMs and LXCs on vmbr2, and the opnsense VM acting as DHCP server). Debian LXCs, and Ubuntu & openSuSE VMs - no problems. Ubuntu, Alpine & openSuSE LXCs... unable to resolve external names such as ubuntu.com or google.com. The SuSE & Alpine LXCs don't appear to have 'dig' installed, but the Ubuntu LXC does. The connection times out, saying no name servers could be reached. But, they can all ping external IP addresses i.e. 1.1.1.1 directly.

All containers have the default 'Use host settings' for name servers, etc. during creation.

Would this be considered a bug for those container templates (Alpine, Ubuntu and openSuSE)? Why else would some containers seem to resolve names just fine 'out of the box', and others do not - especially when a VM of the same distro does?

 

[memilanuk]

I think I found (part of) the problem. For whatever reason, the Debian container was picking up (or assuming) that the DNS server was the same as the DHCP server, and was looking at the right place - the gateway device. The other devices were using the host info for domain name and DNS, as configured. Unfortunately, I had Tailscale running on the host machine at the time... so they were 'looking' for nameservers they couldn't reach because they don't have access to that network interface.