How DNS Resolution Works: Tracing google.com with dig

DNS is the internet’s phonebook — but how does the lookup actually happen?

You already know DNS translates a domain name into an IP address, the way a phonebook translates a name into a phone number (covered in depth in this series’s article on DNS record types). What’s less obvious is how that lookup actually happens — DNS isn’t one single database somewhere being queried directly. It’s a layered hierarchy of servers, each responsible for a specific piece of the answer, working together in sequence. The best way to actually see this happen is with a command-line tool called dig.

What Is DNS and Why Name Resolution Exists

DNS (Domain Name System) exists because humans remember names far better than numbers — google.com is memorable; 142.250.183.14 isn't. Name resolution is the process of translating that memorable name into the actual IP address a computer needs to establish a connection.

That resolution process isn’t a single lookup — it’s a sequence of queries across a hierarchy of servers, each one narrowing down the answer.

What Is the dig Command and When It Is Used

dig (Domain Information Groper) is a command-line tool for directly querying DNS servers and inspecting exactly what they return — used by developers and system administrators to diagnose DNS issues, verify configuration, or simply understand how resolution actually works, layer by layer.

dig google.com

Unlike a browser (which resolves DNS invisibly, behind the scenes), dig lets you see the raw DNS query and response directly — making it the ideal tool for actually observing the layered process this article walks through.

Understanding dig . NS and Root Name Servers

dig . NS

Querying . (a single dot represents the DNS root) for its NS (Name Server) records returns the root name servers — the very top of the entire DNS hierarchy.

;; ANSWER SECTION:
.    518400  IN  NS  a.root-servers.net.
.    518400  IN  NS  b.root-servers.net.
.    518400  IN  NS  c.root-servers.net.
...

There are 13 sets of root server addresses globally (each actually backed by many physical servers worldwide, for redundancy). Root servers don’t know the IP address for google.com directly — their job is much narrower: they know which servers are responsible for each top-level domain (like .com, .org, .net), and point resolution there next.

Understanding dig com NS and TLD Name Servers

dig com NS

Querying com for its NS records returns the TLD (Top-Level Domain) name servers — the servers specifically responsible for the entire .com namespace.

;; ANSWER SECTION:
com.    172800  IN  NS  a.gtld-servers.net.
com.    172800  IN  NS  b.gtld-servers.net.
com.    172800  IN  NS  c.gtld-servers.net.
...

These TLD servers still don’t know google.com's specific IP address — their job is to know which servers are authoritative for each individual domain registered under .com, and point resolution to those servers next.

Understanding dig google.com NS and Authoritative Name Servers

dig google.com NS

Querying google.com for its NS records returns the authoritative name servers for that specific domain — the servers that actually hold the real, final DNS records (A, AAAA, MX, and so on, covered in this series's DNS record types article).

;; ANSWER SECTION:
google.com.  345600  IN  NS  ns1.google.com.
google.com.  345600  IN  NS  ns2.google.com.
google.com.  345600  IN  NS  ns3.google.com.
google.com.  345600  IN  NS  ns4.google.com.

This is the final layer of the hierarchy — these specific servers are the actual “source of truth” for google.com's DNS records, the ones ultimately queried to get a real, usable answer.

Understanding dig google.com and the Full DNS Resolution Flow

dig google.com

Running dig for the domain itself (without specifying NS) triggers the full resolution process — and returns the actual answer:

;; ANSWER SECTION:
google.com.  245  IN  A  142.250.183.14

But behind that single, clean answer, a full chain of lookups just happened:

The role of the recursive resolver

In everyday use, you don’t personally perform each of these steps — a recursive resolver (typically run by your ISP, or a public option like 8.8.8.8) does this entire chain on your behalf, starting from the root and working down through TLD and authoritative servers, before finally handing your device just the final answer.

This is exactly why a plain dig google.com looks so simple — the resolver has already done the layered work invisibly, and typically caches the result too, so repeated lookups for the same domain don't need to repeat the entire chain every single time.

Connecting This to Real-World Browser Requests

Every time you type a URL into a browser, this exact same layered process happens — usually invisibly, usually in milliseconds, and usually served from a resolver’s cache rather than a fresh full chain lookup. The four dig commands above simply let you manually observe each individual stage that would otherwise happen silently behind the scenes.

Understanding this hierarchy also explains why DNS scales as well as it does globally: no single server needs to know every domain’s IP address — responsibility is deliberately distributed across layers, each one only needing to know how to point toward the next, narrower layer.

Final Takeaway

DNS resolution isn’t a single lookup against one giant database — it’s a deliberately layered hierarchy, each level narrowing the search: root servers know where to find TLD servers; TLD servers know where to find a domain’s authoritative servers; authoritative servers hold the actual, final records. Tracing this with dig . NS, dig com NS, dig google.com NS, and finally dig google.com lets you watch each layer hand off to the next, turning what feels like instant magic in a browser into a clear, traceable, understandable chain — exactly the kind of system-design thinking that makes DNS, and the internet built on top of it, actually make sense.

Frequently Asked Questions

Do I really perform four separate DNS lookups every time I visit a website?

> No — your recursive resolver performs this chain on your behalf, and heavily caches results at every layer, so most everyday lookups are served quickly from cache rather than repeating the entire root-to-authoritative chain each time.

Why does DNS use a layered hierarchy instead of one central server?

> A single central server would be both a massive bottleneck and a single point of failure for the entire internet’s naming system. Distributing responsibility across root, TLD, and authoritative layers lets the system scale globally, with redundancy built into every layer.

What’s the difference between dig google.com and dig google.com NS?

> dig google.com (with no record type specified) defaults to querying for the domain's A record — its actual IP address. dig google.com NS specifically asks which servers are authoritative for that domain, rather than asking for the domain's own IP.

Is dig only useful for advanced networking work?

> Not at all — it’s genuinely useful for any developer diagnosing DNS-related issues (a site not resolving correctly, checking DNS propagation after a change) and, as this article shows, it’s also one of the clearest ways to actually see how DNS resolution works, rather than just reading about it abstractly.