# How DNS Resolution Works: From Domain Name to IP Address ## Introduction: DNS as the Internet’s Phonebook When you type [`google.com`](http://google.com) in your browser, your computer does not understand that name. Computers only understand numbers called **IP addresses**, like `142.250.190.14`. Humans like **names**. Computers need **numbers**. DNS exists to connect the two. **DNS (Domain Name System)** works like the internet’s phonebook. Just like a phonebook maps a person’s name to a phone number, DNS maps a website name to its IP address. Without DNS, you would have to remember numbers for every website you visit. Every time you open a website, DNS quietly finds the correct IP address so your request reaches the right server. This process is called **name resolution**, and it happens automatically in the background. In this blog, we’ll break down how DNS resolution works step by step, using the `dig` command to see what really happens when you look up [`google.com`](http://google.com). ## Why Name Resolution Exists (The Problem DNS Solves) Computers do not understand website names. They only understand **IP addresses**, which are numbers. Humans, on the other hand, cannot easily remember numbers. This creates a problem: * Humans want to use names like [`google.com`](http://google.com) * Computers need numbers like `142.250.190.14` **Name resolution** exists to fix this problem. DNS translates domain names into IP addresses so both humans and computers can work together. DNS also adds flexibility. A website’s IP address can change, but the domain name can stay the same. Users never notice the change. Without DNS, using the internet would be slow, confusing, and painful. ## What Is the `dig` Command and Why Engineers Use It `dig` is a simple command-line tool used to **check DNS records**. Browsers hide DNS details. `dig` shows them. With `dig`, you can: * Ask DNS questions directly * See which servers answer * Understand how name resolution works step by step Engineers use `dig` to: * Debug DNS issues * Learn how DNS is structured * Trace how a domain is resolved In this blog, we’ll use `dig` not for debugging, but to **see DNS layers clearly**—from root servers to the final IP address. ## Understanding `dig . NS` — Root Name Servers The dot (`.`) means the **root of DNS**. It is the starting point of every DNS lookup. When you run: ```bash dig . NS ``` you are asking: **“Who controls the top of the DNS system?”** The answer is a list of **root name servers**. Root servers do **not** know IP addresses for websites. Their only job is to tell you: * Which servers handle `.com` * Which handle `.org` * Which handle `.net` Think of root servers as a **directory of directories**. They point you to the next level, not the final answer. This is the first step in DNS resolution. ## Understanding `dig com NS` — TLD Name Servers After the root, the next level is the **TLD** (Top-Level Domain). For [`google.com`](http://google.com), the TLD is `.com`. When you run: ```bash dig com NS ``` you are asking: **“Who manages all .com domains?”** The answer is a list of **.com name servers**. These servers do **not** know the IP address of [`google.com`](http://google.com). Their job is only to say: * which servers are responsible for [`google.com`](http://google.com) Think of TLD servers as a **middle layer**. They guide you closer to the final owner. This is the second step in DNS resolution. ## Understanding `dig` [`google.com`](http://google.com) `NS` — Authoritative Name Servers Now we reach the **authoritative** level. When you run: ```bash dig google.com NS ``` you are asking: **“Who is responsible for** [**google.com**](http://google.com)**?”** The answer is a list of **authoritative name servers**. These servers are owned by Google (or its DNS provider). They store the **real DNS records** for [`google.com`](http://google.com). Authoritative servers know: * IP addresses * mail servers * other DNS records This is the last stop before getting the final answer. ## Understanding `dig` [`google.com`](http://google.com) — Full DNS Resolution Flow Now we ask DNS the **final question**. When you run: ```bash dig google.com ``` you are asking: **“What is the IP address of** [**google.com**](http://google.com)**?”** Behind the scenes, DNS follows these steps: 1. Ask the **root** servers 2. Go to the **.com** TLD servers 3. Reach the **authoritative** servers 4. Get the **IP address** `dig` may show only the final answer, but this full path happens every time. This layered process makes DNS: * fast * reliable * scalable This is how a name becomes an IP address. ## How Recursive Resolvers Do This for Your Browser Your browser does **not** talk to root or TLD servers directly. It asks a **recursive resolver** (usually from your ISP or DNS provider). The resolver: * talks to root servers * then TLD servers * then authoritative servers * gets the IP address * sends it back to your browser Your browser only sees the **final IP**, not the steps. Resolvers also **cache** results. This makes future requests faster. DNS feels instant because resolvers do the hard work for you. ## Connecting DNS Resolution to a Real Browser Request When you type [`google.com`](http://google.com) in your browser, DNS is the **first step**. The browser: 1. asks the recursive resolver for the IP 2. gets the IP address 3. opens a connection to that IP 4. sends the HTTP request Without DNS, the browser would not know **where** to send the request. DNS always runs **before** HTTP, HTTPS, or APIs. So every page load starts with DNS—even if you never notice it. ## Wrap-up: DNS Resolution as a Layered System DNS works in **layers**, not in one step. * Root servers point to TLD servers * TLD servers point to authoritative servers * Authoritative servers give the final answer Each layer has one clear job. This makes DNS simple, fast, and scalable. Tools like `dig` help us **see** this process clearly. Once you understand this flow, DNS stops feeling magical and starts feeling like a clean system design.