How-to guides · clear steps · safer fixes
troubleshooting

Ubuntu Noble systemd-resolved: Stub Listener Behaviors, Failure Conditions, and Routing Rules

Short answer

Review documented systemd-resolved stub listener behavior, port conflict deactivation, and query routing rules in Ubuntu Noble.

Research-based

Last verified:

Applies to: Ubuntu Noble systemd-resolved documentation and resolved.conf settings

Comparison of systemd-resolved 127.0.0.53 full resolver and 127.0.0.54 proxy listener

Scope and Operating Context

Under the primary documentation for Ubuntu Noble (systemd-resolved.service(8) and resolved.conf(5)), systemd-resolved is a system service providing network name resolution to local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder.

How Applications Connect to systemd-resolved

According to systemd-resolved.service(8), applications obtain name resolution via two primary facilities:

  • glibc NSS API: The glibc Name Service Switch (nss(5)) integrates with the module nss-resolve(8). Using nss-resolve(8) allows glibc NSS resolver functions to resolve hostnames through systemd-resolved. In this setup, entries in /etc/hosts maintain highest priority.
  • DNS Stub Listeners: Programs issuing DNS requests directly over unicast DNS can connect to local stub listeners on loopback port 53:
    • 127.0.0.53: Provides the full feature set of the local resolver, including caching, DNSSEC validation, and LLMNR/MulticastDNS resolution.
    • 127.0.0.54: Operates in “proxy” mode only. It passes DNS messages relatively unmodified to upstream DNS servers without local DNSSEC validation or LLMNR/MulticastDNS processing (translating to DNS-over-TLS if needed).

Documented Causes of Query Failures in systemd-resolved

The supplied man page excerpts document specific operational conditions where resolution queries fail or stub listeners are deactivated:

  • Missing Suitable DNS Servers: A unicast DNS query fails when no suitable DNS servers can be determined from global settings in /etc/systemd/resolved.conf, per-link static settings, DHCP dynamic settings, or resolvectl(1), provided no synthetic records or /etc/hosts mappings satisfy the query.
  • Disabled or Inactive Stub Listener:
    • Setting DNSStubListener=no in configuration explicitly disables the stub listener on 127.0.0.53 and 127.0.0.54.
    • As documented in resolved.conf(5), the DNS stub listener is turned off implicitly when its listening address and port are already in use by another process. The supplied excerpts do not document a specific command to identify conflicting processes.
  • DNSSEC Revocation Failures: When DNSSEC=true is configured and the built-in trust anchor is revoked without updated trust anchors configured locally or via package updates, the resolver cannot prove whether lookups are correctly signed or validly unsigned, causing subsequent lookups to fail.

Documented Routing Behavior Inspected by resolvectl

The supplied excerpts reference resolvectl(1) for inspecting routing status and setting link options such as DefaultRoute=. Documented query routing rules include:

  • Route-Only Domains (~): Domains prefixed with ~ direct DNS queries preferably to a specific interface when suitable per-link DNS servers are known. If no per-link DNS servers are known, route-only domains have no effect.
  • The Root Route-Only Domain (~.): Configuring ~. directs all queries not explicitly matched by other routing domains preferably to that link’s DNS servers.
  • Default Route Flag: Setting DefaultRoute=true on a link without a ~. domain routes unmatched queries to that link only if no other link is preferred. Setting DefaultRoute=false ensures a link never receives DNS traffic outside its configured routing domains.

Configuration Files and Precedence

According to resolved.conf(5), configuration files are evaluated in the following locations:

  • /etc/systemd/resolved.conf (main configuration file; has lower precedence than drop-in files)
  • /etc/systemd/resolved.conf.d/*.conf (administrator drop-ins)
  • /run/systemd/resolved.conf.d/*.conf (runtime drop-ins)
  • /usr/lib/systemd/resolved.conf.d/*.conf (vendor package drop-ins)

Administrator drop-in files in /etc/ override vendor package files in /usr/lib/. A vendor-supplied configuration file can be disabled by placing a symlink to /dev/null with the same filename inside /etc/systemd/resolved.conf.d/.

Options documented in the supplied text include:

  • DNSStubListener=: Accepts yes (default, listens on UDP and TCP), no, udp, or tcp for addresses 127.0.0.53 and 127.0.0.54, port 53.
  • ReadEtcHosts=: Boolean (default yes); reads /etc/hosts to resolve addresses before sending queries to DNS servers.
  • ResolveUnicastSingleLabel=: Boolean (default false); when enabled, forwards single-label names to global DNS over classic DNS.
  • StaleRetentionSec=: Duration (default 0); determines how long expired cache records are retained to answer queries when upstream DNS servers fail or become unreachable (does not apply to NXDOMAIN responses).
Comparison of route-only domain and DefaultRoute routing behavior

Text version of the diagrams

  • Two Local Stub Listener Modes: 127.0.0.53 — Full resolver features; 127.0.0.54 — Proxy mode only; Processing boundary — Validation and multicast differ
  • How DNS Routing Preferences Differ: ~. — Prefer one link broadly; DefaultRoute=true — Use if none preferred; DefaultRoute=false — Restrict to matched domains

Research Method and Limitations

This article was prepared solely from the supplied primary documentation excerpts for Ubuntu Noble: systemd-resolved.service(8) and resolved.conf(5). No competing web coverage or external sources were available for analysis. Material limits include truncated man page passages (which omitted full options such as Cache=), the absence of documented procedures for identifying processes conflicting on port 53, and the absence of client-side error string definitions (such as client library generation of “Temporary failure in name resolution”) or checks for service unit status and /etc/resolv.conf symlink configuration.

Related guides