DNS: The Internet’s Phone Book

What is DNS and Why Name Resolution Exists

Imagine if you had to remember everyone's phone number instead of just their names. That would be a nightmare.

The Internet has the same problem. Every device connected to the Internet has an IP address - a numerical identifier like 142.250.185.46. Computers love these numbers because they can process them incredibly fast using binary math. But humans are terrible at remembering long strings of numbers.

This is where DNS (Domain Name System) comes in. DNS is like a giant, distributed phone book for the Internet. It translates human-friendly names (like www.google.com) into computer-friendly IP addresses (like 142.250.185.46).

Why we need name resolution:

1. Human memory: We remember "facebook.com" much better than "157.240.241.35"

2. Flexibility: If Google changes their server's IP address, they just update DNS - users keep typing "google.com" and never notice

3. Multiple services: One domain can point to different IPs for different services (mail.google.com vs. drive.google.com)

4. Load balancing: One domain name can resolve to multiple IP addresses for distributing traffic

The fundamental problem DNS solves is bridging the gap between what humans find memorable (words) and what computers find efficient (numbers).

The Dig Command

dig (Domain Information Groper) is a command-line tool that lets us query DNS servers and see exactly how name resolution works under the hood. It's like being able to peek inside the phone book and see not just the final number, but how the phone company's directory system found it.

Basic syntax:

dig [domain-name] [record-type]

Use cases of dig command includes

• Troubleshooting: Website not loading? Use dig to check if DNS is resolving correctly

• Learning: Understanding how DNS hierarchy works

• Verification: Checking if your DNS changes have propagated

• Security: Investigating suspicious domains or potential DNS hijacking

Simple example:

dig google.com

This asks: "What's the IP address for google.com?" But dig shows you much more than just the answer - it shows you the entire lookup process, which servers were queried, how long it took, and metadata about the response.

Let's explore DNS from the ground up using dig to understand the hierarchical structure.

Understanding dig . NS and Root Name Servers

The DNS system is hierarchical, like a tree. At the very top are the root name servers - the starting point for all DNS lookups.

Command:

dig . NS

The . represents the DNS root - the absolute top of the hierarchy.

What this returns:

. 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.

Breaking this down:

• .: The root zone

• 518400: TTL (Time To Live) in seconds - how long to cache this information (6 days)

• IN: Internet class (historical; almost always IN)

• NS: Name Server record

• a.root-servers.net. through m.root-servers.net.: The 13 root name server addresses

What are root name servers?

There are 13 root name server addresses (named A through M), but these aren't 13 physical computers. Using a technique called anycast, each "root server" is actually hundreds of physical servers distributed worldwide. There are over 1,000 root server instances globally.

What root servers know:

Root servers don't know the IP address of google.com or any specific website. They only know one thing: which servers are authoritative for each top-level domain (TLD).

When you ask a root server about "google.com", it responds: "I don't know about google.com, but I know who handles all .com domains - go ask them.

<aside> 💡

It never hurts to know one more thing!

</aside>

Why 13?

This is a historical limitation. DNS uses UDP for queries, and UDP packets are limited in size. The response listing all root servers had to fit in a single UDP packet (512 bytes originally). Fitting 13 server addresses was the maximum. (Modern DNS can use larger packets, but we keep 13 for backward compatibility.)

Who operates them?

Different organizations operate root servers:

• VeriSign: A and J root servers

• USC Information Sciences Institute: B root

• Cogent Communications: C root

• University of Maryland: D root

• NASA: E root

• Internet Systems Consortium: F root

• US Defense Information Systems Agency: H root

• Netnod (Sweden): I root

• RIPE NCC (Netherlands): K root

• ICANN: L root

• WIDE Project (Japan): M root

This distributed governance prevents any single entity from controlling the Internet's root.

Understanding dig com NS and TLD Name Servers

One level down from the root are TLD (Top-Level Domain) name servers. These handle domains like .com, .org, .net, .edu, and country codes like .in, .uk, .jp.

Command:

dig com NS

What this returns:

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.

Breaking this down:

• com.: The .com top-level domain

• 172800: TTL of 2 days

• NS: Name Server records

• a.gtld-servers.net. through m.gtld-servers.net.: The 13 name servers for .com domains

What TLD servers know:

TLD servers for .com know which authoritative name servers handle each specific .com domain. They maintain a registry of all domains under their TLD.

When you ask a .com TLD server about "google.com", it responds: "I don't know google.com's IP address, but I know which name servers Google uses - go ask ns1.google.com."

Who manages TLDs?

• Generic TLDs (gTLDs): .com, .net, .org

  • VeriSign operates .com and .net

  • Public Interest Registry operates .org

• Country Code TLDs (ccTLDs): .in, .uk, .jp

  • Each country designates an organization

  • India's .in managed by NIXI (National Internet Exchange of India)

• New gTLDs: .app, .dev, .blog, .tech

  • Various companies manage these (Google, Amazon, etc.)

Understanding dig google.com NS and Authoritative Name Servers

At the bottom of the hierarchy are authoritative name servers - the servers that have the definitive, authoritative information about a specific domain.

Command:

bash

dig google.com NS

What this returns:

google.com. 21600 IN NS ns1.google.com. google.com. 21600 IN NS ns2.google.com. google.com. 21600 IN NS ns3.google.com. google.com. 21600 IN NS ns4.google.com.

Breaking this down:

• google.com.: The specific domain we're asking about

• 21600: TTL of 6 hours

• NS: Name Server records

• ns1.google.com. through ns4.google.com.: Google's authoritative name servers

What authoritative name servers know:

These servers contain the actual DNS records for the domain - the final answers:

• A records: IPv4 addresses (google.com → 142.250.185.46)

• AAAA records: IPv6 addresses

• MX records: Mail servers (where to send email)

• CNAME records: Aliases (www.google.com → google.com)

• TXT records: Text data (verification, security policies)

When you ask ns1.google.com about "google.com", it responds with the actual IP address - this is the final answer.

Who controls authoritative servers?

The domain owner (Google, in this case) controls their authoritative name servers. When you register a domain, you specify which name servers are authoritative for it. This is how domain ownership works at a technical level.

Redundancy:

Notice Google has 4 name servers (ns1, ns2, ns3, ns4). This is for:

1. Reliability: If one fails, others still work

2. Load distribution: Millions of queries distributed across servers

3. Geographic distribution: Servers in different locations for faster response

Most domains have 2-4 authoritative name servers as a best practice.

The complete hierarchy:

Root (.) └── .com (TLD) └── google.com (Authoritative) ├── www.google.com → IP address ├── mail.google.com → IP address └── drive.google.com → IP address

Understanding dig google.com and the Full DNS Resolution Flow

Now let's see how all these pieces work together when you actually look up a domain.

Command:

dig google.com

What this returns:

`; <<>> DiG 9.18.24 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION: ;google.com. IN A

;; ANSWER SECTION: google.com. 300 IN A 142.250.185.46

;; Query time: 23 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jan 24 10:30:00 IST 2025 ;; MSG SIZE rcvd: 55`

Breaking down the output:

1. Header:

• opcode: QUERY: This is a standard query

• status: NOERROR: Query succeeded (alternatives: NXDOMAIN = domain doesn't exist, SERVFAIL = server error)

• flags:

  • qr: Query Response (this is a response, not a query)

  • rd: Recursion Desired (we asked for recursive lookup)

  • ra: Recursion Available (server supports recursion)

2. Question Section:

;google.com. IN A

• We asked: "What is the A record (IPv4 address) for google.com in the Internet class?"

3. Answer Section:

google.com. 300 IN A 142.250.185.46

• google.com: The domain we queried

• 300: TTL of 5 minutes (cache this for 5 minutes)

• IN: Internet class

• A: Address record (IPv4)

• 142.250.185.46: The IP address!

4. Query Stats:

• Query time: 23 msec: Took 23 milliseconds to get answer

• SERVER: 8.8.8.8: We queried Google's public DNS server

The Complete DNS Resolution Flow (Step-by-Step)

What actually happens behind the scenes when you run dig google.com? Let's trace the complete journey:

Step 1: Check Local Cache

Your computer first checks:

1. Browser DNS cache: "Have I visited google.com recently?"

2. Operating system DNS cache: "Does my OS have this cached?"

If found (cache hit), return the IP immediately. If not (cache miss), continue to Step 2.

Step 2: Query Recursive Resolver

Your computer sends the query to a recursive DNS resolver (also called a recursive name server). This is typically:

• Your ISP's DNS server

• Or a public DNS service like:

  • Google DNS: 8.8.8.8 / 8.8.4.4

  • Cloudflare DNS: 1.1.1.1 / 1.0.0.1

  • Quad9: 9.9.9.9

The recursive resolver's job is to do all the work of finding the answer for you.

Step 3: Recursive Resolver Checks Its Cache

The resolver checks: "Have I looked up google.com recently?"

If cached and not expired (TTL hasn't elapsed), return answer immediately. Otherwise, begin the resolution process.

Step 4: Query Root Server

Resolver asks a root server: "Where can I find information about google.com?"

Root server responds: "I don't know about google.com specifically, but here are the name servers for .com domains:"

com. NS a.gtld-servers.net. com. NS b.gtld-servers.net. ...

The root server also includes "glue records" (IP addresses of the TLD servers) so the resolver knows where to send the next query.

Step 5: Query TLD Server

Resolver picks one of the .com TLD servers (say, a.gtld-servers.net) and asks: "Where can I find information about google.com?"

TLD server responds: "I don't know google.com's IP, but here are Google's authoritative name servers:"

google.com. NS ns1.google.com. google.com. NS ns2.google.com. google.com. NS ns3.google.com. google.com. NS ns4.google.com.

Again, includes glue records (IPs of Google's name servers).

Step 6: Query Authoritative Server

Resolver picks one of Google's name servers (say, ns1.google.com) and asks: "What is the IP address for google.com?"

Authoritative server responds with the definitive answer:

google.com. 300 IN A 142.250.185.46

This is the actual IP address!

Step 7: Return Answer and Cache

The recursive resolver:

1. Caches the answer for 300 seconds (5 minutes, based on TTL)

2. Returns the IP to your computer

3. Your computer caches it as well

4. Your computer returns it to your browser

Step 8: Browser Connects

Now that the browser has the IP address (142.250.185.46), it can:

1. Establish a TCP connection to that IP

2. Perform TLS handshake for HTTPS

3. Send HTTP request

4. Receive the webpage

Visual Flow:

You └─> Recursive Resolver (8.8.8.8) └─> Root Server (a.root-servers.net) └─> "Ask .com TLD servers" └─> TLD Server (a.gtld-servers.net) └─> "Ask ns1.google.com" └─> Authoritative Server (ns1.google.com) └─> "142.250.185.46" ← Returns IP to you

Total time: Typically 20-100 milliseconds for a full resolution (if nothing is cached). Much faster if cached (1-5 milliseconds).

<aside> 💡

Great tool!

</aside>

Seeing the Full Resolution with dig +trace

Want to see all these steps in action? Use the +trace flag:

dig +trace google.com

This shows you each step of the resolution:

1. Query to root servers

2. Referral to .com TLD servers

3. Referral to google.com authoritative servers

4. Final answer

It's like watching the DNS hierarchy being traversed in real-time!

Why This Hierarchical System?

1. Scalability:

• No single server needs to know about all domains

• Work distributed across millions of servers worldwide

2. Reliability:

• If one server fails, others handle the load

• Redundancy at every level

3. Speed:

• Caching at multiple levels

• Geographic distribution brings servers closer to users

4. Decentralization:

• No single point of control

• Domain owners control their own authoritative servers

5. Flexibility:

• Change IP addresses without users noticing

• Load balancing across multiple IPs

• Different IPs for different geographic locations

Conclusion

DNS is one of the Internet's most critical yet invisible systems. Every time we type a URL, click a link, or send an email, DNS is working behind the scenes to translate names into addresses.

The dig command lets us peek behind the curtain and see this hierarchical system in action:

• Root servers (.) know about TLDs

• TLD servers (.com) know about domain name servers

• Authoritative servers (ns1.google.com) know the actual IP addresses

This three-level hierarchy, combined with caching at every stage, enables billions of DNS queries per day with millisecond response times.

Understanding DNS helps us troubleshoot network issues, verify domain configurations, and appreciate the elegant engineering that makes the Internet usable for humans while remaining efficient for computers.