DNS Explained

You do this all the time without thinking about it. Like, you open a tab and type youtube.com, hit Enter, and the page shows up.

But here’s a funny thing if you stop and look at it:

• You typed a name, youtube.com, not a number.
• Yet computers on the internet find each other using numbers, not names.
• So how does typing a name actually get you to the right machine sitting somewhere on the planet?

The answer is a quiet little system working in the background called DNS. Let’s see what it is and how it pulls this off.

🎯 The Problem

Here’s the pain DNS is solving for you. Think about how you and a computer each like to remember things:

• You remember names. youtube.com, google.com, wikipedia.org. These are easy for a human brain to hold onto.
• Computers don’t route traffic using names. They use IP addresses, which are just numeric addresses of machines, something like 142.250.190.78. (IP is short for Internet Protocol.)
• So there’s a mismatch. You speak in names, the network speaks in numbers.

Now imagine if there were no fix for this:

• You’d have to memorize a long number for every single site you visit.
• And those numbers can change when a company moves its servers, so your memorized number would just stop working one day.

That’s clearly no good. We need something that turns the name you remember into the number the network needs. That something is DNS.

📖 What is DNS

So let’s define it plainly first.

• DNS stands for Domain Name System.
• It’s the system that maps domain names (like youtube.com) to IP addresses (like 142.250.190.78).
• The everyday way to picture it is the internet’s phone book. You look up a name, and it gives you back the number to actually reach.

Think back to calling a friend. You know your friend Alex by name, right? But to actually call, you need Alex’s phone number. So you open your contacts, look up “Alex”, and get the number. DNS does the same job for the web:

• The domain name is like the contact’s name.
• The IP address is like the phone number.
• DNS is the contacts app that connects the two.

One thing to keep straight: DNS only finds the address. It doesn’t fetch the web page itself. That comes later over a separate connection. DNS’s whole job is just answering one question, “what’s the IP for this name?”

🗂️ The Players

Looking up a name isn’t one computer doing all the work. It’s a small team, and each member has a clear role. Let’s meet them one by one.

• Recursive resolver. This is the helper that does the searching for you. When your browser needs an IP, it hands the question to the resolver and says “go find this for me.” The resolver then runs around asking the other servers until it has an answer. It’s usually run by your ISP (your Internet Service Provider, the company you pay for internet), or it can be a public one like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1.
• Root server. This is the starting point of the search. The root server doesn’t know the final answer, but it knows who to ask next. Think of it as the front desk that points you toward the right department.
• TLD server. TLD means Top-Level Domain, which is the last part of a name, like .com, .org, or .net. The TLD server for .com knows where all the .com names are managed. It still doesn’t have the final IP, but it knows who does.
• Authoritative server. This is the official source for a specific domain. The authoritative server for youtube.com holds the real, correct IP address for that name. When it answers, that answer is the truth. “Authoritative” just means it’s the boss of that name.

Here’s the easy way to remember the chain: the resolver asks around, the root points to the TLD, the TLD points to the authoritative server, and the authoritative server gives the real answer.

🔎 How a DNS Lookup Works

Okay so now let’s walk the whole thing end to end. You typed youtube.com. Your browser needs the IP. Here’s the journey, and notice that it checks the closest, fastest places first before going far out.

• Browser cache. Your browser remembers names it looked up recently. So first it just checks its own memory. If the answer is there, we’re done already.
• OS cache. If the browser doesn’t have it, your operating system keeps its own little memory of recent lookups too. It checks there next.
• Recursive resolver. No luck locally, so the question goes out to the resolver. The resolver also has a cache of its own, so it might answer right away. If not, it starts the real search.
• Root server. The resolver asks a root server. The root says “I don’t have it, but for a .com name, go ask the .com TLD server.”
• TLD server. The resolver asks the .com TLD server. It replies “I don’t have the IP, but the authoritative server for youtube.com is over here.”
• Authoritative server. The resolver finally asks the authoritative server, which hands back the real IP address.

Then the answer travels back to your browser, and it gets saved at each layer along the way so the next lookup is faster. Now your browser has the IP and can go open a connection.

⏳ Caching and TTL

We keep saying answers get “saved.” Let’s make that precise, because there’s an important rule controlling it.

• An answer can’t be saved forever. What if the site moves to a new IP? Your saved old answer would send you to the wrong place.
• So every DNS answer comes with a TTL. TTL stands for Time To Live. It’s a timer that says how long this answer is allowed to stay cached.
• For example, a TTL of 3600 means “keep this for 3600 seconds (one hour), then throw it away and look it up fresh.”

This explains a couple of things you’ve probably noticed or wondered about:

• Why repeat visits feel fast. The first time you visit a site, your resolver might walk part of the chain. But for the next while, the answer sits in cache, so the lookup is basically instant. No walking the chain, just read it from memory.
• Why DNS changes aren’t instant. When a site owner points their name at a new IP, the old answer is still cached around the world until each TTL runs out. This gradual catching-up is called propagation, and it’s why a DNS change can take time to reach everyone.

🧾 DNS Record Types

A name doesn’t map to just one kind of thing. The authoritative server stores different records for a domain, each answering a different question. Here are the common ones you’ll meet first.

So the same domain can have an A record for its website and an MX record for its email, all sitting together. A CNAME is handy when, say, www.example.com should just follow wherever example.com points, so you set it once and stop worrying.

⚡ Why DNS Matters in System Design

DNS isn’t just a lookup trick. In a real system it’s a piece of critical infrastructure, and that cuts both ways. Let’s look at why it matters when you’re designing things.

• It’s a single point of failure if you’re not careful. If your DNS goes down, people typing your name get nothing back, so your whole site looks dead even if your servers are perfectly healthy. (A single point of failure, or SPOF, is one part whose failure takes everything down.) That’s why big sites use multiple DNS providers and many nameservers.
• It can be a bottleneck. Every request to your site starts with a lookup. If resolution is slow, every single user feels that delay before anything else even begins. So fast, well-cached DNS matters for performance.
• It’s a tool for load balancing. You can give one name several IP addresses and let DNS hand out different ones to different users. That spreads traffic across servers. This is the idea behind DNS-based load balancing.
• It’s a tool for failover. If one server or region goes down, you can update DNS to point the name at a healthy one instead. Combined with low TTLs, this lets traffic shift away from trouble fairly quickly. This is DNS failover.

So when you design a system, DNS is one of the first things in the path and one of the most important to get right.

⚠️ Common Mistakes and Misconceptions

A few things trip people up early. Let’s clear them out so they don’t trip you up in an interview.

• “A DNS change takes effect instantly.” Nope. Old answers stay cached until their TTL runs out, so the change spreads gradually. That spreading is propagation, and it can take a while.
• “DNS is the website.” DNS only finds the address. It doesn’t store or serve your pages. The actual page comes from a web server over a separate connection, after DNS has done its part.
• “The resolver and the authoritative server are the same thing.” They’re not. The resolver asks questions on your behalf and caches answers. The authoritative server is the official source that holds the real records. One asks, the other answers.
• “One name means one IP.” Often a name maps to several IPs, which is exactly what makes load balancing and failover possible.

🧩 What You’ve Learned

You can now explain what DNS is and how a name turns into an address. Here’s what you’ve picked up.

• ✅ DNS is the internet’s phone book, mapping domain names to IP addresses.
• ✅ A lookup checks caches first, then walks resolver, root, TLD, and authoritative servers.
• ✅ TTL controls how long answers stay cached, which is why repeat visits are fast and changes aren’t instant.
• ✅ Common records include A, AAAA, CNAME, and MX, each pointing to a different thing.
• ✅ DNS is critical infrastructure and can power load balancing and failover, or become a bottleneck or single point of failure.

🧠

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

1. 1

   What does DNS do?

   It stores and serves the web page you asked for It maps domain names like youtube.com to IP addresses It encrypts your connection to the server It speeds up your internet connection
   Check

   Why: DNS is the internet's phone book; it turns a name you remember into the IP address the network needs, but it does not serve the page itself.

2. 2

   In a full DNS lookup, what is the correct order after the caches?

   Authoritative server, then TLD server, then root server Recursive resolver, then root server, then TLD server, then authoritative server TLD server, then root server, then resolver Root server, then authoritative server, then resolver
   Check

   Why: The resolver asks a root server, which points to the TLD server, which points to the authoritative server that returns the real IP.

3. 3

   What does TTL control?

   How fast the server can build a page How long a DNS answer is allowed to stay cached before it is looked up fresh Which IP address a name maps to Whether a connection is encrypted
   Check

   Why: TTL (Time To Live) is a timer on a cached answer; a high TTL means faster repeat lookups but slower updates, and a low TTL means the opposite.

4. 4

   How can DNS help with failover?

   By encrypting the data sent to the server By pointing the name at a healthy server when one fails, with a low TTL making the switch take effect faster By storing a copy of the whole website By blocking traffic to broken servers automatically inside the browser
   Check

   Why: You can update DNS to point a name at a healthy server when one goes down, and a low TTL helps that change spread quickly.

Score: 0 / 4 Reset

🚀 What’s Next?

You now know how a name becomes an address. Next, see where that fits in the bigger picture and how the web stays fast.

• What Happens When You Type a URL shows the full journey from typing a name to seeing the page, with DNS as the first stop.
• CDN Explained shows how copies of a site sit close to users to cut down on latency.

Get these down and you’ll have a solid grip on the network fundamentals every backend and system design interview leans on.