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

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 the system resolver stack and split‑DNS behavior, systemd‑resolved is often a stronger fit. For mixed or legacy environments that already standardize on Bonjour/Zeroconf semantics, consider “Avahi as primary, systemd‑resolved for upstream DNS only.”

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Avahi + nss-mdns	Reliable .local mDNS + DNS‑SD browsing	Mature, Bonjour/Zeroconf‑compatible service discovery on Linux	Needs correct nsswitch.conf and may overlap with systemd‑resolved if not scoped
2	systemd‑resolved (with mDNS enabled)	Unified resolver stack + split DNS	Single daemon for unicast DNS, caching, and optional mDNS	mDNS/DNS‑SD feature set is narrower; DNS‑SD browsing still needs tooling
3	Avahi primary + systemd‑resolved for upstream DNS	Mixed fleets, legacy apps, and predictable Bonjour behavior	Clear separation: Avahi for LAN discovery, resolved for upstream DNS	Requires explicit configuration to avoid fighting over .local

Comparison Criteria

We evaluated each approach on Ubuntu using three practical criteria:

• .local hostname resolution reliability:
  How consistently foo.local resolves across all system programs (CLI tools, GUIs, libraries) using the standard glibc + nsswitch path.

• DNS‑SD browsing support and ecosystem compatibility:
  How well each option discovers and advertises DNS‑SD services (_ipp._tcp, _afpovertcp._tcp, _ssh._tcp, etc.), and how compatible it is with Bonjour/Zeroconf devices already on the LAN.

• Operational clarity on Ubuntu:
  How easy it is to understand, configure, and debug in real deployments without surprising interactions—especially on Ubuntu, where both Avahi and systemd components are typically present.

---

Detailed Breakdown

1. Avahi + nss-mdns (Best overall for predictable .local + DNS‑SD)

Avahi + nss-mdns ranks as the top choice because it implements mDNS/DNS‑SD directly, ships by default in most Linux distributions, and—with nss-mdns—makes *.local work through nsswitch for all system programs.

Avahi is “a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite.” Its primary API is D‑Bus, but it also supports XML service definitions in /etc/avahi/services. The companion nss-mdns project “allows hostname lookup of *.local hostnames via mDNS in all system programs using nsswitch.”

What it does well:

• Reliable .local resolution via nsswitch:

  • nss-mdns plugs mDNS into glibc’s nsswitch mechanism.
  • Any tool that uses the standard resolver path (e.g. ping printer.local, ssh host.local, GUI apps using libc) can resolve .local hostnames via mDNS.
  • Behavior matches what people expect from Bonjour on macOS: join the LAN and hostname.local just works.

• Full DNS‑SD browsing and publication:

  • Avahi runs its own mDNS responder and DNS‑SD browser.
  • Dynamic interactions go through the D‑Bus API: you can browse services, resolve instances, and publish custom services from your own daemons.
  • Static services can be published by dropping XML files into /etc/avahi/services, which Avahi will advertise without any custom publisher.
  • This gives immediate, Bonjour‑style discovery for practical things:
    • “find printers to print to” (_ipp._tcp, _printer._tcp)
    • “find files being shared” (SMB, AFP, SFTP, webdav services)
    • peer applications (_ssh._tcp, _rfb._tcp, custom app IDs).

• Ubuntu‑friendly and widely deployed:

  • Avahi “ships by default in most distributions,” and Ubuntu is no exception; a large percentage of Ubuntu systems already have Avahi available or a one‑step install away.
  • The project is long‑running, with releases like 0.7 and 0.8 documenting technical changes (e.g., “a D-Bus/avahi-core API change related to racing signals with D-Bus object creation”), which is exactly what you want from a system component: boring, predictable evolution.

Tradeoffs & Limitations:

• Needs clean boundaries with systemd‑resolved:
  • On modern Ubuntu, systemd‑resolved is present by default and can also handle .local via mDNS. If both are configured to own .local, you can get inconsistent behavior.
  • You generally want nss-mdns to handle mDNS lookups and Avahi to handle DNS‑SD, while systemd‑resolved focuses on unicast DNS (corporate DNS, public internet). That requires explicit nsswitch.conf and resolved configuration.
  • Misconfigured nsswitch.conf (e.g., hosts: files dns with no mdns or mdns4) will cause .local lookups to bypass Avahi entirely.

Decision Trigger:
Choose Avahi + nss-mdns if you want Bonjour/Zeroconf‑style behavior, need robust DNS‑SD browsing, and want .local to work for every program that uses glibc’s resolver via nsswitch. This is the most reliable setup for typical Ubuntu desktops, labs, and small networks where printers and file shares should “just appear.”

---

2. systemd‑resolved (Best for unified resolver stack & split DNS)

systemd‑resolved is the strongest fit when your top priority is a single, integrated resolver daemon handling unicast DNS, DNS caching, and optionally mDNS, especially in environments with complex split‑DNS needs.

On Ubuntu, systemd‑resolved is the default system resolver. It manages /run/systemd/resolve/resolv.conf, supports per‑link DNS settings (via NetworkManager or netplan), and can optionally do mDNS lookups, including .local, when configured.

What it does well:

• Unified DNS resolver and cache:

  • Centralizes unicast DNS, DNSSEC validation (if enabled), and caching in one place.
  • Plays nicely with corporate setups: multiple DNS servers, search domains, VPN‑specific DNS, and per‑interface policies.
  • CLI tools like resolvectl give you direct introspection (which server answered what, per‑link DNS configs).

• Optional mDNS support built into the same daemon:

  • When you enable mDNS in resolved (e.g., via MulticastDNS=yes in the relevant config), it can answer and query .local addresses on participating interfaces.
  • That means fewer moving parts if you’re willing to rely on the systemd stack for both unicast DNS and mDNS.
  • For simple .local resolution in a controlled environment, this can be sufficient.

Tradeoffs & Limitations:

• DNS‑SD browsing is not its core job:

  • systemd‑resolved focuses on name resolution, not full DNS‑SD service browsing and publication.
  • You still need tools or libraries that know how to browse _services._dns-sd._udp and service types, and you won’t get the same mature D‑Bus DNS‑SD API that Avahi exposes.
  • For applications that expect Bonjour‑style discovery, Avahi’s API and tooling ecosystem are significantly richer and better documented.

• .local behavior can be less predictable in mixed stacks:

  • On Ubuntu systems where both Avahi and systemd‑resolved are active, you can end up with multiple components capable of responding to .local.
  • If nsswitch.conf is not aligned with resolved’s configuration, some applications may bypass mDNS while others hit it, leading to “it works in this CLI tool but not in that GUI” behavior.
  • Debugging often involves checking multiple layers (resolvectl, journalctl for systemd‑resolved, Avahi logs) instead of a single mDNS/DNS‑SD layer.

Decision Trigger:
Choose systemd‑resolved (with mDNS enabled) if you care most about a single resolver stack managing both split DNS and .local, and you only need basic mDNS resolution—not rich, Bonjour‑style DNS‑SD browsing. This is common on server installations where .local is an edge case rather than a core workflow.

---

3. Avahi primary + systemd‑resolved for upstream DNS (Best for mixed / legacy Bonjour environments)

“Avahi primary + systemd‑resolved for upstream DNS” stands out because it gives Avahi clear authority over LAN‑scope mDNS/DNS‑SD while letting systemd‑resolved do what it’s best at: upstream DNS resolution, caching, and split‑DNS.

In practice, this means you treat Avahi (plus nss-mdns) as your Bonjour/Zeroconf implementation, and you configure systemd‑resolved so it doesn’t fight over .local or mDNS handling.

What it does well:

• Clear division of responsibilities:

  • Avahi: mDNS responder, DNS‑SD browsing, and service advertisement.
  • nss‑mdns: integrates *.local mDNS lookups into nsswitch so all system programs see the same behavior.
  • systemd‑resolved: handles unicast DNS queries to upstream servers (corporate DNS, public internet), DNSSEC, and caching.

• Best fit for Bonjour/Zeroconf environments:

  • If you already have a network full of Bonjour devices (macOS, iOS, printers), Avahi gives you a Linux implementation explicitly positioned as Bonjour/Zeroconf‑compatible.
  • Service types and browsing semantics align closely with what those devices expect.
  • This configuration mirrors how many distributions have historically shipped: Avahi for local discovery, a separate resolver for upstream DNS.

Tradeoffs & Limitations:

• Requires explicit configuration work on Ubuntu:
  • You need to ensure:
    • nss-mdns is installed and present in nsswitch.conf (e.g., hosts: files mdns4_minimal [NOTFOUND=return] dns).
    • systemd‑resolved is not trying to override .local with different semantics (adjust its MulticastDNS and routing domain settings as needed).
  • If you skip this hygiene, you can land in hard‑to‑debug states where some queries go via Avahi, others via resolved, and behavior is inconsistent.

Decision Trigger:
Choose Avahi primary + systemd‑resolved for upstream DNS if you’re in a mixed macOS/Linux fleet or a Bonjour‑heavy LAN, and you want Avahi’s mature DNS‑SD implementation while still leveraging systemd‑resolved for advanced unicast DNS features. This is often the most maintainable choice for Ubuntu desktops and workstations in real organizations.

---

Final Verdict

For Ubuntu systems where .local must work reliably and DNS‑SD browsing is a first‑class requirement, Avahi plus nss‑mdns is the most reliable and practical choice. Avahi is a Linux‑first mDNS/DNS‑SD implementation that ships by default in most distributions, integrates via D‑Bus and /etc/avahi/services, and—together with nss-mdns—makes *.local lookups work in “all system programs using nsswitch.” That matches Bonjour/Zeroconf expectations and keeps service discovery boring.

systemd‑resolved has clear strengths as a unified resolver and DNS cache and is suitable when mDNS is a minor concern. But for concrete LAN workflows like “find printers to print to” and “find files being shared” in a Bonjour‑compatible way, delegating mDNS/DNS‑SD to Avahi and using systemd‑resolved for upstream DNS typically yields the most predictable outcomes on Ubuntu.

Next Step

Get Started