what does all this says ?
The first result says that the container dns resolution is fine, as it should be.
The second could have been interesting if the first one had been negative, but it don’t bring much in this case.
The third says that the container resolver, the specialized dnsmasq instance running on the host, is replying to the container indeed, but it is replying it to get lost (status: REFUSED). Obviously there is something wrong with dnsmasq.
why is dnsmasq so difficult, I have no idea. It’s not a common problem seen often on the internet.
I see 2 ways of going forward:
on the host, ps aux | grep dnsmasq
(when the problem happens)
Maybe this will show something obvious.
Or turning logging on; this can be done by editing network (lxc network edit lxdbr0) and adding a raw.dnsmasq key to define an additional config file, such as:
config:
(…)
raw.dnsmasq: conf-file=/media/root/rawdnsmasq-lxd
you have to create the file and add dnsmasq directives like that
log-queries
log-async
log-facility=/var/log/dnsmasq-lxd.log
I am setting this file under /media/root because you can’t use anything under /etc with snap lxd, it’s the first place that I have found escaping the evil claws of snap.