systemd-resolved: DNS, Stub Resolver, and resolvectl

systemd-resolved provides local DNS resolution with service-level awareness and per-link DNS routing features. If you understand how it manages /etc/resolv.conf and how to query with resolvectl, DNS troubleshooting gets much easier.

Table of Contents

This post explains resolved architecture, core configuration, and practical diagnostics.

Resolver Model

Configuration and Queries

Series Navigation

What systemd-resolved does

resolved acts as a local DNS resolver and cache, often exposing a stub resolver endpoint such as 127.0.0.53. Applications query local resolver state, and resolved routes requests based on global and per-link policy.

Practical benefits:

  • Unified DNS behavior across systemd-managed links
  • Per-link DNS and domain routing support
  • Local caching and query tooling through resolvectl
  • Better introspection than editing static resolver files blindly

How etcresolvconf is managed

On resolved-managed hosts, /etc/resolv.conf is often a symlink to a file generated by systemd. Hand-editing it usually causes configuration drift and surprises after reboot or service restart.

Check link target:

ls -l /etc/resolv.conf

If resolved owns resolver state, configure DNS through resolved and network manager inputs rather than direct edits.

Enable and inspect resolver state

sudo systemctl enable --now systemd-resolved.service
systemctl status systemd-resolved.service
resolvectl status

resolvectl status is your primary snapshot for active DNS servers, domains, protocols, and per-link routing behavior.

Configure resolved.conf

Core settings live in /etc/systemd/resolved.conf.

[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=8.8.8.8 8.8.4.4
Domains=corp.example.com
DNSSEC=allow-downgrade
MulticastDNS=no
LLMNR=no

After edits:

sudo systemctl restart systemd-resolved

Tune these values to policy and environment expectations rather than copying defaults blindly.

Use resolvectl for queries

resolvectl supports both status inspection and live DNS lookups.

resolvectl query thelinux.pro
resolvectl dns
resolvectl domain
resolvectl statistics

For incident work, combine query output with status to verify where and how a domain is being resolved.

resolved can route DNS based on link and domain rules, which is useful for VPN and hybrid environments.

Examples:

  • Use search domains for user-friendly short-name lookup
  • Use routing domains like ~corp.example.com to send only matching queries to a specific DNS source
  • Keep public internet lookups on default DNS while private zones use VPN-provided servers

This model pairs well with systemd-networkd because .network files can feed DNS and domain data to resolved.

Avoid resolver conflicts

Pick one authoritative DNS management path per host:

  • systemd-resolved with networkd or compatible manager integration
  • NetworkManager with its own DNS management mode
  • Another explicit resolver stack if required by policy

Conflicting managers cause intermittent DNS behavior that is hard to debug.

Troubleshooting workflow

A practical sequence:

  • Confirm resolved is active with systemctl status
  • Inspect current DNS source and routes with resolvectl status
  • Test affected domains with resolvectl query
  • Check logs with journalctl -u systemd-resolved -b

Useful command set:

resolvectl status
resolvectl query registry.internal.example
journalctl -u systemd-resolved -b -n 100

Series navigation

With DNS covered, the next post handles time synchronization through systemd-timesyncd.

Next in this series

Next, we configure reliable time sync and inspect clock state with timedatectl.

systemd-timesyncd: Simple Time Sync with timedatectl