Skip to main content
HashnodeViraj Explains

Command Palette

Search for a command to run...

How DNS Resolution Works?

A Step-by-Step Guide to Turning Domain Names into IP Addresses

Published
•13 min read
How DNS Resolution Works?
V
Viraj Dandekar

Imagine this: it is the year 2047, and you want to shop online for shoes. You run to your laptop, scratching your head to recall the IP address of amazon.com. Somehow, you remember it, but when you enter it, the browser throws an error “ERR_NAME_NOT_RESOLVED.” You try once more, entering the correct IP from your 1000-page IP directory you maintained. And Eureka, this time the browser takes you to Amazon.

In this case every time you visit a website or web app on the internet, you have to manually input the correct IP addresses. Frightening, right?

But why worry when DNS is the query?

In simple terms, if the Internet is a building, then DNS is the elevator inside the building, taking you to different parts of the building based on the your input. If the Internet is a phone, DNS is its phonebook.

But what is this DNS ? Let’s Find out!!

WHAT IS DNS?

DNS is a tour guide in the wonderland of INTERNET. DNS or Domain Name Server is that critical part of the Internet that takes human-readable domain names, such as www.chaicode.com, and maps them to numeric IP addresses that are readable by machines.

It is a great problem solver , isn’t it.

DNS is nothing less than a phonebook of the internet.

Just as we save contacts in our telephone directory , similarly DNS maps the website domains to their respective IP addresses. Factually speaking there around 10 billion phone numbers in the world for 7 billion of humanity and more than 4 billion IP addresses present currently around the globe. Taking inspiration from phone book to create DNS mapping system was just incredible.

DNS always tells you “Whom to talk to next?”

Some main features of DNS are

  • Recursive in nature

  • Distributed or Decentralized (no single central database)

  • Hierarchical or Delegated (structured in levels)

  • Loosely Coupled ( system components unaware of each others internal working)

  • Fault-tolerant (multiple servers, redundancy)

  • Extremely fast (most lookups take milliseconds)

WHY THE NAME RESOLUTION EXISTS?

  • Computers don’t work with names.
    They navigate through IP addresses 192.168.1.2.

  • So here the computer is trying very hard to “resolve“ the name , to its IP address

  • Resolution means figuring out something !!

Finding the IP address to a domain name is called name resolution.

What does DNS do ? :

  • A domain name → google.com

  • A resolved value → 142.250.195.78

So DNS resolution means translating a human-friendly name into a machine-friendly IP address. DNS resolves meaning it removes ambiguity as the domain name is insufficient to track down the webpage .

The machine which resolves this domain name and brings back IP address to the browser is called as the RESOLVER

dig a diagnostic tool to inspect DNS resolution!!

So till now we have seen what is DNS and what is DNS Resolution. But when you use browser for opening any webpage , does the browser takes you through the whole DNS resolution process ? NO ,you type a URL, and everything happens in the background.

What if you want to see how this DNS Resolution works? Enter dig command.

dig stands for Domain Information Groper.

It is used to:

  • Query DNS servers directly

  • Inspect how a domain name is resolved

  • View detailed DNS records

If by any chance the domain name is not getting resolved and DNS is throwing an error, then to diagnose this issue, programmers and network administrators query the Domain Name System (DNS) and fix the issue. It performs DNS lookups and displays the answers returned from the queried name servers.

Unlike browsers or applications, dig shows you the raw DNS response, without hiding any details.

Example:

dig example.com

;; ANSWER SECTION: 
example.com. 86400 IN A 93.184.216.34

We can interpret this dig command as , display all the information you (DNS) have about google.com.

And DNS responds with:

  • IP addresses

  • Record types

  • TTL values

  • Which server DNS answered

DNS resolution Layers: root → TLD → authoritative

  • When we say DNS Server , we subconsciously assume that it would be one server somewhere in the server room. But in reality DNS is decentralized and delegated , meaning it is spread all over the globe in a hierarchical structure .

  • Therefore the process of DNS Resolution also happens in layers .

  • Each layer has a specific responsibility , to take you one step closer to your destination.

DNS tells you “Whom to talk to next?”

When you type a domain name like example.com into your browser, the answer does not come from a single place.

DNS consist of 3 layers

  1. Root Server Layer

  2. Top Level Domain Server layer (TLD)

  3. Authoritative Name Server Layer

The flow looks like this:

Root Server → TLD Server → Authoritative Server

#Step 1: The Root DNS Servers (The Starting Point)

  • The root DNS servers sit at the very top of the DNS hierarchy. The resolver first comes to the root server seeking IP address.

FUN FACT : In the whole world there are total 13 root servers , but if we consider their implementation across the globe then there are 1600+ root servers deployed.

  • But root servers do not know the IP address of example.com.

  • Instead, they guide the resolver to the server that holds all the information about top level domain. In this case .com is the top level domain.

#Step 2: The TLD DNS Servers (Category Level)

  • Next, the request goes to a TLD server.

  • This server doesn’t know the IP address either.

There are multiple top level domains for IP addresses which are managed by multiple TLD servers .

  1. .com

  2. .org

  3. .net

  4. .in

  5. .io, etc.

  • TLD servers knows which authoritative server is responsible for the domain

#Step 3: The Authoritative DNS Server (Final Answer)

This is where the actual answer lives. This is the final layer of the hierarchy .

The authoritative DNS server*:*

  • Stores the real DNS records

  • Knows the IP address of the domain

  • Gives the final, trusted response

The Authoritative Server Returns

  • IP address (A or AAAA record)

  • Mail servers (MX records)

  • Aliases (CNAME records)

  • Other DNS data

For example.com, it might reply:

“The IP address is 93.184.216.34.”

This answer is then sent back to the browser through resolver .

Full Flow :

Here’s the full journey in simple terms:

  1. Your computer asks:
    “What is the IP for example.com?”

  2. Root server says:
    “Ask the .com TLD server.”

  3. TLD server says:
    “Ask this authoritative server.”

  4. Authoritative server says:
    “Here is the IP address.”

  5. Your computer connects to the server using that IP.

That’s DNS resolution.

A Simple Real-World Analogy 📚

Imagine finding a book in a huge library system:

  • Root server → Which building has computer science books?

  • TLD server → Which floor has networking books?

  • Authoritative server → Here is the exact shelf and book

Each step narrows the search.

Understanding dig . NS and root name servers

Enough of theory , it’s implementation time . Let’s observe this process in action using the dig command.

As we know that root servers redirects the resolver to the TLD server .

Querying Root Name Servers with dig

You can ask DNS to show the root servers directly.

Command

dig . NS

Response

; <<>> DiG 9.18.12 <<>> . NS
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34821
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; QUESTION SECTION:
;.                      IN      NS

;; ANSWER SECTION:
.       518400  IN  NS  a.root-servers.net.
.       518400  IN  NS  b.root-servers.net.
.       518400  IN  NS  c.root-servers.net.
.       518400  IN  NS  d.root-servers.net.
.       518400  IN  NS  e.root-servers.net.
.       518400  IN  NS  f.root-servers.net.
.       518400  IN  NS  g.root-servers.net.
.       518400  IN  NS  h.root-servers.net.
.       518400  IN  NS  i.root-servers.net.
.       518400  IN  NS  j.root-servers.net.
.       518400  IN  NS  k.root-servers.net.
.       518400  IN  NS  l.root-servers.net.
.       518400  IN  NS  m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     518400  IN  A   198.41.0.4
b.root-servers.net.     518400  IN  A   199.9.14.201
c.root-servers.net.     518400  IN  A   192.33.4.12
d.root-servers.net.     518400  IN  A   199.7.91.13
e.root-servers.net.     518400  IN  A   192.203.230.10
f.root-servers.net.     518400  IN  A   192.5.5.241
g.root-servers.net.     518400  IN  A   192.112.36.4
h.root-servers.net.     518400  IN  A   198.97.190.53
i.root-servers.net.     518400  IN  A   192.36.148.17
j.root-servers.net.     518400  IN  A   192.58.128.30
k.root-servers.net.     518400  IN  A   193.0.14.129
l.root-servers.net.     518400  IN  A   199.7.83.42
m.root-servers.net.     518400  IN  A   202.12.27.33

;; Query time: 18 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jan 27 16:55:10 IST 2026
;; MSG SIZE  rcvd: 811

Decoding the answer section!!v

1. QUESTION SECTION

;.  IN  NS

This means:

  • You asked for NS records

  • For the root domain (.)

The dot (.) represents the top of the DNS hierarchy.

2. ANSWER SECTION

. IN NS a.root-servers.net.
. IN NS b.root-servers.net.
...
. IN NS m.root-servers.net.

This depicts:

3. TTL (518400)

518400

This is the Time To Live (TTL) in seconds.

  • 518,400 seconds ≈ 6 days

  • DNS resolvers can cache (remember) this information for that long

Root server information rarely changes as there are limited number of them and most of the updates takes place at the lower levels.

4. ADDITIONAL SECTION

a.root-servers.net. IN A 198.41.0.4

This is extra information that provides:

  • IP addresses for the root name servers

  • So resolvers don’t need to look them up separately

This makes DNS resolution faster.

5. HEADER FLAGS (Quick Insight)

status: NOERROR

Means:

  • No error occurred and the query succeeded.

Understanding dig . com NS and TLD name servers

Querying .com TLD Name Servers Using dig

Lets excavate this .com TLD servers.

Command

dig com NS

This command asks:

"Which name servers are responsible for the .com TLD?"

Response

; <<>> DiG 9.18.12 <<>> com NS
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21458
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 26

;; QUESTION SECTION:
;com.                    IN      NS

;; 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.
com.    172800  IN  NS  d.gtld-servers.net.
com.    172800  IN  NS  e.gtld-servers.net.
com.    172800  IN  NS  f.gtld-servers.net.
com.    172800  IN  NS  g.gtld-servers.net.
com.    172800  IN  NS  h.gtld-servers.net.
com.    172800  IN  NS  i.gtld-servers.net.
com.    172800  IN  NS  j.gtld-servers.net.
com.    172800  IN  NS  k.gtld-servers.net.
com.    172800  IN  NS  l.gtld-servers.net.
com.    172800  IN  NS  m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.  172800  IN  A   192.5.6.30
b.gtld-servers.net.  172800  IN  A   192.33.14.30
c.gtld-servers.net.  172800  IN  A   192.26.92.30
d.gtld-servers.net.  172800  IN  A   192.31.80.30
...

  • .com is managed by GTLD (Generic TLD) name servers

  • There are multiple servers for reliability and performance which run under ICANN’s coordination

  • TTL of these TLD servers is 172800 seconds ≈ 2 days

  • DNS resolvers can cache .com NS records for 2 days . Same as root servers TLD data changes rarely, so longer caching is safe

Understanding dig google.com NS and authoritative name servers

Coming this far you have learned and implemented dig commands like a pro .

This is the final step where finally resolver will get the IP address .

So let us take an example of google.com and run the dig google.com NS command .

For google.com, Google’s authoritative servers know:

  • The IP addresses

  • Mail servers

  • Aliases and other DNS records

If DNS were a chain of command, authoritative servers are the final authority.

Querying Authoritative Name Servers Using dig

  • To find which servers are authoritative for google.com, run:

Command

dig google.com NS

This asks DNS:

“Which name servers are authoritative for google.com?”

dig google.com NS Output

; <<>> DiG 9.18.12 <<>> google.com NS
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50341
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 8

;; QUESTION SECTION:
;google.com.            IN      NS

;; ANSWER SECTION:
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com. 172800  IN  A   216.239.32.10
ns2.google.com. 172800  IN  A   216.239.34.10
ns3.google.com. 172800  IN  A   216.239.36.10
ns4.google.com. 172800  IN  A   216.239.38.10

;; Query time: 22 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jan 27 18:40:12 IST 2026
;; MSG SIZE  rcvd: 239

Let’s decode the output.

google.com. IN NS ns1.google.com.
google.com. IN NS ns2.google.com.
...

This tells you:

  • These servers are authoritative for google.com , they are controlled by Google

  • The final DNS answer must come from these servers .

TTL (172800)

172800 seconds ≈ 2 days

This means:

  • DNS resolvers can cache Google’s NS records for 2 days

ADDITIONAL SECTION WITH IP ADDRESS

ns1.google.com. IN A 216.239.32.10

This provides:

  • IP addresses for the authoritative servers So resolvers can contact them directly

  • Avoids extra lookups and speeds up the DNS resolution process.

Understanding dig google.com and the full DNS resolution flow

So far, you’ve seen how DNS information is organized:

  • Root name servers

  • TLD name servers

  • Authoritative name servers

But your computer never talks to all of these servers directly. Your computer (browser and the OS) is just the face of the DNS resolution process, but it is the resolver that is recursively working making round trips , behind the scenes.

A recursive resolver is a DNS server who :

  • Find the final answer for you

  • Do all the DNS work on your behalf

  • Return a single, complete response

Examples of recursive resolvers:

  • Your ISP’s DNS server

  • Google DNS (8.8.8.8)

  • Cloudflare DNS (1.1.1.1)

Step-by-Step: Recursive Resolution in Action

  1. Client → Recursive Resolver

Your browser or OS sends a request to the recursive resolver:

Find the IP address of google.com

  1. Recursive Resolver → Root Name Servers

If the IP is not cached, the resolver asks a root server:

“Who handles .com domains?”

  1. Root name servers → Recursive Resolver

The root server responds with:

A list of .com TLD name servers

  1. Recursive Resolver → TLD Name Servers

Next, the resolver asks a .com TLD server:

“Who is authoritative for google.com?”

  1. Recursive Resolver ← TLD Name Servers

The TLD server responds with:

Google’s authoritative name servers list

  1. Recursive Resolver → Authoritative Name Servers

Finally, the resolver asks Google’s authoritative server:

“What is the IP address of google.com?”

  1. Recursive Resolver ← Authoritative Name Servers

This server replies with the final IP address through DNS Records.

8. Recursive Resolver → Client

The recursive resolver:

  • Returns the IP address to your computer

  • Stores the result in its cache

  • Sets a TTL based on DNS records

Your browser can now connect to the website.

FULL DNS RESOLUTION FLOW FOR GOOGLE.COM

MAPPING dig COMMANDS TO DNS LOOKUP STAGES

PUTTING IT ALL TOGETHER

DNS resolution is one of those things that works silently every time you use the internet.

DNS is that infinite stop which would annihilate the whole Internet if it crashed.. At its core, DNS exists because humans prefer names, while computers require IP addresses—and name resolution is the bridge that connects the two.

Now you are among top 10 percent that have deep dived in the ocean of DNS . In this blog, you started by understanding what DNS is and why name resolution exists. You then explored the dig command, a powerful but simple tool that lets you inspect DNS behavior instead of guessing what happens behind the scenes. DNS is not magic. It is a well-structured, layered system that can be observed, understood, and debugged. Once you grasp how DNS resolution works, tools like dig stop feeling intimidating and start feeling empowering. And with this foundation, you’re well prepared to explore deeper topics in networking, backend development, and system design with confidence.

#chaicode#dns#dns-resolver#networking#web-development#devops#dns-server

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog

Viraj Explains

10 posts