Avahi Won't Talk to Itself

Symptom:

Let's use hostnames of xena and iris. Suppose, executing on xena, you do a query to Avahi similar to this -- any record type fails similarly.

dig -p 5353 @xena xena.local. A

It times out and no DNS records are returned. Every host fails to respond to queries to itself. Whereas if you executed on xena and said

dig -p 5353 @iris iris.local. A

the mDNS information would be returned. You do have to ask about iris on the iris server, which is the only one that knows about iris' resources. And if you send to the mDNS multicast addresses, 224.0.0.251 or ff02::fb, the query will be received by all hosts including the execution host (xena), and will be responded to by the host having the information.

What's happening:

In /etc/avahi/avahi-daemon.conf there are two parameters, allow-interfaces and deny-interfaces. The values are comma separated lists of net interface names, e.g. eth0,wlan0,vnet1. An interface is allowed if it is not in deny-interfaces and is in allow-interfaces. The defaults are to deny lo (loopback) and point-to-point interfaces, and to allow all others. Allowed interfaces have their announcing flag set, which means that A or AAAA records are created and sent out for global scope addresses on those interfaces, but also, packets arriving on non-announcing interfaces are tossed with an error message, Received packet from invalid interface.

Unicast (not multicast) packets from the local machine to Avahi on the local machine are received via the lo (loopback) interface and are tossed. This explains the symptom.

How to fix:

You don't.

The purpose of Avahi is so a client can find hosts anywhere on the local net that offer relevant services, e.g. printing or media playback. This means that normally the client will send a multicast query, which does report services on self. It's going to be very rare for the client to send a unicast packet to any host -- if it knew the hostname or IP, it would have used the service without going through Avahi. And it's going to be even rarer to send a unicast packet to itself. I encountered this bug or misfeature when writing a test program that checks if various services, such as Avahi, are functioning, and restarts them if not. I have a feeling that the author is not going to put a high priority on fixing this issue.

Avahi has another annoying behavior that causes a bad interaction with dig, the program that makes and prints out DNS queries. When replying to a unicast packet it sends from the address and interface picked by the kernel. On my net the hosts often have both a fixed IPv6 address and a RFC 4862 auto-configured address, so half the time the reply comes from an address different from the one dig sent the unicast packet to. dig is aware of this and tosses the packet with an error message. Most clients, including Perl's Net::DNS::Resolver, will accept a reply from any source, but it would be a helpful (but low priority) bugfix for Avahi to reply to unicast packets from the destination address in the query.

A diversion into paranoid security: When the client asks for the IP address that goes with a hostname, an attacker could respond quickly with the address of its fraud site. The client should use DNSSEC (signed queries and responses) to reject such responses, and the attacker most likely will send from the expected source address anyway, not from its legitimate IP. So excluding responses from the wrong address only weakly adds to security.