DNS, or Domain Name System, is the unsung hero powering every website you visit. Think of it as the internet's phonebook, translating memorable names like "google.com" into IP addresses computers actually use, like 142.250.190.78. Without name resolution, we'd be typing endless number strings—humans prefer words, machines need numbers, so DNS bridges that gap seamlessly.

This detailed guide dives deep into DNS layers using the dig command, a Swiss Army knife for DNS diagnostics. We'll trace queries from root servers to your browser, building a system-design mindset perfect for developers deploying on Vercel or debugging healthcare apps. Expect practical examples, output breakdowns, and real-world ties—aiming for a 9-minute read to solidify your understanding.

When you type google.com into your browser, something remarkable happens in milliseconds: your computer transforms that human-friendly name into an IP address like 142.250.185.46. This transformation is handled by the Domain Name System (DNS), often called the internet's phonebook. But unlike a physical phonebook, DNS is a distributed, hierarchical system that queries multiple servers to find the right answer.

In this post, we'll explore DNS from the ground up using dig, a powerful command-line tool that lets us peek behind the curtains of name resolution.

DNS: The Internet's Distributed Directory

Imagine if every time you wanted to call someone, you had to remember their phone number instead of their name. That's what the internet would be like without DNS. Every website, service, and server on the internet has an IP address (like 172.217.14.206), but we humans prefer memorable names like google.com or github.com.

DNS solves this problem, but not by maintaining one giant centralized database. Instead, it uses a hierarchical, distributed system where responsibility is delegated across thousands of servers worldwide. This design provides redundancy, scalability, and allows organizations to manage their own domains independently.

Meet dig: Your DNS Diagnostic Tool

Before diving into DNS architecture, let's introduce our primary tool: dig (Domain Information Groper). While most applications use DNS transparently in the background, dig lets us interact with DNS servers directly and see exactly what's happening during name resolution.

Think of dig as a diagnostic microscope for DNS. It allows us to:

• Query specific DNS servers

• Request particular types of DNS records

• Trace the resolution path from root to authoritative servers

• Debug DNS configuration issues

• Understand caching and TTL (Time To Live) values

The basic syntax is simple: dig [domain] [record-type]. But as we'll see, understanding what happens behind this simple command reveals the elegant architecture of the entire internet.

The DNS Hierarchy: Root → TLD → Authoritative

DNS resolution follows a hierarchical structure with three main levels:

1. Root Name Servers: The top of the DNS hierarchy, knowing where to find TLD servers

2. TLD (Top-Level Domain) Name Servers: Responsible for domains like .com, .org, .uk

3. Authoritative Name Servers: Hold the actual IP addresses for specific domains

Let's explore each layer by using dig to query them directly.

Layer 1: Root Name Servers with dig . NS

At the very top of the DNS hierarchy sit the root name servers. There are 13 root server identifiers (labeled A through M), though each identifier actually represents multiple servers distributed globally using anycast routing.

Let's query the root servers:

dig . NS

The . (dot) represents the root of the DNS namespace, and NS asks for Name Server records. You'll see output like:

;; ANSWER SECTION:
.                   86400   IN   NS   a.root-servers.net.
.                   86400   IN   NS   b.root-servers.net.
.                   86400   IN   NS   c.root-servers.net.
...
.                   86400   IN   NS   m.root-servers.net.

What does this mean?

Each line tells us about a root name server. The 86400 is the TTL (Time To Live) in seconds—24 hours—indicating how long this information can be cached. The IN stands for "Internet" (a class designation from DNS's early days). NS indicates these are Name Server records.

Why root servers matter:

Root servers don't know the IP address of google.com, but they know who does. When a recursive resolver (like your ISP's DNS server) needs to resolve a domain it hasn't cached, it starts by asking a root server: "Who handles .com domains?" The root server responds with the addresses of the .com TLD servers.

Think of root servers as the reception desk of the internet—they don't have everyone's contact information, but they know which department to send you to.

Layer 2: TLD Name Servers with dig com NS

Once we know where the .com TLD servers are, let's query them:

dig com NS

This asks: "Who are the authoritative name servers for the .com top-level domain?" The output shows:

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

What's happening here?

The .com TLD is managed by Verisign, which operates these gtld-servers.net name servers. Notice the TTL is 172800 seconds (48 hours)—TLD information changes rarely, so it can be cached longer.

The TLD layer's role:

TLD servers are like specialized directories. The .com servers know about every domain registered under .com, the .org servers know about .org domains, and so on. When you ask them about google.com, they don't return the IP address directly. Instead, they tell you which name servers are authoritative for that specific domain.

This delegation model is powerful: Verisign manages the .com infrastructure, but Google manages its own authoritative servers. This separation of concerns allows the system to scale globally.

Layer 3: Authoritative Name Servers with dig google.com NS

Now let's find out who Google has designated as authoritative for their domain:

dig google.com NS

The response shows:

;; ANSWER SECTION:
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.

Understanding authoritative servers:

These are Google's own name servers—the final authority for anything under google.com. When you ask for mail.google.com, drive.google.com, or just google.com, these servers provide the definitive answer.

The TTL here is 21600 seconds (6 hours). This is shorter than TLD records because organizations might need to change their name servers more frequently than TLD infrastructure changes.

Why multiple name servers?

Notice there are four name servers listed. This redundancy is critical:

• If one server fails, others can still respond

• Load can be distributed across multiple servers

• Geographically distributed servers reduce latency

Most domain registrars require at least two name servers for this reason.

The Full Resolution: diggoogle.com

Finally, let's query for the actual IP address:

dig google.com

The output includes several sections:

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)

Breaking down the response:

• QUESTION SECTION: Shows what we asked for—an A record (IPv4 address) for google.com

• ANSWER SECTION: The actual IP address, with a TTL of just 300 seconds (5 minutes)

• Query time: How long the query took

• SERVER: Which DNS server we queried (in this case, Google's public DNS at 8.8.8.8)

Why such a short TTL?

Notice the TTL for the actual IP address is only 5 minutes, much shorter than the NS records. This is intentional. Large services like Google use short TTLs because they:

• Load balance across multiple IP addresses

• Need flexibility to redirect traffic during outages

• Want to update IPs without long propagation delays

Behind the Scenes: The Recursive Resolver's Journey

When your browser needs to resolve google.com, it doesn't perform all these steps itself. Instead, it asks a recursive resolver (typically provided by your ISP or a public DNS service like 8.8.8.8 or 1.1.1.1) to do the heavy lifting.

Here's what the recursive resolver does on your behalf:

1. Check cache: Does it already know the answer? If yes, return it immediately

2. Query root: "Where are the .com servers?" → Gets list of TLD servers

3. Query TLD: "Where are the authoritative servers for google.com?" → Gets Google's name servers

4. Query authoritative: "What's the IP for google.com?" → Gets the actual IP address

5. Return and cache: Send the answer back and cache it according to TTL

This entire process typically completes in milliseconds, even though it involves multiple servers potentially distributed across continents.

Caching is crucial:

Without caching, every DNS query would require this multi-step process. Imagine billions of devices querying root servers for every website request! Caching at multiple levels (browser, OS, recursive resolver) keeps the system performant:

• Your browser might cache for the duration of your session

• Your OS might cache according to TTL

• The recursive resolver caches according to TTL

• Even authoritative servers might have internal caches

Practical Implications for System Design

Understanding DNS resolution has several practical implications:

For developers:

• Set appropriate TTLs based on how frequently you update records (short for dynamic IPs, longer for stable infrastructure)

• Use multiple authoritative name servers in different locations

• Consider using a DNS provider with global presence to reduce latency

• Be aware that DNS changes aren't instant—plan migrations with TTL in mind

For troubleshooting:

• Use dig with +trace to see the full resolution path: dig +trace google.com

• Query specific servers with @: dig @8.8.8.8 google.com

• Check different record types: dig google.com MX for mail servers, dig google.com AAAA for IPv6

For performance:

• DNS resolution adds latency to every new connection

• Services like DNS prefetching can reduce perceived latency

• CDN edge servers often have co-located DNS resolvers to minimize lookup time

Conclusion: A System That Just Works

DNS is one of those fundamental internet technologies that most people never think about—it simply works. But understanding its hierarchical structure and the role of each layer helps us appreciate both its elegance and resilience.

The beauty of DNS lies in its simplicity and delegation:

• Root servers delegate to TLD servers

• TLD servers delegate to authoritative servers

• Authoritative servers provide the final answer

• Caching at every level ensures performance

Next time you type a URL, remember the invisible journey happening in milliseconds: your query traveling through layers of servers, each doing its specific job, collaborating to translate a name into a number so your browser can finally connect.

The dig command gives us a window into this process, transforming DNS from magic into understandable, debuggable infrastructure. Whether you're a developer deploying services, a system administrator troubleshooting connectivity, or simply curious about how the internet works, understanding DNS through tools like dig empowers you to build better systems and solve problems more effectively.

Try it yourself: Open a terminal and run dig +trace google.com to watch the entire resolution process unfold in real-time. You'll see your query travel from root to TLD to authoritative servers, each step of the journey visible and understandable.

First things first …

What is DNS?

Domain name system server (abbreviated as DNS) in simpler terms is a phonebook of internet that translates human-readable domain names to numerical ip address. Inorder to crack interview this won’t sufficient right? So here we go. . Domain Name System is a hirerachial and distributed naming system that translates human readable domain names to numerical or machine readable ip addresses. DNS helps with the following aspects -

• Eliminates the need to remember ip addresses.

• It supports caching and improves retrieval speed.

• It uses TLD,authorative DNS server and root server.

• Converts human-readable address into (let’s say I am taking geeksforgeeks here for reference ) ip address.

There are four DNS servers involved in loading a website:-

1. DNS Recursor :- Now DNS recursor is more like a librarian who is asked a particular book from library. This is specifically designed to recieve queries from client machines in the form of browsers . Basically it helps in DNS query made by client by creating additional request.

2. root name server:- Root name server is a destination where human readable host names are translated into IP addresses. It acts like key in a hashmap that helps in retrieving value from the table.

3. Top level Domain (TLD):- The top level domain server (TLD) can be thought of as a specific rack of books in a library. This nameserver is the next step in the search for a specific IP address, and it hosts the last portion of a hostname (In geeksforgeeks.org the TLD server is “org”).

4. Authoritative nameserver - This final nameserver can be thought of as a dictionary on a rack of books, in which a specific name can be translated into its definition. The authoritative nameserver is the last stop in the nameserver query. If the authoritative name server has access to the requested record, it will return the IP address for the requested hostname back to the DNS Recursor (the librarian) that made the initial request.

Steps in DNS Lookup

The 8 steps in a DNS lookup:

1. A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.

2. The resolver then queries a DNS root nameserver (.).

3. The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.

4. The resolver then makes a request to the .com TLD.

5. The TLD server then responds with the IP address of the domain’s nameserver, example.com.

6. Lastly, the recursive resolver sends a query to the domain’s nameserver.

7. The IP address for example.com is then returned to the resolver from the nameserver.

8. The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

9. Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page:

10. The browser makes a HTTP request to the IP address.

11. The server at that IP returns the webpage to be rendered in the browser (step 10).

Diagram - DNS Lookup

Dns Records

1. A records : A in A record stands for address and this is the most fundamental type in DNS record : it indicates IP address of a given domain. For example, if you pull the DNS records of geekforgeek.org, the A record currently returns an IP address of: 104.17.210.9. A record in most of the cases is the last record from where we can retrieve IP address of host name. A record specifically works for ipv4 address.

2. AAAA record : AAAA record specifically works for all ipv6 addresses where A record doesn’t comes into picture.

3. CNAME record : A "canonical name" (CNAME) record points from an alias domain to a "canonical" domain. A CNAME record is used in lieu of an A record, when a domain or subdomain is an alias of another domain. All CNAME records must point to a domain, never to an IP address. Imagine a scavenger hunt where each clue points to another clue, and the final clue points to the treasure. A domain with a CNAME record is like a clue that can point you to another clue (another domain with a CNAME record) or to the treasure (a domain with an A record).

   For example, suppose blog.example.com has a CNAME record with a value of "swayam.geeksforgeeks.org" (without the "swayam"). This means when a DNS server hits the DNS records for blog.example.com, it actually triggers another DNS lookup to example.com, returning example.com’s IP address via its A record. In this case we would say that example.com is the canonical name (or true name) of swayam.geeksforgeeks.org.

4. MX record: A DNS 'mail exchange' (MX) record directs email to a mail server. The MX record indicates how email messages should be routed in accordance with the Simple Mail Transfer Protocol (SMTP,the standard protocol for all email).

   

   The 'priority' numbers before the domains for these MX records indicate preference; the lower 'priority' value is preferred. The server will always try mailhost1 first because 10 is lower than 20. In the result of a message send failure, the server will default to mailhost2.

   The email service could also configure this MX record so that both servers have equal priority and receive an equal amount of mail:

   

5. TXT record: The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain Name System (DNS). Text is stored in the form of one or more strings within quotation marks. The TXT record was originally intended as a place for human-readable notes. However, now it is also possible to put some machine-readable data into TXT records. One domain can have many TXT records.

Example of a TXT record:

6. NS record:NS stands for ‘nameserver,’ and the nameserver record indicates which DNS server is authoritative for that domain (i.e. which server contains the actual DNS records). Basically, NS records tell the Internet where to go to find out a domain's IP address. A domain often has multiple NS records which can indicate primary and secondary nameservers for that domain. Without properly configured NS records, users will be unable to load a website or application.

   A nameserver is a type of DNS server. It is the server that stores all DNS records for a domain, including A records, MX records, or CNAME records.

   Almost all domains rely on multiple nameservers to increase reliability: if one nameserver goes down or is unavailable, DNS queries can go to another one. Typically there is one primary nameserver and several secondary nameservers, which store exact copies of the DNS records in the primary server. Updating the primary nameserver will trigger an update of the secondary nameservers as well.

   When multiple nameservers are used (as in most cases), NS records should list more than one server.