DNS Tools: dig, host, resolvectl, and /etc/hosts

1. The application’s answer may not come directly from DNS

Most applications use resolver library calls such as getaddrinfo(). The Name Service Switch then follows the hosts: policy in /etc/nsswitch.conf. Sources can include local files, systemd-resolved, traditional DNS, mDNS, and directory services. This means dig and an application can legitimately receive different answers: dig queries DNS, while the application follows local name-service policy.

flowchart TD
  A["Application getaddrinfo"] --> B["NSS hosts policy"]
  B --> C["/etc/hosts"]
  B --> D["systemd-resolved or libc stub"]
  D --> E["Cache and per-link routing domains"]
  E --> F["Recursive DNS resolver"]
  F --> G["Root, TLD, authoritative servers"]
  G --> F
  F --> D
  D --> A

2. Inspect local policy before querying external DNS

grep '^hosts:' /etc/nsswitch.conf
getent hosts localhost
getent ahosts example.com 2>/dev/null || true

# Local static mappings
sed -n '1,160p' /etc/hosts

# Resolver-file ownership and content
ls -l /etc/resolv.conf
cat /etc/resolv.conf

# systemd-resolved view, if active
resolvectl status 2>/dev/null || true
resolvectl statistics 2>/dev/null || true

getent is usually the best first test for “what will a normal application resolve?” because it follows NSS. /etc/hosts entries are exact local mappings and do not carry DNS TTLs. Search domains can transform a short name into one or more fully qualified candidates, so use trailing dots in DNS tools when you need an absolute name.

3. dig exposes DNS protocol details

dig reports the question, answer, authority, and additional sections along with flags, response code, server, timing, and message size. It can query a selected server, request a specific record type, disable recursion, follow delegation, or display only the answer.

# Default configured resolver
 dig example.com A
 dig example.com AAAA

# Concise answers and specific records
 dig +short example.com A
 dig +short example.com MX
 dig +short example.com TXT

# Query an explicit recursive resolver
 dig @1.1.1.1 example.com A

# Ask for authoritative name servers
 dig example.com NS

# Follow delegation from the DNS root; may be filtered
 dig +trace example.com 2>/dev/null | sed -n '1,160p'

# Reverse lookup
 dig -x 8.8.8.8

4. host is concise; resolvectl understands resolved policy

host offers compact forward, reverse, and record-type queries. resolvectl communicates with systemd-resolved and can show which link, DNS server, protocol, and route domain supplied an answer. That is especially important on VPNs and multi-homed hosts using split DNS.

host example.com
host -t MX example.com
host 8.8.8.8

# systemd-resolved queries, if available
resolvectl query example.com 2>/dev/null || true
resolvectl query --type=MX example.com 2>/dev/null || true
resolvectl domain 2>/dev/null || true
resolvectl dns 2>/dev/null || true
resolvectl status 2>/dev/null || true

Per-link routing domains can direct selected suffixes to a VPN or private resolver while public names use another link. A single static nameserver list cannot fully describe this behavior. Preserve the manager’s state before replacing or bypassing it.

5. TTLs and caches make time part of diagnosis

A DNS TTL tells caches how long an answer may be reused. Negative answers can also be cached. During migrations, different resolvers may hold answers from different times. Query the local resolver and one or more explicit resolvers, record TTLs, and identify the authoritative answer before declaring inconsistency.

# Compare configured resolver with explicit public resolvers
for server in default 1.1.1.1 8.8.8.8; do
  printf '\n=== %s ===\n' "$server"
  if [ "$server" = default ]; then
    dig example.com A +noall +answer +comments
  else
    dig @"$server" example.com A +noall +answer +comments
  fi
done

# Clear only the local systemd-resolved cache when explicitly intended
# sudo resolvectl flush-caches

6. Hands-on lab: compare application and DNS answers

lab="$HOME/devops-academy/linux/chapter12/lesson03"
mkdir -p "$lab"
cd "$lab"
name=example.com

{
  date --iso-8601=seconds
  printf '\n=== NSS policy ===\n'; grep '^hosts:' /etc/nsswitch.conf || true
  printf '\n=== application-style lookup ===\n'; getent ahosts "$name" || true
  printf '\n=== resolv.conf ===\n'; ls -l /etc/resolv.conf; cat /etc/resolv.conf
} > local-policy.txt

dig "$name" A > dig-a.txt 2>&1 || true
dig "$name" AAAA > dig-aaaa.txt 2>&1 || true
dig "$name" NS > dig-ns.txt 2>&1 || true
host "$name" > host.txt 2>&1 || true
resolvectl query "$name" > resolvectl.txt 2>&1 || true
sha256sum ./*.txt > evidence.sha256

7. Common DNS mistakes

8. Knowledge check

9. Summary

Linux name resolution is a policy pipeline, not just a DNS-server list. Use getent for application-style results, dig for protocol detail, host for concise queries, and resolvectl for systemd-resolved’s per-link policy. Record response codes, record types, TTLs, server identity, and time before changing caches or configuration.

10. Further reading

• resolvectl documentation and systemd-resolved.service(8).
• dig(1), host(1), getent(1), and nsswitch.conf(5).
• DNS RFCs and authoritative provider documentation for record semantics and DNSSEC.