Linux DNS Resolution Security: resolv.conf, systemd-resolved, and Name Resolution Risks

1. Introduction

DNS affects almost every networked Linux workload. Applications use it to locate APIs, package repositories, identity systems, databases, and remote management endpoints. A resolver misconfiguration can cause outages, leak queries, or redirect traffic toward an attacker-controlled destination. This article focuses on defensive administration, auditing, and authorized lab work. The objective is to understand the control, identify misconfiguration before it becomes an incident, and build a repeatable hardening process that can be applied across real Linux environments.

2. How It Works

Linux systems may use a static /etc/resolv.conf, NetworkManager, systemd-resolved, DHCP-provided DNS servers, or local caching resolvers. The Name Service Switch configuration in /etc/nsswitch.conf controls the order in which hosts are resolved through files, DNS, mDNS, and other mechanisms. Linux security is layered, so this control should be considered together with identity, filesystem permissions, service configuration, kernel policy, network segmentation, and centralized monitoring. A single command rarely tells the whole story; the effective security posture comes from how these layers interact.

3. The Security Problem

Security issues include trusting unapproved DHCP-provided resolvers, using split DNS incorrectly, leaking internal names to public resolvers, permitting insecure local name-resolution methods, and failing to validate that critical names resolve to expected networks. /etc/hosts can also override DNS and is valuable to attackers with root. These weaknesses are often created gradually by troubleshooting, legacy migrations, vendor installation scripts, or temporary exceptions that later become permanent. A good security review therefore looks not only for obviously dangerous settings, but also for configuration that no longer has a clear owner or business justification.

4. How Attackers Abuse It

After compromise, an attacker may alter resolver settings, /etc/hosts, or local DNS infrastructure to redirect updates or internal services. In local networks, weaker name-resolution protocols may also expose credentials or create spoofing opportunities depending on the environment. In an authorized assessment, the goal is to demonstrate exposure safely and report the exact condition that creates the risk. In production incident response, avoid making destructive changes before collecting enough context to understand whether the issue is a simple misconfiguration, active abuse, or a persistence mechanism.

5. How to Detect / Enumerate & Audit It

Command

resolvectl status 2>/dev/null || cat /etc/resolv.conf

What it does: Show active DNS servers and per-link resolver settings.

What to look for: Unexpected resolvers, search domains, or fallback DNS.

Defensive use: Understand the real resolver path.

Command

cat /etc/nsswitch.conf | grep '^hosts:'

What it does: Show host-resolution order.

What to look for: Unexpected mdns or other methods before DNS/files.

Defensive use: Review resolution precedence.

Command

getent hosts example.com

What it does: Resolve a hostname through the system NSS path.

What to look for: Unexpected addresses compared with expected DNS.

Defensive use: Test what applications will actually receive.

Command

stat /etc/hosts /etc/resolv.conf

What it does: Show ownership and metadata for local resolver files.

What to look for: Unexpected modifications or symlink targets.

Defensive use: Support integrity review.

A useful operational habit is to save the output of these checks in a baseline for each server role. A database server, bastion host, developer workstation, and container node will not look identical, so comparison should be against a known-good peer or documented configuration rather than against a generic assumption.

6. How to Audit the Environment

• Inventory approved DNS resolvers and search domains.
• Verify resolver settings on servers are not unexpectedly controlled by untrusted network sources.
• Review /etc/hosts for unauthorized overrides.
• Understand whether systemd-resolved, NetworkManager, or another service owns configuration.
• Disable unneeded local name-resolution mechanisms according to the environment’s design.
• Document every exception with an owner, reason, and review date.
• Re-check the control after upgrades because packages and deployment automation can silently change defaults.

7. How to Fix / Harden It

• Use trusted recursive resolvers and encrypted or authenticated DNS transports when supported by the architecture.
• Protect resolver configuration with configuration management.
• Avoid leaking internal search domains to public resolvers.
• Keep critical infrastructure records under controlled DNS zones.
• Monitor /etc/hosts and resolver configuration for change.
• Apply changes through configuration management when possible so the desired state is reproducible.
• Test hardening first on a staging host or a disposable snapshot and verify that critical services still function.

8. Detection & Monitoring

• Alert on resolver changes, especially on servers.
• Track DNS queries to known malicious domains and unusual new resolvers.
• Investigate sudden changes in destination IPs for critical services.
• Keep time synchronization reliable so host events can be correlated with firewall, identity, EDR, and SIEM data.
• Send high-value security logs off-host because a fully compromised root account can often alter local evidence.

9. MITRE ATT&CK Mapping

MITRE ATT&CK is most useful here as a common language for detection engineering and incident reporting. The mapping does not mean every misconfiguration is an active attack; it shows which attacker behaviors may become easier when the control is weak.

10. Practical Lab

In an isolated Linux lab or disposable VM:

1. Compare getent, dig, and resolvectl behavior in a VM.
2. Add a harmless /etc/hosts override and observe precedence.
3. Remove it and test again.
4. Change the lab DNS server and monitor resolver status.
5. Document which component owns /etc/resolv.conf.
6. Capture screenshots or command output before and after the change so you can prove what the control actually changed.
7. Revert the VM or remove the test configuration when finished.

11. Key Takeaways

• Linux DNS Resolution Security should be treated as part of a layered security model, not as an isolated setting.
• Inventory the current state first, because unknown configuration is difficult to secure.
• Prefer least privilege, explicit ownership, and documented exceptions.
• Monitor changes to the control itself; attackers often try to weaken defenses after gaining access.
• Test fixes in a lab and verify the effective runtime state, not only the configuration file.

Continue learning: Linux Security

This guide is part of our Linux Security series. Related guides in this series cover permissions, sudo, SUID/SGID, Linux capabilities, SSH, PAM, systemd, logging, firewalls, DNS, process security, filesystems, encryption, auditd, kernel hardening, containers, mandatory access control, package security, incident response, and backup protection.