# How DNS Resolution Works
## **What is DNS and why name resolution exists**
The [**Domain Name System (DNS)**](https://www.fortinet.com/resources/cyberglossary/what-is-dns) is a distributed, hierarchical database that translates human-readable domain names (e.g., `example.com`) into machine-readable numerical IP addresses (e.g., `192.0.2.1`). It acts as the internet's "phonebook," enabling browser communication with servers without requiring users to memorize complex IP addresses.
**Why Name Resolution Exists:**
* **Human Usability:** People remember names, while machines require IP addresses to identify and locate devices on the internet.
* **Decentralization & Flexibility:** It allows domain names to remain the same even if the underlying physical server (and its IP address) changes.
* **Efficiency & Performance:** [**DNS caching**](https://www.geeksforgeeks.org/computer-networks/domain-name-system-dns-in-application-layer/) stores previous queries, accelerating site access.
* **Traffic Management:** DNS helps direct users to the closest or most available server.
**Key Components & Process:**
1. **Query:** A user types a URL (e.g., `www.google.com`).
2. **Resolution:** [**Recursive DNS servers**](https://www.fortinet.com/uk/resources/cyberglossary/what-is-dns) search through root, TLD, and authoritative servers to find the mapping.
3. **Result:** The IP address is returned, enabling the browser to load the site.
Without name resolution, accessing websites would require entering numerical IP addresses for every resource, making navigation inefficient.
## **What is the ** `dig` ** command and when it is used**
`dig` stands for **Domain Information Groper**.
It is a **command-line tool** used to **query DNS servers and inspect DNS records**.
In simple words:
👉 `dig` helps you check how DNS is working for a domain.
---
### 🔍 What `dig` is used for
#### 1️⃣ Checking DNS records
You can fetch:**A / AAAA** (IP addresses)
* **MX** (mail servers)
* **NS** (name servers)
* **TXT** (SPF, verification, etc.)
* **CNAME** (aliases)
Example:
```plaintext
dig google.com
dig google.com MX
dig google.com TXT
```
---
#### 2️⃣ Debugging DNS problems
Used when:
* Website not opening
* Email not being delivered
* DNS changes not reflecting
* Verifying SPF / DKIM / DMARC
---
#### 3️⃣ Checking DNS propagation
After changing DNS records, `dig` helps confirm:
* Which servers have updated records
* Whether changes are live
---
#### 4️⃣ Seeing authoritative answers
`dig` shows:
* Which DNS server answered
* TTL values
* Whether the response is authoritative
---
### 🔁 How `dig` works (simple)
1. Sends a DNS query to a server
2. Receives DNS response
3. Displays detailed output
---
### 🧠 Simple analogy
* `dig` = asking a DNS server directly
* Browser = asking politely but hiding details
---
### 📌 Common example
```plaintext
dig example.com A
```
👉 Shows the IPv4 address of [`example.com`](http://example.com)
---
## **Understanding ** `dig . NS` ** and root name servers**
Understanding `dig`, `.NS` (Name Server records), and Root Name Servers is crucial for diagnosing DNS issues and understanding how the internet translates domain names into IP addresses. The `dig` (Domain Information Groper) command is a versatile tool for querying DNS servers, and using it to query root servers allows you to witness the very beginning of the DNS resolution chain.
Here is a detailed breakdown of these components.
**1\. Root Name Servers (.)**
Root servers are the top level of the Domain Name System (DNS) hierarchy, responsible for directing traffic to the correct Top Level Domain (TLD) servers (e.g., .com, .net, .org).
* **13 Logical Servers:** There are 13 named root servers (a.root-servers.net through m.root-servers.net).
* **Anycast Technology:** Despite having only 13 IP addresses, there are hundreds of physical servers (instances) worldwide that use Anycast to handle queries, making the system fast and robust.
* **Role:** When a recursive resolver (like your ISP or Google's 8.8.8.8) does not know the IP address for a domain, it queries a root server to find which TLD server manages the extension (e.g., finding the .com servers for [`google.com`](https://www.google.com/)).
* **Operation:** The root zone is managed by IANA (part of ICANN) and operated by 12 different organizations.
**2\. Name Server (NS) Records**
NS records identify which DNS servers are authoritative for a domain—meaning they store the actual DNS records (A, AAAA, MX).
* **Delegation:** NS records are used to delegate a domain to specific name servers, such as those provided by a domain registrar or a web host.
* **Hierarchy:** The root zone (`.`) contains NS records for all TLDs. TLD servers (`.com`) contain NS records for individual domains ([`example.com`](https://example.com/)).
**3\. Using** `dig` to Investigate
`dig` is an command-line utility used to troubleshoot DNS problems. Here are key commands to understand root servers and NS records:
* `dig . NS` (Query Root Servers):
This command asks for the NS records for the root zone (represented by the dot `.`). The output lists the 13 authorized root servers.**bash**
```plaintext
dig . NS
```
* `dig @a.root-servers.net example.com` (Querying a Root Server Directly):
This asks the "A" root server for the IP address of `example.com`. The root server will not give the final IP but will return a list of TLD servers (e.g., `.com` servers) that can answer the query.
* `dig +trace example.com` (Following the Chain):
This traces the delegation path from the root servers down to the authoritative servers, showing you exactly how the final answer is found.**bash**
```plaintext
dig +trace
```
**bash**
```plaintext
example.com
```
**bash**
* `dig example.com NS` (Querying NS Records):
This queries for the Name Server (NS) records of a specific domain to see which authoritative servers hold its records.
**Key Takeaways**
* **Root Hints:** Every recursive resolver has a "root hints" file that lists the IP addresses of the 13 root servers, allowing them to start the lookup process.
* **Authoritative vs. Recursive:** Root servers are NOT the final answer; they are pointers. The **Authoritative Name Server** is the final stop that holds the actual IP address.
* **Troubleshooting:** `dig +trace` is the best way to see where a DNS delegation breaks down.
## **Understanding ** `dig com NS` ** and TLD name servers**
When you want to know **who is responsible for a domain** or how DNS works step by step, the `dig` command is extremely useful.
---
### 1️⃣ NS Records (Name Servers)
**NS records** specify the **authoritative name servers** for a domain.
These servers **hold the actual DNS records** (A, AAAA, MX, TXT, etc.) for that domain.
Example:
```plaintext
dig example.com NS
```
Output might show:
```plaintext
example.com. 172800 IN NS ns1.hostingprovider.com.
example.com. 172800 IN NS ns2.hostingprovider.com.
```
This means:
* `ns1` and `ns2` are responsible for answering queries about [`example.com`](http://example.com).
---
### 2️⃣ How TLD Name Servers Work
**TLD (Top-Level Domain) servers** manage domains under extensions like `.com`, `.org`, `.net`.
#### Step-by-step name resolution:
1. Browser asks **root DNS server**:
*“Who manages* [`example.com`](http://example.com)?”
2. Root server points to **TLD server** for `.com`
3. TLD server points to **authoritative NS server** for [`example.com`](http://example.com)
4. Authoritative server returns the final IP (A / AAAA record)
---
### 3️⃣ Using `dig` to Check TLD Servers
You can query the TLD server directly:
```plaintext
dig NS example.com @a.gtld-servers.net
```
* `@`[`a.gtld-servers.net`](http://a.gtld-servers.net) → a `.com` TLD server
* Shows the authoritative NS servers for [`example.com`](http://example.com)
This helps **debug DNS issues** and understand **how the chain of DNS resolution works**.
---
### 4️⃣ Why This Matters
* Ensures your domain is pointing to the correct **authoritative servers**
* Helps verify **DNS propagation**
* Useful for **troubleshooting email or website issues**
---
### Simple Analogy
* Root server = main directory
* TLD server = `.com` office
* NS server = local branch responsible for [`example.com`](http://example.com)
## **Understanding ** `dig` [`google.com`](http://google.com) `NS` ** and authoritative name servers**
The `dig` [`google.com`](http://google.com) `NS` command queries DNS resolvers to list the authoritative name servers responsible for [google.com](http://google.com). It identifies which servers hold the final, official mapping of domain names to IP addresses. Running this command typically returns Google's official DNS servers (e.g., [`ns1.google.com`](http://ns1.google.com)), which are authoritative for their own domain.
**Understanding** `dig` for Name Servers (NS)
* `dig` [`google.com`](http://google.com) `NS`: This commands your default resolver to find the Name Server (NS) records for [`google.com`](http://google.com). The answer section will list the servers authorized to provide information about that domain.
* `dig @8.8.8.8` [`google.com`](http://google.com) `NS`: This forces `dig` to use Google’s public DNS resolver (`8.8.8.8`) to perform the query, which is useful for checking how external, public servers see your records.
* `dig +trace` [`google.com`](http://google.com) `NS`: This traces the query from the root servers down to the authoritative name servers, showing the exact delegation path.
**Key Concepts**
* **Authoritative Name Servers (ANS)**: These are the final authority for a domain's IP address. They contain the actual zone files (A, AAAA, MX records).
* **Authoritative vs. Recursive**: Unlike recursive resolvers (like `8.8.8.8` or ISP servers) that *find* information, authoritative servers *know* the information.
* **NS Record**: A type of DNS record that delegates a DNS zone to use specific authoritative name servers.
**Example Output Breakdown**
Running `dig` [`google.com`](http://google.com) `NS` will show an **AUTHORITY SECTION** or **ANSWER SECTION** (depending on the server queried) listing servers like:
* [`ns1.google.com`](http://ns1.google.com)
* [`ns2.google.com`](http://ns2.google.com)
* [`ns3.google.com`](http://ns3.google.com)
* [`ns4.google.com`](http://ns4.google.com)
These are the servers Google maintains to ensure their domain resolves correctly globally.
## **Understanding ** `dig` [`google.com`](http://google.com) ** and the full DNS resolution flow**
When you type [`google.com`](http://google.com) in your browser, your computer doesn’t automatically know the IP address. It needs to **resolve the domain name into an IP**. The `dig` command is a tool that lets you **see how DNS resolves a domain**.
---
### 1️⃣ Basic `dig` Command
```plaintext
dig google.com
```
* By default, this queries the **A record** (IPv4 address) of [`google.com`](http://google.com).
* Output shows:
* The **IP address** of the website
* The **DNS server** that answered
* **TTL (time to live)**
* Other metadata
Example output snippet:
```plaintext
;; ANSWER SECTION:
google.com. 299 IN A 142.250.190.14
```
This tells you the IPv4 address of Google.
---
### 2️⃣ The Full DNS Resolution Flow
DNS resolution happens in multiple steps:
#### **Step 1: Check local cache**
* Your computer first checks if it already knows the IP in its **local DNS cache**.
* If yes → skip to connecting to the server.
#### **Step 2: Query the recursive resolver**
* If not cached, the request goes to your **ISP’s recursive DNS server** (or public DNS like 8.8.8.8).
* Recursive server handles the query **step by step**.
#### **Step 3: Ask the root name server**
* Root server doesn’t know the exact IP, but it knows **TLD servers** for `.com`, `.org`, `.net`.
* Response points to the `.com` TLD servers.
#### **Step 4: Ask the TLD server**
* TLD server knows which **authoritative name servers** handle [`google.com`](http://google.com).
* Response points to Google’s **NS servers** (like [`ns1.google.com`](http://ns1.google.com), [`ns2.google.com`](http://ns2.google.com)).
#### **Step 5: Ask the authoritative NS server**
* The recursive server queries Google’s authoritative NS.
* It returns the final **A record** (IP address).
#### **Step 6: Response to your computer**
* Your computer receives the IP: `142.250.190.14`
* Browser connects to that IP and loads Google.
---
### 3️⃣ Visual Flow (Simple)
```plaintext
Your Computer
│
▼
Local Cache → if not found
│
▼
Recursive Resolver (ISP DNS)
│
▼
Root Name Server
│
▼
TLD Server (.com)
│
▼
Authoritative NS (google.com)
│
▼
IP Address → Your Computer → Browser connects
```
---
### 4️⃣ Using `dig` to See Each Step
* Check A record:
```plaintext
dig google.com
```
* Check NS records:
```plaintext
dig google.com NS
```
* Query specific DNS server:
```plaintext
dig google.com @8.8.8.8
```
* Query TLD server:
```plaintext
dig google.com NS @a.gtld-servers.net
```
---
### Key Points
* DNS works **hierarchically**: root → TLD → authoritative NS → record
* Recursive resolver does the **heavy lifting** for your computer
* `dig` lets you **see each step** and troubleshoot DNS
---