# How DNS Resolution Works When we type [`google.com`](http://google.com) in a browser, we expect the website to load instantly. But behind this simple action is a well-structured system that translates human-friendly names into machine-friendly IP addresses. This system is called **DNS**, and understanding how it works is essential for anyone interested in networking, backend systems, or system design. In this blog, I’ll explain **how DNS resolution works step by step**, using the `dig` command to build a clear mental model—from root servers all the way to loading a website in your browser. ![A Crash Course in DNS - ByteByteGo Newsletter](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") --- ## 1\. What is DNS and Why Name Resolution Exists DNS (Domain Name System) is often called **the internet’s phonebook**. * We Humans remember names like [`google.com`](http://google.com) * But Computers communicate using IP addresses like `142.250.182.14` DNS exists to **map domain names to IP addresses** so that humans don’t have to remember numbers. Without DNS, we would need to type IP addresses directly into browsers, which is impractical and error-prone. ![Explaining DNS Resolution. DNS resolution, or Domain Name ...](https://miro.medium.com/1%2AgoSb1oow5UBNF3KkzvOX8A.png align="left") --- ## 2\. What is the `dig` Command and When It Is Used `dig` (Domain Information Groper) is a **DNS diagnostic and debugging tool**. It is used to: * Inspect how DNS resolution happens * Query DNS records directly * Troubleshoot DNS issues * Understand which name servers are involved Example: \- dig [google.com](http://google.com) ![Navigating the web: Everything that happens in a DNS lookup ...](https://miro.medium.com/v2/resize%3Afit%3A1400/1%2AKK0uKAzIfDB3ivc-7J8OtQ.jpeg align="left") --- ## 3\. Understanding `dig . NS` and Root Name Servers Let’s start at the very top of the DNS hierarchy. \-dig . NS This command asks: > “Who are the name servers for the root of DNS?” ### What does this mean? * `.` represents the **DNS root** * Root name servers don’t know IPs of websites * They only know **which servers handle each TLD** (`.com`, `.org`, `.in`, etc.) ### Key idea: The [root server](https://www.cloudflare.com/learning/dns/glossary/dns-root-server/) [is the firs](https://www.cloudflare.com/learning/dns/glossary/dns-root-server/)t step in translating human readable host names into IP addresses. They answer questions like: > “For `.com`, go ask these TLD name servers.” --- ## 4\. Understanding `dig com NS` and TLD Name Servers Next layer: \-dig com NS This asks: > “Which name servers are responsible for the `.com` domain?” ### What happens here? * Root servers point us to `.com` TLD servers * TLD servers manage **all** `.com` domains * They don’t store IP addresses of websites * They only know **who the authoritative servers are** ### Key idea: **TLD servers are directory managers for domains under them** They say: > “For [`google.com`](http://google.com), ask these authoritative name servers.” --- ## 5\. Understanding `dig` [`google.com`](http://google.com) `NS` and Authoritative Name Servers Now we query the domain itself: \-dig [google.com](http://google.com) NS This returns **authoritative name servers** for [`google.com`](http://google.com). ### What are authoritative name servers? * They store **actual DNS records** * A, AAAA, MX, CNAME, etc. * They give the **final answer** For example: * [`google.com`](http://google.com) `→ 142.250.x.x` ### Why NS records matter NS (Name Server) records define: * **Who controls the domain’s DNS** * **Where the final truth lives** Without correct NS records, DNS resolution breaks. --- ## 6\. Understanding `dig` [`google.com`](http://google.com) and the Full DNS Resolution Flow Now let’s do the full query: \-dig [google.com](http://google.com) This returns an **A record** (IPv4 address). But here’s the important part: ### `dig` vs browser behavior * `dig` (by default) asks a **recursive resolver** * The resolver performs all steps internally: 1. Ask root servers 2. Ask TLD servers 3. Ask authoritative servers 4. Cache the result --- ## 7\. How Recursive Resolvers Work Behind the Scenes Recursive resolvers (like those run by ISPs or public DNS services) are the **real workers**. They: * Perform the entire DNS lookup chain * Cache results for performance * Reduce load on root and TLD servers ### Why caching matters * Faster browsing * Lower latency * Massive scalability of the internet Without recursive caching, DNS would be slow and overloaded. ![Difference Between Recursive DNS & Authoritative DNS - Cisco ...](https://cdn.umbrella.marketops.umbrella.com/wp-content/uploads/2020/06/16092413/What-is-the-difference-between-Authoritative-and-Recursive-DNS-Nameservers_Cisco-Umbrella-blog_DNS-server-diagram.jpg align="left") --- ## 8\. Connecting `dig` [`google.com`](http://google.com) to Real-World Browser Requests When you open a browser and type: \-[https://google.com](https://google.com) This is what happens: 1. Browser asks OS for IP 2. OS asks recursive DNS resolver 3. Resolver returns IP (often from cache) 4. Browser opens TCP connection to IP 5. HTTPS request is sent 6. Google responds with the webpage DNS is the **first and mandatory step** before any HTTP or HTTPS communication. --- ## Conclusion : DNS is a **distributed, hierarchical, and highly scalable system**. * Root servers → entry points * TLD servers → domain directories * Authoritative servers → source of truth * Recursive resolvers → performance backbone Using `dig` helps us **see the layers clearly**, instead of treating DNS as a black box. This understanding is extremely useful when working with backend systems, cloud deployments, load balancers, CDNs, and production debugging.