DNS resolution

DNS is the Domain Name System. As the name suggests, it is basically a system that has been created to manage domains. Simply put, domains are the names of the websites that users visit. Although computers don’t understand human language like English, for users it is very difficult to remember websites in a computer-understandable language. Hence, this system came into place which basically converts the name of the website into computer-understandable language internally, called IP addresses.

So every website is given an IP address, which is nothing but the address where the code of the website is deployed, indicating on which server in the world it is hosted. Just like we humans live in houses and each house has an address associated with it which helps us identify its location in the world, websites have IP addresses which help in identifying the address where the code is deployed or “living” in the server’s world.
So, DNS resolution is the process of converting a human-readable domain name into its corresponding IP address.
This allows browsers and applications to locate and communicate with the correct server on the internet.

dig (Domain Information Groper) is a command-line tool used to query DNS servers and fetch information like IP addresses, MX records, or name servers for a domain.

Now, first understand a few terms related to DNS servers.
Firstly, what are DNS servers? They are basically servers that track DNS records. For storing the IP addresses of websites, we have dedicated servers called DNS servers, and within them there are further classifications.

Firstly, recursive DNS servers. These are the servers that browsers talk to directly, or in other words, browsers send their DNS queries to these servers first. They cache IP addresses, and if a particular IP is not cached, they internally follow the DNS resolution process to get the IP, which they then cache and also send back to the client who requested it.

Internally, the request first goes to the root servers, which are basically 13 logical root server groups. These servers keep track of which servers handle which top-level domains. For example, these servers know which servers across the globe contain information about “.com” ending websites. So if a DNS query comes for a .com domain, they direct the request to the correct top-level domain servers.

Then, these top-level domain servers contain information about which authoritative servers are responsible for a particular domain. They direct the query to the correct server that has authority over that domain. These servers are called authoritative servers, meaning they have the authority to provide the final DNS answer for that domain. These servers then send the response back to the recursive DNS server as the answer to the DNS query.

So the request flow as mentioned above is:
Client → Recursive DNS Server → Root Server → Top-Level Domain Server → Authoritative Server.
The authoritative server responds back to the recursive DNS server with the IP address where the website is hosted, and then the final flow is:
Recursive DNS Server → Client.

Now we will see the commands that help us fetch information like IP addresses using a command-line tool. But before that, we need to understand one very important concept, which is the NS record.

An NS record, as the name suggests, is a Name Server record. It indicates which server has authority over your domain. Let’s say you bought your domain from Hostinger for your website. Later, when you built the frontend and backend of your website and wanted to deploy it, you realized that you don’t want to use Hostinger’s servers for deployment. Instead, you decide to deploy on Vercel because they provide CDN and SSL certificates, meaning security-related features which otherwise you would have to configure yourself using tools like Nginx, firewalls, etc.

So, to avoid that extra effort, you choose Vercel since it is free and also provides built-in security features. Now, since you bought the domain from Hostinger, you need to go to your Hostinger account, open the DNS records of your domain, and update the NS records provided by Vercel. This tells the entire internet that “Hostinger is no longer responsible for this domain; ask Vercel where the website is.” Hostinger does not host the code anymore, it only points to the manager (Vercel) who knows where the code is hosted.

The dig . NS command helps us identify the list of root name servers, so it shows the names of the root servers.

The dig com NS command helps us get the name servers for the .com top-level domain. These are the authoritative servers responsible for maintaining records of .com domains.

The dig google.com NS command shows the name servers that have authority over the google.com domain. Since Google is a tech giant, they have their own authoritative DNS servers to handle DNS queries, unlike most developers who use providers like Vercel or Netlify.

When you run dig google.com, the command asks the DNS system for the basic DNS information of the domain, and by default it mainly shows the A record, which gives the IP address of google.com. This IP address is what the browser ultimately uses to connect to Google’s servers and load the website.

However, when you run dig google.com NS, you are being specific and asking only for the NS (Name Server) records, which tell you which DNS servers are responsible for managing the google.com domain, not its IP address.

So these are the dig commands application that takes place for getting information similart ot what we got above. Hope this simple-short blog helped you in making the concept of DNS RESOLUTION crystal clear.