DEV Community

Rajat Yadav
Rajat Yadav

Posted on

How DNS Resolution Works

#beginners #cli #networking #tutorial

Every single time we use the internet, DNS is working for you even if you never realized it existed.

When you type google.com in your browser and hit Enter, our computer doesn’t magically know where Google live. In the background, a system has to answer one basic question:

“What IP address belongs to google.com?”

That system is DNS, and dig is a tool that helps us look inside this process instead of treating it like black magic.

In this article, we’ll understand:

  • What DNS is and why name resolution is needed
  • What the dig command does and why engineers use it
  • How DNS lookup happens step by step: root → TLD → authoritative
  • How commands like dig . NS, dig com NS, dig google.com NS, and dig google.com all fit together

I’ll keep the language simple and practical.

1. What Is DNS? (The Internet’s Phonebook Idea)

1.1 Names vs numbers

Humans are comfortable with names:

  • google.com
  • facebook.com
  • myblog.dev

Computers don’t work like that. They talk using numbers called IP addresses, such as:

  • 142.250.72.14
  • 2404:6800:4004:81b::200e

Now imagine trying to remember IP addresses for every website you use. That would be painful and honestly impossible.

That’s why DNS exists.

DNS (Domain Name System) is basically a distributed phonebook for the internet.

You ask:

“What is the IP for google.com?”

DNS replies:

“Here it is.”

This process converting a domain name into an IP address is called name resolution.

1.2 Why name resolution is important

Name resolution exists for some very practical reasons:

  • Humans prefer names, not numbers
  • Servers and IP addresses can change over time
  • We want stable domain names even if infrastructure changes

DNS also enables some powerful features:

  • Load balancing - one domain can point to multiple IPs
  • High availability – traffic can move if a server goes down
  • Geo routing – users get routed to the nearest server

So DNS isn’t just a lookup table. It’s an abstraction layer that makes the internet flexible and scalable.

2. What Is dig and Why Do People Use It?

dig stands for Domain Information Groper. The name sounds funny, but the tool itself is serious.

2.1 What dig actually does

dig is a command-line utility that lets you directly question DNS servers.

For example:

dig google.com
Enter fullscreen mode Exit fullscreen mode

This command shows you:

  • What question was asked
  • What DNS server answered
  • Which records came back
  • Extra DNS details that browsers usually hide

With dig, you can ask things like:

  • “What IP does this domain resolve to?”
  • “Which name servers manage this TLD?”
  • “Who is authoritative for this domain?”

2.2 When dig is useful in real life

You usually reach for dig when:

  • A website isn’t loading and DNS might be the issue
  • You updated DNS records and want to check propagation
  • You’re learning networking or backend systems
  • You’re working in DevOps, cloud, or infrastructure

If curl is essential for HTTP debugging, dig plays the same role for DNS.

3. DNS Is Hierarchical (This Part Is Very Important)

DNS is not flat. It is organized in layers.

Think of it like a tree structure:

  • Root (.) – the top of everything
  • TLDs – .com, .org, .net, .in, .io, etc
  • Domains – google.com, example.com
  • Subdomains – www.google.com, api.example.com

Each layer knows just enough and points you to the next one.

3.1 Who knows what?

  • Root servers
    Know which servers handle each TLD

  • TLD servers (.com, .org, etc.)
    Know which servers handle domains under them

  • Authoritative servers
    Know the actual DNS records for a domain

Your recursive resolver (ISP DNS, 8.8.8.8, 1.1.1.1, etc.) walks through these layers on your behalf.

4. dig . NS – Starting at the Root

Let’s begin from the very top.

dig . NS
Enter fullscreen mode Exit fullscreen mode

4.1 What this command is asking

  • . means the root of DNS
  • NS asks for Name Server records

So the question is:

“Which name servers are responsible for the DNS root?”

4.2 What you’ll see

You’ll get results like:

  • a.root-servers.net
  • b.root-servers.net
  • …
  • m.root-servers.net

There are 13 logical root servers, but each one is backed by many physical servers around the world.

4.3 Why root servers matter

Root servers:

  • Don’t know IPs for websites
  • Don’t know google.com directly
  • Only know who manages TLDs like .com

They basically say:

“I don’t know the answer, but I know who to ask next.”

5. dig com NS – The TLD Layer

Now let’s move one level down.

dig com NS
Enter fullscreen mode Exit fullscreen mode

5.1 What this means

You’re asking:

“Which name servers are responsible for the .com domain?”

5.2 Typical output

You’ll see servers like:

  • a.gtld-servers.net
  • b.gtld-servers.net
  • …

These are TLD name servers for .com.

5.3 What TLD servers do

TLD servers don’t store IP addresses for every website.

Instead, they know:

  • Which servers are authoritative for google.com
  • Which servers are authoritative for facebook.com

So their answer is basically:

“I don’t know the IP, but these servers are allowed to answer for google.com.”

6. dig google.com NS – Authoritative Name Servers

Now we reach the domain itself.

dig google.com NS
Enter fullscreen mode Exit fullscreen mode

6.1 What this command asks

“Which name servers are authoritative for google.com?”

6.2 What you’ll see

Usually something like:

  • ns1.google.com
  • ns2.google.com
  • ns3.google.com
  • ns4.google.com

These servers are controlled by Google and are the source of truth for that domain.

6.3 Why authoritative servers are important

Authoritative servers store real DNS records:

  • A / AAAA → IP addresses
  • MX → mail servers
  • TXT → verification, SPF, etc
  • CNAME → aliases

When asked:

“What is the IP for google.com?”

They can answer directly.

From a system design view, this is where your domain configuration actually lives.

7. dig google.com – The Complete DNS Lookup

Now the most common command.

dig google.com
Enter fullscreen mode Exit fullscreen mode

7.1 What happens behind the scenes

When you run this:

  1. Your recursive resolver checks cache
  2. If not found, it asks root servers
  3. Then it asks .com TLD servers
  4. Then it asks google.com authoritative servers
  5. It returns the final IP

dig then prints:

  • QUESTION section
  • ANSWER section
  • Sometimes AUTHORITY and ADDITIONAL info

7.2 Why you don’t see all steps by default

Normally, recursive resolvers hide this complexity.

To force every step to be shown, you can use:

dig +trace google.com
Enter fullscreen mode Exit fullscreen mode

This displays the full root → TLD → authoritative journey.

8. How Recursive Resolvers Tie Everything Together

Assume nothing is cached.

  1. Browser needs google.com
  2. OS asks the recursive resolver
  3. Resolver asks root
  4. Root points to .com
  5. .com points to google.com NS
  6. Authoritative server gives IP
  7. Resolver caches it (TTL)
  8. Browser connects using TCP/TLS

DNS finishes before HTTP even starts.

9. Why This Matters in Real Systems

DNS directly affects:

  • Website performance
  • Application availability
  • CDN routing
  • Multi-region architectures
  • Failover strategies

A broken DNS setup can make a perfectly healthy server look “down”.

Understanding DNS and dig makes you better at:

  • Debugging
  • Designing scalable systems
  • Working with cloud and infra

10. Final Recap

  • DNS maps domain names to IP addresses
  • Name resolution exists for usability and flexibility
  • dig helps inspect DNS behavior

  • DNS works in layers:

    • Root → dig . NS
    • TLD → dig com NS
    • Authoritative → dig google.com NS
    • Final IP → dig google.com

  • Recursive resolvers walk these layers for you

To practice, try running:

dig . NS
dig com NS
dig google.com NS
dig google.com
Enter fullscreen mode Exit fullscreen mode

Slowly, step by step.

Once this clicks, DNS stops feeling confusing and starts feeling logical.

Happy learning....

Top comments (0)