.local named devices (i.e. ESPHOME devices) only resolve for a few minutes after booting HA

[jjvandenberg]

ESPhome devices show up being "Online" only a few minutes after booting the system. After that, they turn to "Offline", although they are still online. mDNS resolving seems to breakdown within a few minutes after rebooting the OS. Running Home Assistant Operating System, which is, according to the site, the recommended installation method.

[jjvandenberg]

Here is a recent log file: _hassio_dns_logs (1).txt

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jjvandenberg]

Hi , why is development not picking this up ?

[Strohhutpat]

this works for me https://github.com/home-assistant/plugin-dns/issues/64#issuecomment-963986104

[Strohhutpat]

the issue still exists :-1:

[deviantintegral]

I seem to be unable to resolve mDNS hosts even immediately after startup. I was sure this worked at some point in the past, but now I'm not sure. For testing, I downloaded HAOS 6.6 and spun it up in a VM. The host is able to resolve mDNS names, but containers (including hassio_dns) can not.

I verified with tcpdump that mDNS packets are making it to the hassio_dns container network interface.

It looks like there's been work around this at https://github.com/home-assistant/plugin-dns/pull/73, but I'm unclear on how to upgrade to the latest release or properly test it.

[deviantintegral]

I also downloaded a fresh HAOS 7.5 RC VM, and it has the problem out of the box. It's running the 2021.06.0 version of the dns container. I was able to update it manually with ha dns update --version 2022.03.0 and unfortunately mDNS does not resolve with that either.

Since I can easily replicate this outside of my actual HA install, I'm glad to help debug.

[mdegat01]

@deviantintegral if you're doing this testing on a dev system I would recommend changing to the beta channel by doing ha supervisor options --channel beta or channel dev. Beta is currently set to use 2022.03.0and dev is bleeding edge. If you manually update a plugin like that I'm not sure that change will persist.

Anyway more importantly though, the issue at hand. If you have shell access on the host can you try the following:

resolvectl query <mdns address>

Does that work? If not can you share the output?

If it does work then when you try to use that URL within HA is there an error in the DNS plugin's log? supervisor logs -> DNS or just docker logs hassio_dns from the host.

Starting in 2022.03.0 of the DNS plugin those two should be identical unless the DNS plugin is unable to talk to the host over DBus (in which case there should be an error in the DNS plugin's logs). Any time the DNS plugin sees a .local name it hands it off to systemd-resolved on the host, exactly what resolvectl query is doing.

[deviantintegral]

I updated my VM into the beta channel, and it's now fully working for mDNS resolution. I'm guessing that there's other updates needed that prevented it from working when trying on my live host. If I get a chance, I will reset my VM back to the stable channel to prove flipping back and forth fixes things.

[deviantintegral]

I had a chance to fully test this, and the 2022.03.0 version of plugin-dns is working for me 🎉, even without going to the beta channel.

For reference, on the host:

# resolvectl query zigbee2mqtt.local
zigbee2mqtt.local: 2607:f2c0:f00e:7a00:216:3eff:fe85:6a39 -- link: enp0s3
                   2607:f2c0:f00e:7a00::1d0c   -- link: enp0s3

-- Information acquired via protocol mDNS/IPv6 in 126.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Info and behaviour before updating:

# ha os info
board: ova
boot: A
data_disk: /dev/sda8
update_available: false
version: "7.4"
version_latest: "7.4"
# ha dns info
host: 172.30.32.3
locals:
- dns://192.168.20.1
servers: []
update_available: false
version: 2021.06.0
version_latest: 2021.06.0

# docker exec -it homeassistant bash
bash-5.1# ping zigbee2mqtt.localping: bad address 'zigbee2mqtt.local'

After updating to 2022.03.0:

# ha dns update --version 2022.03.0
Command completed successfully.
# docker exec -it homeassistant bash
bash-5.1# ping zigbee2mqtt.local
PING zigbee2mqtt.local (2607:f2c0:f00e:7a00::1d0c): 56 data bytes
64 bytes from 2607:f2c0:f00e:7a00::1d0c: seq=0 ttl=64 time=0.570 ms
64 bytes from 2607:f2c0:f00e:7a00::1d0c: seq=1 ttl=64 time=0.561 ms
64 bytes from 2607:f2c0:f00e:7a00::1d0c: seq=2 ttl=64 time=0.185 ms
^C
--- zigbee2mqtt.local ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.185/0.438/0.570 ms

Assuming the plugin is going to be updated in the stable channel in the next few weeks, I think this issue can probably be closed. Nice work!

[joshuaspence]

2022.03.0 fixes the problem for me.

[core-ssh config]$ ping homeassistant.local
ping: bad address 'homeassistant.local'
[core-ssh config]$ ha dns update --version 2022.03.0
Processing... Done.

Command completed successfully.
[core-ssh config]$ ping homeassistant.local
PING homeassistant.local (172.30.32.1): 56 data bytes
64 bytes from 172.30.32.1: seq=0 ttl=64 time=0.258 ms
64 bytes from 172.30.32.1: seq=1 ttl=64 time=0.207 ms
64 bytes from 172.30.32.1: seq=2 ttl=64 time=0.309 ms

[mdegat01]

Fixed by #82

[mdegat01]

Also note that there is a new option to disable the fallback dns added here: https://github.com/home-assistant/supervisor/pull/3586 as I would guess a number of users on here would be interested in that.