What the Hell Is DNS Doing?
Why DNS?
Y’all probably have heard about DNS before, but what the hell is it?
DNS stands for Domain Name System. But before we go deeper into DNS, you need to get familiar with something first: URLs.
You’ve probably opened YouTube in your browser before, right?
You go to the address bar, type something like “youtube.com” and then hit Enter. Easy enough.
But here’s the thing, youtube.com itself is only part of a URL.
“What do you mean, part?”
Well, a full URL can look something like this:
https://sub.example.com/path?param=klfjaewpoifdsk
That’s an example of a full URL, but you don’t have to use every single part of it.
For now, we’re going to focus on the domain name, which in this example is:
sub.example.com
Now you’re probably wondering:
“What does a domain have to do with DNS?”
Well, we humans identify each other by names. You know someone as “John,” not as some giant sequence of numbers like humans number 4.854.123.435.
The Internet works with names too. We use domain names to identify websites, such as:
- YouTube : youtube.com
- Google : google.com
- Wikipedia : wikipedia.org
But there’s a little problem.
Computers don’t use domain names to identify where to send network traffic. At the network layer, they use IP addresses.
So if you ask the Internet:
“Hey, where the hell is youtube.com?”
The network itself doesn’t just magically know where that name points.
That’s where DNS comes in. DNS basically helps translate a domain name into an IP address.
For example, let’s say “mydomain.com : 185.16.201.1″. So when you type “mydomain.com” you’re basically saying:
“Yo, I wanna go to mydomain.com.”
And DNS can answer:
“Alright, that domain resolves to 185.16.201.1.”
Now your computer has an IP address it can use to communicate with the destination server.
But wait. Why don’t we just type the IP address directly instead of using a domain name?
Well, you actually can.
You could theoretically type something like “185.16.201.1” instead of “mydomain.com”.
But imagine there are millions of websites out there, and every time you want to visit one, you have to remember its IP address.
Remember one or two? Sure, maybe.
Ten? Still possible.
A hundred?
A thousand?
Bro, you’re gonna need Albert Einstein’s brain just to remember where the hell everything is.
And IP addresses can also change, which makes relying on them as human-friendly identifiers even worse.
That’s why we have DNS.
It lets us use names that are much easier for humans to remember while the network can still work with IP addresses.
But this is only the surface of what DNS is doing.
Because DNS isn’t just some magical box that takes a domain and spits out an IP address.
There’s actually a whole process happening behind the scenes. And that’s where things start getting interesting.
How It Works?
So how does DNS actually find that IP address? Now we’re locked in.
When you type a URL into your browser and hit Enter, your browser will first check its own DNS cache.
Basically, it asks:
“Yo, do I already know the IP address for mydomain.com?”
If the browser doesn’t have the answer, the request will move on to your operating system.
The OS will basically ask the same thing:
“Do I already have the IP address for mydomain.com?”
If the answer is no, the OS will send the DNS query to a DNS resolver.
This resolver is usually provided by your ISP, but you can also configure your device to use another DNS resolver.
The DNS resolver will also check its own cache:
“Wait, do I already know the IP address for mydomain.com?”
If the answer is yes, great. We’re done.
But if the resolver doesn’t have the answer either, now the real search begins.
Step 1 : Ask the Root Server
The DNS resolver will first ask a root DNS server:
“Bro, do you know the IP address for mydomain.com?”
The root server doesn’t know the final IP address. Instead, it looks at the domain and sees the “.com” part.
The root server basically says:
“I don’t know where mydomain.com is, but I know who handles .com. Go ask the .com TLD server.”
The root server then gives the resolver information about the appropriate TLD (Top-Level Domain) server.
Step 2 : Ask the TLD Server
Now the DNS resolver goes to the .com TLD server.
“The root server told me that you handle .com. Do you know the IP address for mydomain.com?”
But the TLD server doesn’t know the final IP address either.
What it does know is which authoritative DNS server is responsible for mydomain.com.
So the TLD server basically says:
“Oh, mydomain.com? I don’t know its IP address, but I know which DNS server is responsible for it. Go ask this server.”
And once again, the resolver gets information about where to go next.
Step 3 : Ask the Authoritative Server
Now the DNS resolver contacts the authoritative DNS server.
“The TLD server said you’re responsible for mydomain.com. Do you know its IP address?”
And finally, the authoritative server has the answer.
“Oh, mydomain.com? Yeah, I got you. Here’s the IP address.”
For example:
mydomain.com : 185.16.201.1
Now the DNS resolver finally knows the IP address.
Step 4 : Give the Answer Back
The DNS resolver sends the result back to your operating system. The OS can then give the result back to the browser.
Now the browser knows:
“Alright, mydomain.com is at 185.16.201.1.”
And from here, the browser can start communicating with that IP address.
But Wait… DNS Doesn’t Always Do All of This. At this point, you might be thinking:
“Damn, so every time I visit a website, DNS has to go through all of those servers?”
Nope.
And this is where DNS caching comes in.
The browser, operating system, and DNS resolver can all temporarily store DNS information in their own cache.
So imagine you visited, mydomain.com earlier.
Your browser might already have:
mydomain.com : 185.16.201.1
stored in its DNS cache.
The next time you visit the same domain, your browser can simply use the cached result instead of starting the entire DNS lookup process again.
If the browser doesn’t have it, the OS might. If the OS doesn’t have it, the DNS resolver might.
Only if none of them have a usable cached answer does the resolver need to go through the root , TLD, authoritative-server process.
And DNS records aren’t cached forever.
They are stored for a specific amount of time based on something called TTL (Time To Live).
So, in a simplified way, the process looks like this:
- Browser cache
- OS cache
- DNS Resolver cache
- Root DNS Server
- TLD DNS Server
- Authoritative DNS Server
- IP address
But remember:
Most DNS queries don’t need to travel all the way down this chain.
Caching exists specifically to avoid doing unnecessary work every single time someone asks.
So… What the Hell Is DNS Doing?
And that’s basically DNS. It might look simple from the outside. You type “mydomain.com” and somehow your computer ends up talking to the right server.
But behind that simple domain name, there’s actually a whole system working together.
Your browser checks its cache. Your OS checks its cache. Your DNS resolver checks its cache. And if nobody has the answer, the resolver goes on a little journey through the Root Server, TLD Server, Authoritative Server until it finally finds the answer.
Then the IP address comes all the way back to you.
All of that happens just so you can type something human friendly like:
youtube.com
instead of having to remember something like:
142.250.x.x
And honestly, that’s the whole point of DNS.
DNS lets humans use names while computers use addresses.
So the next time you type a domain into your browser and instantly see a website, remember:
There’s a whole bunch of process happening behind that innocent little youtube.com.
There’s actually a lot more to learn about DNS.
For example, how does an authoritative DNS server actually know which IP address to give you? And what happens if the IP address changes while all of this is happening?
We’ll get into that stuff later.
For now, you know what the hell DNS is doing.