DEV Community

Manmeet Singh
Manmeet Singh

Posted on • Originally published at thatsmanmeet.com

A Beginners Guide to DNS Resolution

#webdev #programming #dns #networking

Whenever you try to open a website, like "google.com," what do you think happens behind the scenes? How does your browser know which server to get data from among millions of servers worldwide? Is it magic? Well, No! It happens with the help of a system known as DNS.

Before we understand this complex system, let’s understand the working of DNS with the help of an Analogy.

Phonebook Analogy

Our smartphones have an app named Contacts, which stores all the phone numbers of our friends, family and other people whom we meet in our life.

Let me ask you this question; Do you remember the phone numbers of all people stored on your mobile?

Phone Book

Most likely, your answer would be no (unless you're a genius or very lonely)! Generally, you might only remember a few phone numbers of your close ones, like your parents. However, you do remember most people's names, and when you need to call them, you open your phone app, search for the person's name, and click the call button. Your phone then automatically dials the number for you.

You see, we humans are not great at remembering numbers, but we are excellent at remembering names. So, we use our contacts app to save a person's name and phone number once, and then our phone app does all the hard work for us.

Just like people have name and phone numbers, the websites have Domain Name and IP Addresses and we really remember websites names like Google, Instagram, Reddit but not their IP Addresses.

Entity Name Number / IP Address
Person John Doe +1034024234
Website Google.com 172.217.19.164 (Real IP btw)

DNS acts like the internet's phonebook. It converts a Domain Name (e.g., Google.com) to its corresponding IP Address (e.g., 172.217.19.164).

Just as we rely on our contacts app to convert a name into a phone number, a web browser like Chrome relies on DNS to convert a domain name into an IP address.

However, your phonebook is probably small with maybe about 500 to 1,000 entries max. But there are millions of websites on the internet. Do you think a single phonebook could handle it all?

Well, No.

It’s not just one massive server; it’s actually many different systems working together. We call this a Decentralised System."

What is DNS

Domain Name System (DNS) is a hierarchal and distributed naming system that converts the human readable domain names into their respective IP addresses which are used by the client such as web browser to access those websites.

High Level DNS

In the diagram above, the DNS system is shown as a single component for simplicity, but it actually consists of multiple different components.

Components of DNS System

  1. Recursive Resolver: Recursive Resolver is the server that is provided by your Internet Service Provider (ISP) and is the main bridge between your System and the other DNS servers.

    • The name Recursive comes from the fact that it makes request to multiple DNS servers in order to get the IP address of the final server. It is also the initial point of contact between client and the global DNS system.

  2. Root Servers: Root Servers provide the IP Address of the servers which contains the records of the top level domains (like .com or .net) and share them with the Resolver.

    • There are technically only 13 Root Server IP addresses in the world. However, don't worry about them crashing—there are actually 1,600+ physical servers worldwide using "Anycast" technology to share those 13 IPs. It’s a massive, distributed safety net.

  3. Top Level Domains: These servers have domain specific and only contains the IP address for the domains that correspond to the specific TLD (e.g .com). This server provides the IP of the Authoritative Servers.

    • TLD are also of different types such as Country Specific (.jp, .in, .ca etc) and Generic (.com, .org, .net etc).

  4. Authoritative Server: These are the servers which holds the actual IP address of the website, you’re trying to visit.

    • There’s a common misconception that Authoritative servers are the final servers where the website is hosted. However, this Idea is wrong!
    • When you buy a domain (from GoDaddy, Namecheap, etc.), they usually provide this server by default. However, as developers, we often configure this to point to a custom provider like Cloudflare or AWS Route53 for better speed and security.

DNS Resolution Process

Now, let's understand how your web browser loads websites using a process called DNS Resolution.

DNS Resolution Process

  1. A user opens the web browser, types the URL (e.g., https://google.com), and presses enter.
  2. The browser will try to find the website's IP address in its local cache. If it finds the IP address, it will load the website, and the rest of the DNS resolution process is skipped.
  3. If the IP address of the website is not found, the DNS query is sent to the Recursive Resolver.
  4. The Recursive Resolver will also check its cache to see if the IP address is available. If it is, the resolver will return the response to the browser, and the rest of the DNS resolution process will be skipped.
  5. If the IP address of the website is not found in the Recursive Resolver’s cache, the request is sent to the Root Servers.
  6. Root Servers check the top-level domain in the URL (like google.com) and provide the IP address of the Top Level Domain Server for .com domains to the Recursive Resolver.
  7. The Recursive Resolver then sends the request to the Top Level Domain Server, which checks the registrar currently handling the website and returns the IP address of the Authoritative Server to the Recursive Resolver.
  8. The Recursive Resolver sends the request to the Authoritative Servers, which provide the actual IP address of the website server (in this case, Google’s server) to the Recursive Resolver.
  9. The Recursive Resolver returns the response to the browser.
  10. The browser then sends the request directly to the website’s server using the IP address provided by the Recursive Resolver and retrieves the data from the website.

Time To Live (TTL)

So far, we have learned the 10-step DNS resolution process. But now, a question might be popping up in your head: “**Does this long, complex process happen for every single resource?**”

Think about it for a second!

Let’s say you have a slow internet connection. The DNS resolution itself takes about 2 to 3 seconds, and finally, the webpage loads. However, a modern webpage isn't just one file. It has images, scripts, fonts, and videos. If that page has 10 images, and your browser had to perform a full DNS resolution for every single one, that would be an extra 10 lookups. At 3 seconds per lookup, you are looking at a 30-second delay just to find the images!

In the world of modern web development (React, heavy JavaScript, rich media), this would be a disaster. The web would be unusable.

So what’s the fix? Well, one word Caching.

Remember, in the DNS resolution step, both the browser and the recursive resolver have a cache, which helps the browser avoid repeating the entire DNS resolution process.

Great, so the browser doesn't need to make requests repeatedly to get the IP address for images and other resources. But who tells the browser when to check the cache again?

Imagine your browser cached a website, and then a developer switched to another server a minute later. If the browser never checks with the recursive resolver again, how would it know the website's IP address has changed?

This is where the concept of Time To Live (TTL) comes into play.

TTL is a setting attached to the DNS record (configured by the domain owner). It tells the resolver exactly how long to keep the data valid.

  • High TTL : This is good for the websites, that are stable and don’t change as often. High TTL could be like 24 hours of time is beneficial for such websites.
  • Low TTL : This is good for the websites, that are change regularly. Low TTL could be like 5 minutes of time is beneficial for such websites.

Essentially, TTL is the expiration date on the data. It ensures your browser remains fast by not making too many request to DNS servers but at the same time doesn’t keep serving the Stale data.

Dig Command

So far, we just learned about the theory. Shall we try seeing this in practice?

We can achieve this using the dig (Domain Information Groper) command. It’s a standard tool for developers to query DNS servers directly and see exactly what is happening under the hood.

Open your terminal and type:

dig google.com
Enter fullscreen mode Exit fullscreen mode

Just take a look at the output below.

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     280 IN  A   142.250.182.206

;; Query time: 20 msec
;; SERVER: 2405:201:5500:6193::c0a8:1d01#53(2405:201:5500:6193::c0a8:1d01)
;; WHEN: Sat Jan 24 16:50:36 IST 2026
;; MSG SIZE  rcvd: 55
Enter fullscreen mode Exit fullscreen mode

The output might look like a wall of text, but let's decode the three most important parts:

  1. Question Section: Contains the query that we sent, In our case to get the IP of google.com

  2. Answer Section: Contains the information about the response we received. This includes information like:

    1. Domain Name: google.com
    2. Time to Live (TTL): 280 seconds
    3. DNS Record Type : A record
    4. IP Address : 142.250.182.206

  3. Additional information: This contains some additional information about the Query such as:

    1. Query time: It took 20 milliseconds for this query to return response.
    2. Server: This is most likely our Recursive Resolver

Seeing the full DNS Resolution using the Dig command

Now with all the knowledge equipped about the DNS and how the Dig command shows the results, are you ready to see full DNS Resolution in action?

Let’s run the dig command with +trace flag.

dig google.com + trace
Enter fullscreen mode Exit fullscreen mode

Just take a look at the output below.

 ~/ dig google.com +trace

; <<>> DiG 9.10.6 <<>> google.com +trace
;; global options: +cmd
.           86363   IN  NS  a.root-servers.net.
.           86363   IN  NS  b.root-servers.net.
.           86363   IN  NS  c.root-servers.net.
.           86363   IN  NS  d.root-servers.net.
.           86363   IN  NS  e.root-servers.net.
.           86363   IN  NS  f.root-servers.net.
.           86363   IN  NS  g.root-servers.net.
.           86363   IN  NS  h.root-servers.net.
.           86363   IN  NS  i.root-servers.net.
.           86363   IN  NS  j.root-servers.net.
.           86363   IN  NS  k.root-servers.net.
.           86363   IN  NS  l.root-servers.net.
.           86363   IN  NS  m.root-servers.net.
;; Received 239 bytes from 127.0.2.2#53(127.0.2.2) in 1 ms

com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            86400   IN  DS  19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com.            86400   IN  RRSIG   DS 8 1 86400 20260206050000 20260124040000 21831 . E/ZKdBG6pUCuQGB0jkM1cndavlviGO62WgLfbmQPNEz/YY7sufjwe8Jp pQA3VU9dgd46/E+90p9q8LnK1pdGm7k0RJlA+XuvenHdXVbX+jzZn+N5 p0+fEsbociE7ot1/JmwKacwPPPKtnrep8iRELxXHU20BA4J/0sp3z9ht 8+2WgDoaQlKb04JQf5eS0J1hJ+mAELQbQKwWXxX8yaisSObq9axWIAKE NHUv4PO82pBf3BMwLLdZhzlfVoX/ObjcDoTm6yhHkhavB9hNOil8o6kA gg0MMcsbJqEGBrgVT1pKn9pDabUR949GFL8Qo1eHm270Dp72F8E+tfE9 ud4Nyw==
;; Received 1170 bytes from 193.0.14.129#53(k.root-servers.net) in 36 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20260130002721 20260122231721 35511 com. FRwJDTYcGgEr+lzbONMVnFNDkoYtjSmaKNF0x+q4JR+sD+rwZDoaYn/D rPkDTs5F1BwixFGXqZQizSc7cFjkdw==
S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8  NS DS RRSIG
S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN RRSIG NSEC3 13 2 900 20260131013349 20260124002349 35511 com. uW9ufLSEVTnIol0z4l+DX8pBSOvPIVaJSeFV8EE7cYJOgu44vzXw0rus XnZN3Zj/y6mjTGmDpGd4QHBnIevvYg==
;; Received 644 bytes from 192.54.112.30#53(h.gtld-servers.net) in 352 ms

google.com.     300 IN  A   142.250.182.46
;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 26 ms
Enter fullscreen mode Exit fullscreen mode

Let's look at the actual output and decode the journey.

Step 1: The Root Check (.)

.           86363   IN  NS  a.root-servers.net.
.           86363   IN  NS  b.root-servers.net.
...
;; Received 239 bytes from 127.0.2.2#53(127.0.2.2) in 1 ms
Enter fullscreen mode Exit fullscreen mode
  • It first queries the Root Servers and picked one of the random servers from the 13 root servers and get’s the IP of TLD server and proceeds to step 2.

Step 2: The TLD Check (com.)

com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
...
;; Received 1170 bytes from 193.0.14.129#53(k.root-servers.net) in 36 ms
Enter fullscreen mode Exit fullscreen mode
  • Now our computer asked the TLD server k.root-servers.net, about the IP of google.com. However it responded with IP of the Authoritative Server.

Step 3: The Authoritative Check (google.com.)

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
...
;; Received 644 bytes from 192.54.112.30#53(h.gtld-servers.net) in 352 ms
Enter fullscreen mode Exit fullscreen mode
  • Now our computer asked the Authoritative Server h.gtld-servers.net, about the IP of google.com. It responded with NS ns2.google.com, telling us to ask the IP from google servers directly.

Step 4: The Final Answer

google.com.     300 IN  A   142.250.182.46
;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 26 ms
Enter fullscreen mode Exit fullscreen mode
  • Our computer sent a request to ns3.google.com which gave us the final IP: 142.250.182.46 and we can now open google.com on our system.

Absolute Cinema Meme

Conclusion

If you've followed along this far in the blog, congratulations! You now understand that DNS is not magic but a complex system that required a lot of engineering to get to where it is today.

Top comments (0)