What happens if we send data with no rules at all?

What happens if we send data without any rules?

Suppose we start sending data on a network without any agreement, rules or order.

Some messages may come in the wrong order.
Some messages may not reach at all.
The receiver may not be ready to receive the data.
We also won’t know which data was received correctly.

This type of communication works only when accuracy is not important.
But in most cases, accuracy is important — like in websites, APIs, online payments, logins, and file sharing.

That is why TCP is used.

What is TCP and why it is needed?

TCP is like a reliable delivery service for your data. It makes sure everything sent between two computers arrives safely, in the right order, with nothing missing or duplicated. You can think of it as a dependable middleman for any online conversation.

So basically jab bhi two systems data exchange karte hain (like your browser and a website), TCP makes sure data sahi, poora, aur sahi order mein pahuche.

What Problems Does TCP Solve?

What is the TCP 3-Way Handshake?

Before sending any real data, TCP first establishes a connection between client & server.
This setup process is called the 3-Way Handshake.

How does it work?

Think of it like starting a phone call

1. Client ——> Server (SYN) [SYN means Synchronize]
   The client says:
   “Hello, I want to talk. Can you hear me?”

2. Server ——> Client (SYN + ACK) [ACK means Acknowledgement]
   The server replies:
   “Yes, I can hear you. Can you hear me?”

3. Client ——> Server (ACK)
   The client confirms:
   “Yes, I can hear you. Let’s talk.”

Step-by-step process : SYN, SYN-ACK, ACK

After 3rd step, both sides are ready & synchronized.

How data transfer works in TCP

After the connection is established

• Data is split into segments

• Each segment gets a sequence number

• Receiver sends back ACKs for received data

• Sender keeps track of what is acknowledged

TCP does not just send & forget. It sends, waits, checks, & resends if needed.

How TCP ensures reliability, order and correctness

1. Reliability (No data loss)

• Every segment must be acknowledged

• If ACK is not received → retransmission (same data dobara send karta hai.)

• Lost packets are detected automatically

2. Order (Correct sequence)

• Sequence numbers define exact order

• Receiver reorders packets if needed

• Application always receives data in order

3. Correctness

• Each segment includes a checksum

• Corrupted data is discarded

• Sender retransmits clean data

4. Flow control

• It is a mechanism used in data communication between a sender and a receiver

• Receiver tells sender how much data it can handle

• Prevents slow receivers from crashing

How a TCP connection is closed

TCP does not just drop connections. Here dropping a connection means, communication ends abruptly without a clean, expected close. Under normal conditions, TCP does not randomly disconnect. It closes them gracefully using FIN and ACK.

Closing steps :

1. One side sends FIN → “I’m done sending data”

2. Other side sends ACK

3. Other side sends its own FIN

4. Final ACK is sent

Connection is now fully closed. This ensures, no data is lost, both sides finish cleanly & resources are released properly

What is FIN —> FIN stands for Finish. In TCP terms,
FIN is a flag used to say ——> “I’m done sending data. I don’t have anything more to send.”

TCP may be slower than UDP, but it is predictable and safe.

That’s why TCP is used for:

• HTTP / HTTPS

• APIs

• Databases

• File transfers

• Emails

• Authentication systems

Whenever correctness matters more than speed, TCP wins.

Internet Runs on Rules

Rules decide how data is sent, how fast & how safely.

What Are TCP and UDP

At a very simple idea, TCP is about reliability and UDP is about speed. They both move data between machines, but they make different tradeoffs (sacrifice).
TCP trades speed for safety & UDP trades safety for speed.

If we need to explain TCP and UDP in a single line, it can be said like this :

TCP ——> Send this data safely, in order, and make sure nothing is lost.

UDP ——> Send this data as fast as possible. If something is lost, move on.

Key Differences Between TCP and UDP

| Parameter      |         TCP           |     UDP            |
| -------------- | --------------------- | ------------------ |
| Connection     | Connection-oriented   | Connectionless     |
| Reliability    | Guaranteed delivery   | No guarantee       |
| Order          | Maintains order       | No ordering        |
| Speed          | Slower (extra checks) | Faster (no checks) |
| Overhead       | Higher                | Lower              |
| Retransmission | Yes                   | No                 |
Note:
Connection - Do both sides say hello & stay connected while talking?
Overhead - How much extra effort is spent just to manage the delivery?
Retransmission - If some data gets lost, does the system try again?

Simple Analogies to understand better about TCP and UDP

TCP : Courier Service

• Package is tracked

• Receiver signs for delivery

• If lost, it’s resent

• Order is preserved

UDP : Live Announcement

• Message is broadcast

• No confirmation

• If missed, it’s gone

• Speed matters more than accuracy

Both are useful. It depends on what we care about more —> correctness or speed.

When to Use TCP

We use TCP when data integrity matters. Here data integrity means the received data is complete, accurate & unchanged. nothing missing, nothing changed & in correct order.
(e.g. if we send the word “INTERNET“, data integrity means the receiver gets “INTERNET“, not “INTRANET“, “INT ER NET“ or any other variations)

Some practical scenarios where we use TCP

• Web pages

• APIs

• File downloads

• Emails

• Database communication

Note: Tradeoff —> yes, it’s slower but correctness beats speed in above mentioned cases.

When to Use UDP

We use UDP when speed & low latency matter more than data integrity.
Here, data integrity is not guaranteed — data packets may be lost, duplicated, or arrive out of order & UDP does not try to fix that.

(e.g. if we send the word “INTERNET”, the receiver might get “INTRNET”, “INET”, or even miss it completely — & we still move on)

Some practical scenarios where we use UDP

• Live video streaming

• Voice calls

• Online multiplayer games

• DNS queries

• Real-time sensor data / IoT

Note: Tradeoff —> yes, it’s faster & lightweight, but correctness, ordering & reliability r not guaranteed — speed beats correctness in the above cases.

Common Real-World Examples

TCP vs UDP Communication Flow

When we use TCP, communication starts only after both sides agree to talk.

• Connection established first
  Sender & receiver perform a handshake. It confirms both sides are ready & reachable.

• Data sent in small pieces
  Large data is broken into smaller packets for easier to manage.

• Every packet is acknowledged
  receiver confirms which packets arrived successfully.

• Lost packets are resent
  If something goes missing, TCP sends it again automatically.

• Data is reassembled in order
  if data packets reach out of order, TCP fixes it before passing data to our application.

UDP works very differently

• No connection setup
  data is sent immediately, no handshake, no preparation.

• Packets are sent independently
  each data packet is treated like a separate message.

• No delivery confirmation
  sender never checks if the packet arrived.

• No retransmission
  If any packet lost, it’s simply ignored.

• Order is not guaranteed
  Packets may reach out of order or not arrive at all.

What Is HTTP and Where It Fits

HTTP is NOT a transport protocol. It is an application-layer protocol. Iska simple meaning, HTTP explain karta hai kya data send karna hai. Request - response ka format kaisa hoga yeh decide karta hai http.

HTTP fits into the application layer. When we open a website, our browser & web server need a common language to request & send web pages. HTTP is that language, so it belongs to the Application layer.

Relationship Between TCP and HTTP

HTTP lives at application layer & TCP lives at transport layer. IP lives below both.

But first try to understand OSI Model.
Network communication ko 7 layers me divide kiya gaya hai. Is model ko ek roadmap kaha ja sakta hai jo batata hai humara data network me kaise travel karta hai, layer by layer.

HTTP → Application Layer —> HTTP bolta hai kya bhejna hai

TCP → Transport Layer —> TCP bolta hai kaise safely bhejna hai

When we open a website:

1. Browser creates an HTTP request

2. HTTP data passed to TCP

3. TCP breaks it into packets

4. IP sends packets over the network

5. TCP reassembles them at the destination

6. HTTP processes the response

Why HTTP Does Not Replace TCP

HTTP depends on TCP’s reliability. It doesn’t try to replace it.
HTTP khud data ko safe banane ki tension nahi leta, because TCP ye kaam already karta hai.

HTTP relies on TCP for reliable delivery, packet loss recovery & congestion control (preventing the network from getting too busy) , so it does not handle these itself.

HTTP focuses only on :

• Request methods (GET, POST, etc.)

• Headers

• Status codes

• Response structure

Is HTTP the same as TCP? Clearly No — HTTP says what data is sent, TCP makes sure it arrives safely.

How the Internet Reaches our Home or Office

When we open a website, our request doesn’t invisibly reach a server. It passes through multiples chain of network devices with specific job.

Networking is like a moving parcels, not data. Every device exists to solve some specific delivery problem.

What Is a Modem and How It Connects You to the Internet?

Modem’s first responsibility to convert signals from our ISP into usable internet data.

What Is a Router and How It Directs Traffic?

Router decide where each packet (small piece of data) should go. Router acts like a traffic police who’s work to reads destination addresses and forwards data packets to the correct path.
Routers are essential for accessing external networks and ensuring data is delivered to the correct destination.

Router’s Duty:

• Assigns private IPs to devices (DHCP —> Dynamic Host Configuration Protocol)
  Jab hum mobile, laptop ya TV Wi-Fi se connect karte hain, to router automatically har device ko ek private IP address deta hai.
  Mobile → 192.168.1.2

  Laptop → 192.168.1.3
  isse humhe manually IP set nahi karna padta.

• Forwards traffic to the internet
  (Router humara data pehle khud leta hai aur phir ISP ke through internet tak forward kar deta hai.)

• Brings responses back to the right device
  (Internet se jab response aata hai router check karta hai:

  Yeh response kis device ne maanga tha?

  Phir router sahi device (mobile/laptop) ko data de deta hai.)

• Often performs NAT (Network Address Translation)
  (devices ke paas private IPs hote hain, jo internet par valid nahi hote. Ab router Sab devices ke data ko ek public IP ke through internet par bhejta hai. Wapas aane par data ko translate karke sahi device ko de deta hai)

Router vs Modem :

• Modem: connects us to the internet

• Router: manages and directs traffic inside and outside our network

Switch vs Hub: How Local Networks Actually Work

Switches enable parallel communication, just like proper concurrency handling in code.

Jaise code me concurrency multiple tasks ko parallel chalne deti hai, waise hi switch network me multiple devices ko same time par communicate karne deta hai.

What Is a Firewall and Why Security Lives Here?

A firewall sits at the boundary of trust (like Security Gate).
Firewall decides what is allowed in or out.

Note : A firewall can be both hardware and software, and it's the main guardian of network security.

Firewall checks :

• Source IP

• Destination IP

• Ports

• Protocols

Firewalls protect computers by blocking unwanted access, allowing only certain connections and keeping internal systems safe from the internet.

Firewalls are the first security layer, before authentication, authorization, or application logic even runs.

What Is a Load Balancer and Why Scalable Systems Need It?

When one server can’t handle all the traffic, we add more servers to share the load, but users still connect through a single entry point so everything stays simple and organized (Like Toll Booth System). It’s main responsibility to distribute traffic across multiple servers.
Load balancer decide karta hai kaunsa user request kaunsa server handle karega.

Real-Life Analogy

McDonald’s counter
1 counter → lambi line ❌
4 counters + manager jo logon ko direct kare → fast service ✔️

• Manager = Load Balancer

• Counters = Servers

How all devices work together in a real-world setup?

At Home:

• Modem connects ISP

• Router manages devices

• Switch connects wired devices

• Firewall rules are basic

In Production:

• Dedicated firewalls

• Multiple routers

• Layered switches

• Load balancers in front of backend services

What is DNS, and why do we need name resolution?

DNS is our internet’s phonebook. But there is one important difference. It never stores names and numbers in one place.

We humans prefer names like “google.com“. But computers only understand IP addresses (142.250.19.46). DNS exist to translate between the two, quickly and reliable, millions times per second.

Without DNS every website we build or visit would require use to remember raw IP addresses which is practically not possible. That’s why internet world relies on DNS where responsibility is split across multiple layers instead of one central database.

Isi design decision ki wajah se, agar internet ka koi hissa fail bhi ho jaaye, phir bhi poora internet chalna band nahi hota.

What is the dig command and when it is used

dig —> Domain Information Groper —> is a diagnostic tool that lets us see DNS in action.

What happens normally? When we open a website in the browser, we don't see the entire DNS process. Browser handles everything in the background. It hides the DNS resolution process.
dig removes that abstraction and shows exactly what was happening.

• which servers are being queried

• what records are returned

• how authority flows through the system

Matlab, DNS ke andar jo actual baat-cheet ho rahi hoti hai, dig woh sab saamne dikha deta hai.

difference between cURL and dig?
—> curl = HTTP ke liye
—> dig = DNS ke liye

Jaise cURL batata hai server se kya response aa raha hai, dig batata hai DNS ke andar kya ho raha hai.
dig = DNS ka X-ray machine

dig works natively on Linux and macOS. On Windows, it does not come by default in Command Prompt, PowerShell or in Windows Terminal. If we install Windows Subsystem for Linux (WSL), we get a real Linux environment inside Windows.

DNS resolution happens in layers

DNS resolution doesn’t give the answer in one go. It finds the answer by moving step by step through different levels.
Pehle root level se poochta hai,
phir TLD (.com, .in, etc.) ke paas jaata hai,
aur finally authoritative DNS server se exact answer leta hai.

Isliye DNS ka process thoda slow lag sakta hai,
par yehi step-by-step design system ko reliable aur stable banata hai.

Note : TLD —> (Top-Level Domain) —> It is the last part of a website name.

Examples: —> .com / .in / .org / .net
When DNS looks for a website, It first asks the root server, root server replies like:
“I don’t know the exact IP, but for .com, ask the TLD server.”

TLD server then points to the authoritative DNS server.

Her Authoritative DNS server means the server that actually knows the correct IP of the domain.

Understanding dig . NS — root name servers

This command asks ——> “Who is authoritative for the root of DNS?”
Response lists root name servers like:

a.root-servers.net
b.root-servers.net

• The root zone doesn’t store domain IPs
  means root server ye nahi batata ki “google.com” ka IP kya hai.

• It only knows which servers handle which TLDs
  root server sirf itna jaanta hai ki kaunsa TLD (jaise .com, .org, .in) kaunsa server handle karta hai.

• There are multiple root servers globally, replicated using Anycast
  Iska matlab hai hum hamesha nearest root server se baat karte hain, isliye DNS fast aur reliable rehta hai.

Understanding dig com NS — TLD name servers

This command solve this:
“Who is responsible for the .com namespace?”
The response lists TLD name servers managed by registries.

Key idea:

• .com servers do not know IPs for “google.com”

• They only know which authoritative servers are responsible for it

This separation keeps DNS scalable and manageable.
Yeh bas direction dete hain, exact answer nahi.

Example:

“Mujhe google.com ka IP nahi pata,
lekin yeh lo, yeh servers hain jo iska final answer de sakte hain.”

Understanding dig google.com NS — authoritative name servers

dig google.com NS

Now we’re asking ——> “Who owns the DNS records for “google.com“?

Understanding dig google.com — full DNS resolution

dig google.com

This command returns the final answer — IP addresses for “google.com“

When we type “google.com”, browser doesn't communicate directly with Google's servers. There's a complex journey that takes place first.

Step 1: Recursive resolver ka role ata hai:
Sabse pehle humara system ek recursive resolver ko request karta hai (ISP DNS, Google DNS, Cloudflare DNS) —> “google.com ka IP pata hai kya?“

Step2 - Root servers se poochha jata hai
Resolver root server se poochta hai —> google.com ka IP pata hai kya?

Step3 - .com TLD servers se baat hoti hai
Ab resolver .com TLD server ke paas jata hai aur poochta hai —> google.com ka IP?
TLD Server reponse karta hai —> IP mere paas bhi nahi hai, par google.com ke authoritative servers ye hain.

Direction to milti hai, final answer nahi.

Step 4: Authoritative server final answer deta hai
Ab resolver Google ke authoritative DNS server se poochta hai —> google.com ka IP kya hai?
Yahin se exact answer aata hai aur actual truth mil jata hai.

Step 5: Caching hoti hai
Resolver is answer ko kuch time ke liye cache kar leta hai.
Benefits - next request me root/TLD tak jane ki zarurat nahi / DNS fast hota hai

Step 6: Browser actual connection banata hai
Ab browser ke paas IP aa chuka hota hai. DNS ka kaam khatam.

After this, the TCP connection is established, followed by the TLS handshake, and then the HTTP request is sent.

Connecting dig output to real browser requests

Every HTTP request starts with DNS.

• Before TLS
  Secure connection (HTTPS / encryption) tabhi start ho sakta hai jab browser ko server ka IP address mil jaye.

• Before headers.
  HTTP headers (User-Agent, Authorization etc.) tab bheje jaate hain jab connection ban chuka ho — aur connection DNS ke baad hi banta hai.

• Before cookies.
  Cookies bhi HTTP headers ka hi part hoti hain, isliye DNS ke baad hi jaati hain.

• Before APIs.
  API call bhi ek HTTP request hi hoti hai. API hit karne se pehle bhi DNS resolve hona zaroori hai.

DNS is the first door of the internet. Agar DNS fail ho gaya, to baaki sab (TLS, headers, cookies, APIs) kabhi start hi nahi honge.

If DNS fails:

• websites don’t load

• APIs appear “down”

• services look broken even when servers are healthy

What is cURL

cURL is a way to send messages to a server without using a browser. But what is a server? It is just another computer connected to the internet whose job can be defined in three segments:

• Receive requests

• Process them

• Send back a response

Whenever we open a website, submit a form, or log into any web app, our system is talking to a server. Now, cURL is a tool that lets us communicate directly with a server from the terminal on our computer.
No UI. No buttons. Just text-based communication.

Why programmers need cURL

We are programmers, we don’t always want to depend on Browser, Frontend codes or postman like tools. Right? Sometimes we just want to quickly hit the server, test an API or just see the raw responses, that’s where cURL shines.

cURL helps us on:

• Server me exactly kya data ja raha hai

• Server se exactly kya response aa raha hai

• Frontend built karne se pehle hi APIs ko test aur debug karna

In backend and system-level work, cURL becomes a daily tool.

How to make our first cURL request

Let’s start with the simplest possible command.

curl https://timearena.in

What will happen?

• cURL sent a request to “timearena.in“

• The server responded with data

• cURL printed that data in our terminal

we just fetched a our website without a browser.

Understanding request and response

Using cURL to talk to APIs

Most modern servers expose API, not webpages.
Jab hum cURL use karte hain, toh hum in APIs se directly baat kar sakte hain. API ka response usually HTML page nahi hota, balki JSON format ka data hota hai, jo machines aur programs ke liye samajhna easy hota hai.

curl https://api.example.com/users 
// This means: 
// “Hey server, give me users”
// Server replies with JSON data

Why Your cURL Command Isn’t Working

Mistake 1: Trying to learn all flags at once (Pehle basic flags seekhna hai (-X, -H, -d)
——> cURL has many options, but you don’t need them on day one.

Mistake 2: Confusing browser behavior with cURL
——> Browsers automatically send cookies, headers, auth. cURL sends only what you tell it to.

Mistake 3: Confused and panicked on ugly output
——> Raw JSON or HTML looks messy in terminal. That’s normal.

Mistake 4: Ignoring status codes
——> Always check whether the request actually succeeded.
1. 200 → Request successfully complete ho gayi ✅
2. 400 → Kuch to request mein problem hai ❌
3. 401 / 403 → Permission ya authentication issue 🔒
4. 500 → Server side error ⚠️

Where cURL fits in backend development

Once we comfortable with cURL, tools like Postman or frontend debugging make much more sense.

Commands You Can Try Safely

• Fetch a webpage (Basic GET request)

    curl https://example.com
    // Probable Output
    <!doctype html>
    <html>
    <head>
      <title>Example Domain</title>
    </head>
    <body>
      <h1>Example Domain</h1>
      <p>This domain is for use in illustrative examples.</p>
    </body>
    </html>
  

  cURL sent a GET request —> Server returned HTML —>This is exactly what a browser gets, but without UI

• Check if a server is alive (Status only)

// Command
curl -I https://example.com
// Output
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

Server is reachable —> 200 OK means success—> No body, only response headers

• Fetch JSON from an API

    // Command
    curl https://jsonplaceholder.typicode.com/posts/1
    //Output
    {
      "userId": 1,
      "id": 1,
      "title": "sunt aut facere repellat provident",
      "body": "quia et suscipit suscipit recusandae"
    }
  

  It tells us, This is an API, not a webpage —> server responds with JSON —> Backend systems usually talk like this.

What DNS Records Are and Why They Exist

Whenever we type a website in our browser like “chatgpt.com”, first and the most simple question needs to be answered first,

“Where should this request go?“

Our computers don’t understand domain names. They understand IP addresses (example - 192.210.210.184.10). DNS (Domain Name System) is there to translate the alphabetical domain names to computer friendly IPs. DNS is like the translator who coverts human friendly names —→ Computer friendly IPs.

We can think DNS like our mobile’s contact list. We just dialed with name, our phone internally dials a specific number. Same thing happened with our domain name. We type “www.hashnode.com“, DNS help to finds the exact destination.
Now, DNS doesn’t store just this information only. It also stores many types of records. Each records solve some specific question. That’s why DNS record types exist.
But actually DNS me record types ka kya matlab hai? —→ DNS ke andar different kinds of answers stored hai, har ek answer ek specific sawal ka jawab deta hai. DNS ek hi question solve nahi karta, alag alag situations ke liye alag information store karta hai.

What DNS record types mean? - yeh types ka matlab samjhata hoon. The record type tells DNS what the value represents. Without mentioning the type, DNS would not know the value you are requesting is for, like is it for an IP address or a mail server or some other domain name. “Types” answers those question.

A Record – Mapping Domain Name to IP Address (domain → IPv4 address)

The purpose of A Record —> Which IP address should our typed domain point to?

chatgpt.com → 104.18.32.47
google.com → 142.251.45.174

Now when someone visits chatgpt.com, DNS needs to reply by saying Bhai iss domain ka server iss IP →104.18.32.47 hai.
A record —> direct address.
Important to remember
—> One domain can have multiple A records.
—> It helps for load balancing (traffic multiple servers pe distrubute karna) and high availability (Service hamesha available rahe).

AAAA Record – Domain to IPv6 Address

We talked about A Record, which maps a domain to an IPv4 address. But internet sirf IPv4 pe hi nahi chal raha anymore.

First understand What is IPv4? —> IPv4 is just an address system for computers on this internet. just like our house has an address or our mobile has a number. Every computer or server in the internet needs an accurate address so the data knows where to reach. That address is called an IP address.

An IPv4 address looks like this —> 93.184.216.34

(Four numbers / Separated by dots /Each number between 0 and 255 )
That’s why it’s called IPv4 —> Version 4 of Internet Protocol.

Now the problem is — IPv4 addresses are limited. Internet grow ho gaya, devices explode ho gaye, IPs kam pad gaye. To solve this, IPv6 was introduced.
IPv6 looks like this:

2606:4700:4700::1111

Same job as A Record, bas IP version alag hai. How it works, same like A records, you open a website, browser usually does this:

1. First checks —> AAAA record

2. If IPv6 available —> uses it

3. If not —> falls back to A record (IPv4)

User ko kuch pata bhi nahi chalta. Sab silently hota hai.
One thing to remember, AAAA record is not mandatory but highly recommended for modern systems.

CNAME Record – Domain Alias & Indirection

CNAME record points one domain to another domain, not to an IP address.

www.chatgpt.com -----> chatgpt.com
app.mycompany.com → mycompany.vercel.app

Jab user “www.chatgpt.com” type karta hai, DNS indicate karta hai,
Yeh asli domain nahi hai, iska alias chatgpt.com hai.
Phir DNS “chatgpt.com” ka IP nikalta hai aur request waha bhej deta hai.

Why CNAME exists

• Avoid duplication:
  —> Same cheez baar-baar likhne ki zarurat nahi hoti.

• Easy management:
  —> Ek jagah change karo, sab jagah automatically update ho jata hai.

• Used with CDNs & SaaS tools:
  —> CDNs aur SaaS services ke saath domain connect karna easy ho jata hai.
  Here CDN means —> Content Delivery Network —> servers ka ek network hota hai jo website ke content ko user ke nearest location se deliver karta hai.

MX Record – How Email Routing Works

When someone sends email to your specified email like - user@youremail.com, DNS is asked —> Which server should receive the email for this domain? Emails kaha deliver karni hai?

yourdomain.com → MX → mail.google.com

MX record tells the internet which mail server should receive emails for a domain. It actually points email messages to the correct post office for delivery.
MX Record ——> post office address for emails.

NS Record – Who Controls the Domain

NS full form ——> Name Server.

When someone asks about your website like “yourdomain.com“, DNS doesn’t give IP address immediately. It first asks, is domain ke records kis DNS ke paas hai?
NS record replies like this

yourdomain.com → ns1.cloudflare.com
yourdomain.com → ns2.cloudflare.com

NS record does not store website IPs or email servers. It only tells who has the right data.

Simple DNS Flow

Let’s say you type “yourdomain.com“ :

1. Root DNS —> .com domain kaun handle karta hai?

2. .com DNS —> yourdomain.com ke liye ye NS servers responsible hai

3. Authoritative DNS (from NS record) —> main hi boss hoon. batao kya chahiye — A record? MX record?

NS vs MX

• NS Record —> DNS ka manager kaun hai?

  MX Record —> Emails kaha jayengi

• NS —> ghar ka caretaker
  MX —> post office address

TXT Record – Extra Information & Verification

Till now what we have read, DNS records were doing routing work, But sometimes, DNS is not about routing. Sometimes it’s about proof. That’s where TXT Record comes in. Some extra information attached to a domain, used for verification and security.

TXT Record stores plain text information for a domain.

DNS just says —> “Here is some text related to this domain.”
No IP / No server ———> Just information.

What problem does this actually solve? this question —> “Are you really the owner of this domain?”
DNS can answer that using a TXT record.
We add a secret text value ——> service checks it ——>ownership verified

example.com → TXT → google-site-verification=abc123

TXT records protect emails from spam & spoofing.

v=spf1 include:_spf.google.com ~all
// meaning  - Only Google can send emails on behalf of this domain.

Last important points to remember —> TXT records are read by machines, not humans.

How Multiple DNS Records Work Together

chaiaurcode.com
├── A → Web server IP
├── www → CNAME → chaiaurcode.com
├── api → A → Backend server IP
├── MX → Google Mail servers
└── NS → Cloudflare name servers