DNS resolution- How does it work?

What is DNS?

DNS, or Domain Name System, is the unsung hero powering every website you visit. Think of it as the internet's phonebook, translating memorable names like "google.com" into IP addresses computers actually use, like 142.250.190.78. Without name resolution, we'd be typing endless number strings—humans prefer words, machines need numbers, so DNS bridges that gap seamlessly.

This detailed guide dives deep into DNS layers using the dig command, a Swiss Army knife for DNS diagnostics. We'll trace queries from root servers to your browser, building a system-design mindset perfect for developers deploying on Vercel or debugging healthcare apps. Expect practical examples, output breakdowns, and real-world ties—aiming for a 9-minute read to solidify your understanding.

When you type google.com into your browser, something remarkable happens in milliseconds: your computer transforms that human-friendly name into an IP address like 142.250.185.46. This transformation is handled by the Domain Name System (DNS), often called the internet's phonebook. But unlike a physical phonebook, DNS is a distributed, hierarchical system that queries multiple servers to find the right answer.

In this post, we'll explore DNS from the ground up using dig, a powerful command-line tool that lets us peek behind the curtains of name resolution.

DNS: The Internet's Distributed Directory

Imagine if every time you wanted to call someone, you had to remember their phone number instead of their name. That's what the internet would be like without DNS. Every website, service, and server on the internet has an IP address (like 172.217.14.206), but we humans prefer memorable names like google.com or github.com.

DNS solves this problem, but not by maintaining one giant centralized database. Instead, it uses a hierarchical, distributed system where responsibility is delegated across thousands of servers worldwide. This design provides redundancy, scalability, and allows organizations to manage their own domains independently.

Meet dig: Your DNS Diagnostic Tool

Before diving into DNS architecture, let's introduce our primary tool: dig (Domain Information Groper). While most applications use DNS transparently in the background, dig lets us interact with DNS servers directly and see exactly what's happening during name resolution.

Think of dig as a diagnostic microscope for DNS. It allows us to:

• Query specific DNS servers

• Request particular types of DNS records

• Trace the resolution path from root to authoritative servers

• Debug DNS configuration issues

• Understand caching and TTL (Time To Live) values

The basic syntax is simple: dig [domain] [record-type]. But as we'll see, understanding what happens behind this simple command reveals the elegant architecture of the entire internet.

The DNS Hierarchy: Root → TLD → Authoritative

DNS resolution follows a hierarchical structure with three main levels:

1. Root Name Servers: The top of the DNS hierarchy, knowing where to find TLD servers

2. TLD (Top-Level Domain) Name Servers: Responsible for domains like .com, .org, .uk

3. Authoritative Name Servers: Hold the actual IP addresses for specific domains

Let's explore each layer by using dig to query them directly.

Layer 1: Root Name Servers with dig . NS

At the very top of the DNS hierarchy sit the root name servers. There are 13 root server identifiers (labeled A through M), though each identifier actually represents multiple servers distributed globally using anycast routing.

Let's query the root servers:

dig . NS

The . (dot) represents the root of the DNS namespace, and NS asks for Name Server records. You'll see output like:

;; ANSWER SECTION:
.                   86400   IN   NS   a.root-servers.net.
.                   86400   IN   NS   b.root-servers.net.
.                   86400   IN   NS   c.root-servers.net.
...
.                   86400   IN   NS   m.root-servers.net.

What does this mean?

Each line tells us about a root name server. The 86400 is the TTL (Time To Live) in seconds—24 hours—indicating how long this information can be cached. The IN stands for "Internet" (a class designation from DNS's early days). NS indicates these are Name Server records.

Why root servers matter:

Root servers don't know the IP address of google.com, but they know who does. When a recursive resolver (like your ISP's DNS server) needs to resolve a domain it hasn't cached, it starts by asking a root server: "Who handles .com domains?" The root server responds with the addresses of the .com TLD servers.

Think of root servers as the reception desk of the internet—they don't have everyone's contact information, but they know which department to send you to.

Layer 2: TLD Name Servers with dig com NS

Once we know where the .com TLD servers are, let's query them:

dig com NS

This asks: "Who are the authoritative name servers for the .com top-level domain?" The output shows:

;; ANSWER SECTION:
com.                172800  IN   NS   a.gtld-servers.net.
com.                172800  IN   NS   b.gtld-servers.net.
com.                172800  IN   NS   c.gtld-servers.net.
...

What's happening here?

The .com TLD is managed by Verisign, which operates these gtld-servers.net name servers. Notice the TTL is 172800 seconds (48 hours)—TLD information changes rarely, so it can be cached longer.

The TLD layer's role:

TLD servers are like specialized directories. The .com servers know about every domain registered under .com, the .org servers know about .org domains, and so on. When you ask them about google.com, they don't return the IP address directly. Instead, they tell you which name servers are authoritative for that specific domain.

This delegation model is powerful: Verisign manages the .com infrastructure, but Google manages its own authoritative servers. This separation of concerns allows the system to scale globally.

Layer 3: Authoritative Name Servers with dig google.com NS

Now let's find out who Google has designated as authoritative for their domain:

dig google.com NS

The response shows:

;; ANSWER SECTION:
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.

Understanding authoritative servers:

These are Google's own name servers—the final authority for anything under google.com. When you ask for mail.google.com, drive.google.com, or just google.com, these servers provide the definitive answer.

The TTL here is 21600 seconds (6 hours). This is shorter than TLD records because organizations might need to change their name servers more frequently than TLD infrastructure changes.

Why multiple name servers?

Notice there are four name servers listed. This redundancy is critical:

• If one server fails, others can still respond

• Load can be distributed across multiple servers

• Geographically distributed servers reduce latency

Most domain registrars require at least two name servers for this reason.

The Full Resolution: diggoogle.com

Finally, let's query for the actual IP address:

dig google.com

The output includes several sections:

QUESTION SECTION:
google.com.                    IN      A

 ANSWER SECTION:
google.com.         300     IN   A    142.250.185.46

 Query time: 23 msec
 SERVER: 8.8.8.8#53(8.8.8.8)

Breaking down the response:

• QUESTION SECTION: Shows what we asked for—an A record (IPv4 address) for google.com

• ANSWER SECTION: The actual IP address, with a TTL of just 300 seconds (5 minutes)

• Query time: How long the query took

• SERVER: Which DNS server we queried (in this case, Google's public DNS at 8.8.8.8)

Why such a short TTL?

Notice the TTL for the actual IP address is only 5 minutes, much shorter than the NS records. This is intentional. Large services like Google use short TTLs because they:

• Load balance across multiple IP addresses

• Need flexibility to redirect traffic during outages

• Want to update IPs without long propagation delays

Behind the Scenes: The Recursive Resolver's Journey

When your browser needs to resolve google.com, it doesn't perform all these steps itself. Instead, it asks a recursive resolver (typically provided by your ISP or a public DNS service like 8.8.8.8 or 1.1.1.1) to do the heavy lifting.

Here's what the recursive resolver does on your behalf:

1. Check cache: Does it already know the answer? If yes, return it immediately

2. Query root: "Where are the .com servers?" → Gets list of TLD servers

3. Query TLD: "Where are the authoritative servers for google.com?" → Gets Google's name servers

4. Query authoritative: "What's the IP for google.com?" → Gets the actual IP address

5. Return and cache: Send the answer back and cache it according to TTL

This entire process typically completes in milliseconds, even though it involves multiple servers potentially distributed across continents.

Caching is crucial:

Without caching, every DNS query would require this multi-step process. Imagine billions of devices querying root servers for every website request! Caching at multiple levels (browser, OS, recursive resolver) keeps the system performant:

• Your browser might cache for the duration of your session

• Your OS might cache according to TTL

• The recursive resolver caches according to TTL

• Even authoritative servers might have internal caches

Practical Implications for System Design

Understanding DNS resolution has several practical implications:

For developers:

• Set appropriate TTLs based on how frequently you update records (short for dynamic IPs, longer for stable infrastructure)

• Use multiple authoritative name servers in different locations

• Consider using a DNS provider with global presence to reduce latency

• Be aware that DNS changes aren't instant—plan migrations with TTL in mind

For troubleshooting:

• Use dig with +trace to see the full resolution path: dig +trace google.com

• Query specific servers with @: dig @8.8.8.8 google.com

• Check different record types: dig google.com MX for mail servers, dig google.com AAAA for IPv6

For performance:

• DNS resolution adds latency to every new connection

• Services like DNS prefetching can reduce perceived latency

• CDN edge servers often have co-located DNS resolvers to minimize lookup time

Conclusion: A System That Just Works

DNS is one of those fundamental internet technologies that most people never think about—it simply works. But understanding its hierarchical structure and the role of each layer helps us appreciate both its elegance and resilience.

The beauty of DNS lies in its simplicity and delegation:

• Root servers delegate to TLD servers

• TLD servers delegate to authoritative servers

• Authoritative servers provide the final answer

• Caching at every level ensures performance

Next time you type a URL, remember the invisible journey happening in milliseconds: your query traveling through layers of servers, each doing its specific job, collaborating to translate a name into a number so your browser can finally connect.

The dig command gives us a window into this process, transforming DNS from magic into understandable, debuggable infrastructure. Whether you're a developer deploying services, a system administrator troubleshooting connectivity, or simply curious about how the internet works, understanding DNS through tools like dig empowers you to build better systems and solve problems more effectively.

---

Try it yourself: Open a terminal and run dig +trace google.com to watch the entire resolution process unfold in real-time. You'll see your query travel from root to TLD to authoritative servers, each step of the journey visible and understandable.