# How DNS Resolution Works

We call our friends by their names, talk with them, and they respond to our questions. There's nothing special about that, right? But what about computers? They only understand numbers and can't understand names. One device can't call Google and say, "Hey Google, let me get this one." So, how do they communicate with each other? Do they have something special or magical for this?

The answer is actually 'Yes.' That special thing is the network. For computers to communicate, they use the internet and certain protocols. But to share data between two computers, one needs to know the other's address. So, how does one computer know about another computer to connect? That’s where DNS comes into the picture. DNS makes sure that a client gets the IP address to communicate.

Technical analogy: Think of DNS as the Internet’s phonebook.

Humans remember names like google.com. Computers do not work with names. They only understand numbers called IP addresses, like 142.250.190.14. DNS is the system that connects these two. When you type a website name into your browser, DNS looks it up and finds the correct IP address, just like a phonebook helps you find a person’s phone number from their name. Once the IP address is found, your browser knows exactly where to go and can connect to the website’s server. Without DNS, you would have to remember long numeric addresses for every website, which is impractical and error-prone.

## DNS hierarchy

Let's briefly understand how computers connect to each other.

When we type a domain name like **example.com** into a browser, the browser first checks if it already knows the IP address. It looks in the browser cache, then the operating system cache, and sometimes the router cache. If the IP address is found at any of these levels, DNS resolution stops there, and the browser connects directly to the server. This caching step speeds up the process and reduces unnecessary network traffic.

If the IP address is not found in the cache, the request is sent to a **recursive resolver**, usually provided by your Internet Service Provider or a public DNS service like Google DNS or Cloudflare. The recursive resolver is responsible for finding the correct IP address on behalf of the client.

The recursive resolver starts by querying a **root DNS server**. Root servers do not know the website’s IP address, but they know where to find information about top-level domains (TLDs). The root server responds with the address of the appropriate TLD server, such as .com, .org, or .in.

Next, the resolver contacts the **TLD server**. The TLD server also does not hold the final IP address but knows which **authoritative name server** manages the domain. It replies with the authoritative server’s address.

Finally, the recursive resolver queries the **authoritative DNS server**, which holds the actual DNS records for the domain, including the A or AAAA record containing the IP address. The authoritative server returns the IP address to the resolver, which then passes it back to your browser.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769617032763/ce5ecf20-de72-4c58-8aaa-1cdb2d072df0.png align="center")

Once the browser has the IP, it can connect to the web server. In this way, **recursive resolvers handle all the steps behind the scenes**, allowing computers to find each other using domain names and communicate seamlessly.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769617205811/a146e4d6-9a1b-4cbd-ae94-90f7400f62a4.png align="center")

## The dig commands

In normal browsing, DNS resolution happens silently in the background, so we never see the individual steps involved. To inspect DNS resolution directly, we use the **dig** command.

The **dig** command, short for Domain Information Groper, is a diagnostic tool used to query DNS servers and understand how DNS resolution works. Unlike a browser, which simply uses the final IP address, dig shows the full DNS response returned by a server.

When a domain name is queried using dig, it sends a direct request to a DNS server and displays detailed information such as the resolved IP address, the DNS record type, the responding server, and whether the answer is authoritative or served from cache. Because of this low-level visibility, dig is especially useful for debugging and learning DNS behavior.

Using dig, we can observe how a domain like [**google.com**](http://google.com) is resolved step by step at the DNS level, before any connection to the actual application is made.

### dig . NS

**NS (Name Server) records** are a type of DNS record that specify which **servers are authoritative** for a particular domain. In simple terms, an NS record tells the internet:

*"If you want information about this domain, ask these servers."*

These records are very important because they **define the chain of trust in DNS resolution**.

The command ‘**dig . NS**’ shows the **root name servers**, which are the first servers a recursive resolver contacts when it does not have cached information.

These root servers do not know Google’s IP address. Instead, they tell the resolver **where to find information about** `.com` domains. In the context of Google, this step directs the resolver toward the `.com` Top-Level Domain servers, which is the next place to look for [google.com](http://google.com).

This is the starting point of Google’s DNS resolution.

In short, ‘**dig . NS’** lets you see the root servers that guide all DNS lookups, helping you understand how domain names eventually translate into IP addresses.

### dig com NS

After contacting a root server, the resolver moves to the next level.  
The command ‘**dig com NS**’ shows the **authoritative name servers for the** .com TLD.

For google.com, these .com servers still do not provide Google’s IP address. Instead, they tell the resolver **which authoritative name servers are responsible for google.com**. This step narrows the search from all .com domains to Google’s own DNS infrastructure.

This is how DNS moves from a general domain zone to Google’s specific domain.

### dig google.com NS

The command ‘**dig google.com’** NS queries the **authoritative name servers for** [**google.com**](http://google.com).  
These servers are managed by Google and are responsible for holding Google’s DNS records.

At this stage, the resolver learns **which servers can give the final answer** for google.com, such as its IP addresses, mail servers, and other records. These name servers are the official source of truth for Google’s domain.

This step confirms where Google’s DNS is actually hosted.

### dig google.com

Finally, ‘**dig google.com’** retrieves the **actual IP address** for google.com.  
The recursive resolver asks Google’s authoritative name servers and receives an **A or AAAA record** containing the IP address.

Once this IP is returned, the browser uses it to establish an **HTTP or HTTPS connection** to Google’s servers.  
This is the exact address your browser connects to when you open google.com.

In short, this command shows the final DNS answer that makes accessing Google possible.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769618994406/8347eb17-e05a-4886-afc4-10fcdeb5f55e.png align="center")

DNS is the backbone of the internet, translating human-friendly domain names into machine-readable IP addresses. Recursive resolvers handle the complex process of querying root, TLD, and authoritative servers behind the scenes, ensuring browsers can quickly and reliably connect to websites.

Tools like **dig** allow us to inspect this process, understand the hierarchy of DNS, and troubleshoot issues effectively. Without DNS, the internet as we know it—fast, accessible, and user-friendly—would not be possible.