How DNS Resolution Works
Understanding the Steps in DNS Resolution
When we open a website like google.com, it feels instant. We type a name, press Enter, and the page loads. What we don’t see is the long chain of systems working behind the scenes to convert that human friendly name into something computers actually understand.
This is where DNS comes in.
DNS is one of those systems every web developer uses every day, often without realising it. To truly understand how the web works, we must understand DNS, not just definitions, but how it behaves in the real world. In this article, we will break DNS down step by step and use the dig command to build a clear mental model of how name resolution actually happens.
What is DNS and why name resolution exists
Computers do not understand domain names. They communicate using IP addresses, which are numeric values like 142.250.190.14. Humans, however, cannot easily remember numbers, especially at the scale of the internet.
DNS (Domain Name System) exists to solve this exact problem.
We can think of DNS as the internet’s phonebook. Instead of memorising IP addresses, we remember names like google.com. DNS acts as the translation system that maps these names to their corresponding IP addresses.
Without DNS, the web would still work, but it would be unusable for humans. Every website visit would require remembering and typing raw IP addresses. DNS makes the web usable, scalable, and human friendly.
What is the dig command and when it is used
dig stands for Domain Information Groper. It is a command line tool used to query DNS servers directly and inspect DNS records.
Browsers perform DNS lookups automatically, but they hide the details from us. dig removes that abstraction. It allows us to ask very specific DNS questions and see exactly which server responds and what information is returned.
We typically use dig when:
Debugging DNS issues
Understanding how DNS resolution flows
Verifying DNS records like NS, A, MX, TXT
Learning how DNS works internally
In short, dig is not just a tool, it is a lens into the DNS system.
Understanding dig . NS and root name servers
Let’s start at the very top of DNS.
When we run:
dig . NS
We are asking:
“Who is responsible for the root of the DNS system?”
The dot (.) represents the DNS root zone. Root name servers do not know IP addresses for domains like google.com. Instead, they know where to find information about top level domains such as .com, .org, .net, and country codes like .in.
Root servers are the first step in DNS resolution. They act like a directory that says,
“I don’t know the final answer, but I know who might.”
There are total 13 Root servers in the world, but total 1600+ implementations, means there are 1600+ copies present in the world.
This is an important concept: DNS works by referral, not by guessing.
Understanding dig com NS and TLD name servers
Next, we move one level down the hierarchy.
When we run:
dig com NS
We are asking:
“Which name servers are responsible for the .com domain?”
These servers are called TLD (Top Level Domain) name servers.
TLD servers do not know the IP address of google.com. Instead, they know which authoritative name servers are responsible for domains under .com.
So again, we see the same pattern:
Root → points to TLD
TLD → points to authoritative servers
DNS is intentionally layered to remain scalable across billions of domains.
This output shows the result of running dig com NS, which asks DNS who is responsible for the .com top level domain. The important part is the ANSWER SECTION. It lists multiple NS (Name Server) records like a.gtld-servers.net, b.gtld-servers.net, and so on. These are the official TLD name servers for .com, and they are managed by the .com registry. The number 172800 is the TTL (time to live), which means resolvers can cache this information for about 2 days. This output does not give IP addresses for websites like google.com; instead, it tells DNS resolvers where to go next to find which authoritative name servers handle a specific .com domain.
Understanding dig google.com NS and authoritative name servers
When we run:
dig google.com NS
We are asking:
“Which name servers are authoritative for google.com?”
Authoritative name servers are the source of truth for a domain. They are configured by the domain owner (or their DNS provider). These servers contain the actual DNS records A, AAAA, MX, TXT, and more.
Once a resolver reaches the authoritative name server, it can finally ask:
“What is the IP address forgoogle.com?”
And this server gives the final answer.
This output shows the result of running dig google.com NS, which asks DNS which name servers are authoritative for the google.com domain. In the ANSWER SECTION, we see four NS records: ns1.google.com, ns2.google.com, ns3.google.com, and ns4.google.com. These are Google’s authoritative name servers, meaning they are the final source of truth for all DNS records of google.com. The TTL value (270971) tells resolvers how long this information can be cached. The ADDITIONAL SECTION includes the actual IP addresses (both IPv4 A and IPv6 AAAA) of these name servers, so resolvers can contact them directly without doing another lookup. At this stage of DNS resolution, the system now knows exactly where to ask for the final IP address of google.com.
Understanding dig google.com and the full DNS resolution flow
Now let’s connect everything.
When we run:
dig google.com
dig performs the full lookup and shows us the final DNS response. But behind the scenes, the resolution followed a clear path:
Ask root name servers where .com lives
Ask .com TLD servers where google.com lives
Ask Google’s authoritative servers for the IP address
Receive the final answer
This entire process usually happens in milliseconds.
In real life, browsers don’t talk directly to root or TLD servers. They use recursive resolvers (usually provided by ISPs or public services like Google DNS). These resolvers perform all the steps on our behalf and cache results to make future lookups faster.
This output shows the final step of DNS resolution. The command dig google.com asks for the A record of google.com, which means we are now asking for the actual IP address to connect to. In the ANSWER SECTION, DNS returns 172.217.27.174, which is one of Google’s server IPs. The TTL value (107) is very small, showing that Google keeps this record short lived so traffic can be routed dynamically. At this point, DNS resolution is complete, the browser now has a concrete IP address and can open a network connection to Google’s servers.
What NS records represent and why they matter
NS (Name Server) records define who controls a domain’s DNS.
They are critical because:
They define authority
They enable delegation
They allow DNS to scale globally
Without NS records, DNS would have no way to know where responsibility for a domain begins and ends.
Whenever we change DNS providers, what we are really doing is changing NS records.
How recursive resolvers use this information behind the scenes
Recursive resolvers are like professional DNS investigators.
They:
Query root servers
Follow referrals to TLD servers
Reach authoritative servers
Cache responses using TTL values
This caching is why DNS lookups are fast most of the time and slow only on first access.
Resolvers hide complexity, but dig exposes it, making DNS understandable instead of mysterious.
