Imagine trying to send a book to a friend by mailing each page in a separate envelope. Without a system, your friend might receive page 10 before page 1, or page 5 might never show up at all. TCP (Transmission Control Protocol) is the system that ensures the book arrives perfectly, page by page.

The Problem: What Happens Without Rules?

Imagine you're trying to have a conversation across a crowded, noisy room. You shout "Hello!" but the other person doesn't hear you. You yell louder. They catch part of it but miss some words. You repeat yourself. Messages arrive out of order. Chaos.

This is what happens when computers try to communicate over the internet without a protocol.

The challenges:

• Packets get lost - Data travels through multiple routers and networks. Sometimes packets disappear.

• Packets arrive out of order - The internet routes packets independently. Packet #3 might arrive before packet #1.

• Packets get corrupted - Electrical interference or hardware errors can flip bits during transmission.

• No confirmation - If you send data, how do you know it was received?

• No flow control - A fast sender can overwhelm a slow receiver.

Without addressing these problems, the internet wouldn't work. You'd download corrupted files, web pages would load with missing pieces, and video calls would be unintelligible.

This is where TCP comes in.

What is TCP and Why Do We Need It?

TCP is a "connection-oriented" protocol. Unlike its faster, messier cousin UDP (which just throws data at the receiver), TCP insists on a formal introduction before any data is sent.

It was designed to solve three major problems:

1. Packet Loss: Data getting lost in transit.

2. Out-of-Order Delivery: Data arriving in the wrong sequence.

3. Data Corruption: Data getting mangled during the journey.

TCP vs UDP:

TCP isn't the only transport protocol. There's also UDP (User Datagram Protocol), which is faster but unreliable. UDP just sends data and hopes for the best—no guarantees, no handshakes, no retransmissions.

• TCP: Reliable, ordered, slow. Used for web browsing, email, file transfers.

• UDP: Fast, unreliable, no guarantees. Used for video streaming, gaming, DNS lookups.

Choose TCP when you need reliability. Choose UDP when you need speed and can tolerate some loss

The TCP 3-Way Handshake: Establishing a Connection

Before any data is sent, TCP establishes a connection using a 3-way handshake. This ensures both client and server are ready to communicate.

Think of it like a phone call:

• You: "Hello? Can you hear me?"

• Friend: "Yes, I can hear you. Can you hear me?"

• You: "Yes! Okay, let's talk."

Only after this exchange do you start your actual conversation. TCP does the same thing.

The Three Steps

The handshake involves three messages:

1. SYN (Synchronize) - Client to Server

2. SYN-ACK (Synchronize-Acknowledge) - Server to Client

3. ACK (Acknowledge) - Client to Server

After these three messages, the connection is established and data transfer can begin.

Step 1: Client Sends SYN

What happens:

The client wants to establish a connection. It sends a packet with:

• SYN flag set to 1 (this marks it as a synchronization request)

• Sequence number (let's say 1000) - a random starting number

Meaning: "Hi, I want to connect. My starting sequence number is 1000. Are you ready?"

Technical details:

Client → Server
SYN: 1
Sequence Number: 1000

The client is now in SYN_SENT state, waiting for a response.

Step 2: Server Sends SYN-ACK

What happens:

If the server is willing to accept the connection, it responds with:

• SYN flag set to 1 (server also wants to synchronize)

• ACK flag set to 1 (acknowledging the client's SYN)

• Sequence number (let's say 5000) - the server's random starting number

• Acknowledgment number set to 1001 (client's sequence + 1)

Meaning: "I received your request. My starting sequence number is 5000. I'm ready. I'm expecting your next byte to be 1001."

Technical details:

Server → Client
SYN: 1
ACK: 1
Sequence Number: 5000
Acknowledgment Number: 1001

The server is now in SYN_RECEIVED state.

Step 3: Client Sends ACK

What happens:

The client acknowledges the server's response:

• ACK flag set to 1

• Sequence number 1001 (as the server expected)

• Acknowledgment number set to 5001 (server's sequence + 1)

Meaning: "Got it! I received your confirmation. Let's communicate."

Technical details:

Client → Server
ACK: 1
Sequence Number: 1001
Acknowledgment Number: 5001

The connection is now ESTABLISHED on both sides. Data transfer can begin.

Visual: 3-Way Handshake

CLIENT                                   SERVER
  │                                        │
  │  1. SYN (seq=1000)                     │
  │ ─────────────────────────────────────> │
  │                                        │
  │  "I want to connect. My seq is 1000"   │
  │                                        │
  │                                        │
  │  2. SYN-ACK (seq=5000, ack=1001)       │
  │ <───────────────────────────────────── │
  │                                        │
  │  "Okay! My seq is 5000. I got yours"   │
  │                                        │
  │                                        │
  │  3. ACK (seq=1001, ack=5001)           │
  │ ─────────────────────────────────────> │
  │                                        │
  │  "Perfect! Connection established"     │
  │                                        │
  │━━━━━━━━ CONNECTION ESTABLISHED ━━━━━━━│
  │                                        │
  │  Now data can flow both ways           │
  │                                        │

Why Three Steps? Why Not Two?

You might wonder: why does the client need to send a final ACK? Couldn't we establish the connection after just SYN and SYN-ACK?

The reason: TCP is a two-way connection. Both sides need to:

1. Announce their starting sequence numbers

2. Acknowledge the other side's sequence number

Two messages wouldn't be enough:

• After SYN, the client knows the server is listening

• After SYN-ACK, the server knows the client is listening

• But the client doesn't yet know the server received confirmation

The third ACK ensures both sides are synchronized and ready.

How Data Transfer Works in TCP

Once the connection is established, data flows with sequence and acknowledgment numbers tracking everything.

Sequence Numbers

Every byte of data has a sequence number. If the client sends 100 bytes starting at sequence 1001, those bytes are numbered 1001 through 1100.

Example:

Client sends 100 bytes of data:

Client → Server
Sequence Number: 1001
Data: [100 bytes]

The server receives it and acknowledges:

Server → Client
Acknowledgment Number: 1101

This ACK says: "I received bytes 1001-1100. I'm expecting byte 1101 next."

Acknowledgments

TCP uses cumulative acknowledgments. An ACK number means: "I've successfully received all bytes up to (but not including) this number."

Example conversation:

Client sends bytes 1001-1100
Server ACKs: 1101 ("Got everything up to 1100")

Client sends bytes 1101-1200
Server ACKs: 1201 ("Got everything up to 1200")

Client sends bytes 1201-1300
Server ACKs: 1301 ("Got everything up to 1300")

This continues until all data is transferred.

Bidirectional Communication

TCP is full-duplex, meaning both sides can send and receive simultaneously. Each direction has its own sequence numbers.

CLIENT                          SERVER
  │                               │
  │  Data (seq=1001-1100)         │
  │ ───────────────────────────>  │
  │                               │
  │  Data (seq=5001-5200)         │
  │ <─────────────────────────── │
  │                               │
  │  ACK (ack=5201)               │
  │ ───────────────────────────>  │
  │                               │
  │  ACK (ack=1101)               │
  │ <─────────────────────────── │

Both sides maintain their own sequence numbers and acknowledge the other side's data

How a TCP Connection is Closed

Just like establishing a connection requires a handshake, closing it also requires a proper procedure. TCP uses a 4-way handshake for termination.

The Four Steps

1. FIN - Client to Server (or vice versa)

2. ACK - Server to Client

3. FIN - Server to Client

4. ACK - Client to Server

Step-by-Step Termination

Step 1: Client Sends FIN

The client is done sending data:

Client → Server
FIN: 1
Sequence Number: 1500

"I'm finished sending data."

Step 2: Server Sends ACK

The server acknowledges:

Server → Client
ACK: 1
Acknowledgment Number: 1501

"I got your FIN. I'm still processing."

At this point, the connection is half-closed. The client won't send more data, but the server can still send data to the client.

Step 3: Server Sends FIN

When the server is done:

Server → Client
FIN: 1
Sequence Number: 6000

"I'm finished sending data too."

Step 4: Client Sends ACK

The client acknowledges:

Client → Server
ACK: 1
Acknowledgment Number: 6001

"Got it. Connection closed."

The connection is now fully terminated.

Why Four Steps?

TCP is full-duplex—data flows in both directions independently. Each direction must be closed separately:

• Client → Server direction closes (FIN + ACK)

• Server → Client direction closes (FIN + ACK)

Total: 4 messages.

Complete Example: Loading a Web Page

Let's trace a real-world scenario: you visit https://example.com

Step 1: DNS Lookup (not TCP, but necessary) Your browser resolves example.com to IP address 93.184.216.34

Step 2: TCP 3-Way Handshake

Browser → Server (93.184.216.34:443)
  SYN (seq=1000)

Server → Browser
  SYN-ACK (seq=5000, ack=1001)

Browser → Server
  ACK (seq=1001, ack=5001)

Connection established.

Step 3: TLS Handshake (happens over TCP) HTTPS requires encryption, so a TLS handshake occurs here. We'll skip details.

Step 4: HTTP Request

Browser → Server
  Sequence: 1001
  Data: "GET / HTTP/1.1\r\nHost: example.com\r\n..."

Server → Browser
  ACK (ack=1100)

Step 5: HTTP Response

Server → Browser
  Sequence: 5001
  Data: "HTTP/1.1 200 OK\r\n...<html>..."

Browser → Server
  ACK (ack=7000)

Server may send multiple packets if the page is large.

Step 6: Connection Termination

Browser → Server
  FIN (seq=1100)

Server → Browser
  ACK (ack=1101)

Server → Browser
  FIN (seq=7000)

Browser → Server
  ACK (ack=7001)

Connection closed. Web page loaded.

All of this happens in milliseconds.

Key Takeaways

• TCP is a reliable, ordered, connection-oriented protocol that solves the chaos of unreliable networks

• The 3-way handshake (SYN, SYN-ACK, ACK) establishes a connection and synchronizes both sides

• Sequence numbers and acknowledgments ensure data arrives in order and completely

• Retransmissions and timeouts handle packet loss

• Checksums detect corrupted data

• Flow control prevents fast senders from overwhelming slow receivers

• Congestion control prevents network overload

• The 4-way handshake (FIN, ACK, FIN, ACK) properly terminates connections

• TCP trades speed for reliability - it's slower than UDP but guarantees delivery

Summary: Why TCP is the Backbone of the Web

TCP is the unsung hero of the internet. While it adds a bit of "overhead" (extra time for handshakes and ACKs), it provides the guaranteed delivery that makes the modern web possible. Without it, every file download would be a gamble and every website would be a broken mess.

“Where on earth should this request go?”

The system that solves this mystery is DNS (Domain Name System) — often called the phonebook of the internet.
Computers understand numbers (IP addresses), while humans prefer names (domain names). DNS acts as the bridge between the two by translating human-friendly domain names into machine-understandable instructions.

Instead of hard-coding IP addresses everywhere, DNS uses records — small configuration entries that describe how different kinds of requests for a domain should be handled. Different record types exist for different jobs: some point to web servers, some route emails, and some declare who is actually in charge of the domain’s DNS.

In this blog, we’ll break down the most important DNS record types, understand why they exist, and see how they work together in real production systems — in a way that’s easy to follow and useful for interviews.

What Are DNS Records and Why Do They Exist?

A DNS record is a single row in the DNS “database” that says:

For this name, here is how to handle a specific kind of request.

Each record answers a specific question about a domain, such as:

• Where is the website hosted?

• Where should email be delivered?

• Who is responsible for managing the domain?

Instead of providing one generic answer, DNS uses different record types, each with a focused responsibility.

Think of DNS as a traffic control system:

• Web traffic goes this way

• Email traffic goes that way

• Management and authority are handled separately

Each DNS record has at least:

• Name (e.g., example.com, api.example.com)

• Type (A, AAAA, CNAME, MX, NS, TXT, etc.)

• Value (IP address, another domain, mail host, or name server)

• TTL (Time To Live) — how long DNS resolvers can cache the answer

In short, DNS records allow humans to use names instead of IP addresses, while ownership and configuration are cleanly delegated behind the scenes.

A Record: Mapping Domain Names to IPv4 Addresses

What Problem Does It Solve?

Computers do not understand domain names — they understand IP addresses.

An A (Address) record maps a domain name to an IPv4 address.
It answers the question:

“Which server IP should handle this request?”

Example

example.com → 93.184.216.34

When you type example.com, your browser first talks to a DNS resolver (also called a recursive DNS server). The resolver does the heavy lifting — querying the root name servers, the TLD server (.com), and finally the authoritative name server to obtain the A record.

This resolution happens before the TCP handshake. Without the A record, the browser has no IP address to send the initial SYN packet to.

Real-World Usage

• Websites hosted on AWS, Azure, or GCP

• Backend APIs

• Load balancers pointing to multiple servers

AAAA Record: Mapping Domains to IPv6 Addresses

What Problem Does It Solve?

The internet is gradually moving from IPv4 to IPv6 due to address exhaustion.

An AAAA (Quad-A) record maps a domain name to an IPv6 address.
Functionally, it is the same as an A record — except it works with IPv6.

Question it answers:
“Which IPv6 server should handle this request?”

example.com → 2606:2800:220:1:248:1893:25c8:1946

Real-World Usage

• Modern cloud infrastructure

• Mobile networks

• IPv6-enabled ISPs

• Dual-stack deployments (IPv4 + IPv6)

CNAME Record: Domain Aliases and Indirection

What Problem Does It Solve?

Sometimes, the DNS resolver reaches the authoritative name server and receives another domain name instead of an IP address.

This is where the CNAME (Canonical Name) record comes in.

The CNAME answers:

“This domain is an alias — where is the real one?”

Example

www.example.com → example.com

The authoritative server is effectively saying:

“I don’t have an IP for www.example.com, but I can tell you it’s an alias for example.com.”

The resolver then resolves example.com (often using cached root and TLD data) to obtain the final A or AAAA record.

Real-World Usage

• Cloud services (CloudFront, Azure App Service, GitHub Pages)

• Avoiding IP changes when infrastructure changes

• Cleaner DNS management

Key Points

• You cannot have a CNAME and other record types (A, MX, TXT) for the same hostname.

• CNAMEs are usually avoided at the zone apex (example.com); instead, A/AAAA records are used.

• If the IP behind example.com changes, the CNAME does not need updating — only the final A/AAAA record does.

Common Confusion: A vs CNAME

NS Record: Who Controls the Domain?

What Problem Does It Solve?

An NS (Name Server) record specifies which DNS servers are authoritative for a domain.

It answers:

“Which servers have the final, official DNS records for this domain?”

When the resolver queries the TLD server (.com), the TLD responds with NS records saying:

“I don’t know the IP, but these servers own the DNS for example.com. Go ask them.”

Where the NS Record Lives (Delegation)

NS records exist in two places:

1. Parent zone (e.g., .com): tells resolvers where authority is delegated

2. Child zone (authoritative server): confirms it owns the zone

The “Chicken and Egg” Problem: Glue Records

If a nameserver is inside the same domain it serves (e.g., ns1.example.com), the resolver needs its IP before it can query it.

To solve this circular dependency, the TLD server provides a Glue Record — an A record containing the IP of the nameserver.

Key takeaway:
NS records say who to ask. Glue records say how to reach them.

Summary Table for the "End-to-End" Flow.

Common Confusion: NS vs MX

TXT Record: Storing Text-Based Instructions and Proof

What Problem Does It Solve?

Sometimes DNS needs to store information, not routing data.

A TXT record stores arbitrary text used by external systems for verification and security.

Question it answers:
“Can this domain prove or publish something?”

Example

example.com → "v=spf1 include:_spf.google.com ~all"

This SPF record tells mail servers which systems are allowed to send email for the domain.

Real-World Usage

• SPF, DKIM, and DMARC

• Domain ownership verification

• SSL certificate validation

• Third-party service integrations

Key Point:
TXT records do not control traffic. They provide proof and configuration data.

Final Thoughts: DNS Is Simple — Until It Isn’t

DNS looks simple on the surface, but it quietly powers almost everything on the internet. Websites load, emails get delivered, and cloud systems scale — all because DNS answers one fundamental question correctly:

“Where should this request go?”

Each DNS record exists to answer a specific version of that question:

• A / AAAA → Where is the server?

• CNAME → Is this an alias?

• MX → Where should email be delivered?

• TXT → Can this domain prove something?

• NS → Who controls the domain?

In real production systems, these records work together, not in isolation. A single DNS change can enable global scale — or cause a global outage.

DNS isn’t about memorizing record types.
It’s about understanding traffic, ownership, and trust on the internet.

DNS Records: Interview Questions & Answers

Q1. What are DNS records and why do they exist?

Answer:
DNS records are instructions stored in DNS servers that tell the internet how to route requests for a domain. They exist to translate human-readable domain names into actionable information such as IP addresses, mail servers, or verification data.

Without DNS records, systems would not know:

• Where a website is hosted

• Where emails should be delivered

• Who controls a domain

Q2. What is the difference between an A record and a CNAME record?

Answer:

• An A record maps a domain directly to an IPv4 address.

• A CNAME record maps a domain to another domain name.

Key rule:
A domain with a CNAME record cannot have other records like MX or TXT.

Example:

example.com      → A → 93.184.216.34
www.example.com  → CNAME → example.com

Q3. When should you use AAAA records?

Answer:
AAAA records are used to map a domain to an IPv6 address.
They are increasingly important as IPv6 adoption grows.

In modern production systems, it’s common to configure both A and AAAA records so clients can connect using either IPv4 or IPv6.

Q4. How does email routing work using MX records?

Answer:
MX records specify which mail servers are responsible for receiving emails for a domain.

They include a priority value, where lower numbers are tried first.

Example:

example.com → MX 10 mail1.example.com
example.com → MX 20 mail2.example.com

If the first server fails, the second is used automatically.

Q5. What is a TXT record and why is it important?

Answer:
TXT records store arbitrary text and are commonly used for:

• Domain ownership verification

• Email security (SPF, DKIM, DMARC)

• Service integrations (Google, Microsoft, GitHub)

TXT records play a critical role in security and trust on the internet.

Q6. What does an NS record do?

Answer:
NS records define which name servers are authoritative for a domain.

They establish control and delegation, not traffic routing.

Without correct NS records:

• DNS changes won’t propagate

• Domains may stop resolving entirely

Q7. Can a single domain have multiple DNS records?

Answer:
Yes. A domain typically has multiple DNS records working together.

Example:

• A / AAAA → Website access

• MX → Email delivery

• TXT → Security and verification

• NS → DNS authority

Each record answers a different routing question.

Q8. Common DNS Interview Trick Question

Question:
Why can’t you use both CNAME and MX on the same domain?

Answer:
Because a CNAME replaces the domain name entirely with another name.
Allowing MX or TXT alongside it would create ambiguity during DNS resolution.

Q9. How does DNS relate to real production systems?

Answer:
In production:

• Load balancers rely on DNS

• Failover is often DNS-based

• Cloud services depend heavily on DNS TTLs

• Misconfigured DNS can cause global outages

DNS is a critical infrastructure layer, not just a configuration detail.