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 actually does
systemd-resolved is a Linux name-resolution service, not just a replacement for /etc/resolv.conf. It sits between applications and upstream resolvers, deciding which DNS server to query and when to apply per-link rules such as split DNS.
That control plane matters because modern Linux hosts often have overlapping resolution sources: local system domains, corporate VPN domains, public DNS, and container or virtual-network overlays. systemd-resolved gives the host a more explicit policy layer for choosing the right path.
How split DNS changes resolution behavior
Split DNS means different domains can be sent to different resolvers. For example, internal corporate names can go to a VPN-provided DNS server while public names continue to use a public resolver. That prevents all traffic from being forced through one resolver and avoids exposing internal names to external DNS infrastructure.
Per-interface resolution is the key mechanism here. A host can learn DNS servers from multiple links at the same time, then resolve queries using the interface or routing rules that best match the destination domain. This is especially useful on laptops, jump hosts, and developer workstations that move between networks.
Why systemd-resolved is different from a plain resolv.conf
A traditional resolv.conf file is usually a single list of name servers with limited policy. That is simple, but it cannot model nuanced cases well when a host needs both internal and external resolution at once. systemd-resolved makes DNS selection stateful and interface-aware rather than purely static.
The trade-off is that resolution behavior becomes more dependent on daemon state, link discovery, and correct network configuration. If the upstream policy is wrong, the resolver may send a query to the wrong server, return incomplete answers, or make internal service discovery appear broken even though the network is otherwise reachable.
Security implications of structured DNS control
DNS is part of the trust path for almost every application, so resolver behavior has security consequences even when the service itself is not a security tool. A structured resolver can help reduce accidental name leakage, preserve internal zone separation, and support more predictable handling of trusted and untrusted networks. It also creates a clearer place to inspect DNS policy when troubleshooting access to internal services.
For hosts that depend on VPNs or enterprise overlays, the resolver layer becomes part of the effective access boundary. If split DNS is not working as intended, users may see name-resolution failures, internal domains may resolve incorrectly, or a host may fall back to the wrong path and expose operational details that were meant to stay internal.
Risk and Threat Considerations
Misconfiguration is the main risk: if per-interface rules, search domains, or fallback resolvers are wrong, the host may leak internal queries, resolve sensitive names through the wrong path, or fail over in ways that break access to private services. DNS also remains a common trust boundary, so incorrect resolver selection can create both confidentiality and availability issues.
Failure mechanism: A host trusts the resolver policy to choose the correct upstream server, but bad link state, stale network metadata, or an overly broad fallback path can route queries incorrectly. That can produce query leakage, wrong-answer resolution, or hard-to-diagnose service outages.
Impact: Internal service names may become visible to an unintended resolver, private applications may fail to connect, and troubleshooting becomes harder because the failure sits in name resolution rather than in the application itself.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Split DNS and per-link resolver policy define DNS trust boundaries across networks. |
| CM-2 — Baseline Configuration | Resolver behavior depends on consistent host configuration and managed DNS policy. | |
| CM-6 — Configuration Settings | systemd-resolved is governed by explicit DNS configuration choices and fallback behavior. | |
| Recommendation — Apply SC-7 to keep internal and external DNS paths separated by network boundary. Baseline resolver settings so DNS policy stays consistent across hosts and links. Define approved resolver settings and review them whenever network topology changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | The resolver must be administered through controlled network and system access paths. |
| PR.DS-01 — Data-at-rest is protected | DNS policy can affect exposure of internal names and resolution data. | |
| PR.SC-01 — Supply Chain Risk Management Process | Resolver behavior depends on trusted OS and network components delivered through the platform. | |
| Recommendation — Restrict who can alter resolver policy and network-advertised DNS settings. Protect stored DNS configuration and logs that reveal internal naming patterns. Trust only managed platform components when deploying resolver policy and dependencies. | ||
Practitioner Guidance
Why practitioners should care: systemd-resolved is most valuable when a host must survive mixed-network reality, but that same flexibility means DNS policy should be treated as part of network design rather than as a default daemon setting. Check that the resolver behavior matches the intended trust boundaries for VPN, corporate, and public domains.
Common misunderstanding: Replacing /etc/resolv.conf does not automatically mean DNS is “simpler” or “more secure.” It usually means the host now depends on explicit policy, so correctness depends on how the links and domains are advertised and consumed.
