The question: "What is the difference between resolvconf, systemd-resolve, and avahi?"
The answer: "As for resolvconf :
In the old days you edited /etc/resolv.conf manually. Now often some programs want to edit this file. We will have conflict. So there is another way - these programs send dns changes to resolvconf utility and it changes /etc/resolv.conf A program sends dns change to resolvocnf. resolvconf saves the change in its so called database(actually it is files inside /run/resolvonf/...) then resolvoconf analyzes the list of all dns servers it has in database and write to /etc/resolv.conf up to 3 dns servers. It selects dns servers for writing using the following algorythm: suppose we have lo interface, enp0s3 interface, tun0 interface. resolvconf gets dns server ip from a program and analyzes which network interface is needed to reach this dns. For instance we send 1.1.1.1 to resolvconf. It finds out 1.1.1.1 is reachable via enp0s3 and it writes 1.1.1.1 in file "
# cat /run/resolvconf/interface/enp0s3.inet nameserver 1.1.1.1
Next we pass 127.0.0.34 to resolvoconf, it finds out 127.0.0.34 is reachable via lo interface, resolvconf writes the info in its database
# cat /run/resolvconf/interface/lo.dnsmasq nameserver 127.0.0.1
Suppose we have finally the following database:
# cat /run/resolvconf/interface/enp0s3.inet nameserver 1.1.1.1 nameserver 2.2.2.2 # cat /run/resolvconf/interface/lo.dnsmasq nameserver 127.0.0.1 # cat /run/resolvconf/interface/tun0.inet nameserver 192.168.1.10 nameserver 192.168.1.11
The next step resolconf have a file "interface-order" that ranks the interfaces:
lo.* tun*.* ... ...
So resolvconf will take the dns server from "lo" file, after that it will take dns server from "tun" file until it gets 3 nameservers and write them to /etc/resolv.conf
So /etc/resolv.conf will look like
nameserver 127.0.0.1 nameserver 192.168.1.10 nameserver 192.168.1.11
Also, when we push some new dns server to resolvconf it not only modifies /etc/resolv.conf it also pushes dns changes inside some programs as well.
For instance it pushes dns changes to dnsmasq. To be specific it changes the file /run/dnsmasq/resolv.conf
The funny thing is there are multiple "resolvconf" packages: resolvconf, openresolve etc.
As for systemd-resolve:
It is the client for server systemd-resolved. Now systemd-resolve is replaced by resolvectl. systemd-resolved is dns resolver ans dns caching server.
As for avahi:
avahi is mDNS and DNS-SD daemon
Id like to talk about mDNS. When we have LAN and want to make name resolution (convert dns names to ip) without dedicated dns server - in this case we can use mDNS. avahi (mDNS) lets us to resolve domain names ".local" to ip inside LAN . mDNS is based on multicast traffic. So avahi is about resolving domain names ".local" inside LAN. It's useless for dns resolution for servers in the Internet.
When you have avahi daemon on the host and the host name is johndo the you can successfully ping
# ping johndo.local
Suppose your raspberry has "rasp" hostname and your ubuntu host has "ub1" hostname. The following ping should work
# ping rasp.local # ping ub1.local
The resolving works via avahi.
The question: "Which utilities are responsible for this?"
The answer: " resolvonf package is installed on both hosts. It generates /etc/resolv.conf"
avahi daemon on both hosts is sufficient to make dns resolution between hosts inside LAN. If you need to make dns resolution of servers from Internet you need to use smth in addition. systemd-resolved installed on Ubuntu host can make such resolution however you can use some other dns resolver like dnsmasq or built-in in linux "glibc dns resolver".
As for the post of first answer, id like to add some tips.
When we use some program or utility that works with network we often put as an argument dns name of server in it. for instance
$ ping -c1 g.com
the program like ping treats the argument as dns server name. to make connection to the server dns name is not suitables. we need ip address instead. The ping needs to make some way the conversion from dns name to ip. In linux there is NSS subsystem\api \ glibc library whatever. If the program uses NSS it passes dns name to NSS. That is - the program uses some NSS function to make dns resolving. NSS function abstracts how actually dns resolving is made. NSS has nsswitch.conf file, inside we have the line like this.
hosts: resolve files myhostname dns
The line sepcifies how actually dns request is performed via NSS. resolve, files, myhostname, dns - are NSS plugins, they all are shared libraries
# find /usr/lib/ -type f -name "libnss*.so*" /usr/lib/libnss_winbind.so.2 /usr/lib/libnss_wins.so.2 /usr/lib/samba/libnss-info-private-samba.so /usr/lib/libnss_mdns_minimal.so.2 /usr/lib/libnssutil3.so /usr/lib/libnsssysinit.so /usr/lib/libnss3.so /usr/lib/libnss_mdns6_minimal.so.2 /usr/lib/libnss_mymachines.so.2 /usr/lib/libnss_myhostname.so.2 /usr/lib/libnss_systemd.so.2 /usr/lib/libnss_resolve.so.2 /usr/lib/libnss_mdns6.so.2 /usr/lib/libnss_mdns4_minimal.so.2 /usr/lib/libnss_dns.so.2 /usr/lib/libnss_db.so.2 /usr/lib/libnss_files.so.2 /usr/lib/libnss_hesiod.so.2 /usr/lib/libnss_mdns.so.2 /usr/lib/libnss_mdns4.so.2 /usr/lib/libnss_compat.so.2
when NSS subsystem processes dns request it executes these plugins one by one untul the request is successfully resolved or plugins are exhausted Each plugin works in its way. Plugin "files" searches dns names inside a file /etc/hosts (man man nsswitch.conf). Plugin "dns" is built-in dns resolver. it reads its configuration from /etc/resolv.conf , in particular it reads uplink dns servers from this file. dns plugin makes requests to uplink servers to resolve our dns request. Plugin "resolve" forward the request to systemd-resolved daemon. Plugin "mdns4" is used to resolve mDNS domains "*.local", the plugin forwards the request to avahi daemon (according the docs)
So every plugin tries to accomplish initial dns request in its own way. NSS tries to resolve dns request invoking every plugin one-by-one from left to right until it succeeds.
I'd like to point out that the program might use NSS but also might NOT use NSS. For instance "dig" do NOT use NSS. In this case settings in nsswitch.conf do not make any influence. dig just reads /etc/resolv.conf and tries to make dns request by itself to uplink dns server specified in /etc/resolv.conf Another example. resolvectl do not use NSS and do not read /etc/resolv.conf, it forwards the request to systemd-resolved daemon and just waits the answer.
Another example getent uses NSS. Another example ping and curl use NSS. How to determine if the program uses NSS - they all open nsswitch.conf in this case.
# strace -e openat ping -4 -c1 google.com 2>&1 | grep nssw openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 4
Generally i'd like to underline that a user program for dns resolving might use NSS subsystem, but also might not.
By the way systemd-resolved also can work as mDNS client+server, i didnt test but i suspect that mdns4 can work not only with avahi but systemd-resolved.
As for /etc/resolv.conf ,a dns resolver(one of many) may read the file for configuration , but also may not. It depends on particular dns resolver. For instance systemd-resolved do not use /etc/resolv.conf for configuration (inspite the docs say it does). dnsmask does not read /etc/resolv.conf
Hope it helps
