resolvconf is a loose convention for assembling DNS settings from multiple inputs. NetworkManager is a fuller network manager with a D-Bus API and optional dnsmasq mode for split DNS. systemd-resolved is a resolver service with per-interface control and richer routing behavior. The key distinction is how much policy each one can express and override.
How the three DNS components differ in responsibility
The practical difference is scope. IANA is not one of these resolvers, but it is the authoritative registry backdrop for DNS names, ports, and related protocol parameters. In the local stack, resolvconf is a coordination layer, NetworkManager is a broader network control plane, and systemd-resolved is an actual resolver service.
resolvconf’s job is usually to collect DNS settings from multiple producers and write them into a form that other software can consume. It is intentionally lightweight and convention-driven, so it does not try to own the whole network state. That makes it useful on systems where different interfaces, VPN clients, or DHCP hooks need to contribute DNS data without a single full network manager taking over.
NetworkManager sits at a higher level. It manages interfaces, connection profiles, routing decisions, and DNS policy together, and it can publish DNS settings through a D-Bus API or hand them to helper services. Its dnsmasq mode can also support split DNS behavior, so it is often chosen when DNS is only one part of a larger network automation problem.
How policy and override behavior change the result
systemd-resolved is the most resolver-specific of the three. It is designed to answer queries itself, keep per-interface DNS state, and apply richer routing logic when different links should resolve different domains. In practice, that means it can express more policy than resolvconf and usually more resolver behavior than NetworkManager alone.
The key distinction is how much each tool can override and how much it assumes about the rest of the stack. resolvconf mostly assembles inputs, so its authority is limited by whoever writes to it. NetworkManager can own the network relationship end to end, so it can decide which server, search domain, or link should win. systemd-resolved can then enforce resolver behavior at query time, which matters when link-specific DNS, VPN DNS, or fallback servers need predictable routing.
That is why these tools are often alternatives in the same deployment, but not always direct substitutes in capability. A system can use NetworkManager without systemd-resolved, use resolvconf as glue for other clients, or use systemd-resolved as the actual local stub resolver while another component feeds it configuration. The difference is less about “DNS lookup” in the abstract and more about where policy lives.
What practitioners should compare before choosing one
If you need only to merge DNS inputs from several sources, resolvconf-style behavior is enough. If you need connection management, interface lifecycles, VPN awareness, and centralized network policy, NetworkManager is the broader fit. If your main requirement is fine-grained resolver behavior, per-link DNS, or explicit routing of queries to different servers, systemd-resolved is the strongest resolver-centric option.
The common mistake is to compare them as if they were the same kind of component. They solve different layers of the stack, so the right choice depends on whether you are managing DNS as a byproduct of network management or as a dedicated resolution service. On many Linux systems, the real question is which component is authoritative for DNS state, and which ones are only feeding or consuming it.
What to verify: Check which process actually owns /etc/resolv.conf, which service is sending DNS settings to the system, and whether VPN or split-DNS requirements depend on per-interface routing. If the wrong layer is authoritative, changes may appear to work but be overwritten later.
What good looks like: One component owns network policy, one component owns resolver behavior, and the handoff between them is explicit. That reduces conflicting updates, makes troubleshooting easier, and prevents “it works on one interface but not another” failures.
Practitioner takeaway: Choose by control plane, not by label: resolvconf is an aggregator, NetworkManager is a network manager with DNS policy, and systemd-resolved is a resolver with stronger query-routing behavior.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | DNS resolution affects transport trust and server selection. |
| Recommendation — Verify resolver and transport choices preserve trusted name resolution. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Split DNS and per-interface routing depend on controlled trust boundaries. |
| CM-2 — Baseline Configuration | The question turns on which component owns local DNS configuration. | |
| Recommendation — Define which links may receive which DNS paths and enforce them. Document the authoritative DNS component and keep its configuration consistent. | ||
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
