AVAHI vs systemd-resolved on Ubuntu: which is more reliable for .local resolution and DNS-SD browsing in practice?

On an Ubuntu system, you effectively have two different philosophies competing for control of .local and DNS-SD: AVAHI (plus nss‑mdns) on one side, and systemd‑resolved’s built‑in mDNS/DNS‑SD logic on the other. In practice, you want one clear owner of mDNS, a predictable nsswitch configuration, and behavior that matches the Bonjour/Zeroconf ecosystem on your LAN.

Quick Answer: The best overall choice for reliable .local resolution and DNS‑SD browsing on Ubuntu is Avahi + nss‑mdns. If your priority is tight integration with systemd’s stub resolver and centralized DNS handling, systemd‑resolved is often a stronger fit. For mixed or legacy environments that need Bonjour‑compatible browsing without surprises, consider Avahi as the mDNS/DNS‑SD layer with systemd‑resolved limited to unicast DNS.

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Avahi + nss‑mdns	Reliable *.local and DNS‑SD on Ubuntu & other Linux	Mature, Bonjour/Zeroconf‑compatible mDNS/DNS‑SD with wide distro adoption	Requires aligning nsswitch and avoiding overlap with systemd‑resolved’s mDNS
2	systemd‑resolved (mDNS + LLMNR)	Admins standardizing on systemd’s resolver stack	Single daemon for unicast DNS, mDNS, and optionally LLMNR	Feature set and behavior lag Avahi for DNS‑SD browsing; more Ubuntu‑specific quirks
3	Hybrid: Avahi for mDNS/DNS‑SD, resolved for DNS	Mixed networks or multi‑distro fleets	Keeps Bonjour‑compatible service discovery while using systemd‑resolved for upstream DNS	Needs careful configuration to prevent double‑handling *.local

Comparison Criteria

We evaluated each option against the following criteria to ensure a fair comparison:

• .local resolution reliability: How consistently hostnames like printer.local and nas.local resolve from common CLI tools and applications, across different networks and Ubuntu releases.
• DNS‑SD browsing stability: How well the stack discovers services via DNS‑SD (e.g., _ipp._tcp, _afpovertcp._tcp, _smb._tcp), including listing and resolving services advertised by Bonjour/Zeroconf devices.
• Operational predictability on Ubuntu: How easy it is to deploy, debug, and maintain the configuration on Ubuntu, including interactions with NetworkManager, nsswitch, and systemd defaults.

---

Detailed Breakdown

1. Avahi + nss‑mdns (Best overall for reliable, Bonjour‑compatible discovery)

Avahi + nss‑mdns ranks as the top choice because it provides a mature, Bonjour/Zeroconf‑compatible implementation of mDNS/DNS‑SD and integrates cleanly with Ubuntu’s nsswitch for *.local resolution across “all system programs using nsswitch.”

From Avahi’s own definition: it is “a system which facilitates service discovery on a local network via the mDNS/DNS‑SD protocol suite.” It is “primarily targetted at Linux systems and ships by default in most distributions,” and the nss‑mdns companion allows “hostname lookup of *.local hostnames via mDNS in all system programs using nsswitch.” That’s exactly the behavior you want when you type ping host.local or when a GUI “Network” browser lists your printers and file shares.

What it does well:

• Mature, cross‑distro behavior:

  • Avahi has been the de‑facto mDNS/DNS‑SD implementation across major Linux distributions (Ubuntu, Debian, Fedora, many BSD‑like systems) for years.
  • Bonjour/Zeroconf devices (Macs, printers, NAS boxes) expect this style of mDNS/DNS‑SD behavior. In practice, you get fewer surprises with service browsing (_ipp._tcp, _smb._tcp, _afpovertcp._tcp, etc.).
  • The primary API is D‑Bus, which is stable and used by a large set of desktop and server software for dynamic service registration and browsing.

• *Predictable .local resolution via nss‑mdns:

  • With nss‑mdns installed and mdns or mdns4_minimal configured in /etc/nsswitch.conf, *.local hostnames are resolved via mDNS in “all system programs using nsswitch.”
  • CLI tools such as ping, ssh, curl, and any library that honors getaddrinfo() see host.local exactly the same way a macOS client does.
  • Resolution behavior is easy to reason about: hosts: files mdns4_minimal [NOTFOUND=return] dns makes *.local go to mDNS first, then “normal” unicast DNS for other domains.

• Robust DNS‑SD browsing:

  • Avahi implements DNS‑SD browsing as a first‑class feature. Browsers such as avahi-browse and GUIs that rely on the Avahi D‑Bus API can enumerate and resolve services reliably.
  • The /etc/avahi/services XML mechanism lets you publish services without writing a publisher, which is useful for static LAN services (e.g., a file server exporting _smb._tcp).
  • Wide adoption means most odd edge cases with service types, TXT records, and interoperability with Bonjour are already explored and documented.

Tradeoffs & Limitations:

• Needs clear boundaries with systemd‑resolved:
  • On modern Ubuntu releases, systemd‑resolved is enabled by default and can also handle mDNS. If both Avahi/nss‑mdns and resolved try to own *.local, you get flapping or inconsistent results.
  • You must ensure:
    • LLMNR=no and MulticastDNS=no in systemd-resolved.conf if you want Avahi to be the only mDNS implementation, or
    • Adjust nsswitch so *.local lookups go where you intend (either to nss‑mdns, or to resolved’s resolve NSS module, but not both).
  • In mixed setups, mis‑ordering mdns4_minimal, resolve, and dns in nsswitch.conf is a common cause of “sometimes host.local works, sometimes it doesn’t.”

Decision Trigger: Choose Avahi + nss‑mdns if you want stable *.local resolution and full DNS‑SD browsing that matches Bonjour/Zeroconf across Linux distributions, and you prioritize predictable behavior over having everything inside a single systemd daemon.

---

2. systemd‑resolved (Best for single‑daemon, systemd‑centric setups)

systemd‑resolved is the strongest fit here because it centralizes unicast DNS, caching, and optional mDNS/LLMNR into one resolver daemon tightly integrated with systemd, which some Ubuntu admins prefer for consistency and management.

Resolved sits in front of glibc as a stub resolver (127.0.0.53), handles DNS servers provided by NetworkManager or netplan, and can also synthesize mDNS responses for local hostnames and services if configured.

What it does well:

• Unified resolver:

  • One daemon handles upstream DNS, split DNS, DNSSEC validation (when enabled), and mDNS/LLMNR if you turn them on.
  • From an operational standpoint, you have a single status command (resolvectl status) and a single configuration file (/etc/systemd/resolved.conf) to examine for most name resolution behavior.
  • For some environments, especially where systemd is the baseline and Avahi is seen as “another moving part,” this simplifies mental models.

• Tight integration with Ubuntu’s networking stack:

  • NetworkManager and netplan are already wired to systemd‑resolved on recent Ubuntu releases.
  • When network interfaces come and go, DNS server changes propagate cleanly into resolved’s configuration.
  • This can be appealing for laptops frequently roaming between different enterprise networks, VPNs, and home LANs.

Tradeoffs & Limitations:

• Less battle‑tested for DNS‑SD browsing:

  • systemd‑resolved’s DNS‑SD support is younger and not as widely depended on as Avahi’s. If your workflow relies on robust service browsing (e.g., avahi-browse‑style enumeration, complex TXT records, or a range of third‑party Bonjour devices), you’ll run into more corner cases.
  • Client tooling is less uniform. Many applications on Ubuntu are already written to talk to Avahi over D‑Bus; porting them to use resolved’s interfaces is not always straightforward.

• Interoperability quirks on mixed networks:

  • In networks populated with Macs and embedded Bonjour devices, I’ve seen more variations in how resolved behaves with naming conflicts, multiple answers, and high‑churn environments.
  • The default .local semantics under systemd‑resolved can differ from what other systems expect, particularly once you bring LLMNR into the mix. This can matter when devices rely heavily on classic mDNS behavior.

Decision Trigger: Choose systemd‑resolved if you want a single, systemd‑native resolver managing DNS and mDNS on Ubuntu, accept a less mature DNS‑SD browsing story than Avahi, and you’re comfortable debugging name resolution primarily via systemd-resolved tooling and logs.

---

3. Hybrid: Avahi for mDNS/DNS‑SD, resolved for unicast DNS (Best for mixed fleets and cautious migrations)

The hybrid model stands out for this scenario because it lets systemd‑resolved focus on upstream DNS while Avahi handles mDNS/DNS‑SD, which is aligned with how most non‑systemd distributions operate and with Bonjour/Zeroconf expectations.

This is effectively the “classic” Linux behavior—Avahi for service discovery and *.local names, another resolver for DNS—adapted to an Ubuntu world where systemd‑resolved is the default DNS stub.

What it does well:

• Boring, interoperable service discovery:

  • Avahi remains the authority for mDNS and DNS‑SD, matching behavior across other Linux and BSD systems in your fleet.
  • systemd‑resolved handles what it’s already good at: upstream DNS from your router, enterprise resolvers, or VPN split‑DNS configuration.
  • This minimizes surprises when you put Ubuntu desktops next to Macs and other Bonjour devices on the same LAN.

• Incremental migration path:

  • If you’re moving from a traditional dnsmasq + Avahi world to systemd‑resolved, you can keep Avahi untouched and only swap out the unicast DNS resolver.
  • If issues arise, you can debug one plane at a time: mDNS/DNS‑SD via Avahi (avahi-browse, journalctl -u avahi-daemon), DNS via resolved (resolvectl, journalctl -u systemd-resolved).

Tradeoffs & Limitations:

• Requires careful configuration to avoid double ownership:
  • You must clearly disable mDNS in systemd‑resolved (MulticastDNS=no) or ensure that its resolve nss module is not competing with nss‑mdns for *.local in /etc/nsswitch.conf.
  • Failure to do so leads to non‑deterministic resolution: sometimes host.local is answered by resolved, sometimes by Avahi, and the results may differ.
  • This is still operationally simple, but it does mean you need a documented “this is how we wire name resolution on Ubuntu” standard for your team.

Decision Trigger: Choose the hybrid model if you want Avahi’s mature mDNS/DNS‑SD behavior while still using systemd‑resolved as Ubuntu’s default DNS stub, and you’re willing to invest in a one‑time, well‑documented configuration to keep roles cleanly separated.

---

Final Verdict

On Ubuntu, if your question is strictly “which is more reliable for .local resolution and DNS‑SD browsing in practice?”, the answer leans toward Avahi + nss‑mdns:

• It’s purpose‑built for mDNS/DNS‑SD, “primarily targetted at Linux systems,” and ships by default in most distributions, which means a lot of real‑world exposure and debugging.
• With nss‑mdns in place, it provides “hostname lookup of *.local hostnames via mDNS in all system programs using nsswitch,” aligning Ubuntu with macOS and other Bonjour/Zeroconf devices on your LAN.
• DNS‑SD browsing via Avahi’s D‑Bus interface and tools like avahi-browse is more mature than what you’ll see if you rely solely on systemd‑resolved today.

Use systemd‑resolved alone if you want a single, systemd‑centric resolver and your DNS‑SD requirements are minimal. Use the hybrid approach if you want the best of both worlds: Avahi owning mDNS/DNS‑SD, resolved owning unicast DNS, and a clean, documented boundary between them.

Next Step

Get Started