Deconstructing DNS: A Layered Exploration with dig
When you type google.com into your browser, a complex, millisecond-fast "dance" occurs behind the scenes before the website even begins to load. This invisible process is driven by DNS the Domain Name System.
For system designers, developers, and network engineers, understanding DNS is not optional it is foundational. It is one of the most critical, yet often misunderstood, distributed systems in existence.
This post will break down how DNS resolution works by peeling back its layers. We won't just talk about theory we will use a powerful diagnostic tool called dig to inspect the very infrastructure that makes the internet usable.
What is DNS and Why Do We Need Name Resolution?
At its core, the internet is built on IP addresses numerical labels like 142.250.190.78 (IPv4) or 2607:f8b0:4005:800::200e (IPv6) that identify devices on a network. Computers love numbers but humans do not. We prefer memorable names like github.com or wikipedia.org.
DNS is often called "the phonebook of the internet." It exists to bridge this gap, translating human readable domain names into machine-readable IP addresses. Without DNS, we would be stuck memorizing long strings of numbers for every service we wanted to access.
The Hierarchy
Crucially, DNS is not a single, massive database sitting on one supercomputer. If it were, the internet would break constantly. Instead, DNS is a highly distributed, hierarchical database structured like an inverted tree.
When you look up a domain, you aren't querying one central authority. You are traversing a path down that tree, layer by layer, to find the answer.
Introducing - dig
To understand this traversal, we need a tool to inspect DNS records. Enter dig (Domain Information Groper).
dig is a command-line tool used by network administrators to interrogate DNS name servers. While a web browser hides the complexity of DNS, dig exposes the raw data, letting us see exactly what information differing name servers hold.
The Hierarchy in Action: Following the Breadcrumbs
We are going to trace a DNS request for google.com by manually inspecting each layer of the hierarchy. To do this, we will be focusing on NS Records.
What is an NS Record? An NS (Name Server) record doesn't contain the final IP address of a website. Instead, it acts as a delegation pointer. It tells you: "I don't have the final answer, but here are the servers responsible for the next layer down. Go ask them."
Layer 1: The Root Name Servers ( . )
Every DNS lookup logically starts at the very top of the hierarchy: the "dot" trailing every fully qualified domain name (e.g., google.com.). These are the Root Name Servers. They are the gatekeepers of the internet's top-level structure.
Let’s ask DNS: "Who are the root servers?"
Bash
$ dig . NS +short
Note: The +short flag makes the output easier to read for this demonstration.
Output:
a.root-servers.net.
b.root-servers.net.
c.root-servers.net.
... (truncated list to m.root-servers.net)
What this means: There are 13 logical root server addresses (named a through m). These servers don't know the IP address of google.com. They only know one thing: which servers manage the Top-Level Domains (like .com, .org, .io). They are the starting point of delegation.
Layer 2: The TLD Name Servers (The .com layer)
To find google.com, the root servers direct us to the servers responsible for the .com Top-Level Domain (TLD). These TLD servers are managed by large registries (like Verisign for .com).
Let's use dig to see who is responsible for the .com zone.
Bash
$ dig com NS +short
Output:
a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
...
What this means: These "gtld-servers" are massive operations responsible for knowing the location of every single domain ending in .com.
Again, these servers do not know the specific IP address of Google's web server. But they do know which servers Google has authorized to answer questions about their domain.
Layer 3: Authoritative Name Servers (The final destination)
The TLD servers delegate responsibility to the "Authoritative Name Servers." These are the servers actually owned by the organization (like Google) or their DNS provider (like Cloudflare, AWS Route53, or NS1). They hold the "authority" providing final answers.
Let's ask the .com infrastructure who handles google.com:
Bash
$ dig google.com NS +short
Output:
ns1.google.com.
ns2.google.com.
ns3.google.com.
ns4.google.com.
What this means: We have arrived. These four servers are the ultimate source of truth for anything related to the google.com domain. If you want to know the IP address for mail.google.com or just google.com, these are the specific machines that have the answer.
The Full Resolution Flow: Putting it Together
We just manually walked through the hierarchy using dig to inspect NS records. In the real world, your web browser doesn't do this manual walking. It relies on a "Recursive Resolver."
A Recursive Resolver is a server, usually provided by your ISP (like Comcast or AT&T) or a public service (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1), that does the legwork for you.
When you type google.com in your browser, here is the actual system design flow:
When you run a standard dig command without specifying a record type, it asks your configured recursive resolver to perform this entire dance and just give you the final "A record" (the IPv4 address).
Bash
$ dig google.com +short
Output:
142.250.190.78
By understanding the layers underneath from Root to TLD to Authoritative you gain a much clearer mental model of internet infrastructure. You understand why DNS propagation takes time (caching at various layers), why DNS outages can be localized to specific TLDs, and how to troubleshoot connectivity issues when they arise.
