AVAHI vs systemd-resolved: what are the security considerations and hardening options for each (exposure, interfaces, publishing)?

Administrators often lump Avahi and systemd‑resolved together as “the thing doing DNS on my box,” but from a security perspective they have very different roles, attack surfaces, and hardening levers. Avahi is a LAN‑only mDNS/DNS‑SD service discovery daemon; systemd‑resolved is a general resolver and stub DNS server. Comparing their exposure, interfaces, and publishing behavior helps you decide where to run each, how to lock them down, and when to disable them.

This analysis assumes a Linux‑first environment, Bonjour/Zeroconf compatibility requirements, and typical desktop/server profiles.

---

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Avahi + nss-mdns	LAN service discovery with minimal external exposure	Narrow, LAN-scoped attack surface; clear D-Bus and /etc/avahi/services interfaces	Can leak service metadata on “untrusted” Wi‑Fi if not constrained
2	systemd-resolved alone	General DNS resolution and DNSSEC/DoT/DoH	Strong upstream resolver features and cache, no service publishing	mDNS support is limited and easier to misconfigure than Avahi for Zeroconf-style use
3	Avahi disabled, resolved only	Locked-down servers that do not advertise services	Smallest local discovery footprint	No Bonjour/Zeroconf discovery; harder peer-to-peer workflows on LANs

---

Comparison Criteria

We evaluated Avahi and systemd‑resolved against three practical security criteria:

• Network exposure and trust boundaries:
  Which networks and interfaces they listen on, and what they expose beyond the local host—critical for “untrusted Wi‑Fi vs. corporate LAN” decisions.

• Interfaces and capabilities:
  How applications interact with each service (D‑Bus, NSS, XML configs, stub listeners) and how those interfaces can be abused or constrained.

• Publishing and metadata leakage:
  Whether and how services are advertised (mDNS, DNS‑SD, hostnames), what information is exposed to peers, and how you can limit or disable it.

---

Detailed Breakdown

1. Avahi + nss-mdns (Best overall for LAN discovery with controlled exposure)

Avahi is purpose-built for local network service discovery via mDNS/DNS‑SD; combined with nss‑mdns it gives you Bonjour/Zeroconf behavior while keeping a tightly scoped, LAN-only attack surface.

What it does well

• LAN-scoped, multicast-only exposure

  • Avahi’s core job is to send and receive mDNS traffic (UDP 5353, multicast 224.0.0.251/ff02::fb).
  • It does not act as a general Internet-facing resolver or accept arbitrary TCP connections like a classic DNS server.
  • By design, its visibility is per‑link (usually per‑interface), which matches the “I joined this Wi‑Fi, find printers and file shares” use case.

  Hardening implications:

  • Tighten which interfaces Avahi binds to. On a laptop, you may not want to advertise anything on open Wi‑Fi:
    • Use browse-domains, allow-interfaces, and deny-interfaces in avahi-daemon.conf to restrict scope.
    • On some distros, NetworkManager can mark networks as “untrusted”; you can coordinate Avahi masking/stopping on those.

• Clear separation of integration paths

  • For dynamic interaction, Avahi exposes a D‑Bus API through avahi-daemon. This is the primary interface recommended for non‑C applications.
  • For static publication, it supports XML service definitions in /etc/avahi/services, allowing services to be registered without running custom publisher code.
  • nss‑mdns plugs into nsswitch.conf (hosts: line) to enable *.local lookups via mDNS for “all system programs using nsswitch.”

  Hardening implications:

  • D‑Bus access is mediatable via standard D‑Bus policy (and systemd service units). You can:
    • Restrict which users/groups can browse or publish services.
    • Constrain containers/flatpaks from using system Avahi by D‑Bus policy or namespace isolation.
  • /etc/avahi/services is root‑owned; normal users cannot trivially publish persistent services. Use standard UNIX permissions to ensure only trusted configuration management touches it.
  • nss-mdns can be limited so that only hosts: files mdns4_minimal [NOTFOUND=return] dns or similar patterns are allowed; you can avoid surprising *.local resolution paths for security‑sensitive tools.

• Predictable Zeroconf semantics

  • Avahi implements the Bonjour/Zeroconf mDNS/DNS‑SD behavior that other devices expect (printers, media servers, file shares).
  • This compatibility reduces surprises: you are not improvising service discovery semantics on top of a general resolver.

  Hardening implications:

  • Because the protocol behavior is standardized, you can reuse existing firewall rules, ACL patterns, and monitoring.
  • Avahi does not attempt to interpret or validate arbitrary DNS zones from the Internet; its domain is the local link.

Tradeoffs & Limitations

• Metadata leakage on shared networks

  • Avahi advertises service types (_ipp._tcp, _ssh._tcp, etc.), instance names, and hostnames. On an open network, this can reveal:
    • The presence of SSH, HTTP, or other services.
    • Hostnames that may encode usernames, roles, or asset tags.
  • Even if the service itself is access‑controlled, the fact of its existence can help an attacker prioritize targets.

  Hardening options:

  • Disable publishing entirely on certain profiles:
    • Mask or stop avahi-daemon on servers that must not advertise.
    • Use only browsing (clients that discover others) by not adding any services in /etc/avahi/services and keeping D‑Bus access restricted.
  • Minimize information in SRV/TXT records. Avoid embedding usernames, internal environment names, or version strings in TXT data unless strictly needed.
  • Use firewall rules to block mDNS multicast on untrusted interfaces where you cannot fully control Avahi configuration.

Decision Trigger:
Choose Avahi + nss-mdns if you need Bonjour/Zeroconf-style LAN discovery (printers, file shares, peer applications) and want a narrow, LAN-only attack surface with well‑defined hardening points (D‑Bus policies, interface allow/deny lists, and root-owned /etc/avahi/services for publication control).

---

2. systemd-resolved alone (Best for general DNS resolution with resolver-level security features)

systemd‑resolved is a stub resolver and caching DNS service, not a DNS‑SD service discovery stack. Its strength lies in upstream DNS security features (DNSSEC, DNS‑over‑TLS/HTTPS), split DNS, and host‑local stub interfaces.

What it does well

• Upstream DNS security and isolation

  • Supports DNSSEC validation (depending on distro defaults and configuration).
  • Supports encryption to upstream resolvers (DoT, DoH in newer systemd releases).
  • Runs as a local caching stub; applications talk to 127.0.0.53 by default, not directly to the network:
    • This centralizes your DNS policy at one process, simplifying auditing and logging.

  Hardening implications:

  • You can enforce a single set of upstream resolvers and DNSSEC policy for the host, reducing risk of per‑application misconfiguration.
  • You can restrict outbound DNS at the firewall to allow only systemd‑resolved to reach upstream servers, and block direct port 53/853/443 DNS from other processes.
  • Logging from resolved gives you a single place to inspect DNS queries for anomaly detection.

• Limited service exposure by default

  • systemd‑resolved listens primarily on:
    • Localhost stub (127.0.0.53).
    • Optionally on link-local addresses for LLMNR/mDNS depending on configuration and systemd version.
  • It is not intended to be a general WAN‑exposed DNS server for other hosts; most distros do not enable a “full recursive DNS server” mode by default.

  Hardening implications:

  • Ensure DNSStubListener and MulticastDNS are set explicitly in resolved.conf to avoid accidental exposures or unintended mDNS behavior.
  • Confirm the unit’s IPAddressDeny= / IPAddressAllow= options (if used) and firewall rules so that resolved is not reachable from other hosts as a recursive resolver.

• Simple integration for non-Zeroconf environments

  • For servers that never participate in Zeroconf or Bonjour, systemd‑resolved can handle all DNS needs.
  • This reduces the number of moving pieces: no multicast traffic, no service publishing, no nss‑mdns.

  Hardening implications:

  • On headless, Internet-facing systems that do not need LAN discovery, disabling Avahi and running resolved alone is often the simplest, safest configuration.
  • You still need to harden upstream DNS choices (e.g., corporate resolvers, DNS over TLS) and consider DNS privacy, but you avoid the service discovery metadata surface entirely.

Tradeoffs & Limitations

• Weak fit for Bonjour/Zeroconf workflows

  • systemd‑resolved is not a drop-in replacement for Avahi for mDNS/DNS‑SD service discovery.
  • Even where it supports mDNS, it does not provide the same D‑Bus interfaces, /etc/avahi/services semantics, or rich DNS‑SD browsing that Avahi offers.

  Security implications:

  • If you attempt to “make resolved do service discovery,” you may end up with:
    • Ad hoc scripts or extra components that are harder to audit and secure.
    • Inconsistent behavior vs Bonjour devices, creating a false sense of coverage while some services remain invisible or mis-announced.

Decision Trigger:
Choose systemd-resolved alone if you primarily care about secure, auditable DNS resolution (DNSSEC, DoT/DoH) and do not require LAN service publishing or Bonjour/Zeroconf interoperability. This is typical for locked-down servers and many container hosts.

---

3. Avahi disabled, resolved only (Best for non-advertising, locked-down servers)

The third “option” is a deployment pattern: deliberately disabling Avahi while keeping systemd‑resolved as the resolver. This is useful where not advertising is a requirement.

What it does well

• Minimal discovery footprint

  • With avahi-daemon stopped/masked, the host:
    • Does not emit mDNS/DNS‑SD announcements for its services.
    • Does not respond to Bonjour-style queries from peers.
  • If you also remove or de‑prioritize mdns from nsswitch.conf, you avoid *.local behavior altogether.

  Hardening implications:

  • This is the most conservative stance: no mDNS traffic, no service metadata on the wire, and no D‑Bus interface for publishing services.
  • It pairs well with strict firewalling and “servers must be reached via known hostnames from corporate DNS only.”

• Straightforward policy story

  • All name resolution flows through systemd‑resolved (or your chosen resolver stack).
  • Network policies, monitoring, and logging can focus on standard DNS, without needing to interpret or filter multicast traffic.

Tradeoffs & Limitations

• No peer discovery convenience

  • Users lose the ability to “just find printers and file shares” on a LAN without central DNS:
    • Any shared resources must be configured manually (IP/hostname), or central DNS must be kept up to date.
  • For developer fleets, this can make ad-hoc services and peer-to-peer workflows more painful.

  Security implications:

  • Some teams will circumvent the policy with local hacks (hard-coded IPs, ad-hoc scripts), which can undermine the neat security boundary you intended.
  • For internal, trusted segments, not providing Avahi can be a usability regression with no strong threat model justification.

Decision Trigger:
Choose Avahi disabled, resolved only when your threat model says “no service discovery on this host,” such as hardened bastion hosts, external-facing load balancers, or servers in regulated zones where any untracked advertisement is unacceptable.

---

Cross-Cutting Security Considerations

Regardless of where you land in the Avahi vs systemd‑resolved space, there are a few shared themes worth calling out.

1. Exposure: what crosses the network, and where?

• Avahi

  • Multicast on local segments only.
  • Broadcasts service records and responds to mDNS inquiries.
  • Harden by:
    • Restricting interfaces (allow/deny).
    • Disabling publishing or minimizing advertised services.
    • Using network firewalls to block mDNS where needed.

• systemd-resolved

  • Unicast to configured upstream DNS (potentially encrypted).
  • Optional multicast/LLMNR depending on configuration and version.
  • Harden by:
    • Pinning resolvers and enforcing DNSSEC.
    • Restricting outbound DNS ports to resolved only.
    • Ensuring it is not accidentally acting as a recursive server for other hosts.

2. Interfaces: how can local processes influence behavior?

• Avahi

  • D‑Bus is the main integration surface for browsing/publishing.
  • /etc/avahi/services for static publication, root-owned.
  • nss‑mdns integrates via nsswitch.conf for *.local.

  Hardening checklist:

  • Audit D‑Bus policies: which users can call Avahi’s interfaces?
  • Ensure /etc/avahi/services is only writable by root and managed tools.
  • Treat nsswitch.conf as a security-relevant configuration; avoid surprising mdns precedence over files/dns unless intentional.

• systemd-resolved

  • Applications typically talk via libc’s resolver using nsswitch.conf.
  • DBus control/status interface (e.g., resolvectl), depending on policy.
  • Per-link configuration via systemd‑networkd or NetworkManager.

  Hardening checklist:

  • Ensure only privileged tools can modify upstream DNS settings (no untrusted resolvectl).
  • Avoid giving containers direct access to resolved’s D‑Bus interface unless heavily sandboxed.
  • Lock down who can change network configuration units that affect DNS.

3. Publishing: what do you reveal about the host?

• Avahi

  • Explicit publisher of services (SRV/TXT records) and hostnames via mDNS.
  • Every published service is a small “host profile” for anyone on that link.

  Publishing hardening:

  • Publish only necessary services; prefer “opt‑in” rather than “advertise everything by default.”
  • Use generic instance names when possible (“Office Printer,” not “alice‑laptop._ipp._tcp”).
  • Regularly review /etc/avahi/services in configuration management for unexpected additions.

• systemd-resolved

  • Does not publish service records by itself; it’s a resolver.
  • Hostname exposure is via other layers (e.g., DHCP, central DNS), not resolved.

  Publishing hardening:

  • Focus on DHCP and central DNS policies: what hostnames get registered, and who can query them.
  • Use PTR/forward zone ACLs to limit who can enumerate infrastructure.

---

Final Verdict

From a security perspective, Avahi and systemd‑resolved occupy different layers:

• Avahi is your mDNS/DNS‑SD stack for local LAN discovery. Its security surface is the multicast link, its D‑Bus API, and the set of services you choose to publish via /etc/avahi/services or programmatically. Hardening is about constraining interfaces, controlling D‑Bus access, minimizing published metadata, and disabling the daemon where discovery is not desired.

• systemd‑resolved is your upstream-oriented resolver and stub DNS server. Its security surface is the upstream DNS path and the local APIs that let applications influence DNS behavior. Hardening is about DNSSEC, encrypted transport, resolver pinning, and making sure the host is not an unintended recursive DNS service for others.

A sane pattern in many fleets is:

• Desktops and developer laptops on trusted LANs:
  Avahi + nss‑mdns enabled for Zeroconf convenience; systemd‑resolved used for upstream DNS with DNSSEC where possible. Avahi restricted on untrusted Wi‑Fi and configured to publish only necessary services.

• Headless servers and exposed infrastructure:
  Avahi disabled or masked; systemd‑resolved (or an alternative) used as the single DNS resolver, with strong upstream policies and outbound DNS firewalling.

If you treat Avahi as the LAN discovery layer and systemd‑resolved as the upstream resolver, you can harden each on its own terms instead of trying to make one solve the other’s problem.

---

Next Step

Get Started