DNS Anatomy: Tracing the Internet with dig
Introduction: Beyond the Phonebook
People often say that DNS is the "phone book of the internet." That's a good way to describe what it does, but it's not a good way to explain how it works.
A real phonebook is one big book with all the numbers in it. If DNS worked that way, we would have to download a 500TB file every time we opened a web browser. DNS is not a single hierarchy. It's like a tree where no one server knows everything, but every server knows who to ask next.
We will use the command-line tool dig to manually walk down this tree, from the root of the internet to a specific website, to learn how name resolution really works.
The Tool: What is dig?
dig (Domain Information Groper) is a tool for managing networks that lets you ask DNS name servers questions. Dig is different from ping because it asks specific DNS servers specific questions and shows you the raw answer.
Launch your terminal. We are going to follow a request.
Step 1: The Root (.)
Every domain name actually ends with a hidden dot. google.com is technically google.com.. This dot represents the Root.
Let’s ask the internet: "Who manages the Root?"
dig . NS
You will see a list of servers with names like a.root-servers.net, b.root-servers.net, and so on, up to m. This means that these are the Root Name Servers. There are 13 logical root server IP addresses all over the world. They don't know what the IP address of google.com is. The only thing they know is where to find the Top-Level Domains (TLDs).
Step 2: The TLD (com)
Now that we know the Root servers exist, a real DNS resolver would ask one of them: "I’m looking for google.com. Who handles .com?"
Let’s simulate that by asking for the Name Servers (NS) of the .com registry.
dig com. NS
What you see: You will see servers like a.gtld-servers.net.
These are the TLD Name Servers, which means what they are. Verisign is in charge of the .com TLD. These servers still don't know what Google's IP address is. They only know that the domain google.com was bought by Google.
Step 3: The Authoritative Server (google.com)
The TLD server says: "I don't know the IP for google.com, but I know that Google manages their own DNS. Go ask them."
Let’s find Google’s specific Name Servers.
dig google.com NS
You will see servers like ns1.google.com or ns2.google.com. This means that these are the Authoritative Name Servers. This is the last stop on the list. Google owns these servers, and they are the only ones who know for sure where their websites are.
Step 4: The Resolution (A Record)
Finally, we ask the Authoritative Server: "Okay, I’m here. Give me the IP address for google.com."
dig google.com
(By default, dig asks for the A record).
What you see:
;; ANSWER SECTION:
google.com. 206 IN A 142.250.193.206
The Full Flow:
Browser: "Where is google.com?"
Root Server: "I don't know, ask the
.comguys."TLD Server: "I don't know, ask Google's nameservers (
ns1.google.com)."Authoritative Server: "I know! It is
142.250.193.206."
Pro Tip: The Shortcut (+trace)
We just manually walked through every step of the resolution process to understand the layers. However, dig has a built-in feature to do this automatically.
If you run:
dig google.com +trace
You will see dig perform the full marathon in real-time. It will output the Root response, then the TLD response, and finally the Authoritative response, all in one go. It’s the best way to debug exactly where a DNS request is failing.
Conclusion: The Recursive Resolver
Your browser doesn't run these commands by hand in the real world. Instead, it uses a Recursive Resolver, which is usually provided by your ISP or a public one like Cloudflare 1.1.1.1 or Google 8.8.8.8.
This Resolver does all the hard work for you. It runs the marathon from Root to TLD to Authoritative, stores the results, and then gives your browser the final IP address. If you want to figure out why a newly bought domain isn't loading (propagation delay) or why a site is down (DNS poisoning or misconfigured NS records), you need to understand this flow.
