DNS

Overview

For a Linux host to resolve names like example.com, it must know which DNS resolvers to use and how to look names up. This lesson covers DNS configuration and resolution on Linux — the practical, host-level side of the DNS concepts from the networking path.

Learning objectives

• Identify where Linux gets its DNS resolver configuration.
• Use command-line tools to resolve names.
• Distinguish name resolution from network-path problems.

Core concept

Linux name resolution depends on configuration and tools:

• Resolver configuration — traditionally /etc/resolv.conf lists the nameservers to query (on many modern systems this is managed by systemd-resolved or NetworkManager rather than edited by hand).
• /etc/hosts — a static file mapping names to IPs, checked before DNS for listed entries.
• Lookup tools — dig and nslookup (query DNS directly), and getent hosts <name> (resolve the way applications do, honoring /etc/hosts and DNS).

How it works

When a program resolves a name, the system follows its configured order — often checking /etc/hosts first, then querying the nameservers from the resolver configuration. dig example.com queries DNS directly and shows the answer and which server responded, making it ideal for troubleshooting. getent hosts example.com reflects what an application would actually get (including /etc/hosts overrides). Separating "does the name resolve?" from "is the network path up?" is a key diagnostic step (as in the networking troubleshooting lesson).

Practical example

$ dig +short example.com
93.184.216.34
$ getent hosts example.com
93.184.216.34  example.com
$ cat /etc/resolv.conf
nameserver 192.168.1.1

dig +short returns just the resolved address, getent shows the resolution as apps see it, and /etc/resolv.conf reveals the configured nameserver (here the local gateway). If dig by name failed but pinging an IP worked, the problem would be DNS, not the network path.

Cybersecurity relevance

Host DNS configuration is security-relevant. A malicious entry in /etc/hosts can silently redirect a name to an attacker's IP (a local hijack technique), so investigators check it for tampering. A changed nameserver in the resolver config can point a host at a malicious DNS server. During assessment or response, verifying DNS configuration and using dig/getent to see what names actually resolve to helps detect redirection and diagnose issues. This mirrors the DNS-spoofing risks from the networking path, applied at the host level.

Common mistakes

• Editing /etc/resolv.conf by hand on systems where it is managed (changes get overwritten).
• Forgetting /etc/hosts is checked first for listed names — a stale or malicious entry overrides DNS.
• Confusing DNS failure with network failure — test by IP vs by name to tell them apart.

Key takeaways

• Linux resolver settings come from /etc/resolv.conf (often managed by systemd-resolved/NetworkManager), and /etc/hosts provides static overrides checked first.
• Resolve names with dig/nslookup (direct DNS queries) and getent hosts (as applications resolve); separate name resolution from network-path problems.
• /etc/hosts tampering and altered nameservers are host-level DNS-redirection risks to check during investigation.

Check your understanding

• Which file provides static name-to-IP mappings that are checked before DNS, and why is it a tampering target?
• How would you use command-line tools to determine whether a connectivity problem is DNS-related rather than a network-path issue?