# How DNS Resolution Works (Step by Step) ## DNS: The internet’s phonebook (quick recap) When we type a website like: ```plaintext google.com ``` into a browser, the browser doesn’t know where that site is hosted. Computers don’t understand names — they understand **IP addresses**. So DNS exists to answer one basic question: 👉 **“What IP address belongs to this domain name?”** DNS works like the **phonebook of the internet**: * Domain name → IP address * Human-friendly → machine-friendly But how does DNS *actually* find that answer? That’s what DNS resolution is about. --- ## What is DNS resolution? **DNS resolution** is the step-by-step process of finding the IP address for a domain name. It doesn’t happen in one jump. It happens in **layers**: ```plaintext Root servers ↓ TLD servers (.com, .org, .in) ↓ Authoritative name servers ↓ Final IP address ``` To understand this clearly, we’ll use a tool called **dig**. --- ## What is the `dig` command? **dig** stands for **Domain Information Groper**. It is a command-line tool used to: * inspect DNS records * debug DNS issues * understand how DNS resolution works internally Browsers do DNS lookups automatically. `dig` lets us **see each step manually**. Think of dig as: > “Show me how DNS finds the answer.” --- ## Understanding `dig . NS` — Root name servers Let’s start from the **top of the DNS hierarchy**. ```plaintext dig . NS ``` ### What does this mean? * `.` represents the **DNS root** * `NS` asks: *Which name servers are responsible here?* ### What we learn This command returns the **root name servers**. Root servers don’t know IP addresses for websites. They only know: > “Who handles `.com`, `.org`, `.net`, etc.” They are the **starting point** of every DNS lookup. --- ## Understanding `dig com NS` — TLD name servers Now let’s ask about the `.com` domain. ```plaintext dig com NS ``` ### What does this mean? * We are asking: *Who manages all* `.com` domains? ### What we learn This returns **TLD (Top-Level Domain) name servers** for `.com`. These servers don’t know Google’s IP yet. They only know: > “Which name servers are responsible for each `.com` domain?” So they will point us to the **authoritative name servers**. --- ## Understanding `dig` [`google.com`](http://google.com) `NS` — Authoritative name servers Next step: ```plaintext dig google.com NS ``` ### What does this mean? * We are asking: *Which servers are authoritative for* [*google.com*](http://google.com)*?* ### What we learn This returns Google’s **authoritative name servers**. These servers: * hold the real DNS records * know the actual IP addresses * are the **final authority** for the domain At this point, DNS knows **where to ask for the final answer**. --- ## Understanding `dig` [`google.com`](http://google.com) — Full DNS resolution Now the final step: ```plaintext dig google.com ``` ### What happens here? * dig follows the DNS chain * queries the authoritative name servers * retrieves the **A / AAAA records** ### Result We finally get: * IP address(es) for [`google.com`](http://google.com) * TTL (cache time) * record type (A or AAAA) This is the same information a browser uses to connect to Google’s servers. --- ## DNS resolution flow (putting it all together) When a browser tries to open [`google.com`](http://google.com), the flow looks like this: 1. Ask a **recursive resolver** (ISP / local DNS) 2. Resolver asks **root servers** 3. Root points to **.com TLD servers** 4. TLD points to **Google’s authoritative servers** 5. Authoritative server returns **IP address** 6. Browser connects to the server The browser never talks directly to all these servers. The **recursive resolver** does this work behind the scenes. --- ## Why NS records matter in DNS resolution **NS (Name Server) records** define: * who is responsible for a domain * where DNS queries should be sent next Without NS records: * DNS resolution cannot move forward * the chain breaks Every layer in DNS resolution depends on NS records to continue. --- ## How this connects to real browser requests When we open a website: * DNS resolution happens first * IP address is resolved * HTTP request is sent next If DNS fails: * the browser never reaches the server * we see errors like *“DNS\_PROBE\_FINISHED\_NXDOMAIN”* Understanding DNS resolution helps us debug: * website not loading * incorrect hosting * email delivery issues --- ## Visual mental model ![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://miro.medium.com/1%2AgoSb1oow5UBNF3KkzvOX8A.png](https://miro.medium.com/1%2AgoSb1oow5UBNF3KkzvOX8A.png align="left") ![https://www.researchgate.net/publication/330006223/figure/fig1/AS%3A709642057445377%401546203259697/Domain-resolution-process-with-a-recursive-resolver.ppm](https://images.openai.com/static-rsc-1/eMoys5SJkXyMzPrVBY5Rm30PUgagtq29J-cPzby1s-3HpokSFuB4a8yp1h6lFUjjIK5fE4bOtVPImErYgPziL18lmQkwl14G1wx2R3mplhsVy8gY2HIlS205ceJAgNDGSlq2eM4qtt-kA9tQShINgA align="left") 4 --- ## Final thoughts DNS resolution may look complex, but it’s actually very structured. Key takeaways: * DNS works in **layers** * Each layer only knows **one level down** * `dig` lets us inspect each stage * Browsers rely on recursive resolvers to do this work Once we understand DNS resolution: * system design concepts feel clearer * backend debugging becomes easier * networking stops feeling mysterious And that’s why DNS resolution is a **core concept every web developer should understand** 🚀