Comment 3 for bug 1830531

The most likely cause for this is that you have packets outbound on port 5353 firewalled either locally or on your network device. When another host pings the address, the responses are sent via multicast and Avahi caches that response, and so can then use it without having to transmit a packet.

Until someone else looks it up, the cache is empty and the query packet is blocked, so no resolution happens.

To confirm this, other than checking and clearing both iptables and nftables, you could try run tcpdump on your host and then on another host to see if you can see the packet generated locally, and then if it actually arrives on the network.

Note that once avahi has the address in its cache, when it queries the network for it, it includes that address in the packet as "Known Answer" and the other host won't respond. So when testing this you are likely best to restart the local avahi daemon to clear it's cache before each test. You can see those "Known Answers" in the tcpdump though.

Best viewed with wireshark as it makes decoding the DNS part easy.

As a secondary test, I would suggest trying a different network adapter (possibly wired instead of wireless, or vica-versa) - you can also get these problems from weird drivers in some cases. Though usually broken drivers prevent you from RECEIVING multicast, and so manifests that this never works, so that seems unlikely in your case, but perhaps not impossible.

As a third test try 'avahi-resolve-host-name' instead of ping, to isolate if "avahi" / multicast is the issue, as opposed to the nss-mdns layer.

Going to mark this Invalid for now, however, if you can show from the packet dumps that the query packets are really not being sent at all even locally feel free to set the status back to New for further investigation.