DNS & Name Resolution
DNS translates hostnames into IP addresses through a hierarchical system of resolvers and authoritative servers. Learn every record type, the resolution flow, caching and how to debug resolution with dig.
What is this?
The Domain Name System (RFC 1035) maps human-readable names like example.com to IP addresses. Clients query a recursive resolver, which walks the hierarchy — root servers, top-level domains, then the authoritative server for the domain — and returns records that are cached according to their TTL.
Why do you need it?
- Every curl, kubectl and container DNS lookup depends on correct resolution.
- Misconfigured DNS causes some of the most confusing intermittent outages in production.
- You will configure DNS for TLS certificates, service discovery and load balancing.
- Reading dig output is a core DevOps debugging skill.
Mental model
A phonebook lookup
DNS resolution
You look up a name in the phonebook to find the number. DNS does the same for hostnames, but the phonebook is distributed across millions of servers and copies pages in a cache so lookups are fast.
How it works
- The app asks the OS resolver (getaddrinfo) for example.com; the resolver uses the servers in /etc/resolv.conf.
- A recursive resolver like 8.8.8.8 walks the tree: it asks a root server for .com, then the .com TLD server, then example.com's authoritative servers.
- The authoritative server returns the A (IPv4) or AAAA (IPv6) record plus a TTL that says how long it may be cached.
- Caching happens at every step — OS, resolver, and any local DNS cache — so repeated lookups are fast.
- The client connects to the returned IP; when the TTL expires, the lookup is repeated.
Full resolution flow for example.com.
Key commands
dig example.com AQuery the A (IPv4) record for a name.
dig @8.8.8.8 example.comQuery a specific resolver, bypassing the configured one.
dig +trace example.comShow the full root → TLD → authoritative resolution path.
dig example.com MXShow mail exchange records and their priority.
dig -x 8.8.8.8Reverse lookup: find the PTR record (name) for an IP.
getent hosts example.comResolve through the OS resolver, matching what applications see.
Examples
Query example.com with dig
$ dig +noall +answer example.comexample.com. 3600 IN A 93.184.216.34example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946 $ dig +short example.com93.184.216.34 $ dig example.com NS;; ANSWER SECTION:example.com. 21600 IN NS a.iana-servers.net.example.com. 21600 IN NS b.iana-servers.net.dig +short returns just the answer; full output shows the record type, TTL in seconds, and which name servers are authoritative. If the ANSWER SECTION is empty but you see SOA, the name exists but has no record of that type.
In production
- CNAMEs point service aliases at infrastructure and let you change backends without touching clients.
- Health-aware DNS (like DNS-based load balancing and failover) routes traffic away from dead IPs.
- TLS issuance (Let's Encrypt HTTP-01 and DNS-01 challenges) depends on DNS records you control.
- Kubernetes uses DNS for service discovery: svc names resolve inside the cluster for free.
Best practices
- Set TTLs short (60–300s) on records you may change during incidents, longer for stable records.
- Use CNAME for aliases and A/AAAA for the actual endpoints; never CNAME the zone apex.
- Pin resolver choice in tests: dig @8.8.8.8 isolates your local resolver from the answer.
- Monitor DNS as a dependency: slow or failing resolvers degrade everything.
Common mistakes
- Creating an MX record for a name that should be a CNAME — these cannot coexist.
- Forgetting trailing dots in zone files, making records relative instead of absolute.
- Short TTL everywhere, hammering authoritative servers and breaking client caching.
- Editing DNS and testing immediately from a machine whose resolver still caches the old value.
Common issues
Server DNS address could not be foundNo answer from the configured resolver, or the resolver has no path to upstream.
Check /etc/resolv.conf, ping 8.8.8.8, and test dig @8.8.8.8 to separate connectivity from resolver failure.
NXDOMAIN for a domain that existsTypo, or you queried the wrong zone (stale cache or wrong resolver).
dig @8.8.8.8 with the exact name; verify with dig +trace to find where resolution breaks.
dig returns the old IP after a DNS changeCaching at the resolver, OS, or browser layer before the TTL expired.
Wait out the old TTL, flush the local cache (systemd-resolve --flush-caches) or use dig @8.8.8.8 to bypass.
Debugging tips
- dig +noall +answer to skip the noise and see only records.
- Compare dig against the configured resolver vs @8.8.8.8 to find poison at the resolver.
- Check for a missing SOA in the AUTHORITY section — it means no such domain.
- Use getent hosts to reproduce exactly what the application's resolver will return.
Interview checkpoint
Hands-on lab
- Read dig output including ANSWER and AUTHORITY sections
- Query a specific resolver
- Walk the full root-to-authoritative path with +trace
- Perform a reverse lookup
Trace a DNS Query with dig
25 min · intermediate
Quick quiz
Which DNS record maps a hostname to an IPv4 address?
Which record maps a hostname to another hostname?
A recursive resolver queries the root servers first when resolving a name for the first time.
Cheat sheet
AHostname → IPv4 addressAAAAHostname → IPv6 addressCNAMEHostname → another hostname (alias)MXMail server for the domain (with priority)NSAuthoritative name servers for a zonePTRIP → hostname (reverse lookup)TXTArbitrary text — SPF, DKIM, verificationSOAStart of authority: zone metadatadig +short example.comJust the answerdig @8.8.8.8 example.comBypass local resolverdig +trace example.comFull path root → TLD → authdig -x 8.8.8.8Reverse lookup (PTR)