Introduction
In the previous blog, we established what DNS is, why name resolution exists, and how a browser ultimately gets an IP address. That gave us the theory.
This article is about execution. Here, we shift from conceptual DNS to observable DNS. Using the dig command, we will see the layers of DNS resolution exactly the way a recursive DNS resolver does it—step by step, server by server.
Think of this as:
- Moving from “DNS is the internet’s phonebook”
- To “Let’s watch the recursive query happen, live.”
By the end, you should be able to:
- Read the
digoutput without guessing - Understand how root, TLD, and authoritative servers cooperate
- Map DNS lookups directly to what happens during a real browser request
Why dig Matters
If DNS is the phonebook, dig is the X-ray machine.
It doesn’t resolve names magically like a DNS Resolver does. Instead, it lets you:
- Query specific DNS layers
- How each layers are connected to each other
- Inspect NS records
- Observe how authority is delegated across the DNS hierarchy
This makes dig indispensable for:
- Debugging DNS issues
- Understanding DNS Server's behavior
- Learning how recursive resolvers actually operate
DNS Resolution Happens in Layers (Quick Recap)
In the previous blog, we have already discussed about the DNS resolution in detail, We won’t re-explain that theory here again, but keep this mental model handy:
Browser Search → Cache (The IP details will be returned to the browser if found; else move to the next step)
DNS Resolver → Root DNS Server → TLD Server → Authoritative DNS Server
What is the dig command and when it is used
dig (Domain Information Groper) is a command-line tool used to query DNS servers and inspect how name resolution works. Basically, it's a tool which is used to gather information related to DNS. This command is a part of the bind9-dnsutils package along with other dns troubleshooting commands and tools. You can access nslookup, dig command by installing this package on Windows or on Linux.
- For Linux it’s quite simple, just open the terminal and type
sudo apt install bind9-dnsutils, assuming you have sudo privileges. - Enter your account password, and press enter.
- Press ‘y‘ and then Enter.
This will install the bind9-dnsutils package which has the dig command. To verify, just run dig command in a new terminal. It should look something like this—
No need to be overwhelmed from now, it was just to verify whether the package is properly installed or not. We are going to deep-dive into these to the upcoming sections.
It is mainly used by developers, system administrators, and network engineers to debug DNS problems, check name servers, and understand how DNS resolution is happening.
Using dig, we can see:
- What IP, does this domain resolve to?
- Which nameservers are involved
- Which records are returned and check whether they are correct or not
- How the DNS query travels step by step
Now let’s understand how DNS resolution happens in layers. Let's assume you are searching for google.com in your browser. So what actually happens? We will see everything via the dig command in the below sections.
dig . NS — Talking to the Root of the Internet
This command asks:
Who are the name servers for the root of the DNS system
What This Query Represents
- This is not a lookup for a website.
- This is a lookup for who controls the DNS root zone.
- The . (dot) represents the DNS root zone—the top of the hierarchy. Root name servers are the top-level servers in the DNS hierarchy.
What You’re Observing
- A list of root name servers (a.root-servers.net through m.root-servers.net)
- These servers do not know IPs for websites
- They only know which servers handle each TLD. During the recursive DNS resolution, this root DNS server tells to which top-level domain server it needs to talk.
dig com NS — Discovering the TLD Authorities
What Changed?
Now we’re querying:
Who is authoritative for the .com top-level domain? Means Which Nameservers handle the .com zone??
What the Output Tells You
- A list of TLD name servers responsible for all .com websites. (e.g., a.gtld-servers.net)
- These servers manage delegation for all .com domains
- These servers return the NS records for google.com as defined in the .com zone, delegating authority to Google’s name servers.
Key Insight
Each DNS layer answers only what it owns and whom to talk next.
This strict separation is what allows DNS to scale globally.
dig google.com NS — Finding the Authoritative Source of Truth
Google hosts their own servers, and they have 4 authoratitive name servers from ns1 to ns4.google.com.
What This Query Does Actually
This asks:
“Which name servers are responsible for google.com?”
Why NS Records Matter
NS records are control boundaries.
They define:
- Who owns the domain
- Who is allowed to answer definitively
- Where recursive resolvers must go next
At this point, we’ve reached the end of delegation.
Important Distinction
- Authoritative servers don’t recurse
- They answer directly from zone files
- Their responses are considered final
dig google.com — The Full Resolution Flow
What Happens Behind the Scenes
Even though this looks like a single query, a recursive resolver performs:
- Query root servers
- Query .com TLD servers
- Query Google’s authoritative servers
- Cache the result
dig hides the recursion—but the response contains the outcome. Though by using +trace, the recursion can be revealed. You can check out the command dig google.com +trace.
How This Connects to Browser Requests
When your browser requests https://google.com:
- DNS resolution must complete before TCP
- DNS latency directly impacts page load time
- Cached records often eliminate repeated lookups
This is why:
- CDNs
- TTL tuning
- Resolver placement
all matter in real-world systems.
How Recursive Resolvers Use All This Information
The key takeaway is this:
Recursive resolvers don’t know anything upfront.
They:
- Discover authority dynamically and recursively
- Caches DNS records (A, NS, and glue records) according to their TTLs to avoid repeated upstream queries.
- Reuse NS knowledge across domains
This is why DNS is:
- Fast
- Distributed
- Resilient
And why a single dig command can reveal so much about the internet’s control plane.
Conclusion
DNS resolution is not a black box—it’s a layered negotiation of responsibility.
Using dig, we can observe:
- How authority flows downward
- Why NS records are the backbone of DNS
- How recursive resolvers stitch the system together invisibly
If the previous blog explained what DNS is, this one shows how DNS behaves—in real time, with real servers.
Once you can read dig output confidently, DNS stops being magic and starts being engineering.
Follow for more beginner-friendly breakdowns of core software engineering concepts.
Top comments (0)