# How DNS Resolution works ## **What is DNS and Why Does Name Resolution Exist?** DNS stands for Domain Name System. It acts as the intermediate layer between humans and machines (computers/servers). Humans prefer using words in languages like English, such as [google.com](http://google.com), [twitter.com](http://twitter.com), or [myawesomeblog.in](http://myawesomeblog.in). However, computers understand IP addresses (like 142.250.183.78) and ultimately operate in machine language (1s and 0s). On the internet, communication is essentially between computers. When you type [google.com](http://google.com) in your browser, your system doesn't directly understand it. This is where DNS comes in. DNS translates human-readable domain names (like [google.com](http://google.com)) into machine-readable IP addresses so your computer can connect to the correct server. A simple analogy is: * **DNS = Phonebook of the Internet** * It translates **human-readable names → machine-readable IPs** **How DNS Resolves an IP Address** The typical resolution path is: ```plaintext Root → TLD → Authoritative → IP ``` ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769374534936/e6fdcc53-8996-41c3-b760-90dcf764c065.png align="center") Before this process begins, your system and DNS resolver first check the **cache**: * If the IP is already cached (stored from a previous lookup), it’s returned immediately. * If not, the resolver starts from the beginning (root servers). **Simple Example** You type [`example.com`](http://example.com) in your browser: 1. The browser asks: “Do I already know the IP for [`example.com`](http://example.com)?” 2. If not, it asks the OS → the DNS resolver → which may ask root, then TLD, then authoritative servers. 3. Eventually, DNS returns something like `93.184.216.34`. 4. Your browser then connects to `93.184.216.34`. --- ## **What is the** `dig` **Command and When is it Used?** In normal English, **“dig”** means **to search for or uncover something**. In DNS, the `dig` command helps you **dig into DNS** to see what’s going on. You use `dig` to: * Inspect DNS records * Diagnose DNS configuration issues * Debug when a domain doesn’t resolve correctly * See **which servers** are answering **which questions** Common situations where `dig` is useful: * DNS is misconfigured * A domain doesn’t resolve * SSL / CDN issues * It works in production but not on your local machine Example: `dig` [`google.com`](http://google.com) This command provides detailed DNS information, including: * The answer section (IP addresses and other records) * Which server replied * How long it took * Additional technical details --- ## **Understanding** `dig . NS` **and Root Name Servers** When you run: `dig . NS` You’re asking: “Who are the **root DNS servers**?” **What This Means** * `.` = the **root zone** (similar to `/` in Linux representing the root directory) * `NS` = **Name Server** records **What Root Servers Do** Root servers: * **Do NOT know** the IPs for specific websites * They only know **where the TLD (Top-Level Domain) servers are** There are **13 logical root servers** ([`a.root-servers.net`](http://a.root-servers.net) … [`m.root-servers.net`](http://m.root-servers.net)) distributed globally using many physical machines. **Note:** Root servers don’t know the final answer (like the IP of [`google.com`](http://google.com)). They just know **which direction to send you next** (e.g., to `.com` TLD servers). --- ## **Understanding** `dig com NS` **and TLD Name Servers** When you run: `dig com NS` You’re asking: “Who manages **.com** domains?” **What TLD Servers Do** TLD (Top-Level Domain) servers: * Handle domains under a specific TLD: `.com`, `.org`, `.net`, `.in`, etc. * Know **which authoritative name servers** are responsible for each domain (like [`google.com`](http://google.com), [`facebook.com`](http://facebook.com)) * They still **do not know the final IP addresses** for individual websites. TLD servers say something like: “For [`google.com`](http://google.com), ask these authoritative name servers.” --- ## **Understanding** `dig` [`google.com`](http://google.com) `NS` **and Authoritative Name Servers** When you run: `dig` [`google.com`](http://google.com) `NS` You’re asking: “Who is **authoritative** for [`google.com`](http://google.com)?” **Authoritative Servers** Authoritative name servers: * Are usually **owned or controlled by the domain owner** (or their DNS provider) * Store the actual **DNS records** for the domain * Provide the **final, correct answers** for that domain Examples of records they store: * `A` records → IPv4 addresses * `AAAA` records → IPv6 addresses * `MX` records → Mail servers * `TXT` records → Text data (verification, SPF, etc.) --- ## **Understanding** `dig` [`google.com`](http://google.com) **and the Full DNS Resolution Flow** If you simply run: `dig` [`google.com`](http://google.com) You’re asking for **the actual DNS records** (like IP addresses) for [`google.com`](http://google.com). This is where the **“truth”** lives for that query: the final IP, like `142.250.x.x`. --- * Step-by-Step * **Browser** asks OS: ```plaintext Do we know google.com? ``` * **OS cache** checked If not found → * **Recursive Resolver** (ISP / Public DNS like 8.8.8.8) * Resolver asks **Root Server**: ```plaintext Where is .com? ``` * Root replies: ```plaintext Ask these .com TLD servers ``` * Resolver asks **.com TLD server**: ```plaintext Where is google.com? ``` * TLD replies: ```plaintext Ask these authoritative servers ``` * Resolver asks **Authoritative Server**: ```plaintext What is the IP of google.com? ``` * Authoritative replies: ```plaintext 142.250.x.x ``` * Resolver caches it and returns IP to browser * Browser connects to the server