DNS and Resolution

How a Linux machine turns a hostname like example.com into an IP address before it can connect to anything - the resolution chain, and the tools for testing it directly.

Networking Updated August 28, 2026

  • networking
  • dns

Once basic IP connectivity works, resolution is usually the next thing to check - a huge share of "the internet is down" reports turn out to be a DNS problem, not a routing one.

The resolution chain

When a program asks to connect to a hostname, the C library consults /etc/nsswitch.conf to decide, in order, where to look for an answer - typically local files first, then DNS:

hosts: files dns

  • files - checks /etc/hosts first, a plain-text list of manual hostname-to-IP overrides:

    127.0.0.1   localhost
192.168.1.50   dev-server

    Useful for local overrides during development without touching real DNS records.

  • dns - if not found in /etc/hosts, queries a DNS resolver.

Where the resolver's address comes from

Traditionally, /etc/resolv.conf lists the DNS servers to query directly:

nameserver 192.168.1.1
nameserver 8.8.8.8

On many current distributions, /etc/resolv.conf is instead managed by systemd-resolved, a local stub resolver that handles caching and per-interface DNS configuration, with /etc/resolv.conf typically a symlink into /run/systemd/resolve/. Check whether it's active, and query it directly, with:

resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 2 (enp3s0)
    Current Scopes: DNS
DefaultRoute setting: yes
     Current DNS Server: 192.168.1.1
            DNS Servers: 192.168.1.1

Testing resolution directly

dig example.com

;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34

dig is the most detailed and the standard tool for real diagnosis; host gives a terser one-line answer for quick checks; nslookup is older and considered semi-deprecated in favor of dig, but still widely available and fine for a quick lookup.

host example.com
nslookup example.com

To test whether a specific DNS server is the problem (bypassing whatever your system is configured to use), query it directly:

dig @8.8.8.8 example.com

If that succeeds but a plain dig example.com fails, the problem is your configured resolver, not DNS itself or the domain.

Record types worth knowing

Type Holds
A An IPv4 address
AAAA An IPv6 address
CNAME An alias pointing to another hostname
MX Mail server for a domain
TXT Arbitrary text - commonly used for domain verification and SPF/DKIM
NS Which nameservers are authoritative for a domain

Clearing a stale cache

If a record was recently changed but an old value keeps coming back, check whether a local cache is involved:

sudo resolvectl flush-caches       # systemd-resolved
sudo systemctl restart nscd        # if nscd is installed and running

DNS records also carry a TTL (time to live) telling resolvers how long to cache them - a value that just changed may simply not have expired everywhere yet, independent of any local caching on your machine.