How DNS Resolution Works

How DNS Resolution Works (Step by Step, Using dig)

Most of the internet feels instant. You type google.com, press Enter, and a webpage appears.

What actually happens before that page loads is DNS resolution — a layered, distributed lookup process that translates a human-readable domain name into an IP address.

This blog breaks DNS resolution down from first principles, using the dig command to inspect every layer involved.

What is DNS?

At its core, DNS is often called the "phonebook of the internet." Computers communicate using numbers (IP addresses like 142.250.190.46), but humans prefer memorable names (like google.com).

DNS resolution is the process of mapping these names to addresses. Without it, you would need to memorize the IP address of every website you wish to visit.

Why DNS exists:

• IPs change, names shouldn’t

• Services need load balancing

• The system must scale to billions of queries

• No single central database can handle the internet

DNS solves this using delegation and hierarchy.

The Diagnostic Tool: dig

To understand how this mapping actually happens, we use dig (Domain Information Groper). It is a standard network administration tool used to query DNS servers and inspect the responses. Unlike a web browser which hides the details, dig shows us exactly whom we are asking and what they are answering.

Layer 1: The Root of It All (.)

The DNS hierarchy starts at the very top: the Root.

When a resolver (the server looking up the address for you) doesn't know where google.com is, it starts by asking the root servers.

Command:

Bash

dig . NS

What this tells us: This command asks, "Who are the Name Servers (NS) for the root zone (.)?"
The Output: You will see a list of servers named a.root-servers.net through m.root-servers.net.

• These 13 logical servers (replicated physically hundreds of times globally) are the gatekeepers of the internet's naming system.

• They do not know the IP address of google.com. They only know who handles the top-level extensions like .com, .org, or .net.

Layer 2: Top-Level Domains (TLD)

Once the root server sees you are looking for a .com address, it directs you to the TLD servers for the .com zone.

Command:

Bash

dig com NS

What this tells us: This asks, "Who manages the list of all .com websites?"

The Output: The response will list servers managed by a registry (for .com, this is Verisign), such as a.gtld-servers.net.

• These servers still do not know the IP address of google.com.

• However, they know exactly which "Authoritative Name Server" has the specific details for google.com.

Layer 3: Authoritative Name Servers

The TLD server directs us to the specific servers owned or rented by the organization (Google). These are the Authoritative Name Servers.

Command:

Bash

dig google.com NS

What this tells us: This asks, "Who is the final authority for google.com?"

The Output: You will see servers like ns1.google.com.

• These servers contain the actual "A Record" (Address Record) mapping the name to the IP address.

• This is the final stop in the lookup chain before an answer is returned.

When you run a standard lookup, your computer (the stub resolver) usually asks a Recursive Resolver (like your ISP's server or Google's 8.8.8.8) to do the heavy lifting described above.

Command:

Bash

dig google.com

The Resolution Flow:

1. Request: Your computer asks the Recursive Resolver: "Where is google.com?"

2. Recursive Step 1 (Root): The Resolver asks a Root Server (.). The Root says: "Ask the .com TLD servers."

3. Recursive Step 2 (TLD): The Resolver asks the .com TLD server. The TLD server says: "Ask ns1.google.com."

4. Recursive Step 3 (Authoritative): The Resolver asks ns1.google.com. The Authoritative server says: "The IP is 142.250.190.46."

5. Response: The Recursive Resolver hands that IP back to your computer.

Why NS Records Matter

The NS records we inspected in the previous steps act as the signposts. Without them, the Recursive Resolver wouldn't know which server to ask next. The internet relies on this chain of trust—Root trusts TLD, TLD trusts Authoritative—to maintain a decentralized yet organized system.

Conclusion

By using dig, we move from viewing DNS as a "magic box" to understanding it as a structured, hierarchical query system. Whether you are debugging a site migration or designing a distributed system, understanding the path from Root to Authoritative is fundamental to internet engineering.