Help understanding networking around .local suffix routing from inside containers

Incus
1

I have Incus 6.7 running on a Debian bookworm machine with a number of mainly bookworm containers, with docker services running inside them, ports forwarded etc all working fine, so I have a reasonable handle on the basics. Everything is connected to incusbr0.

$ incus network ls
+-------------+----------+---------+-----------------+------+-------------+---------+---------+
|    NAME     |   TYPE   | MANAGED |      IPV4       | IPV6 | DESCRIPTION | USED BY |  STATE  |
+-------------+----------+---------+-----------------+------+-------------+---------+---------+
| eno2        | physical | NO      |                 |      |             | 0       |         |
+-------------+----------+---------+-----------------+------+-------------+---------+---------+
| incusbr0    | bridge   | YES     | 10.92.119.1/24  |      |             | 10      | CREATED |
Background about why .local is involved

I have recently migrated HomeAssistant from a dedicated Pi to running as a VM in Incus, and tried to set up an ESPHome device, which has given me this confusion about .local and containers/ VMs. I have worked around it for the time being by setting a static IP on the device and forcing pings rather than mDNS .local lookups but I’d like to understand where the gap is.

ESPHome flashes onto my device, and gives it devicename.local, in this case, esphome-1.local as an address, and expects to find it at that address. This name resolution does not work inside an Incus VM or container, but it works from the rest of the network.

Pinging directly from host

$ ping esphome-1.local
PING esphome-1.local (192.168.0.55) 56(84) bytes of data.
64 bytes from esphome-1.lan (192.168.0.55): icmp_seq=1 ttl=255 time=60.3 ms

Pinging via container

$ incus exec utils ping esphome-1.local
ping: esphome-1.local: Temporary failure in name resolution

While trying to understand and resolve this, I’ve installed resolvectl which I previously didn’t need.
From the host

$ resolvectl query 192.168.0.55
192.168.0.55: esphome-1.lan                    -- link: eno2

Via a container

$ incus exec utils resolvectl query 192.168.0.55
192.168.0.55: esphome-1.lan                    -- link: eth0

I have used resolvectl to enable mDNS on eno2, eth0, incusbr0 in varying configurations and nothing I’ve tried lets the container resolve the .local address like can be done from the host.

I’m sure there’s something really simple that I’m missing, but I’ve run out of throwing stuff at the wall options, so would appreciate some pointers.

2

Wondering if the right way to do it is to play with the configuration options (dns.domain, dns.mode, dns.search, etc) on the incusbr0 bridge (using incus network command) so that resolution happens on the bridge controlled by incus (and not doing it from the host os ?). Bridge network - Incus documentation (under Configuration Options). I am not suggesting that is the right way to do it (because I don’t know :frowning: Just thinking loud.

3

Do you have the mDNS server too? That’s usually avahi-daemon on most Linux systems.

4

Thanks for the pointers both, I’ll have a play over the weekend and report back-not currently running avahi as far as I’m aware of.