Have you ever wondered what happens when you type "google.com" in your browser?
Like, how does your computer know where to find Google's website?
It's not magic – it's DNS. And honestly, once you understand it, it's pretty cool.
Let me walk you through this step by step, just like I learned it myself.
What is DNS and Why Does It Exist?
Okay, so here's the thing.
Computers don't understand names like "google.com" or "facebook.com".
They only understand numbers – specifically, IP addresses.
An IP address looks something like this: 142.250.183.206
Now imagine if you had to remember these numbers for every website you visit.
Sounds painful, right?
That's exactly why DNS exists.
DNS stands for Domain Name System.
Think of it like the internet's phonebook.
You give it a name (like "google.com"), and it gives you back the phone number (the IP address).
Without DNS, we'd all be memorizing random numbers instead of easy names. Not fun.
What is the dig Command?
Before we go deeper, let me introduce you to a super useful tool: dig.
dig is a command-line tool that lets you see exactly how DNS resolution works behind the scenes.
It's like peeking into the kitchen to see how your favorite dish is made.
When do you use dig?
When a website isn't loading and you want to check DNS issues
When you're curious how domain names get resolved
When you're debugging network problems
You can run it on your terminal like this:
dig google.com
And boom – you get all the DNS information for google.com.
Pretty handy, right?
Understanding DNS Resolution: The Layers
Here's where it gets interesting.
DNS resolution doesn't happen in one go.
It's like asking for directions – you don't just ask one person. You ask a series of people, each giving you more specific information.
DNS works in three main layers:
Root Name Servers
TLD (Top-Level Domain) Name Servers
Authoritative Name Servers
Let's break each one down.
Step 1: Root Name Servers – dig . NS
The root name servers are the starting point of all DNS queries.
Think of them as the "master directory" of the internet.
When your computer asks, "Where can I find google.com?", it first asks the root servers.
The root servers don't know the exact answer, but they point you in the right direction.
Run this command:
dig . NS
You'll see a list of root name servers with names like:
a.root-servers.net
b.root-servers.net
c.root-servers.net
There are 13 sets of root servers (labeled A to M) spread across the world.
They say: "I don't know where google.com is, but I know who handles .com domains."
And that's where the next layer comes in.
Now your query moves to the TLD (Top-Level Domain) servers.
These servers handle specific extensions like .com, .org, .net, .in, etc.
Run this:
dig com NS
You'll see name servers like:
a.gtld-servers.net
b.gtld-servers.net
These are the servers responsible for all .com domains.
They say: "I don't have the IP for google.com, but I know who does. Go ask the authoritative name servers for google.com."
See the pattern? We're getting closer.
Finally, we reach the authoritative name servers.
These are the servers that actually own the DNS records for a specific domain.
Run this:
dig google.com NS
You'll see something like:
ns1.google.com
ns2.google.com
ns3.google.com
These servers know everything about google.com.
They hold the final answer: the actual IP address.
Step 4: Full DNS Resolution – dig google.com
Now, let's see the complete picture.
Run this:
dig google.com
You'll get output that looks like this:
; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24854
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 87 IN A 142.250.183.238
;; Query time: 92 msec
;; SERVER: fe80::5a07:f8ff:fea2:d51%16#53(fe80::5a07:f8ff:fea2:d51%16)
;; WHEN: Tue Jan 20 21:58:18 IST 2026
;; MSG SIZE rcvd: 55
This means:
Boom. That's how DNS works.
What Are NS Records?
You might've noticed "NS" appearing a lot.
NS stands for Name Server.
An NS record tells you which server is responsible for a domain's DNS information.
For example:
Root servers have NS records pointing to TLD servers
TLD servers have NS records pointing to authoritative servers
Authoritative servers have the final DNS records
It's like a chain of responsibility.
How Does This Happen in Real Life?
When you type "google.com" in your browser, here's what happens behind the scenes:
Your computer asks a recursive resolver (usually your ISP's DNS server)
The resolver asks the root servers: "Who handles .com?"
Root servers respond: "Ask the TLD servers for .com"
The resolver asks the TLD servers: "Who handles google.com?"
TLD servers respond: "Ask Google's authoritative name servers"
The resolver asks Google's authoritative servers: "What's the IP for google.com?"
Google's servers respond: "It's 142.250.183.206"
Your browser connects to that IP and loads the website
All of this happens in milliseconds.
Pretty amazing, right?
DNS Hierarchy Diagram
Here's a simple way to visualize it:
Root Servers (.)
↓
TLD Servers (.com, .org, .net)
↓
Authoritative Servers (google.com, facebook.com)
↓
IP Address (142.250.183.206)
Each layer knows just enough to pass you to the next one.
Why Should You Care About This?
Honestly, understanding DNS helps you in so many ways:
Debugging: When a site won't load, you can check if DNS is the problem
System Design: If you're building web apps, knowing DNS is essential
Performance: DNS lookups can slow down websites if not optimized
Security: DNS attacks are real – knowing how it works helps you stay safe
Plus, it just feels good to understand how the internet actually works, you know?
Quick Recap
Let me sum it all up:
DNS is the internet's phonebook – it converts names to IP addresses
dig is a tool to inspect DNS resolution step by step
DNS works in layers: Root → TLD → Authoritative
NS records tell you which server is responsible for a domain
Recursive resolvers do all this work behind the scenes so you don't have to
And that's it. You now understand how DNS resolution works.
Next time someone asks you how the internet works, you can actually explain it.
How cool is that?
About the Author
Hi, I'm Saurabh Prajapati – a full-stack software engineer from India, currently working at IBM India Software Labon cloud-native enterprise solutions.
I specialize in GenAI, React, and modern web technologies, and I love breaking down complex topics into simple, easy-to-understand explanations.
📧 Email: saurabhprajapati120@gmail.com
🐙 GitHub: prajapatisaurabh
💼 LinkedIn: saurabh-prajapati
