Avahi Hostname Resolution: Is it caching somewhere?

Question

I am using Fedora 18 with the avahi command line tools (version 0.6.31)

I use avahi-resolve-host-name to discover the IP address of units on my subnet, for testing purposes during development. I monitor the request and response with Wireshark. After one successful request and response, no further requests show up on Wireshark, but the tool still returns an IP address. Is it possible the computer/avahi daemon/something else is 'caching' the result?

The Question: I wish to send out the request packet with EVERY CALL of avahi-resolve-host-name. Is this possible?

The Reason: I'm getting 'false positives' so to speak. I try to resolve 'test1.local', and I am getting a resulting IP, but the unit is no longer located at this IP. I want the request sent every time so I can avoid seeing units at incorrect IP addresses.

Dumps

Answer 1

I see that I'm a bit late to answer your question but I'm going to leave a generic answer in case someone else stumbles upon this.

My answer is based on avahi-0.6.32_rc.

---

Is it possible the computer/avahi daemon/something else is 'caching' the result?

Yes, avahi-daemon is caching lookup results. While this doesn't seem to be explicitly listed in features, the avahi-daemon(8) manpage tips it:

The daemon [...] provides two IPC APIs for local programs to make use of the mDNS record cache the avahi-daemon maintains.

---

I wish to send out the request packet with EVERY CALL of avahi-resolve-host-name. Is this possible?

Yes, it is. The relevant option is cache-entries-max (from avahi-daemon.conf(5)):

cache-entries-max= Takes an unsigned integer specifying how many resource records are cached per interface. Bigger values allow mDNS work correctly in large LANs but also increase memory consumption.

To achieve the desired effect, you can simply set:

cache-entries-max=0

This will disable the caching entirely and force avahi-daemon to reissue the MDNS packets on every request, therefore making it possible for you to monitor them.

However, I should note here that this will also render avahi pretty much useless for normal use. While avahi-daemon will be issuing lookup packets, it will be unable to store the results and every call of avahi-resolve-host-name (as well as other command-line tools, nss-mdns, D-Bus API…) will fail.

Homicide

Is there a command to clear the cache instead of changing the conf? – Corotto

When I set cache-entries-max=0 my avahi isn't able to resovle anything anymore.... – Potted

Answer 2

I just stumbled upon this problem myself and found solution that doesn't require changing the config. It seems that simply killing the daemon (avahi-daemon --kill) flushes the cache. I'm on Ubuntu 18.04 and the daemon is restarted automatically. If on some other distro it isn't running after being killed, it can be restarted with avahi-daemon --daemonize.

Note that root is needed to kill avahi daemon, so this might not be the best option in some cases.

Step

Answer 3

just stumbled upon this old question, having the same problem (a machine was assigned a new IP address, and even after rebooting that machine i could not connect via mymachine.local anymore - my system would always try to use the old IP address)

here's what i found out in the end:

names (hostnames, usernames,...) are typically cached for performance reasons by the nscd (Name Service Cache Daemon) service.

luckily, nscd provides an invalidate command, which flushes the cache for a given type of names.

e.g.

$ ping mymachine.local
PING mymachine.local (192.168.1.234) 56(84) bytes of data.
^C
--- lists.local ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 0ms

$ sudo nscd -i hosts

$ ping mymachine.local
PING lists.local (192.168.1.27) 56(84) bytes of data.
64 bytes from 192.168.1.27: icmp_seq=1 ttl=64 time=0.621 ms
64 bytes from 192.168.1.27: icmp_seq=2 ttl=64 time=0.590 ms
^C
--- lists.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.590/0.605/0.621/0.015 ms

Hadwin