Exploring the DNS Resolution Process

We are already aware that computers do not understand website names but only IP addresses. DNS exists to translate the website names into IP addresses.

DNS resolution or lookup is the internet process that translates human friendly domain names into machine readable IP addresses.

Most of the times, DNS works invisibly, but the developers obviously needs to understand the behind the scenes process, this is where dig comes in. dig is Domain Information Groper, it is a diagnostic tool that lets you query DNS and troubleshoot DNS issues. It isn’t used to browse the web but to understand and debug DNS.

The above picture displays the hierarchy of the DNS. Each level of the DNS does not know everything, they are only aware who is responsible for the next level.

Starting with dig . NS - Root name servers : we will get the list of the root name servers, which only know who manages the TLDs.

Next dig command would be dig com NS - Top-Level Domain : this is going to give the answer to what server owns which .com domain.

Then comes dig.google.com NS - Second-Level Domain : You get google’s authoritative name servers, these servers act as the main identifier of the websites. These servers store DNS records (A, AAAA, MX, TXT, etc.)

dig.google.com is the step where you get the actual IP address from the A record. This is the end of the DNS journey.

www, mail, docs these are all subdomains, they come under authoritative servers.

What are NS records and why they matter :

The name server records designate the authoritative servers for a domain. They act as a guide for browsers to find where the website’s IP address is stored. Without NS internet usage will be impossible.

We don’t usually run dig manually, instead our system uses a recursive resolver to find the IP address by querying other DNS servers until an answer is found. We can call the recursive resolver the DNS middleman.

How it works:

the browser sends a query to the recursive resolver → the resolver will check the local cache(if the IP exists there, it will return it immediately, ending the process) → but if not the resolver will move to the root server → the root server will guide it to the apt TLD server → the TLD server would direct it to the specific authoritative server which holds the final IP address → the IP is cached and also send to the client.