systemd-resolved is a DNS resolver service on Linux that can manage name resolution per interface and support split DNS behavior. It provides a more structured control plane than a plain resolv.conf file, which makes it useful in environments where local, VPN, and public resolution need to coexist.
What systemd-resolved does in Linux name resolution
systemd-resolved sits between applications and upstream DNS servers, giving Linux a resolver service that can route queries by interface, network, and search domain. That matters when a host needs different answers for local, corporate VPN, and public networks at the same time, without relying on one static resolver path.
Compared with a plain resolv.conf file, it introduces a structured control plane for name resolution. The practical result is more consistent handling of split DNS, per-link DNS servers, and changing network conditions on laptops, servers, and virtual machines.
How split DNS and per-interface resolution work
Split DNS means different interfaces can use different DNS servers or routing rules for different domains. For example, a VPN interface can resolve internal hostnames while the default network continues to resolve public names, reducing the need to manually switch resolver settings whenever connectivity changes.
Per-interface resolution is especially useful when multiple network paths are active at once. systemd-resolved can decide which interface should answer a query, which helps avoid leakage of internal queries to public DNS and reduces ambiguity when the same device is connected to more than one network.
The design is useful, but it also means DNS behaviour is no longer purely a file edit. Administrators need to understand how link-scoped configuration, search domains, and fallback resolvers interact, because the effective answer a host receives can depend on the active network state at the moment of the query.
Why systemd-resolved can improve reliability and policy enforcement
On modern Linux systems, name resolution is part of operational control, not just convenience. A resolver service can preserve policy across Wi-Fi changes, VPN reconnects, container hosts, and roaming laptops, where a hand-edited resolver file often becomes stale or is overwritten by network management tools.
It can also make DNS behaviour easier to reason about in mixed environments. When local services, internal enterprise zones, and public internet domains must coexist, a central resolver service can reduce misrouting, duplicate configuration, and accidental dependence on whichever process last wrote resolv.conf.
For security teams, that structure is valuable because DNS is a trust boundary. The resolver path affects what names can be reached, which servers receive queries, and whether internal namespaces remain internal. In practice, that makes resolver selection and interface scoping part of the host’s access-control posture.
Common operational failure modes and what to watch
The main failure mode is configuration drift between the resolver service and the rest of the host. If the system is expected to use systemd-resolved but applications, NetworkManager, VPN software, or containers still point at a different resolver path, queries can bypass the intended policy or fail in inconsistent ways.
Another common issue is incorrect split-DNS routing. If internal zones are not associated with the right interface, or fallback DNS is too permissive, sensitive hostnames may resolve incorrectly or internal lookups may spill to the wrong path. Troubleshooting often starts by checking which DNS servers are bound to each link and whether the effective search domains match the intended network design.
Availability can also be affected when DNS state changes quickly, such as during VPN churn, interface flaps, or DHCP renewal. In those cases, the resolver may be correct in principle but still produce timeouts or stale answers until the link state settles.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-20 — Secure Name/Address Resolution Service (Authoritative Source not used? No, SC-20 is Secure Name/Address Resolution Service) | Covers DNS resolver control and protected name resolution paths. |
| SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver) | Directly addresses recursive resolver behavior and trusted DNS handling. | |
| CM-7 — Least Functionality | Supports limiting resolver paths and only enabling needed network/name services. | |
| Recommendation — Use SC-20 to secure host name resolution and constrain resolver trust paths. Apply SC-21 to control recursive DNS resolution and prevent unsafe resolver exposure. Use CM-7 to remove unnecessary DNS resolution paths and default services. | ||
| NIST CSF 2.0 | PR.PS-01 — Platform Security | Covers secure configuration of endpoint services that mediate DNS resolution. |
| Recommendation — Harden endpoint DNS services under PR.PS-01 to preserve intended resolution behavior. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Matches resolver hardening and consistent endpoint configuration management. |
| CIS-12 — Network Infrastructure Management | Applies to managing DNS and network-linked services across interfaces and VPNs. | |
| Recommendation — Standardize DNS resolver settings under CIS-4 to reduce configuration drift. Manage DNS routing and interface-scoped resolution as part of CIS-12 network control. | ||
Practitioner Guidance
Why practitioners should care: systemd-resolved is not just a local DNS helper, it is the policy point that determines which network gets to answer which name. Treat it as part of endpoint and network configuration management, especially where internal and public resolution must coexist cleanly.
What to watch for: verify that the host’s actual resolver path matches the intended design after VPN connects, disconnects, or renegotiates. The most useful check is whether internal domains resolve only over the expected interface and whether public lookups still behave normally when that interface is absent.
Governance implication: standardise how Linux hosts receive DNS policy so teams do not rely on ad hoc resolv.conf edits. Consistent ownership matters here because name resolution failures often look like application bugs, while the real issue is conflicting resolver control.
Related resources from NHI Mgmt Group
- What is the difference between resolvconf, NetworkManager, and systemd-resolved in DNS management?
- What is the difference between Kubernetes probes and systemd readiness signals?
- What should teams check before switching from systemd to sysvinit in embedded systems?
- What should teams do when pod identity cannot be resolved?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org