Skip to main content

Command Palette

Search for a command to run...

DNS Resolution Explained: How Websites Reach Your Browser

Updated
9 min read
DNS Resolution Explained: How Websites Reach Your Browser
S
Full-stack developer obsessed with performance, scalability, and clean systems. I use Arch btw.

Introduction

Imagine you’re sitting down for dinner and you open youtube.com on your phone, laptop, or TV to watch something while enjoying your meal. Now, unless you’ve been living under a rock, you know you need an active internet connection to open a website like YouTube. That’s because the website is hosted on a remote server (just a fancy name for a computer that serves data over the internet).

But have you ever wondered how your computer, which only understands 0s and 1s, is able to find the exact remote server that hosts youtube.com, among billions of other servers on the internet?


What are Domains?

We don’t remember phone numbers of our friends and family members anymore. We simply look up their saved contact in our phones. If you think about it, your contacts app simply maintains a mapping of your friend’s name to their phone number. This saves you the hassle of remembering the phone numbers of all your friends, family members, etc.

Contacts app mapping names to phone numbers (analogy for DNS)

Now coming to the point, you might have already heard the term “IP addresses” in cool hacker movies 😎. They look something like this: 142.250.70.78. An IP address is like a phone number, a unique identifier for every device on the internet. So your smartphone has a unique IP address, your computer has a unique IP address, and even your smart refrigerator has one! Likewise, the YouTube server also has an IP address. Since these IPs are unique, if we somehow get our hands on the IP address of YouTube’s server, we will be able to contact the server and ask it for all the data we need to load up the YouTube website in our browser.

And this is where the problem arrives. We, as humans, who can’t even remember 10 phone numbers normally, can surely never remember the IP addresses of billions of websites out there! The solution is domains. A domain like youtube.com is simply a user-friendly name that we can remember instead of something like 142.250.70.78. This is just like how we save our friend’s phone numbers with their name, so that we don’t have to remember such long numbers.


Anatomy of a Domain

Here’s how a domain name is structured (subdomain, SLD, and TLD):

Domain anatomy showing subdomain, SLD, and TLD

What is Name Resolution?

Now that we know what domains are, we need to understand this fancy term called “Domain Name Resolution.” Just like I explained in the previous section, domains are surely easy to remember, however we need a process that converts these domains to their IP addresses, so that when we enter a website’s domain, the browser can find its IP address and load the website up for us. This process is called Name Resolution, since we are “resolving” the domain name to its IP address.


DNS: The Contacts App of the Internet

DNS stands for Domain Name System. For now, you can think of it as a server that maintains a mapping of a website’s domain name, for example, youtube.com, to its IP address. This means whenever you type youtube.com in your browser, it simply reaches out to a DNS server, asks for its IP, and then goes and gets all the website data from the server having that IP.

Browser querying DNS server and then YouTube server using IP address

However, this is just a high-level overview. In reality, this process is much larger, involving multiple different steps and many different types of DNS servers.


The DNS Hierarchy

Now that you have a high-level understanding of what domains are, why we need them, and how DNS resolves a domain to an IP address, let’s deep dive into the series of steps that happen behind the scenes whenever you enter a website’s domain name in your browser.

DNS resolution flow: browser → recursive resolver → root → TLD → authoritative

Component 1: Browser

When you enter a domain name in your browser (for example, youtube.com), the browser first checks its own DNS cache before making a request anywhere. This is because you may have visited that website before, and the browser might have cached its IP address to save time in the future.

If the IP is found in the cache, there’s no need to reach out to any DNS server. The browser can directly connect to the website’s server and fetch the required data.

Component 2: Stub Resolver

A stub resolver is a small DNS client built into your operating system. Its job is very simple. It receives the DNS query from your browser and forwards it to a recursive DNS resolver.

Component 3: Recursive DNS Resolver

This is the most important component in the DNS hierarchy. A recursive DNS resolver is a type of DNS server whose job is to find the IP address of a domain by contacting other DNS servers step-by-step until it gets the final answer.

As you can see in the diagram, it acts like a middleman between your browser and the rest of the DNS system. However, before making any further requests, the recursive resolver also checks its own cache. If it already has the IP address stored (and the TTL hasn’t expired), it saves time and simply returns the cached answer.

Component 4: Root Server

Root servers are the topmost DNS servers in the hierarchy. They do not know the IP addresses of websites like youtube.com. However, they do know where to find the next step.

When the recursive resolver asks a root server about youtube.com, the root server looks at the Top-Level Domain (TLD) part (.com) and responds with a referral to the TLD name servers responsible for .com.

In simple words, the root server responds with something like:

“I don’t know the IP for youtube.com, but here are the DNS servers that manage .com.”

💡
Bonus: There are only 13 named root servers (labeled A through M). However, they are represented by 1,750+ individual server instances distributed globally using something called Anycast routing.

Component 5: TLD Server

After getting referred to the .com TLD servers, the recursive DNS resolver contacts one of them. The TLD server checks the Second-Level Domain (SLD) in the query (like youtube in youtube.com) and responds with the authoritative name servers for that domain.

So the TLD server basically says:

“I don’t know the final IP either, but here are the authoritative servers for youtube.com.“

Component 6: Authoritative Server

Authoritative DNS servers are the final source of truth for a domain. These servers are usually managed by your DNS provider/host like Cloudflare, GoDaddy, Hostinger, etc.

They store different DNS records for your domain, such as:

  • A/AAAA (IP address)

  • CNAME

  • MX, etc.

The recursive resolver reaches out to the authoritative server and asks for the A (or AAAA) record of the domain. This record contains the IP address of the server hosting the website.

Finally, this IP address is returned to your browser, and your browser can then connect to the website’s server and fetch the actual website data.

Summary

The entire process can be summarized as the quest for finding the A record of the domain name you entered. That A record can either be in your browser cache, or in the DNS resolver’s cache, or the resolver may have to do the entire process step-by-step, querying each server and finding the next location every time, in order to find it.

Also, do note that this entire process only finds us the IP address of YouTube’s server. This does not fetch the data of YouTube’s website itself. That is done after the browser receives the IP address from this process.


dig: A DNS Diagnostic Tool

Before finishing, let’s take a quick look at dig. dig is a very useful command-line utility, that you can use to query DNS servers. By using dig, you can find out things like:

  • What IP address is associated with this domain?

  • Which DNS servers are authoritative for this domain?

  • Which mail server(s) receive emails for this domain?

Querying for an IP Address

In order to fetch the IP address of a domain, you can simply run the following command:

dig youtube.com

In the output, you will see a section like this:

;; ANSWER SECTION:
youtube.com.		153	IN	A	142.250.70.78

This is YouTube’s IP address.

💡
Note: By default, dig asks for the A record, which holds the IP address.

Querying a Specific DNS Record

We can also query for a particular record by doing:

dig youtube.com NS

The output would look something like this:

;; ANSWER SECTION:
youtube.com.		238608	IN	NS	ns4.google.com.
youtube.com.		238608	IN	NS	ns2.google.com.
youtube.com.		238608	IN	NS	ns3.google.com.
youtube.com.		238608	IN	NS	ns1.google.com.

Querying a Specific DNS Server

We can also query a particular DNS server. For example, now that we know the nameservers of youtube.com, let’s query a specific one to get the A record:

dig @ns4.google.com youtube.com A

The output would look like this:

;; ANSWER SECTION:
youtube.com.		300	IN	A	142.250.207.206
💡
Note: The IP address might be different than what we saw in the previous section, since big sites like youtube.com run on multiple different servers, load balancers, etc.

Fetching the Root Servers

We can fetch all 13 root DNS servers by doing this:

dig . NS

The output would look like this:

;; ANSWER SECTION:
.			205024	IN	NS	a.root-servers.net.
.			205024	IN	NS	b.root-servers.net.
.			205024	IN	NS	c.root-servers.net.
.			205024	IN	NS	d.root-servers.net.
.			205024	IN	NS	e.root-servers.net.
.			205024	IN	NS	f.root-servers.net.
.			205024	IN	NS	g.root-servers.net.
.			205024	IN	NS	h.root-servers.net.
.			205024	IN	NS	i.root-servers.net.
.			205024	IN	NS	j.root-servers.net.
.			205024	IN	NS	k.root-servers.net.
.			205024	IN	NS	l.root-servers.net.
.			205024	IN	NS	m.root-servers.net.

Conclusion

DNS is indeed a magical system powering the web invisibly. It is not a single server, but an entire system of servers that help your browser get the associated IP address for a domain. These IP addresses are sharded around the world, distributed across multiple servers based on the TLD, authoritative servers, etc. And the DNS resolver does the job of recursively finding out the next location in the DNS hierarchy until we find the A record.