How DNS Resolution Works
When you type a website name into a browser, your computer somehow figures out where that website lives on the internet. This process is called DNS resolution.
You already know that DNS works like the phonebook of the internet. DNS resolution is simply the process of looking up a name in that phonebook and finding the correct address.
But how does that lookup actually happen?
Let’s walk through it slowly, one layer at a time.
Why name resolution exists in the first place
Humans like names. Computers like numbers.
Websites are hosted on servers identified by IP addresses, but remembering numbers like 142.250.183.14 would be painful. DNS exists so humans can use readable names while computers still get the numeric addresses they need.
DNS resolution is the journey from a domain name to its final IP address.
Introducing dig: a tool to inspect DNS
Before understanding the flow, we need one simple tool: dig.
dig stands for Domain Information Groper. It’s a command-line tool that lets you ask DNS questions directly and see the answers.
Browsers do DNS resolution silently in the background. dig lets us slow things down and observe each step.
You don’t use dig every day as a developer, but it’s incredibly useful when something goes wrong or when you want to understand how DNS really works.
DNS resolution happens in layers
DNS is not a single database. It’s a hierarchy.
Instead of one central phonebook, DNS is split into layers, where each layer knows just enough to point you to the next one.
The journey usually looks like this:
root name servers → TLD name servers → authoritative name servers
Let’s see what that actually means using dig.
Step 1: Asking the root name servers
When a resolver wants to find information about a domain, it starts at the very top: the root.
You can see this yourself by running:
dig . NS
This command asks: who is responsible for the root of the DNS system?
The response contains a list of root name servers. These servers don’t know where google.com lives. Their job is simpler. They only know which name servers are responsible for top-level domains like .com, .org, or .net.
Think of the root as someone saying:
“I don’t know the full address, but I know who handles this area.”
Step 2: Asking the TLD name servers
Next comes the top-level domain, or TLD.
If you’re looking for a .com website, the resolver needs to know which servers handle .com.
You can ask this directly:
dig com NS
This command asks: who is responsible for the .com domain?
The response gives you the TLD name servers for .com. These servers don’t know the final IP address either. They only know which name servers are authoritative for specific .com domains.
At this stage, DNS is narrowing things down.
Step 3: Asking the authoritative name servers
Now we ask about the specific domain:
dig google.com NS
This command asks: who is responsible for google.com?
The answer gives you the authoritative name servers for that domain. These servers are the source of truth. They contain the actual DNS records like A, AAAA, MX, and TXT.
Once the resolver reaches this level, it’s finally talking to the servers that know the real answers.
Step 4: Resolving the domain to an IP address
Now comes the final step:
dig google.com
This command asks the authoritative name server:
“What is the IP address for this domain?”
The response includes the A or AAAA records that map google.com to an IP address. This is the answer the browser actually needs.
Once the IP address is known, the browser can connect directly to the server and request the website.
DNS resolution is complete.
What NS records really represent in this flow
Throughout this process, NS records play a key role.
NS records don’t give IP addresses. They tell DNS resolvers where to ask next.
Each layer uses NS records to delegate responsibility downward, from root to TLD to authoritative servers. This delegation is what makes DNS scalable and reliable.
Instead of one massive database, DNS spreads responsibility across many servers worldwide.
What your browser actually does
When you open a website, your browser doesn’t usually run all these steps itself.
Instead, it asks a recursive resolver, often provided by your ISP or a public DNS service. That resolver performs the full root → TLD → authoritative lookup, caches the result, and returns the final IP address to the browser.
This caching is why DNS lookups are usually fast, even though the system looks complex.
The big picture
DNS resolution is not magic. It’s a structured lookup process that moves step by step through a hierarchy.
Each layer knows just enough to point to the next one. By the time the resolver reaches the authoritative name server, it has all the information needed to complete the request.
Understanding this flow makes tools like dig far less intimidating and helps you reason about real-world issues like slow websites, DNS misconfigurations, or deployment problems.
Final thought
If this made something click for you, great. That’s the goal. I’ll keep sharing things the way I wish someone had explained them to me when I started.