DNS Resolution on Linux: dig, nslookup, resolv.conf

When you type curl example.com, your machine has to figure out which IP address that name maps to. That’s DNS resolution. When it works, it’s invisible. When it breaks, you get “name or service not known” and your day grinds to a halt. Here are the tools to figure out exactly where DNS is failing.

The fastest test: dig

dig is the standard DNS query tool. Concise output, lots of options.

dig example.com                # full output
dig +short example.com         # just the IP
dig example.com MX             # mail records
dig example.com NS             # name servers
dig example.com TXT            # text records (SPF, etc.)
dig example.com A              # explicit A (IPv4) record
dig example.com AAAA           # IPv6
dig example.com ANY            # all record types

# Use a specific resolver instead of system default
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# Reverse lookup (IP to name)
dig -x 8.8.8.8

Read dig output

Key parts of dig’s response:

• QUESTION SECTION: what you asked.
• ANSWER SECTION: the answer (IP, etc.).
• AUTHORITY SECTION: which server owns this zone.
• Query time: how long the resolver took.
• SERVER: which DNS server gave the answer.

nslookup (older, still works)

nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=MX example.com

nslookup is fine for casual use. dig is better for debugging.

host (one-line answer)

host example.com
host example.com 1.1.1.1
host -t MX example.com

Where Linux looks for DNS settings

/etc/resolv.conf

The classic file — lists DNS servers your machine uses:

cat /etc/resolv.conf
# nameserver 1.1.1.1
# nameserver 8.8.8.8
# search example.com

On modern systems with NetworkManager or systemd-resolved, this file is usually auto-managed. Editing it directly may be overwritten.

/etc/hosts

Static name-to-IP mapping. Checked BEFORE DNS:

cat /etc/hosts
# 127.0.0.1 localhost
# 192.168.1.50 myserver.local

Use this to override DNS for testing or to add local names.

/etc/nsswitch.conf

Controls the lookup order:

grep ^hosts /etc/nsswitch.conf
# hosts: files dns
# → check /etc/hosts FIRST, then DNS

systemd-resolved

Modern Linux often uses systemd-resolved as a local stub resolver. It listens on 127.0.0.53.

resolvectl status               # show all configured DNS servers
resolvectl query example.com    # resolve via systemd-resolved
resolvectl flush-caches         # clear DNS cache
sudo systemctl restart systemd-resolved

Common DNS problems and fixes

“Name or service not known”

Tests in order:

# 1. Can you reach a DNS server?
ping -c2 1.1.1.1

# 2. Does direct query work?
dig @1.1.1.1 example.com

# 3. What's in resolv.conf?
cat /etc/resolv.conf

# 4. Is systemd-resolved running?
resolvectl status

Lookups are slow

• Try a different resolver: dig @1.1.1.1 example.com. If fast, your default resolver is the problem.
• Check IPv6 — sometimes lookups wait for AAAA timeouts. Try dig +noaaaa or set options single-request in resolv.conf.

Wrong IP returned

• Check /etc/hosts — it’s higher priority than DNS.
• Check the cache: resolvectl flush-caches.
• Compare results from multiple resolvers (dig @1.1.1.1, dig @8.8.8.8) — DNS propagation might be in flight.

Useful one-liners

# What's MY public IP?
dig +short myip.opendns.com @resolver1.opendns.com
curl -s ifconfig.me

# Get all A records as plain IPs
dig +short example.com A

# Trace DNS resolution path
dig +trace example.com

# Check propagation across multiple servers
for ns in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo -n "$ns: "
  dig @$ns +short example.com
done

# Reverse DNS for a list of IPs
for ip in 1.1.1.1 8.8.8.8; do
  echo -n "$ip: "
  dig -x $ip +short
done

Common mistakes

• Editing /etc/resolv.conf on a system where it’s auto-managed — gets overwritten.
• Forgetting that /etc/hosts is checked first.
• Confusing slow DNS with slow website — test resolution speed separately.

What to learn next

Once names resolve, the next layer is connecting securely — SSH, the protocol you’ll use to log in to every Linux server. Up next.