Multicast DNS in Ubuntu: avahi vs systemd-resolved

Lukas Märdian slyon at
Tue Mar 7 14:47:41 UTC 2023

Hey folks!

At we're getting frequent requests about supporting systemd-resolved's mDNS (Multicast DNS) functionality in Ubuntu's network configuration, in order to resolve ".local" domains. [1][2] But we feel like this should not be a Netplan setting, but rather "just work" on a Distro level, without explicit configuration.

Traditionally, Ubuntu is using Avahi + libnss-mdns [3] to resolve .local domains, respond to service discovery requests on port 5353 and support other Zeroconf features. nss-mdns and avahi-daemon are seeded by default on Ubuntu Desktop, but apparently not on Ubuntu Server or Ubuntu Core. Systemd's resolved also supports mDNS, but having two daemons fighting for access to port 5353 sounds like a bad idea. Furthermore, resolved is limited in its functionality compared to Avahi:

"resolved only handles mDNS hostname lookups (something.local) and not generic service discovery. [...] systemd supports registering a SRV and TXT record for a systemd service [1] (e.g. a _ipps-system._tcp service registration for cupsd, if it supported the IPP System Service), but not "sub-services" under that systemd service (like the individual printer registrations to _ipp._tcp and _ipps._tcp), nor does it support DNS-SD sub-types (like _print._sub._ipp._tcp for IPP Everywhere), flagship naming (_printer._tcp is used to reserve service instance names for network printers)." [4]

Once installed, libnss-mdns will enable itself in /etc/nsswitch.conf, by adding IPv4 resolution via "mdns4_minimal [NOTFOUND=return]" and will talk to avahi-daemon to do its job:
> hosts:          files mdns4_minimal [NOTFOUND=return] dns

There are some limited usecases, which aren't covered by this solution, though:
1/ Resolution of local IPv6 only devices

Maybe we should enable the more universal "mdns[_minimal]" NSS module by default?

2/ Applications that are talking to sd-resolved's stub resolver at directly (or sd-resolved's DBus API?), won't go through glibc's Name Service Switch (NSS) mdns*[_minimal] module and thus will lack Avahi's functionality.

sd-resolved has a resolve-only mode [5], where it will try to resolve .local domains, but won't listen or respond on port 5353 for other service discovery requests, thus avoiding conflicts with Avahi. Maybe we should enable "/etc/systemd/resolved.conf:[Resolve].MulticastDNS=resolve" in Ubuntu's systemd by default, so that it's easier for users to install override.conf snippets for specific network interfaces to make use of resolved's mDNS resolver only (keeping the responder disabled). Maybe this setting could then eventually even be controlled (or enabled by default?) through Netplan.
=> The drawback would be that we would then have two mDNS resolvers in place and if issues appear it would be harder to debug (two cases instead of one).

Avahi has been the default for years and is being used on Ubuntu Desktop by default, so I feel we should build upon that and enable the same usecases for Ubuntu Server/Cloud/Core (i.e. make .local resolution "just work" by seeding it accordingly and potentially enable IPv6 resolution, too) instead of giving the option for enabling an additional, conflicting mDNS resolver through systemd-resolved via Netplan. This alone should already support most of the usecases. Additionally, I feel like we should enable "MulticastDNS=resolve" in systemd on a global level, to make it easier for users to activate it on their network interfaces if they really need it for their specific usecase (application talking to sd-resolved directly), this would be similarly to how "read-only" LLMNR lookup is being enabled by default in sd-resolved upstream.

What are your opinions on this proposal?


PS: Also, have a look at Fedora's implementation of using systemd's nss-resolve module instead of glibc's legacy nss-dns module [6][7], and the counter-arguments in [8]. This avoids some redirection when calling into Glibc -> legacy nss-dns -> sd-resolved stub resolver -> upstream DNS server or cache. But it still has the same open question if .local domains should be resolved (exclusively) in Avahi and/or resolved.


More information about the ubuntu-devel mailing list