DNS Resolution Explained: From URL to IP Address, Step by Step

Every time you load a web page, your computer performs a multi-stage lookup to translate a human-readable domain name into an IP address. Here is exactly what happens, layer by layer, and how to debug it when something goes wrong.

The Domain Name System is essentially the phone book of the internet. Humans remember names like wierdx.net; routers and servers communicate using numeric IP addresses like 203.0.113.42. DNS bridges those two worlds. Understanding how the resolution chain works helps you diagnose latency issues, debug deployment problems, and design systems that handle DNS gracefully. It also complements what you already know about TCP/IP networking.

The Resolution Chain: Eight Steps

When you type https://example.com into your browser and press Enter, the following sequence unfolds before a single byte of HTTP traffic flows.

1. Browser cache. The browser first checks its own in-memory DNS cache. Chrome maintains one internally; you can inspect it at chrome://net-internals/#dns. If a cached record exists and its TTL has not expired, the lookup ends here.
2. Operating system cache. If the browser has no cached answer, it asks the OS resolver. On Linux and macOS this means checking /etc/hosts first (local overrides), then the OS-level DNS cache. On macOS you can flush it with sudo dscacheutil -flushcache; on Linux with sudo systemd-resolve --flush-caches.
3. Recursive resolver query. The OS sends a UDP query (port 53, or TCP for large responses) to the recursive resolver configured in /etc/resolv.conf or via DHCP. This is usually your ISP's resolver, Google's 8.8.8.8, or Cloudflare's 1.1.1.1. The recursive resolver does the heavy lifting on your behalf.
4. Recursive resolver cache. The resolver checks its own cache. If a previous client already looked up example.com within its TTL window, the cached answer is returned immediately. Most production resolvers serve the vast majority of queries from cache.
5. Root nameserver query. On a cache miss, the recursive resolver contacts one of the 13 root nameserver clusters (lettered A through M, each anycast across hundreds of physical machines). The root does not know the IP for example.com, but it knows which nameservers are authoritative for .com. It returns an NS referral for the .com TLD zone.
6. TLD nameserver query. The resolver now queries a .com TLD nameserver (operated by Verisign). The TLD server does not know the final IP either, but it knows which nameservers are authoritative for the example.com domain specifically. It returns another NS referral.
7. Authoritative nameserver query. The resolver contacts the authoritative nameserver for example.com — the server that holds the actual DNS zone file. This nameserver returns the final answer: the A record (IPv4) or AAAA record (IPv6) pointing to the server's IP address.
8. Response returned and cached. The recursive resolver passes the answer back to the OS, which passes it to the browser. Both the resolver and the OS cache the record for its TTL duration. Subsequent lookups skip steps 5 through 7 entirely until the TTL expires.

DNS Record Types

Each entry in a zone file is called a resource record. The type field tells resolvers how to interpret the data.

A key restriction: you cannot place a CNAME record at the apex (root) of a zone alongside other records. That is why DNS providers offer proprietary record types like ALIAS or ANAME that behave like CNAME at the apex without violating the RFC.

TTL and Negative Caching

TTL (Time To Live) is measured in seconds and travels in every DNS response. A TTL of 300 means resolvers may cache that record for five minutes before re-querying. Low TTLs give you faster failover when you change IP addresses; high TTLs reduce load on your nameservers and speed up lookups for end users. A common pattern before a planned server migration is to drop TTL to 60 seconds 24 hours in advance so the transition propagates quickly.

Negative caching applies when a name does not exist. If a resolver queries for typo.example.com and the authoritative server returns NXDOMAIN (non-existent domain), that negative result is also cached, for the duration specified in the zone SOA record's negative TTL field. This prevents thundering-herd queries for mistyped hostnames.

Debugging with dig

The dig command is the standard tool for inspecting DNS responses. It ships with most Linux distributions via the bind-utils or dnsutils package.

# Basic A record lookup
dig example.com A

# Query a specific resolver (Cloudflare)
dig @1.1.1.1 example.com A

# Trace the full resolution chain step by step
dig +trace example.com

# Look up MX records
dig example.com MX

# Short output: just the answer
dig +short example.com

# Check TTL remaining on a cached record
dig +ttlunits example.com A

# Reverse lookup (PTR)
dig -x 93.184.216.34

The +trace flag is especially useful for diagnosing propagation problems. It forces dig to perform a full iterative lookup starting from the root servers, mirroring what a recursive resolver does, so you can see exactly which nameserver is returning stale or incorrect data. This pairs well with knowledge of HTTP status codes when diagnosing end-to-end connectivity failures.