I’ve got LXD installed as a snap. I’ve also got a local dnsmasq installation that only listens to specific interfaces, excluding lxdbr0 (the default bridge interface).
When launching LXC containers, dnsmasq correctly assign IPs, but fails to resolve any DNS requests.
My network configuration (lxc network show lxdbr0):
Maybe run tcpdump -ni lxdbr0 port 53 to see the actual request being made and then tcpdump -ni lo port 53 to maybe see the request that’s forwarded to your local dnsmasq?
I believe dnsmasq usually just relays through whatever is in /etc/resolv.conf, so in your case, LXD’s dnsmasq will likely be talking to your system’s dnsmasq.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
12:42:06.571487 IP 10.204.141.222.33599 > 10.204.141.1.53: 14579+ [1au] A? google.com. (51)
12:42:06.571487 IP 10.204.141.222.33599 > 10.204.141.1.53: 14579+ [1au] A? google.com. (51)
12:42:06.571678 IP 10.204.141.1.53 > 10.204.141.222.33599: 14579 Refused$ 0/0/1 (39)
12:42:06.571693 IP 10.204.141.1.53 > 10.204.141.222.33599: 14579 Refused$ 0/0/1 (39)
That’s all for the query I made in the container.
As I said, the query is REFUSED by the LXD dnsmasq instance. According to RFC1035 Section 4.1.1 RCODE 5:
Refused - The name server refuses to perform the specified operation
for policy reasons. For example, a name server may not wish to
provide the information to the particular requester, or a name server
may not wish to perform a particular operation (e.g., zone transfer)
for particular data.
I suspect the LXD dnsmasq is not aware of any upstream DNS server (that would be the local one). Any idea how I could see the status of the snap dnsmasq?
dnsmasq will log to syslog so you may want to check that.
As for what it uses for upstream servers, I believe it inspects your system’s /etc/resolv.conf.
You can change that though by setting raw.dnsmasq to any dnsmasq config you want and so can use that to point to different upstream servers.
I will try to look at my notes. Sadly, I’m away from my computer and won’t be able to look at what caused the problem until maybe at least 22:00 GMT (18:00 EST).
What would be useful would be to say your current distro version your servers are using. Also, assuming you’re using a custom DNS server, how did you configure it?
I don’t remember precisely the problem, but I think it was setting a custom upstream DNS server in Dnsmasq on Ubuntu and disabling systemd-resolved. Not that in itself is wrong, but it’s pretty fragile. Resolving DNS has become such a complicated task today on GNU/Linux. With too many solutions depending on context.
I ended up still using dnsmasq on the local machine, but did some tricks I’ll have to investigate.
The logs you show seem to originate from the container.
I think this is not the same architecture I had. What I had was Dnsmasq running in the bare metal host. LXD is already using its own dnsmasq service to provide DNS configuration to containers. However, LXD’s dnsmasq couldn’t communicate correctly with the bare metal host. The containers I used didn’t have dnsmasq installed.