# DNS : In Depth # DNS Explained with `dig`: From Root Servers to [Google.com](http://Google.com) When you type [`google.com`](http://google.com) into your browser, a surprising amount of distributed system machinery spins up behind the scenes. At the heart of it all is **DNS — the Domain Name System**. This article breaks DNS down layer by layer using the `dig` command, so you can *see* how name resolution actually works instead of memorizing theory. --- ## DNS: The Internet’s Phonebook ☎️ Humans remember names. Machines route traffic using IP addresses. DNS exists to translate **human-friendly domain names** like: ```plaintext google.com ``` into **machine-friendly IP addresses** like: ```plaintext 142.250.190.14 ``` Without DNS, we’d be browsing the internet by typing numbers—clearly not ideal. Key idea: > **DNS is a globally distributed, hierarchical database optimized for reads.** --- ## Introducing `dig`: Your DNS X-Ray Tool 🔍 `dig` (Domain Information Groper) is a command-line tool that lets you **inspect DNS resolution at every layer**. You use `dig` when you want to: * Debug DNS issues * Understand name server delegation * See authoritative vs recursive behavior * Learn how browsers actually resolve domains Basic syntax: ```plaintext dig ``` --- ## DNS Resolution Happens in Layers DNS resolution is **not a single lookup**. It’s a chain of delegations: ![https://substackcdn.com/image/fetch/%24s_%21P_Ol%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0a1bb2c-a1bc-40ce-abde-6fb9d2a66ce8_1600x570.png](https://substackcdn.com/image/fetch/%24s_%21P_Ol%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0a1bb2c-a1bc-40ce-abde-6fb9d2a66ce8_1600x570.png align="left") ![https://substackcdn.com/image/fetch/%24s_%21_iP7%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8a5ed500-6b67-4b36-b6fc-fe04d8b02914_2876x1697.png](https://substackcdn.com/image/fetch/%24s_%21_iP7%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8a5ed500-6b67-4b36-b6fc-fe04d8b02914_2876x1697.png align="left") ![https://www.researchgate.net/publication/342547942/figure/fig1/AS%3A907969327800320%401593488165786/llustration-of-DNS-resolution-over-recursive-root-TLD-and-authoritative-name-server.png](https://www.researchgate.net/publication/342547942/figure/fig1/AS%3A907969327800320%401593488165786/llustration-of-DNS-resolution-over-recursive-root-TLD-and-authoritative-name-server.png align="left") 4 ```plaintext Root servers (.) ↓ TLD servers (.com, .org, .net) ↓ Authoritative servers (google.com) ``` Let’s walk this hierarchy using `dig`. --- ## `dig . NS` — Root Name Servers 🌍 ```plaintext dig . NS ``` This asks: > “Who is authoritative for the **root zone**?” ### What you’ll see * Servers like [`a.root-servers.net`](http://a.root-servers.net) * Managed by organizations like Verisign, ICANN, etc. Key points: * There are **13 logical root servers** (A–M) * Each is anycasted globally (hundreds of physical instances) * Root servers **do not know IPs for** [**google.com**](http://google.com) * They only know **where** `.com` lives Think of them as: > “I don’t know the answer, but I know who to ask next.” --- ## `dig com NS` — TLD Name Servers 📛 ```plaintext dig com NS ``` This queries the **Top-Level Domain (TLD)** servers for `.com`. ### What this tells us * `.com` is managed by **Verisign** * These servers know: * Which name servers are authoritative for [`google.com`](http://google.com) * They **still don’t know** [**google.com**](http://google.com)**’s IP** TLD servers act as: > A directory of domains registered under `.com` --- ## `dig` [`google.com`](http://google.com) `NS` — Authoritative Name Servers 🏛️ ```plaintext dig google.com NS ``` Now we’re asking: > “Who is authoritative for [`google.com`](http://google.com)?” ### Output highlights * Name servers like: ```plaintext ns1.google.com ns2.google.com ns3.google.com ns4.google.com ``` These servers: * Are controlled by Google * Hold the **actual DNS records** * Provide final answers (A, AAAA, MX, TXT, etc.) This is where **truth lives** in DNS. --- ## `dig` [`google.com`](http://google.com) — Full DNS Resolution 🔄 ```plaintext dig google.com ``` This returns: * `A` records (IPv4) * Possibly `AAAA` records (IPv6) * TTL values * Which server answered the query But here’s the important part: > **Your system did not query root → TLD → authoritative directly.** Instead, this was handled by a **recursive resolver**. --- ## Recursive Resolvers: The Hidden Middleman 🧠 Your laptop/browser typically asks: * ISP DNS * Google DNS (`8.8.8.8`) * Cloudflare (`1.1.1.1`) ![https://www.researchgate.net/publication/330006223/figure/fig1/AS%3A709642057445377%401546203259697/Domain-resolution-process-with-a-recursive-resolver.ppm](https://www.researchgate.net/publication/330006223/figure/fig1/AS%3A709642057445377%401546203259697/Domain-resolution-process-with-a-recursive-resolver.ppm align="left") ![https://media.geeksforgeeks.org/wp-content/uploads/20220713172800/RecursiveDNS1.png](https://media.geeksforgeeks.org/wp-content/uploads/20220713172800/RecursiveDNS1.png align="left") ![https://i.sstatic.net/00S6Q.jpg](https://images.openai.com/thumbnails/url/oHTed3icu5mZUVJSUGylr5-al1xUWVCSmqJbkpRnoJdeXJJYkpmsl5yfq5-Zm5ieWmxfaAuUsXL0S7F0Tw4yznAL94kwDHD2SvF19DcPKYmM1E13C8jxCisL0jVI9MlNdU92DTJMjExKLa3wD_NVKwYAOzAlYA align="left") 4 ### What the recursive resolver does 1. Ask root servers for `.com` 2. Ask `.com` servers for [`google.com`](http://google.com) 3. Ask Google’s authoritative servers for IP 4. Cache the result 5. Return the IP to your browser All in milliseconds. --- ## Mapping `dig` Commands to DNS Stages ![https://substackcdn.com/image/fetch/%24s_%21piIO%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1adddd56-9fb5-4dc4-ad1a-0faea938acf0_2284x2054.png](https://substackcdn.com/image/fetch/%24s_%21piIO%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1adddd56-9fb5-4dc4-ad1a-0faea938acf0_2284x2054.png align="left") ![https://scribbledtech.com/wp-content/uploads/2023/02/image-10-1024x924.png](https://scribbledtech.com/wp-content/uploads/2023/02/image-10-1024x924.png align="left") ![https://miro.medium.com/v2/resize%3Afit%3A1400/1%2AKK0uKAzIfDB3ivc-7J8OtQ.jpeg](https://miro.medium.com/v2/resize%3Afit%3A1400/1%2AKK0uKAzIfDB3ivc-7J8OtQ.jpeg align="left") 4 | `dig` Command | DNS Layer | | --- | --- | | `dig . NS` | Root name servers | | `dig com NS` | TLD servers | | `dig` [`google.com`](http://google.com) `NS` | Authoritative servers | | `dig` [`google.com`](http://google.com) | Full resolution via recursive resolver | This mapping is gold for **system design interviews**. --- ## Why NS Records Matter in System Design NS records: * Enable **horizontal scaling** of DNS * Allow delegation without central coordination * Prevent single points of failure * Make DNS one of the most resilient systems ever built Design insight: > DNS works because *no server needs to know everything*. --- ## Connecting DNS to Real Browser Requests 🌐 When you type [`https://google.com`](https://google.com): 1. DNS resolves [`google.com`](http://google.com) → IP 2. TCP connection is established 3. TLS handshake happens 4. HTTP request is sent If DNS fails: * Nothing else even starts That’s why DNS latency and availability are **critical** at scale. --- ## Final Takeaways * DNS is a **hierarchical, distributed database** * `dig` lets you observe DNS like a systems engineer * Root → TLD → Authoritative is the backbone of resolution * Recursive resolvers hide complexity but rely on this hierarchy * Understanding DNS deeply pays off in **backend, infra, and SRE roles**