DEV Community: Vigneshkumar Selvaraj

DNS Explained for Beginners: How Does the Internet Find a Website?

Vigneshkumar Selvaraj — Fri, 30 Oct 2026 13:12:12 +0000

Have you ever wondered what happens when you type www.google.com into your browser and press Enter?

Within seconds, Google's homepage appears on your screen. But how does your computer know where Google is hosted? How does it find the correct server among millions of servers connected to the internet?

The answer is DNS (Domain Name System).

I recently started exploring DNS as part of my AWS Cloud Quest learning journey. Initially, concepts like Root Nameservers, TLD Nameservers, Authoritative Nameservers, and DNS Resolvers were a little confusing.

So, I decided to explain DNS in simple words, using real-world examples.

If you are new to AWS, cloud computing, or networking, this article is for you!

1. What is DNS?

DNS stands for Domain Name System.

In simple terms, DNS translates human-readable domain names into IP addresses that computers use to communicate with each other.

Let's understand this with an example.

Imagine you want to call your friend Rahul.

You don't remember his phone number, but you remember his name. You open your phone contacts, search for Rahul, find his phone number, and make the call.

DNS works in a similar way.

For example:

Domain name: www.google.com
IP address: 142.250.183.68 (example IP address)

Humans find domain names easier to remember, while computers use IP addresses to communicate.

DNS helps find the IP address associated with a domain name.

Think of DNS as the phonebook of the internet.

2. Why Do We Need DNS?

Imagine if we had to remember the IP address of every website we visited.

For example:

Google: An IP address
YouTube: An IP address
Amazon: An IP address
Netflix: An IP address

It would be difficult to remember all these numbers.

Instead, we use simple domain names such as:

google.com
youtube.com
amazon.com
netflix.com

When we enter a domain name in the browser, DNS helps our computer find the corresponding IP address.

That's why DNS is an important part of internet communication.

3. How Does DNS Actually Work?

Now let's understand the interesting part.

Suppose you open your browser and enter:

www.example.com

How does your computer find the server hosting this website?

DNS resolution involves several components working together.

Before looking at the complete process, let's understand the four important components.

A. DNS Resolver

A DNS Resolver is the component that handles DNS queries on behalf of your computer.

Think of it as an assistant who searches for the IP address of a website for you.

Your DNS resolver might be provided by:

Your Internet Service Provider (ISP)
Google Public DNS (8.8.8.8)
Cloudflare DNS (1.1.1.1)

When you request a website, your computer sends a DNS query to the resolver.

If the resolver already has the answer in its cache, it can return it immediately.

Otherwise, it starts looking for the answer.

B. Root Nameserver

The Root Nameserver is the starting point of the DNS hierarchy.

There are 13 logical root server identities, operated by multiple organisations across many physical locations.

The Root Nameserver doesn't normally provide the actual IP address of the website.

Instead, it directs the resolver to the appropriate Top-Level Domain (TLD) nameserver.

For example, if you are looking for www.example.com, the Root Nameserver tells the resolver where to find information about .com domains.

C. TLD Nameserver

TLD stands for Top-Level Domain.

It is the last part of a domain name.

Examples:

Domain	TLD
google.com	.com
amazon.in	.in
wikipedia.org	.org
example.net	.net

The TLD Nameserver helps the resolver find the authoritative nameserver responsible for a particular domain.

For example, when the resolver asks the .com TLD Nameserver about example.com, it provides the nameserver information for that domain.

D. Authoritative Nameserver

This is where the actual DNS records for a domain are maintained.

The Authoritative Nameserver knows the DNS information configured for a particular domain.

For example, it might contain a DNS record like this:

Field	Value
Domain	www.example.com
Record Type	A
IP Address	93.184.216.34

When the resolver asks for the IP address of www.example.com, the Authoritative Nameserver returns the corresponding DNS record.

Now the resolver has the answer!

4. DNS Query Process: Step by Step

Let's connect all these components.

Suppose you type:

www.example.com

into your browser.

Here is what happens behind the scenes.

Step 1: Your computer sends a DNS query

Your computer first checks available DNS caches.

If it doesn't already have a valid answer, it sends a DNS query to a DNS Resolver.

Step 2: Resolver contacts the Root Nameserver

If the resolver doesn't know the answer, it contacts a Root Nameserver.

The Root Nameserver responds:

"I don't have the IP address, but you can find information about .com domains through the .com TLD Nameserver."

Step 3: Resolver contacts the TLD Nameserver

The resolver contacts the .com TLD Nameserver.

The TLD Nameserver responds:

"I don't have the website's IP address, but here are the authoritative nameservers responsible for example.com."

Step 4: Resolver contacts the Authoritative Nameserver

The resolver now contacts the authoritative nameserver for example.com.

It asks:

"What is the IP address of www.example.com?"

The authoritative nameserver checks its DNS records and returns the requested information.

For example:

www.example.com → 93.184.216.34

Step 5: Resolver returns the IP address

The DNS resolver sends the IP address back to your computer.

Your browser can now connect to the web server using that IP address.

Step 6: Website loads

Your browser establishes a connection to the server and requests the website.

Finally, the website appears on your screen!

That's how DNS resolution works.

5. What Are DNS Records?

DNS records contain information about domain names.

Different DNS record types are used for different purposes.

Here are some important DNS records you should know.

Record Type	Purpose	Example
A	Maps a domain to an IPv4 address	example.com → 192.0.2.1
AAAA	Maps a domain to an IPv6 address	example.com → IPv6 address
CNAME	Points one domain name to another domain name	www.example.com → example.com
MX	Specifies mail servers for a domain	Mail server information
NS	Identifies authoritative nameservers	Nameserver information
TXT	Stores text information	Domain verification

One important thing to remember:

An A record points to an IPv4 address, while a CNAME record points to another domain name.

These records are important when configuring domains and applications in AWS.

6. What Is DNS Caching and TTL?

Imagine you visit Google.

Your computer sends a DNS query, and the resolver finds Google's IP address.

Now, what happens if you visit Google again after a few seconds?

Does the resolver need to contact the Root, TLD, and Authoritative Nameservers again?

Usually, no!

The resolver can temporarily store the DNS response and reuse it for subsequent requests.

This is called DNS Caching.

TTL stands for Time To Live.

It determines how long a DNS record can be cached.

For example:

TTL = 3600 seconds

This means the DNS response can be cached for up to one hour.

Why is caching useful?

Reduces DNS lookup time.
Improves performance.
Reduces unnecessary DNS queries.
Helps reduce the load on DNS infrastructure.

7. What Is Amazon Route 53?

Now that we understand DNS, let's connect it to AWS.

Amazon Route 53 is AWS's managed Domain Name System (DNS) service.

It helps you manage domain names and route incoming requests to your applications and other resources.

Imagine you have deployed a Python FastAPI application on AWS ECS.

Your application is accessible through an Application Load Balancer.

However, you don't want users to access your application using a long AWS-generated load balancer address.

Instead, you want users to access it through:

api.mycompany.com

This is where Amazon Route 53 becomes useful.

You can configure a DNS record in Route 53 to direct users to your Application Load Balancer.

The simplified flow looks like this:

A user enters api.mycompany.com in the browser.
The DNS resolver looks up the domain.
Route 53, acting as the authoritative DNS service, provides the configured DNS response.
The browser connects to the destination through the Application Load Balancer.
The load balancer forwards the request to your application running on ECS.

Now users can access your application using a simple domain name!

Important Route 53 Concepts

While exploring Route 53, you will come across these terms.

Hosted Zone

A Hosted Zone is a container for DNS records belonging to a domain.

For example, if you own mycompany.com, you can create a Hosted Zone for it and configure records such as:

www.mycompany.com
api.mycompany.com
mail.mycompany.com

Record Sets

These are the DNS records you configure inside a Hosted Zone.

For example, you can create an A record, CNAME record, MX record, or other supported record types.

Routing Policies

Route 53 supports different routing policies to control how DNS queries are answered.

Some important routing policies include:

Simple Routing: Routes traffic to a single resource.
Weighted Routing: Distributes traffic across multiple resources based on assigned weights.
Latency-Based Routing: Routes users to resources based on network latency.
Failover Routing: Routes traffic to a healthy resource when the primary resource becomes unavailable.
Geolocation Routing: Routes users based on their geographic location.
Geoproximity Routing: Routes traffic based on the geographic location of users and resources, with optional bias.

These routing policies become especially useful when building highly available and globally distributed applications.

8. DNS vs Amazon Route 53

You might wonder whether DNS and Route 53 are the same thing.

They are not.

DNS is the overall system used to translate domain names into IP addresses.

Amazon Route 53 is an AWS service that provides managed DNS functionality and additional routing features.

Think of it this way:

DNS is the concept.
Route 53 is one service that helps implement and manage DNS.

There are other DNS providers as well, such as Cloudflare and Google Cloud DNS.

9. What I Learned

While learning AWS through Cloud Quest, DNS was one of the concepts I wanted to understand beyond just remembering definitions.

The most important thing I learned is that when we enter a website name in a browser, several components work together behind the scenes to find the correct server.

Here is a quick recap:

Component	Responsibility
DNS Resolver	Searches for the requested DNS information
Root Nameserver	Directs the resolver to a TLD nameserver
TLD Nameserver	Directs the resolver to an authoritative nameserver
Authoritative Nameserver	Provides the actual DNS records
Amazon Route 53	AWS managed DNS service

Understanding these concepts makes it easier to work with AWS services such as Route 53, EC2, ECS, and Elastic Load Balancing.

Conclusion

DNS is one of the fundamental building blocks of the internet.

Every time we access a website using a domain name, DNS helps our computer find the correct destination.

If you are starting your AWS journey, I recommend understanding DNS resolution before moving on to Amazon Route 53 and its advanced routing features.

I hope this explanation helps someone who is learning DNS for the first time.

Happy Learning!

If you found this article useful, feel free to share your thoughts or ask questions in the comments.

References

How Redis Caching Actually Works (Explained Like You're 5, But for Developers)

Vigneshkumar Selvaraj — Sat, 18 Jul 2026 14:17:01 +0000

When I started learning Redis, I had one big question: "If thousands of people are using the same app at the same time, how does the app know whose data belongs to whom?"

Turns out, the answer is simpler than I thought, but it took me a while to fully connect the dots. So I'm writing this post the way I wish someone had explained it to me: in plain English, no jargon left unexplained.

What is Redis, in one sentence?

Redis is a super-fast, temporary storage box that sits between your app's backend and your database. Instead of asking the (slower) database the same question over and over, your app can ask Redis first. If Redis already has the answer stored, it replies instantly.

Think of it like a librarian who keeps the 10 most-requested books on her desk instead of walking to the back shelf every single time someone asks for them.

The big question: how does Redis know which data belongs to which user?

Redis doesn't magically "know" anything. It's just a giant dictionary. You give it a key, it gives you back a value. That's it.

key   → value
"hello" → "world"

So the real trick isn't in Redis itself. It's in how your backend code names the keys.

The pattern: build the key from the user's identity

Every time a user logs in, they get some kind of unique ID (a session ID, a token, whatever). Your backend uses that ID to build a unique key for each piece of data:

user:123:profile
user:123:cart
user:456:profile
user:456:cart

User 123 and user 456 never touch each other's data, because they're stored under completely different keys, even though it's the exact same Redis, being hit by both users at the exact same time.

Simple analogy: imagine a huge wall of PO boxes at a post office. Every box has a number. Redis is just the wall of boxes, it doesn't care who owns which box. Your app's job is to always use the right box number (key) for the right person.

What about the same question with different details?

Here's where it got interesting for me. Say a user asks for "my orders," but sometimes they want pending orders, sometimes delivered orders, sometimes page 1, sometimes page 2. It's the "same" request, just with different filters (called query parameters).

The solution: the filters become part of the key too.

user:123:orders:status=pending
user:123:orders:status=delivered
user:123:orders:page=1
user:123:orders:page=2

Same user, same "operation," but different filters means different Redis entries. Next time the exact same filters come in, the backend rebuilds the exact same key, finds the cached answer, and skips the slow database call entirely.

A neat trick: hashing long filters

If there are a lot of filters, keys can get messy. So a common trick is to squish all the filters into one short fingerprint using something called a hash function (like MD5 or a faster one like xxHash):

Input:  {"status": "pending", "page": 1, "limit": 10}
Output: e4d7f1b4ed2e42d15898f4b27b019... (a fixed-length code)

Same input always produces the same fingerprint. So instead of matching keys, the backend just re-generates the fingerprint from the new request and checks if it already exists in Redis. No decoding needed, you never need to reverse a hash, you just recreate it.

Important: this fingerprint is purely an internal backend detail. The frontend never sees it, never sends it, and doesn't need to know it exists. The frontend just sends normal filters like ?status=pending, and gets back normal data like JSON. Nothing about hashing or Redis is visible to it.

"But doesn't the whole website get cached too?"

This was my next confusion, since the UI (the buttons, layout, colors) looks the same for every user, is that cached in Redis too?

Nope. That's a completely different system called a CDN (Content Delivery Network).

CDN = caches the static stuff (HTML, CSS, JavaScript, images) that's identical for every visitor. It stores copies of these files on servers physically located all around the world, so you always download them from whichever copy is nearest to you, instead of from one single far-away server.
Redis = caches the personal stuff (your cart, your profile, your orders) that's different for every user.

Simple analogy: a CDN is like a chain of local libraries, each holding a copy of a popular book so you don't have to travel across the country to the one original library. Redis is like your own personal mailbox, nobody else's mail goes into it, no matter how many mailboxes are on the same street.

Let's actually try it: Redis with Python

Reading about Redis is one thing, but running it yourself makes it click much faster. Here's the minimum you need to get hands on.

Step 1: Download and install Redis

You can get Redis (and see the official docs) from redis.io. On Mac, the easiest way is Homebrew:

brew install redis
brew services start redis

On Linux, you can install it through your package manager, and on Windows, the official docs point you toward using WSL or Docker. Once installed, you can test the server directly with the command line tool that ships with it:

redis-cli ping

If it replies PONG, Redis is running and ready.

Step 2: Try some basic Redis commands

You don't even need Python yet to get a feel for how Redis stores data. Open redis-cli and try:

SET user:123:name "Vignesh"
GET user:123:name

SET user:123:cart "2 items"
EXPIRE user:123:cart 60
TTL user:123:cart

DEL user:123:name

A quick rundown of what each command does:

SET key value stores a value under a key.
GET key fetches the value back.
EXPIRE key seconds makes the key automatically disappear after a set number of seconds (useful for temporary cached data).
TTL key tells you how many seconds are left before a key expires.
DEL key deletes a key immediately.

Step 3: Install Redis in Python

The official Python client is called redis. Install it with pip:

pip install redis

If you want faster response parsing, you can install it with an optional extra:

pip install "redis[hiredis]"

Step 4: Use Redis from Python

Here's a small working example, connecting to Redis, setting a value, and reading it back:

import redis

r = redis.Redis(
    host="localhost",
    port=6379,
    db=0,
    decode_responses=True  # returns normal strings instead of bytes
)

# check the connection
print(r.ping())  # True

# store a value, matching the user:id:resource pattern from earlier
r.set("user:123:cart", "2 items")

# read it back
print(r.get("user:123:cart"))  # "2 items"

# set a value that expires after 60 seconds
r.setex("user:123:session", 60, "active")

# store multiple fields under one key using a hash
r.hset("user:123:profile", mapping={"name": "Vignesh", "role": "student"})
print(r.hgetall("user:123:profile"))

This is the exact same pattern discussed earlier in this post, just written in real, runnable code. Once you connect this into a small Flask or FastAPI app, you have the full picture: a request comes in, the backend builds a key like user:123:orders, checks Redis first with r.get(), and only hits the database if it's a cache miss.

Putting it all together

Here's the full journey of a single click, from a fresh understanding:

You open a website. Static UI files load from the nearest CDN location.
You click something. The app calls the backend, sending your user ID.
The backend builds a specific key using your user ID plus what you asked for.
It checks Redis first. If the answer's already there, it replies instantly.
If not, it asks the actual database, gets the answer, saves it in Redis for next time, and replies to you.

Two completely different caching systems, solving two completely different problems, but built on the exact same core idea: don't redo expensive work if you already have the answer stored somewhere fast.

If you're learning backend development or AWS, I'd love to hear what confused you the most when you first learned about caching. Drop a comment below!