<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[How DNS Resolution Works: A Deep Dive]]></title><description><![CDATA[How DNS Resolution Works: A Deep Dive]]></description><link>https://how-dns-resolution-works-a-deep-dive.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Wed, 24 Jun 2026 23:14:33 GMT</lastBuildDate><atom:link href="https://how-dns-resolution-works-a-deep-dive.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[How DNS Resolution Works: A Deep Dive]]></title><description><![CDATA[Have you ever wondered, when we search on a browser- Google.com, how it appears on our screen?? There is no magic behind the scenes; it's just a system that holds the addresses of every website, and that system's name is DNS (Domain Name System).
The...]]></description><link>https://how-dns-resolution-works-a-deep-dive.hashnode.dev/how-dns-resolution-works-a-deep-dive</link><guid isPermaLink="true">https://how-dns-resolution-works-a-deep-dive.hashnode.dev/how-dns-resolution-works-a-deep-dive</guid><category><![CDATA[ChaiCode]]></category><category><![CDATA[dns resolver]]></category><dc:creator><![CDATA[Vinny Madaan]]></dc:creator><pubDate>Thu, 22 Jan 2026 13:25:56 GMT</pubDate><enclosure url="https://cdn.hashnode.com/res/hashnode/image/upload/v1769086411709/1633b12f-a85d-437c-a82c-133caab318e0.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Have you ever wondered, when we search on a browser- Google.com, how it appears on our screen?? There is no magic behind the scenes; it's just a system that holds the addresses of every website, and that system's name is DNS (Domain Name System).</p>
<h3 id="heading-the-core-problem">The Core Problem</h3>
<p>Our computers only understand 0 and 1. When we search for google.com, computers don’t have any idea what is written here. To find the website, they need a unique identifier, and that is the IP address of the website, which is stored by DNS.</p>
<h2 id="heading-what-is-the-domain-name-system">What is the Domain Name System?</h2>
<ul>
<li><p>DNS holds the IP address of the website and maps the domain name to its authoritative servers, resolving the domain name by looking up these stored records.</p>
</li>
<li><p>In simple language, you can understand DNS like the internet’s phonebook.</p>
</li>
<li><p>DNS translates a domain name into an IP address, allowing browsers to access information on the Internet.</p>
</li>
<li><p>Without DNS, we need to remember IP’s which is next to impossible for humans, and then the internet becomes unusable for us.</p>
</li>
</ul>
<h2 id="heading-why-does-name-resolution-exist">Why does name resolution exist?</h2>
<ul>
<li><p>Name resolution is a process to find the IP address of a domain name, and the entire journey is known as DNS resolution.</p>
</li>
<li><p>It is important because without name resolution, we need to remember IPs manually.</p>
</li>
</ul>
<p>➡️ Now, let’s understand how DNS resolution works??</p>
<p><strong><em>Step:1 Browser</em></strong></p>
<ul>
<li><p>Searching: <code>https://google.com</code></p>
</li>
<li><p>Browsers don’t have any Ip itself, it asks the operating system - “Did you know the Ip of google.com?“</p>
</li>
</ul>
<p><strong><em>Step:2 OS</em></strong></p>
<ul>
<li><p>The operating system then checks in two places: <strong>Browser cache</strong> and the <strong>OS cache</strong>.</p>
</li>
<li><p>If it finds it passes to the browser; otherwise, it raises a request for DNS packets to the router.</p>
</li>
</ul>
<p><strong><em>Step:3 Router</em></strong></p>
<ul>
<li><p>It receives DNS packet requests and looks at the destination IP.</p>
</li>
<li><p>Forward packets to the ISP.</p>
</li>
</ul>
<p><strong><em>Step:4 ISP</em></strong></p>
<ul>
<li>ISP directs the request to its DNS resolver.</li>
</ul>
<p><strong><em>Step:5 DNS Resolver</em></strong></p>
<ul>
<li><p>It first checks its own cache</p>
</li>
<li><p>if not found:</p>
<ol>
<li><p>Ask the Root Server</p>
</li>
<li><p>then .com TLD server</p>
</li>
<li><p>Then Google’s authoritative server.</p>
</li>
</ol>
</li>
</ul>
<p><strong>➡️ After these steps, the IP is transferred back to the browser from the same path it came from.</strong></p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769087249792/a2220a64-604e-4ecd-ab60-25040049b4e9.png" alt class="image--center mx-auto" /></p>
<h2 id="heading-what-is-the-dig-command-and-when-it-is-used">What is the <code>dig</code> Command and when it is used?</h2>
<p>Let’s understand why we need this command, what the dig command is, and its working.</p>
<h3 id="heading-why-we-need-dig-command">Why we need <code>dig</code> Command?</h3>
<ul>
<li><p>We knew DNS works behind the scenes, and that’s why we never see,</p>
<ul>
<li><p>Which DNS server replied</p>
</li>
<li><p>Which record was used</p>
</li>
<li><p>Where the answer came from</p>
</li>
</ul>
</li>
<li><p>So, how does a developer see what DNS is actually doing??</p>
</li>
</ul>
<h3 id="heading-what-is-dig">What is <code>dig</code>?</h3>
<ul>
<li><p><code>dig</code> stands for <strong>Domain Information Groper.</strong></p>
</li>
<li><p><code>dig</code> is a command-line tool that lets you directly ask DNS servers questions and see their raw answers.</p>
</li>
</ul>
<p>You can ask things like:</p>
<ol>
<li><p>What is the IP of this domain?</p>
</li>
<li><p>Who is authoritative for this domain?</p>
</li>
<li><p>What are the name servers?</p>
</li>
<li><p>What DNS record exists?</p>
<p> ➡️Anything related to DNS, you can ask with <code>dig</code> command.</p>
</li>
</ol>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769067067556/e171dfcc-7c41-48c2-b8e4-782565174302.png" alt class="image--center mx-auto" /></p>
<h2 id="heading-dns-hierarchy-how-dns-servers-are-organized">DNS Hierarchy: How DNS Servers Are Organized</h2>
<p>DNS is a hierarchical naming system that translates human-readable domain names into IP addresses.</p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769088305436/d42d997b-1a1f-4c35-92cf-adf3c918f0e5.png" alt class="image--center mx-auto" /></p>
<h2 id="heading-understanding-digns-and-root-name-servers">Understanding <code>dig.NS</code> and Root Name Servers</h2>
<p><strong>What Does</strong> <code>.</code> <strong>Mean in DNS?</strong></p>
<p>In DNS:</p>
<p><code>. = ROOT</code></p>
<ul>
<li><p>The dot (<code>.</code>) represents the <strong>root of the DNS hierarchy</strong></p>
</li>
<li><p>Every domain ends with a dot (it’s just hidden)</p>
</li>
<li><p>Example: <code>google.com.</code></p>
</li>
<li><p>The last dot means: “Start at the root of DNS.”</p>
</li>
</ul>
<p><strong>What Are Root Name Servers?</strong></p>
<ul>
<li><p>Root name servers are the <strong>starting point</strong> of DNS resolution.</p>
</li>
<li><p>They sit at the <strong>top of the DNS hierarchy</strong></p>
</li>
<li><p>They know <strong>where TLD servers are</strong></p>
</li>
<li><p>They do <strong>NOT</strong> know the IPs of websites</p>
</li>
<li><p>They only answer: “Which servers handle <code>.com</code>, <code>.org</code>, <code>.net</code>, etc.?”</p>
</li>
</ul>
<p><strong>Run This Command:</strong></p>
<pre><code class="lang-bash">dig . NS
</code></pre>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769085057676/2d187b98-903d-47e9-bf05-b84ba0fdcad8.png" alt class="image--center mx-auto" /></p>
<pre><code class="lang-bash">dig . NS @1.1.1.1
</code></pre>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769085137279/fd7bd9c3-2667-46ee-9cf8-ffdfe297a9dc.png" alt class="image--center mx-auto" /></p>
<ul>
<li><p>These are Root DNS servers</p>
</li>
<li><p>Managed by different organizations</p>
</li>
<li><p>Globally distributed</p>
</li>
<li><p>There are <strong>13 logical root servers</strong> (A–M).</p>
</li>
</ul>
<p>When running <code>dig . NS</code>, the query may fail if the system is using a home router as its DNS server. Consumer routers typically act as DNS forwarders and may not support root-level DNS queries, resulting in a <code>SERVFAIL</code> response. Querying a public DNS resolver such as Google (<code>8.8.8.8</code>) or Cloudflare (<code>1.1.1.1</code>) bypasses this limitation and returns the root name server records correctly.</p>
<h2 id="heading-understanding-dig-com-ns-and-tld-name-servers">Understanding <code>dig com NS</code> and TLD Name Servers</h2>
<h3 id="heading-tld-top-level-domain">TLD = Top-Level Domain</h3>
<p>Examples:</p>
<ul>
<li><p><code>.com</code></p>
</li>
<li><p><code>.org</code></p>
</li>
<li><p><code>.net</code></p>
</li>
<li><p><code>.in</code></p>
</li>
</ul>
<blockquote>
<p>TLD name servers know <strong>which authoritative servers are responsible for a domain</strong>.</p>
<p>“For <a target="_blank" href="http://google.com"><code>google.com</code></a>, ask these authoritative servers.”</p>
</blockquote>
<p><strong>Run This Command</strong></p>
<pre><code class="lang-bash">dig com NS @8.8.8.8
</code></pre>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769085515317/2cedbb88-9526-416b-9b0d-902739d8ca4b.png" alt class="image--center mx-auto" /></p>
<p>These are:</p>
<ul>
<li><p><code>.com</code> TLD name servers</p>
</li>
<li><p>Operated under ICANN</p>
</li>
<li><p>Globally distributed</p>
</li>
</ul>
<p>These servers handle <strong>ALL</strong> <code>.com</code> domains:</p>
<ul>
<li><p><a target="_blank" href="http://google.com">google.com</a></p>
</li>
<li><p><a target="_blank" href="http://amazon.com">amazon.com</a></p>
</li>
<li><p><a target="_blank" href="http://facebook.com">facebook.com</a></p>
</li>
<li><p>millions more</p>
</li>
</ul>
<h2 id="heading-understanding-dig-googlecomhttpgooglecom-ns">Understanding <code>dig</code> <a target="_blank" href="http://google.com"><code>google.com</code></a> <code>NS</code></h2>
<p><strong>Authoritative Name Server</strong></p>
<blockquote>
<p>An authoritative name server is the <strong>source of truth</strong> for a domain.</p>
</blockquote>
<ul>
<li><p>It is controlled by the domain owner</p>
</li>
<li><p>Stores actual DNS records:</p>
<ul>
<li><p>A</p>
</li>
<li><p>AAAA</p>
</li>
<li><p>MX</p>
</li>
<li><p>CNAME</p>
</li>
</ul>
</li>
<li><p>Gives <strong>final answers</strong>, not directions</p>
</li>
</ul>
<p><strong>Run This Command:</strong></p>
<pre><code class="lang-bash">dig google.com NS @8.8.8.8
</code></pre>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769085805500/43d1aa95-9d59-4344-a139-7705688eb1fd.png" alt class="image--center mx-auto" /></p>
<p>These servers:</p>
<ul>
<li><p>Are owned by Google</p>
</li>
<li><p>Answer all DNS questions for <a target="_blank" href="http://google.com"><code>google.com</code></a></p>
</li>
<li><p>Store the actual records</p>
</li>
</ul>
<p>Authoritative name servers are responsible for storing and serving the actual DNS records of a domain. Unlike root and TLD servers, authoritative servers provide final answers to DNS queries, including IP address mappings. These servers are operated by the domain owner or their DNS provider.</p>
<h2 id="heading-understanding-dig-googlecomhttpgooglecom">Understanding <code>dig</code> <a target="_blank" href="http://google.com"><code>google.com</code></a></h2>
<p><strong>When you run:</strong></p>
<pre><code class="lang-bash">dig google.com
</code></pre>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1769086003902/4a8dfd6f-c983-48b5-8baa-3b3f4b125df1.png" alt class="image--center mx-auto" /></p>
<p>You are asking:</p>
<blockquote>
<p>“Show me the final DNS answer for <a target="_blank" href="http://google.com"><code>google.com</code></a>, after the entire DNS hierarchy has done its job.”</p>
</blockquote>
<p>DNS resolution is not a single lookup but a structured, hierarchical discovery process. When a user enters a domain name such as <a target="_blank" href="http://google.com"><code>google.com</code></a>The browser relies on a DNS resolver to navigate the global DNS hierarchy, starting from the root name servers, moving through the appropriate top-level domain (TLD) servers, and finally reaching the authoritative name servers that store the actual DNS records.</p>
<p>Tools like <code>dig</code> allow us to observe this otherwise invisible process. By querying root servers (<code>dig . NS</code>), TLD servers (<code>dig com NS</code>), and authoritative servers (<code>dig</code> <a target="_blank" href="http://google.com"><code>google.com</code></a> <code>NS</code>) We can see how responsibility is distributed across different layers of DNS. The final query (<code>dig</code> <a target="_blank" href="http://google.com"><code>google.com</code></a>) demonstrates the outcome of this entire flow: the IP address that browsers use to establish network connections.</p>
<p>This hierarchical design makes DNS scalable, reliable, and fast, even at the scale of the global internet. Understanding DNS resolution not only demystifies how browsers locate websites but also provides a strong foundation for deeper topics in networking, system design, and web infrastructure.</p>
<p>Once you understand DNS, the internet stops feeling like magic and starts feeling like engineering.</p>
<h3 id="heading-feedback-request"><mark>Feedback Request:</mark></h3>
<p><em>“I’m a beginner learning computer science. If you’re experienced, I’d really appreciate feedback on clarity, accuracy, and structure. Be honest, it’ll help me improve.”</em></p>
]]></content:encoded></item></channel></rss>