# How DNS Resolution Works: A Simple Guide for Beginners 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: ```bash dig google.com ``` And boom – you get all the DNS information for google.com. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768926297695/878e1380-0dfb-4142-9b11-b6865a507d5e.jpeg align="center") 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**: 1. **Root Name Servers** 2. **TLD (Top-Level Domain) Name Servers** 3. **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: ```bash dig . NS ``` ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768926395954/016ef50d-ed88-4ffc-b03a-25a3883f34a7.jpeg align="center") 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. --- ## Step 2: TLD Name Servers – `dig com NS` Now your query moves to the **TLD (Top-Level Domain) servers**. These servers handle specific extensions like `.com`, `.org`, `.net`, `.in`, etc. Run this: ```bash dig com NS ``` ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768926475301/3c9c69ff-cb0d-444d-807a-aa0766f5c8b0.jpeg align="center") 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. --- ## Step 3: Authoritative Name Servers – `dig google.com NS` Finally, we reach the **authoritative name servers**. These are the servers that actually **own** the DNS records for a specific domain. Run this: ```bash 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: ```bash dig google.com ``` You'll get output that looks like this: ```plaintext ; <<>> 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: * **google.com** resolves to the IP address **142.250.183.206** * Your browser can now connect to Google's server using this IP 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: 1. Your computer asks a **recursive resolver** (usually your ISP's DNS server) 2. The resolver asks the **root servers**: "Who handles `.com`?" 3. Root servers respond: "Ask the TLD servers for `.com`" 4. The resolver asks the **TLD servers**: "Who handles google.com?" 5. TLD servers respond: "Ask Google's authoritative name servers" 6. The resolver asks **Google's authoritative servers**: "What's the IP for google.com?" 7. Google's servers respond: "It's 142.250.183.206" 8. 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: ```plaintext 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 Lab**on 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](https://github.com/prajapatisaurabh) 💼 **LinkedIn**: [saurabh-prajapati](https://linkedin.com/in/saurabh-prajapati) ---