# The Secret Highway of Data: Tracked!

### 🕵️ When You Search "Netflix"... What *Actually* Happens?

You go to Google.  
You type **"Netflix"**.  
You click the first link.

And just like that — [`https://www.netflix.com`](https://www.netflix.com) opens.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742746125224/3bc0efca-4be9-450f-b2f5-2cfc1398ee29.png align="center")

But pause. Think for a second.

**What just happened?**  
**How did that website open?**  
And more importantly — **how are you able to binge-watch an entire series without even thinking about it?**

Well, without data being transferred behind the scenes, **nothing** would load. Not a single episode. Not a thumbnail. Not even the homepage.

🌐 So… How? Where? And Who’s Involved?

Let’s break it down.

When you open Netflix — whether on your **laptop**, **tablet**, or **phone** — your device is the one *asking* for data.

In technical terms, your device becomes the **client**.

We can represent it like this:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742746527476/c5641a28-1552-4213-8922-5b281eb190fc.png align="center")

This client (your browser/device) sends out a request:  
**“Hey, I want to watch a show on** [**netflix.com**](http://netflix.com) **— help me find it and bring the content back!”**

But who does it ask? How does it know where Netflix lives ?

Let’s dive deeper into the hidden data journey — where it travels, who guides it, and how it returns to you in the form of a show you can’t stop watching.

## 🌐 What Happens After the Click?

As soon as you click on the URL [`www.netflix.com`](http://www.netflix.com), your device (the client) doesn’t magically know where to go.

Instead, it sends out a request —**"Where is this website located?"**  
And this request goes to something called the **DNS** — *Domain Name System*.

Let’s represent it like this:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742746958577/c2105584-9a6e-42e4-ad05-ce304c192392.png align="center")

## 🧠 Wait — What *Is* DNS Server Anyway?

Before we continue down the data journey, let’s quickly understand what DNS Server actually does.

Think of it like your **phone’s contact list**.

You don’t remember everyone’s phone number, right? You just tap on a name like "Muskaan" and your phone dials the correct number behind the scenes.

In the same way, [**Netflix.com**](http://Netflix.com) is just a name.  
The real identifier is something called an **IP address**\*(It’s the contact number in the world of internet)\* — something like `192.0.2.1`.

So far, here’s what’s happened:

* You typed [`netflix.com`](http://netflix.com) into your browser.
    
* Your device (client) sent a request to the **DNS** Server.
    
* Now the DNS Server has a job: to **find out where** [**netflix.com**](http://netflix.com) **lives**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742756785261/4bdddc63-a5df-4297-a095-adfd4bb4b98c.png align="center")

### So what's the DNS Server next step?

It reaches out to the **Root Server**.

## 🌳 DNS Server Contacts the Root Server

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742757904961/2994982b-76e3-4fa8-a1f2-bbb66144dc2d.png align="center")

### 🌍 What is a Root Server?

Think of it like the **root of a tree** — the very base from where all paths begin.  
Just like a tree distributes nutrients through branches, the **Root Server directs DNS traffic** to where it needs to go next.

There are **13 main root servers** around the world (named A–M) and they have further sub-servers as well.

### 🧭 But What Do Root Servers Actually Do?

Root servers **don’t know the final IP** of [`netflix.com`](http://netflix.com) — but they know where to find the next clue. Think of it like a scavenger hunt.

They store mappings for **Top-Level Domains (TLDs)** — like:

* `.com`
    
* `.net`
    
* `.org`
    
* `.in`
    
* `.us`
    

So when DNS Server asks, “Where is [**netflix.com**](http://netflix.com)?”,  
the root server replies: 🗣️ “I don’t know where [**netflix.com**](http://netflix.com) lives, but I can point you to the **.com TLD server** — it might know!”

## 🧩 The Root Server Brings a Clue

So, the DNS Server asked the **Root Server**:  
“Where can I find [**netflix.com**](http://netflix.com)?”

The Root Server responds:  
🗣️ *“I don’t know exactly where* [***netflix.com***](http://netflix.com) *is, but I do know who handles all* `.com` domains. Here’s their contact!”

In tech terms, the **Root Server shares the IP address** of the `.com` TLD server — the next stop in the journey.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742758098862/8770554e-2cc0-4dbb-b1a8-a6d1cb2a0235.png align="center")

So, it's like the Root Server hands the DNS Server a clue and says:

🔎 *“I didn’t solve the mystery, but here’s the next lead.”*

This clue gets passed back to the DNS Server .

Now the DNS Server knows who to ask next — the **.com TLD server(in our case server with .com addresses)**, which might just have the answer we’re looking for.

## 🔍The TLD Server Finds the Host

Now the DNS Server takes the clue from the Root Server and heads over to the **TLD Server** — in this case, the one responsible for **.com** domains.

So it asks the `.com` TLD server:  
🗣️ *“Hey, I’m looking for* [***netflix.com***](http://netflix.com)*. Do you know where it lives?”*

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742759078058/535999a5-8ff4-473a-bbed-b1a238e1cf3f.png align="center")

The TLD server responds:  
✅ *“Yes! I don’t know the exact house, but I know the person who owns it. Here’s the address of the* ***authoritative name server*** *for* [*netflix.com*](http://netflix.com)*.”*

This **authoritative name server** is typically managed by the company where the domain is registered or hosted — like **GoDaddy**, **Namecheap**, **Cloudflare**, **AWS** , etc.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742759297329/8d975840-0704-4c8f-a61c-2211bbd6923c.png align="center")

And this server?  
It holds the final, most important piece of the puzzle:  
T**he actual IP address of** [**netflix.com**](http://netflix.com) — the true digital home where the site is hosted.

## 🧠 The Authoritative Name Server — Final Answer

We’re now holding three clues:

* The browser asked the **DNS server**,
    
* The resolver asked the **Root Server**,
    
* The Root pointed to the **TLD Server (.com)**,
    
* And the TLD Server gave us a lead:  
    *“Ask the Authoritative Name Server. It knows it all.”*
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742759847411/5ef563c2-0e27-4e24-b2f1-f49cac90b35b.png align="center")

So now, the DNS Server heads to the **authoritative name server** —  
Let’s say, for example, Netflix is hosted on **AWS Route 53** (very likely, since AWS is one of the biggest DNS providers).

🕵️ The resolver now asks:  
*“Hey Authoritative Server, I’ve followed every clue — can you finally tell me the IP address of* [***netflix.com***](http://netflix.com)*?”*

And the authoritative server responds:  
✅ “Yes. Here you go — Netflix lives at **\[actual IP address\]**.”

💡 Boom! We now have the **exact coordinates** of where Netflix is hosted.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742759954762/36724d36-4248-444b-b807-4999d9012740.png align="center")

## 💾 Mission Complete

Now that the DNS server has the final IP address, it sends that information **all the way back to your browser**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742760327285/91aa5469-adbd-4b29-93c4-c48ea4db6e7d.png align="center")

**Step 7** , At this point, something powerful happens: The **browser establishes a direct connection** with the Netflix server at that IP address.

From here on, the client and server can now **talk directly** to each other.

**Step 8 & 9:** Let the Conversation Begin

With the connection open, your browser sends an actual **HTTP request** to the Netflix server —  
something like: 👉 *“Hey, I want to load the homepage of* [*netflix.com*](http://netflix.com)*!”*

The server understands the request and responds with the necessary data — HTML, CSS, JavaScript, or even video stream chunks.

This **two-way communication** (request ↔ response) is what powers your Netflix experience.

📝 For simplicity, we show this to-and-fro as a single step idn the diagram, but just know: Your browser **keeps talking** to the server as long as it needs data (images, scripts, videos, etc.)

## 🧾 **Summary: The Secret Life of Data — Revealed**

Let’s recap the thrilling behind-the-scenes journey of what happens when you search and click on [**netflix.com**](http://netflix.com):

1. **Client Request:**  
    Your browser (the *client*) sends a request for [`netflix.com`](http://netflix.com).
    
2. **DNS** Server **Lookup Begins:**  
    The request is sent to the **DNS server**, asking, “Where is [netflix.com](http://netflix.com)?”
    
3. **Root Server Step:**  
    The DNS Server contacts a **Root Server**, which points it to the **.com TLD server**.
    
4. **TLD Server Step:**  
    The **TLD server** (for `.com`) gives the address of the **authoritative name server** for Netflix.
    
5. **Authoritative Server Response:**  
    The **authoritative name server** provides the **final IP address** of [`netflix.com`](http://netflix.com) (e.g., hosted on AWS).
    
6. **DNS** Server **Sends Back IP:**  
    This IP is returned to your **browser** — now it knows exactly where to go.
    
7. **Connection is Established:**  
    The browser creates a direct **TCP connection** with the Netflix server.
    
8. **Data Request:**  
    The browser sends an **HTTP request** to that IP asking for the homepage.
    
9. **Data Delivery:**  
    The server responds with the required content — and the Netflix site starts loading on your screen.
    

### **DNS resolution**

It is this process of **translating a domain name** (like [`netflix.com`](http://netflix.com)) into its corresponding **IP address** (like `52.94.134.119`) so that your browser can find and connect to the correct server.

The reverse of it is Reverse DNS Lookup

### **Reverse DNS Lookup (rDNS)**

**Reverse DNS** is the **opposite** of the usual DNS process.

* **DNS (forward lookup):**  
    `domain name → IP address`  
    *e.g.,* [*netflix.com*](http://netflix.com) *→ 52.94.134.119*
    
* **Reverse DNS (rDNS):**  
    `IP address → domain name`  
    *e.g., 52.94.134.119 →* [*netflix.com*](http://netflix.com)
    

This reverse lookup uses a **PTR (Pointer) record**.

Mail servers use rDNS to check if the sender’s IP actually maps to a legitimate domain.

Example:You receive an email from [`xyz@bank.com`](mailto:xyz@bank.com), but the IP address doesn't go to [bank.com](http://bank.com).  
The server may flag or reject the email as **suspicious**.

## BONUS

**DNS Record** is a piece of information stored in DNS servers that tells the internet how to handle requests for a domain — like where to find the website, send emails, or verify ownership.

The following are it’s types :

| 🔠 **Record** | 🔍 **What It Does** | 🌍 **Real-World Analogy** | 🧭 **Where/When It's Used** |
| --- | --- | --- | --- |
| **A** | Maps domain → IPv4 address | Your physical home address | ✅ **Step 6 & 7** — returned by authoritative name server to resolver → client |
| **AAAA** | Maps domain → IPv6 address | Same as A, but for newer GPS systems | ✅ **Step 6 & 7** — used like A, if IPv6 is supported |
| **CNAME** | Alias one domain to another domain | Nickname redirect to main name | ✅ **Step 6** — used inside authoritative server resolution |
| **MX** | Directs email to mail server | Mailroom address of a company | ❌ Not used in web resolution; ✅ **Used in email systems** |
| **TXT** | Stores text info (SPF/DKIM/verification) | Sticky note: “Only X can deliver here” | ❌ Not for site load; ✅ **Used in email + domain verification (Google, AWS)** |
| **NS** | Says which name servers are authoritative | Reception desk directory | ✅ **Step 3 (Root)** & **Step 5 (TLD)** — used to delegate & point to authoritative server |
| **SOA** | Stores zone-level admin info | Receptionist’s private logbook | ✅ Exists in **Step 5–6**, but **used internally** by DNS servers only |
| **PTR** | Maps IP → domain (Reverse DNS) | Caller ID for an incoming phone number | ❌ Not in forward resolution; ✅ **Used in reverse lookups, email anti-spam, logs** |
| **SRV** | Points to services (port+host) | Meeting room + floor | ❌ Not in website resolution; ✅ **Used in VoIP, Zoom, MS Teams** |
| **CAA** | Limits who can issue SSL certs | Authorization stamp for ID issuing | ❌ Not part of DNS journey; ✅ **Queried by Certificate Authorities during HTTPS setup** |

---