DNS Demystified: Using dig to Trace the Internet’s Phonebook
From root servers to IP addresses: a step-by-step guide to how the world finds your website.
Imagine your phone book gets wiped out and now you have to dial numbers , instead of tapping on “Mom” or “Best Friend” you have type 10 digit phone number relying on your memory. Internet browsing would become a tedious nightmare overnight if we had to type 142.251.179.100 just to open Google.com.
Luckily, the Domain Name System (DNS) handles this for us becoming the "phonebook of the internet." DNS is the essential background service that translates human-friendly names like google.com into the numeric IP addresses computers use to talk to each other. In this article, we’ll explore the intricate inner workings of this crucial internet backbone.
DNS: The Internet's Phonebook
DNS or the Domain Name System is a distributed system that translates the domain name into the IP address to establish a communication system between devices around the globe. It provides convenience to user to access website using domain names. The implementation of DNS is done on the application layer.
The dig Command
DIG (Domain Information Groper) is a command line diagnostic tool that allows you to query DNS servers directly from the command line. Your web browser uses DNS to resolve domain names to IP addresses but you won’t see how the lookup is performed behind the scenes; dig shows you every detail of the resolution chain. It is invaluable for:
Debugging DNS issues
Understanding the working of DNS
Checking DNS propogation
Inspecting DNS records
DNS Hierarchy
DNS operates as a distributed hierarchical database..
Root DNS Servers: The top-level directory that doesn't know the IP address but knows exactly which Top-Level Domain (TLD) server to ask.
Top-Level Domain (TLD) Servers: The seervers responsible for specific endings like .com, .org, or .edu.
Authoritative Servers: The endpoint server and the only source that holds the actual, definitive IP address for the website you want.
Recursive Resolver: The middleman-server that receives your request and hunts down the answer by talking to all other servers on your behalf.
Let’s explore each layer using dig command.
Root Name Servers: dig . NS
The root servers sit at the top of the DNS hierarchy. They don't know where google.com is, but they know which servers handle the .com top-level domain.
dig . NS
This shows the root name servers that know about all top-level domains (.com, .org, .net, etc.). What you’ll see:
; <<>> DiG 9.18.28 <<>> . NS
;; QUESTION SECTION:
;. IN NS
;; 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 root name server networks (labeled a-m) that form the foundation of DNS. When a recursive resolver starts a lookup from scratch, it contacts one of these root servers first.
TLD Name Servers: dig com NS
Top-level domain (TLD) servers know about all domains within their extension (.com, .org, .net, etc.).
dig com NS
This shows the authoritative name servers for the .com top-level domain. What you’ll see:
; <<>> DiG 9.18.28 <<>> com NS
;; QUESTION SECTION:
;com. IN NS
;; 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 are Verisign's servers that manage the entire .com namespace. They don't know Google's IP address, but they know which name servers are authoritative for google.com.
Authoritative Name Servers: dig google.com NS
Authoritative name servers are the final authority for a specific domain. They hold the actual DNS records.
dig google.com NS
This shows the name servers that have authoritative information about google.com. What you’ll see:
; <<>> DiG 9.18.28 <<>> google.com NS
;; QUESTION SECTION:
;google.com. IN NS
;; ANSWER SECTION:
google.com. 21600 IN NS ns1.google.com.
google.com. 21600 IN NS ns2.google.com.
google.com. 21600 IN NS ns3.google.com.
google.com. 21600 IN NS ns4.google.com.
Google operates its own authoritative name servers. These servers contain the actual DNS records (A records, MX records, etc.) for google.com and can answer queries about it definitively.
Full Resolution: dig google.com
Now let's see the complete lookup that gets us the actual IP address:
dig google.com
What you’ll see:
; <<>> DiG 9.18.28 <<>> google.com
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
;; AUTHORITY SECTION:
google.com. 21600 IN NS ns1.google.com.
google.com. 21600 IN NS ns2.google.com.
google.com. 21600 IN NS ns3.google.com.
google.com. 21600 IN NS ns4.google.com.
;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
The output shows:
QUESTION: What we asked for (A record for google.com)
ANSWER: The IP address(es) for google.com
AUTHORITY: The authoritative name servers (shown for reference)
Query time: How long the lookup took
SERVER: Which DNS resolver we queried
The Complete DNS Resolution Flow
Here's what actually happens behind the scenes when you run dig google.com:
What NS Records Represent
NS (Name Server) records are delegation pointers. They provides the information about the server that are authoritative for a particular zone in DNS:
Root NS records → Point to servers authoritative for the root zone
TLD NS records → Point to servers authoritative for top-level domains
Domain NS records → Point to servers authoritative for specific domains
Without NS records, the DNS hierarchy wouldn't work, there'd be no way to delegate authority from one level to the next.
Real-World Browser Requests
When you visit https://google.com in your browser:
Browser checks its cache - Have I visited google.com recently?
OS checks its cache - Does the operating system know the IP?
Recursive resolver lookup - Query configured DNS server (often ISP or 8.8.8.8)
Full resolution chain - If not cached, the resolver walks the DNS hierarchy
TCP connection - Browser connects to the returned IP address
HTTPS negotiation - Establish encrypted connection
HTTP request- Send GET / request
Page loads - Receive and render content
The entire DNS lookup typically takes 20-100ms, but caching makes it near-instantaneous for frequently visited sites.
Practical dig Tips
Trace the full resolution path:
dig +trace google.com
Query a specific DNS server:
dig @8.8.8.8 google.com
Get only the answer:
dig +short google.com
Check specific record types:
dig google.com MX # Mail servers
dig google.com TXT # Text records
dig google.com AAAA # IPv6 addresses
When you enter a URL into your web browser, you're not simply browsing to a particular destination; you're participating in an ongoing global game of Telephone. Your request travels through a sophisticated, multi-tiered path in fraction of milliseconds through the Root servers until it arrives at either one of the Top-Level Domains (TLD) or at the authoritative source that has the exact digital coordinates for what you are looking for.
As shown via the usage of the dig command, the DNS system is much more than a static list of servers; it functions as a constantly evolving and distributed data repository, requiring coordination at all times. This aspect eliminates the "nightmare" of memorizing strings of digits and provides an easy-to-use interface whereby users can interact with the modern-world internet.
Whether it be via the NS Records that delegate authority, or via the Recursive Resolver performing most of the work on your behalf, the DNS system is the underlying "silent architect" that keeps the entire planet connected by resolving one domain name at a time.
