How DNS Resolution Works

Every time you type sukanta.dev into your browser to see my cool portfolio, a fascinating chain of events flows behind the scenes. Our computers, as a node in the network, does not know what sukanta.dev, chaicode.com or google.com actually means. It can only connect with other computers using its IP address only, which looks like 142.240.169.46. So

The Domain Name System (DNS) what bridges this gap, acting as the internet's phonebook by translating human-readable domain names into machine-readable IP addresses.

But how does this translation actually happen? Let's explore DNS resolution from the ground up using dig, a powerful diagnostic tool that lets us peek inside this process.

What is DNS and Why Does Name Resolution Exist?

Imagine if you had to remember 142.250.185.46 instead of "google.com" for every website you visit. The internet would be nearly impossible to use. DNS exists to solve this fundamental problem: computers need numerical IP addresses to route traffic, but humans prefer memorable names.

DNS is a hierarchical, distributed database system that maps domain names to IP addresses. When you request a website, your computer needs to resolve that domain name through DNS before it can establish a connection. This resolution process happens so quickly (typically under 100 milliseconds) that you rarely notice it, but understanding how it works reveals the elegant architecture underlying the internet.

The dig Command: Your DNS Inspection Tool

The dig (Domain Information Groper) command is a flexible DNS lookup utility available on most Unix-like systems. While tools like nslookup exist, dig provides more detailed output and greater control, making it the preferred choice for network administrators and developers.

Basic syntax is straightforward:

dig sukanta.dev

This command queries DNS servers to resolve "example.com" and returns detailed information about the resolution process. But dig can do much more, it can query specific record types, target specific nameservers, and reveal the hierarchical structure of DNS itself.

Understanding DNS Hierarchy: Root Nameservers

Let's start at the very top of the DNS hierarchy:

dig . NS

The dot (.) represents the root of the DNS hierarchy, and NS requests nameserver records. When you run this command, you'll see something like:

.                    518400  IN  NS  a.root-servers.net.
.                    518400  IN  NS  b.root-servers.net.
.                    518400  IN  NS  c.root-servers.net.
...

There are 13 root nameserver identities (a.root-servers.net through m.root-servers.net), though each is backed by many physical servers distributed globally using anycast routing. These root servers are the starting point for all DNS resolution.

What do root nameservers do? They don't know the IP address of google.com, but they know who does: they can direct you to the nameservers responsible for top-level domains (TLDs) like .com, .org, or .net.

Think of root nameservers as the reception desk at a massive organization. They don't have every employee's direct extension, but they know which department to send you to.

Top-Level Domain Nameservers

Let's move down one level:

dig com NS

This queries for the nameservers responsible for the .com TLD. You'll see output like:

com.                 172800  IN  NS  a.gtld-servers.net.
com.                 172800  IN  NS  b.gtld-servers.net.
com.                 172800  IN  NS  c.gtld-servers.net.
...

The .com TLD nameservers (operated by Verisign) manage information about all domains ending in .com. There are millions of .com domains, but these servers don't store all their records directly. Instead, they know which authoritative nameservers are responsible for each specific domain.

The delegation model: Root servers delegate to TLD servers, which in turn delegate to authoritative nameservers. This hierarchical delegation is what makes DNS scalable enough to handle billions of domains.

Authoritative Nameservers: The Final Authority

Now let's find who actually knows about google.com:

dig google.com NS

This returns:

google.com.          21600   IN  NS  ns1.google.com.
google.com.          21600   IN  NS  ns2.google.com.
google.com.          21600   IN  NS  ns3.google.com.
google.com.          21600   IN  NS  ns4.google.com.

These are Google's authoritative nameservers, the servers that hold the definitive DNS records for google.com. When you register a domain, you specify which nameservers have authority over it. These servers are the single source of truth for that domain's DNS records.

NS records matter because they establish the chain of authority. Each level of the DNS hierarchy uses NS records to point to the next level, creating a clear path from root to your desired domain.

The Complete DNS Resolution Flow

Now let's see the full process in action:

dig google.com

The output shows the actual IP address resolution:

google.com.          300     IN  A   142.250.185.46

But what happened behind the scenes? When your recursive resolver (typically provided by your ISP or a service like 8.8.8.8) received this query, it followed this path:

1. Query root nameserver: "Where can I find information about .com domains?"

   • Root responds: "Ask the .com TLD nameservers"

2. Query TLD nameserver: "Where can I find information about google.com?"

   • TLD responds: "Ask ns1.google.com (and its siblings)"

3. Query authoritative nameserver: "What's the IP address for google.com?"

   • Authoritative server responds: "142.250.185.46"

This entire process happens recursively, meaning your local DNS resolver handles all these queries on your behalf. You just asked for google.com once, but your resolver made multiple queries to different servers in the hierarchy.

Caching: The Unsung Hero

Notice the numbers before IN in dig output (like 300 or 21600)? These are TTL (Time To Live) values in seconds. They tell resolvers how long they can cache this response before querying again.

Caching dramatically improves DNS performance. Without it, every DNS query would require traversing the entire hierarchy. With caching, frequently accessed domains resolve almost instantly from your local resolver's cache.

The dig output includes a "Query time" field showing how long the lookup took. Cached responses return in single-digit milliseconds, while uncached queries might take 50-100ms as they traverse the hierarchy.

Connecting to Real-World Browser Requests

When you type "google.com" into your browser:

1. Browser checks its own DNS cache

2. Operating system checks its DNS cache

3. OS queries configured recursive resolver

4. Resolver checks its cache, or performs recursive resolution

5. IP address returns to browser

6. Browser initiates TCP connection to that IP

7. HTTPS handshake and page load begin

All of this happens before you see a single pixel of content. DNS resolution is the critical first step that makes the web usable.

Practical Takeaways

Understanding DNS resolution helps you:

• Debug connectivity issues: Is DNS resolution failing, or is the server down?

• Optimize performance: Lower TTLs for frequently changing records, higher for stable ones

• Design resilient systems: Multiple nameservers provide redundancy

• Understand internet architecture: DNS is foundational infrastructure

The dig command transforms DNS from a mysterious black box into a transparent, inspectable system. Next time your website seems slow or unreachable, start with dig—it might just reveal where the problem lies.

The hierarchical elegance of DNS, with its clear delegation model and distributed architecture, is a testament to brilliant systems design. It scales globally, handles billions of queries per day, and remains one of the internet's most critical and resilient services.