There's a moment every developer hits where they stop taking DNS for granted. For me it was during my final year project when I changed an A record, refreshed the browser thirty seconds later, and nothing happened. I refreshed again. Still nothing. I spent two hours thinking my deployment was broken before someone told me DNS changes take time to propagate.
"What do you mean propagate? Where does it go?"
Nobody could explain it clearly. So I started digging — quite literally. There's a command called dig that shows you exactly how DNS resolution works, step by step, layer by layer. Once I understood what dig was telling me, DNS stopped being a black box entirely.
This blog walks through exactly what I learned: how DNS resolution actually works, and how to trace it yourself in your terminal.
What DNS Is (And Why Name Resolution Exists)
Quick recap first. DNS stands for Domain Name System. It translates human-readable domain names like google.com into machine-readable IP addresses like 142.250.185.46.
Computers don't understand google.com. They need an IP address to know where to send packets. But nobody wants to memorize 142.250.185.46. DNS solves this by being the internet's phonebook — you look up a name, it gives you the number.
But here's what most explanations skip: DNS isn't a single server somewhere that knows everything. It's a hierarchy — a tree of servers distributed across the planet, each responsible for different parts of the domain namespace. When your browser needs to resolve google.com, it doesn't ask one server. It works through a chain.
Understanding that chain is what this entire blog is about.
dig stands for Domain Information Groper (yes, really). It's a command-line tool that lets you manually query DNS servers and see exactly what they respond with.
Developers and system administrators use dig for:
Debugging DNS issues (why isn't my domain resolving?)
Verifying that DNS changes propagated correctly
Checking what nameservers are authoritative for a domain
Tracing the full DNS resolution path
Inspecting specific record types
If you're on Linux or macOS, dig is almost certainly already installed. On Windows, you can use WSL or install it via BIND tools.
Basic syntax:
dig [domain] [record type]
dig [domain] [record type] @[nameserver]
We're going to use four specific dig commands that walk through the entire DNS resolution hierarchy, from the very top of the tree all the way down to the final answer.
Layer 1: dig . NS — The Root of Everything
Let's start at the absolute beginning. Run this in your terminal:
dig . NS
That dot (.) represents the root of the DNS hierarchy. Every domain name actually ends with a dot — google.com. — you just never type it. The root is above everything.
You'll get back something like:
;; 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.
Thirteen root name servers. a.root-servers.net through m.root-servers.net.
These are the starting point for all DNS resolution on the internet. They don't know where google.com is — but they know who to ask next. Root servers know which servers are responsible for each TLD (Top-Level Domain): .com, .net, .org, .in, .dev, and every other extension.
Think of root servers as the head office of a massive postal network. They don't know your specific delivery address. But they know which regional office handles your area, and they'll point you there.
There are only 13 logical root server addresses, but each one is actually a cluster of hundreds of physical machines distributed globally (using a technique called anycast). So "13 root servers" doesn't mean 13 machines — it means 13 address identifiers, each backed by hundreds of servers worldwide. The whole system is designed to never go down.
The 518400 number in that output is the TTL — Time To Live — in seconds (518400 seconds = 6 days). DNS responses can be cached for this duration before needing a fresh lookup.
Now let's go one level deeper. We know root servers handle the top of the tree. The next layer down is the TLD layer. Run:
dig com NS
Output:
;; 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.
These are the .com TLD nameservers, operated by Verisign. GTLD stands for Generic Top-Level Domain. These servers know about every registered .com domain — not what IP they point to, but which nameservers are responsible for them.
When you register a domain like myportfolio.com with GoDaddy or Namecheap, your registrar tells these .com TLD servers: "Hey, myportfolio.com is managed by these nameservers." That's the NS record we talked about in the DNS records blog.
So the TLD servers answer a very specific question: "For this .com domain, who is the authoritative nameserver?" They don't give you IPs. They hand you off to the next layer.
Think of TLD servers as regional post offices. The head office (root) says ".com? Go to the regional office for America." That regional office knows which local branch office handles your specific street, but doesn't know your exact house number.
If you want to try the same for a different TLD:
dig in NS
dig dev NS
dig org NS
Each TLD has its own set of authoritative nameservers managed by a different organization.
Now we're getting specific. Run:
dig google.com NS
Output:
;; ANSWER SECTION:
google.com. 345600 IN NS ns1.google.com.
google.com. 345600 IN NS ns2.google.com.
google.com. 345600 IN NS ns3.google.com.
google.com. 345600 IN NS ns4.google.com.
These are Google's own authoritative nameservers. These servers hold the actual DNS records for google.com — the A records, AAAA records, MX records, TXT records, everything.
The TLD servers for .com know that google.com is managed by ns1.google.com through ns4.google.com. So when someone needs to resolve google.com, the .com TLD servers say: "Go ask ns1.google.com."
These authoritative nameservers are the final stop. They give a definitive answer. There's no "ask someone else" at this layer — the buck stops here.
For your own domain, these would be your hosting provider's nameservers, Cloudflare's nameservers, or whatever you configured as your NS records. When you set up a website and point your domain to Cloudflare, you're telling the TLD servers: "Cloudflare's nameservers are authoritative for this domain now."
The word "authoritative" is important. A nameserver is authoritative for a domain if it's the designated final source of truth for that domain's DNS records. All other DNS servers are just caching or relaying — only the authoritative server truly "owns" the answer.
Now the full picture. Run:
dig google.com
Output:
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Feb 15 10:23:44 IST 2026
;; MSG SIZE rcvd: 55
There it is. google.com resolves to 142.250.185.46. That's the IP address your browser will use to make an HTTP connection.
Let's break down the output fields:
QUESTION SECTION: What you asked — the A record for google.com.
ANSWER SECTION: The response — the IPv4 address.
300: TTL of 300 seconds (5 minutes). After 5 minutes, this cached answer expires and needs a fresh lookup.
SERVER: 192.168.1.1: This is your local recursive resolver — usually your router or ISP's DNS server. You didn't query the root servers directly. Your recursive resolver did all the legwork.
That last point is crucial to understand.
The Recursive Resolver: The One Doing All the Work
When you run dig google.com, your query goes to a recursive resolver — typically your ISP's DNS server or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.
The recursive resolver walks the hierarchy on your behalf:
Queries a root nameserver: "Who handles .com?" → "Try a.gtld-servers.net."
Queries the .com TLD server: "Who handles google.com?" → "Try ns1.google.com."
Queries Google's authoritative nameserver: "What's the A record for google.com?" → "142.250.185.46."
Returns the answer to you and caches it.
Your browser sent one query. The resolver made three or four separate queries to servers across the internet. This entire process typically completes in under 50 milliseconds.
Every subsequent request for google.com within the TTL window (300 seconds here) comes from cache — no hierarchy walk needed.
To trace this manually without caching:
dig com NS @a.root-servers.net
dig google.com NS @a.gtld-servers.net
dig google.com A @ns1.google.com
Each command is one hop. This is exactly what your recursive resolver does automatically, every time.
The Caching Layer: Why DNS Changes Take Time
Remember my earlier frustration about DNS changes taking time? Now it makes sense.
Every DNS response includes a TTL. When a recursive resolver caches google.com -> 142.250.185.46 with a TTL of 300 seconds, it serves that cached answer to everyone who asks for the next 5 minutes — without going back to Google's nameservers.
If you change your A record from one IP to another, every cached copy of the old record across thousands of recursive resolvers worldwide has to expire first. Some resolvers cache aggressively. Some ISPs ignore TTLs entirely and cache for longer. This is why DNS propagation can take anywhere from a few minutes to 48 hours depending on your previous TTL setting.
Developer pro tip: If you know you're about to make a DNS change, lower your TTL to 300 seconds (5 minutes) a day before. Then make the change. Propagation will be much faster because resolvers cached your records with a short TTL. After the change stabilizes, raise it back to something like 86400 (24 hours) to reduce DNS lookup overhead.
Connecting This to Real Browser Requests
When you type google.com and hit enter, your browser doesn't immediately call a DNS server. It checks its own cache first — browsers maintain their own DNS cache. On Chrome: chrome://net-internals/#dns.
If the browser cache misses, it asks the OS. Your OS has its own DNS cache too (resolvectl statistics on Linux). If that misses, the query goes to the recursive resolver configured on your network (/etc/resolv.conf on Linux).
Only if all caches miss does the full recursive resolution happen:
Browser cache
-> OS cache
-> Recursive resolver cache
-> Root -> TLD -> Authoritative
-> IP address returned
Most requests never make it past the third step. DNS is fast because caching is aggressive at every layer.
What dig Teaches You That Documentation Doesn't
Running these four commands in order genuinely changed how I understood the internet. Not from reading — from seeing the actual responses:
dig . NS
dig com NS
dig google.com NS
dig google.com
Each command revealed one layer. Together they showed me the complete hierarchy.
For any domain you're working with, swap out google.com for your own domain and run the same sequence. You'll see which nameservers are authoritative for your domain, what TTLs you've configured, which IP your A record points to, and whether your DNS changes have actually propagated to the authoritative layer.
And the next time a deployment breaks because of DNS, you'll know exactly where to look.
DNS resolution is one of those foundational internet concepts that software engineers encounter constantly — domain setup, CDN configuration, service discovery, Kubernetes DNS — but rarely fully understand. The dig command is your lens into all of it. Use it.