How DNS Resolution Works: Turning a Domain Name Into an IP

Behind a single lookup, your request is relayed through a recursive resolver and the root, TLD, and authoritative servers to turn `example.com` into an IP address you can actually connect to.

When you type example.com into your browser, your computer can't connect to that name directly—networks route traffic by IP address, not by words. The process that translates a human-friendly domain into an IP is DNS resolution (the Domain Name System). Think of it as a globally distributed phone book, looked up through a relay of several parties.

Two Query Styles: Recursive vs. Iterative

DNS queries come in two flavors:

  • Recursive: you hand the whole problem to one server and say "figure it out and bring me the final answer." That's what your device asks of a recursive resolver.
  • Iterative: a queried server that doesn't know the answer simply replies "I don't have it, but ask this server next," handing back a referral. That's how the resolver talks to the upstream servers.

In short: you ask once (recursively), and the resolver asks around many times (iteratively) on your behalf.

The DNS Hierarchy

Authoritative data lives in a tree, resolved right-to-left:

  • Root DNS: 13 root server groups worldwide that know where each top-level domain is handled.
  • TLD DNS: responsible for suffixes like .com, .net, and .org, and knows the authoritative server for each domain beneath them.
  • Authoritative DNS: holds the real records for example.com (A, AAAA, MX, and so on) and gives the final answer.

Authoritative name servers are usually hosted by your domain registrar or a dedicated DNS provider. The "NS records" you set in your registrar's dashboard declare who has the final say over your domain.

The Full Journey of One Lookup

Say you're resolving www.example.com:

  • Your computer first checks its local caches (browser, OS, hosts); a hit returns immediately.
  • On a miss, it asks the configured recursive resolver—your ISP's, or a public one like 8.8.8.8.
  • If the resolver's cache is empty too, it starts asking iteratively: first the root, which points it to the .com TLD servers.
  • The resolver asks the TLD, which returns the authoritative servers for example.com.
  • Finally the resolver asks the authoritative server and gets the IP for www.
  • The resolver caches the result for a while (governed by the record's TTL) and hands it back, and your browser opens the connection.

Caching is everywhere—it's why the vast majority of lookups never have to bother a root server.

Watching It With dig / nslookup

Install the tools on Ubuntu/Debian:

sudo apt update
sudo apt install dnsutils

Check the final answer:

dig www.example.com A +short
nslookup www.example.com

Use +trace to watch the resolver walk from the root down to the authoritative server:

dig www.example.com +trace

Inspect a domain's authoritative name servers and the remaining cache TTL:

dig example.com NS +short
dig www.example.com   # note the TTL value in the answer

Summary

DNS resolution is a relay that turns a name into an IP: your device sends one recursive request to a recursive resolver, which then works iteratively through the root → TLD → authoritative tiers to fetch the IP and cache it for the record's TTL. Once this chain clicks—especially paired with dig +trace—troubleshooting "the site won't load" or "my DNS change hasn't taken effect yet" becomes far more straightforward.