# How DNS Resolution Works ## **What is DNS?** **DNS** stands for **Domain Name System**. It’s like a **phone book for the internet** that **translates human-friendly website names into numbers computers understand**. * Humans use names like [**www.google.com**](http://www.google.com) because they’re easy to remember. * Computers and networks use **IP addresses** (like `192.0.2.1`) to actually send data. * DNS helps convert a name → IP address so your browser knows **where to go**. Without DNS, you’d have to remember and type long number strings every time you want to visit a website. Think of DNS like a **global directory** that looks up names and finds matching addresses behind the scenes. --- ## **What is name resolution?** **Name resolution** is the **process** of looking up and finding the **numeric IP address** that matches a name you give (like a domain name). * When you type a domain into your browser, the system checks its cache or asks DNS servers for the matching IP. * That loop of asking and replying is called **name resolution** or **DNS resolution**. ## **Why does name resolution exist?** There are two main reasons: ### **1\. Human convenience** It’s **much easier to remember words** than long numeric IP addresses. Imagine having to remember “173.194.39.78” instead of “[google.com](http://google.com)”! ### **2\. Computers need numbers** Computers and networks **don’t understand names**—they only work with **IP addresses** to send and receive data. Name resolution bridges that gap, so humans and computers both get what they need. ## **What is the** `dig` Command? `dig` stands for **“Domain Information Groper”** — it’s a **command-line tool** used to **ask DNS servers for information about domain names**. It performs **DNS lookups** and shows you detailed answers about records like IP addresses, mail servers, name servers, etc. **Why and When You Use** `dig` ### 1\. **Troubleshooting DNS Issues** If a website doesn’t resolve or email isn’t working, admins use `dig` to check whether the DNS records are correct and where the problem might lie. ### 2\. **Verifying DNS Records** It helps verify that DNS records (A, MX, CNAME, TXT, etc.) are set up properly after you configure them. ### 3\. **Checking DNS Propagation** After changing DNS settings, you can use `dig` to see if many different DNS servers are returning the new values. ### 4\. **Querying Specific DNS Servers** You can point `dig` at a specific DNS server—for instance Google’s (`@8.8.8.8`)—to compare results or test specific servers. ### 5\. **Learning & Debugging** Because its output shows all parts of a DNS response (QUESTION, ANSWER, AUTHORITY, etc.), it’s great for learning how DNS works under the hood. # Understanding `dig . NS` and root name servers ## **What** `dig . NS` Does * `dig` is a command-line tool that asks DNS servers questions and shows you the results. * `.` (dot) represents the **root of the DNS system** — the very top level of the global internet naming hierarchy. * `NS` means **Name Server records** — it asks, “which DNS servers are responsible for this zone?” ## **What are Root Name Servers?** * **Root name servers** are the **first stop** in DNS resolution. * They **don’t know the IP address of every website**, but they *do know* where to find the **Top-Level Domain (TLD) servers** (like `.com`, `.org`, `.net`, `.in`, etc.). * There are **13 named servers (a through m)**, but each name represents many servers distributed worldwide using **anycast** to make them fast and reliable. So root servers answer the question: **“Which servers handle the next level?”** (e.g., where to ask about `.com`) — not “what’s the IP of [google.com?”](http://google.com?%E2%80%9D) directly. # Understanding `dig com NS` and TLD name servers ## **1\. DNS Hierarchy Recap** DNS resolves domain names in **layers**, like stepping down a ladder: 1. **Root name servers** – the top of the system 2. **TLD name servers** – next level (e.g., `.com`, `.org`, `.net`) 3. **Authoritative name servers** – the servers that know the exact domain’s records (like [`google.com`](http://google.com)) ## **2\. What Does** `dig com NS` Do? When you run: ```bash dig com NS ``` you are asking: **“Who are the name servers responsible for the** `.com` top-level domain?” The output will list something like: ```plaintext com. IN NSa.gtld-servers.net. com. IN NSb.gtld-servers.net. ... ``` These are the **TLD name servers** for `.com`. ## **3\. What are TLD Name Servers?** **TLD name servers** are the servers that handle one specific **top-level domain** — in this case, `.com`. They don’t hold every website’s IP address, but they **know where to find the authoritative name servers** for domains under `.com` (like [`google.com`](http://google.com), [`example.com`](http://example.com)). So if you ask them: **“Where can I find the DNS authority for** [`example.com`](http://example.com)?” they point you to the **authoritative name servers** for that domain. # Understanding `dig` [`google.com`](http://google.com) `NS` and authoritative name servers ## **What** `dig` [`google.com`](http://google.com) `NS` Means When you run: ```bash dig google.com NS ``` you’re asking: **“Which name servers are responsible for the domain** [`google.com`](http://google.com)?” — that is, *which servers are authoritative for* [`google.com`](http://google.com). In the output you’ll typically see something like: ```plaintext google.com. IN NS ns1.google.com. google.com. IN NS ns2.google.com. google.com. IN NS ns3.google.com. google.com. IN NS ns4.google.com. ``` These are **Google’s own authoritative name servers** — the servers that *actually hold the DNS data* for the [`google.com`](http://google.com) domain. ## **What Are Authoritative Name Servers?** **Authoritative name servers** are the servers that **store the real DNS records** (- like IP addresses, mail servers, CNAMEs, etc. -) for a domain. They are the **“source of truth”** for that domain’s DNS data. ### Key points: These servers are **specifically set up by the domain owner** (Google in this case) to *answer queries about that domain*. They respond with **definitive DNS records** — not cached copies from elsewhere. When you query them directly (e.g., `dig @`[`ns1.google.com`](http://ns1.google.com) [`google.com`](http://google.com)), you’re asking the *original source* for the data. ## **1\. You Run** `dig` [`google.com`](http://google.com) When you run: ```bash dig google.com ``` you’re *asking DNS*: **“What is the IP address of** [`google.com`](http://google.com)?” This is similar to what your browser does before connecting to a website — it needs to turn the domain name into an IP address. However, DNS resolution isn’t done in a single step — it goes **through multiple layers**. --- ## **2\. What Actually Happens Behind the Scenes** Your computer *doesn’t ask all servers directly*. Instead, it sends the query to a **recursive resolver** (often provided by your ISP or a public DNS service like Google DNS). That resolver does the heavy lifting. ## **3\. DNS Resolution Flow (Step-by-Step)** ### **Step 1 — Recursive Resolver** Your local resolver receives the query and first checks if it already has the answer cached (from a recent lookup). If so, it can *skip the rest*. If not, it starts the full lookup. --- ### **Step 2 — Root Name Servers** The resolver asks a **root name server**: *“Where do I find information about domains like* [`google.com`](http://google.com)?” But root servers don’t know the IP — they only point to the right **TLD (Top-Level Domain) servers** (like `.com`). --- ### **Step 3 — TLD Servers (.com)** The root servers reply with the addresses of the `.com` TLD name servers. Then the resolver asks one of those: *“Where can I find the authoritative DNS servers for* [`google.com`](http://google.com)?” The `.com` TLD servers then point the resolver to **Google’s authoritative name servers**. ### **Step 4 — Authoritative Name Servers** Now the resolver asks Google’s authoritative name server: *“What is the IP address for* [`google.com`](http://google.com)?” These servers **actually hold the DNS records** (like the A record that gives IP addresses). They reply with the final answer — the IP address. --- ### **Step 5 — Back to You** The recursive resolver gets the IP address and returns it to your system. Now your computer knows the IP of [`google.com`](http://google.com) and can start connecting to it.