# How DNS resolution works?

# What is DNS and why name resolution exists?

* DNS is the internet’s phonebook: it maps human-friendly names (like [google.com](http://google.com)) to IP addresses that machines use.
    
* Name resolution lets users remember names instead of IPs, enables service abstraction (moving servers without changing the name), and supports load balancing, redundancy, and geo-routing.
    

# What is the dig command and when it is used?

* dig (Domain Information Groper) is a DNS diagnostic tool you run in a terminal.
    
* You use it to see which DNS servers answer for a name, which records they return, and to troubleshoot resolution, delegation, caching, and propagation.
    

# Understanding dig . NS and root name servers

* Command: dig . NS
    
* Purpose: Ask “Who are the root name servers?” The root zone (.) delegates authority to TLDs (.com, .org, .net, etc.).
    
* The answer shows a set of root servers (e.g., [a.root-servers.net](http://a.root-servers.net), [b.root-servers.net](http://b.root-servers.net)). These are globally distributed and any casted.
    

# Understanding dig com NS and TLD name servers

* Command: dig com NS
    
* Purpose: Ask the root, “Who is authoritative for .com?”
    
* The answer lists the TLD name servers for .com (e.g., [a.gtld-servers.net](http://a.gtld-servers.net), [b.gtld-servers.net](http://b.gtld-servers.net), etc.).
    
* This demonstrates the second layer: root → TLD.
    

# Understanding dig [google.com](http://google.com) NS and authoritative name servers

* Command: dig [google.com](http://google.com) NS
    
* Purpose: Ask the .com TLD, “Who is authoritative for [google.com](http://google.com)?”
    
* The answer lists [google.com](http://google.com)’s authoritative name servers (e.g., [ns1.google.com](http://ns1.google.com), [ns2.google.com](http://ns2.google.com), etc.).
    
* These NS records are the delegation to the zone that holds the actual records for [google.com](http://google.com) (A/AAAA, MX, etc.).
    

# Understanding dig [google.com](http://google.com) and the full DNS resolution flow

* Command: dig [google.com](http://google.com)
    
* Purpose: Resolve the final answer (e.g., A or AAAA records).
    
* Flow behind the scenes (recursive resolver’s perspective):
    
    1. Start at a root server to ask who handles .com (from dig . NS).
        
    2. Go to a .com TLD server to ask who handles [google.com](http://google.com) (from dig com NS).
        
    3. Go to [google.com](http://google.com)’s authoritative servers (from dig [google.com](http://google.com) NS) to ask for A/AAAA (from dig [google.com](http://google.com)).
        
    4. Return the IP(s) to the client, caching along the way to speed future lookups.
        
* The recursive resolver automates this chain; dig shows you each layer explicitly when you query step by step.
    
* In the browser: typing [google.com](http://google.com) triggers the resolver to do this chain (often hitting cache instead of all steps). The browser uses the returned IP to connect to the server.
    

# Why NS records matter at each step?

* Root NS records delegate to TLD servers.
    
* TLD NS records delegate to the domain’s authoritative servers.
    
* Authoritative NS records indicate where the “source of truth” for the domain’s zone lives.
    
* Correct NS delegation is essential for reachability; misconfigured NS leads to resolution failures.
    

# Practical/system-design takeaways

* DNS resolution is hierarchical: root → TLD → authoritative.
    
* Caching at recursive resolvers reduces load and latency.
    
* Any casted NS at root/TLD/authoritative improves resilience and performance.
    
* Using dig in this order (., TLD, domain NS, then full query) builds a clear mental model and helps isolate where a resolution problem is occurring.