What this means in JavaScript

this keyword refers the context where a piece of code runs, might be in function's body or a object. The golden rule that explains everything about this depends on how a function is called, not where its defined but how its invoked.

When a regular function is invoked as a method of an object, this points to that object. When invoked as a standalone function (not attached to an object: func()), this typically refers to the global object (in non-strict mode) or undefined (in strict mode).

this inside a regular function

function showThis() {
  console.log(this);
}

showThis();

How it’s invoked

• Called as a plain function: showThis()

What this is

• In non-strict mode (browser) → this = window

• In strict mode → this = undefined

• In Node.js → this = global (or undefined in strict mode)

👉 Key point: this depends on how the function is called, not where it’s defined.

this inside an object method

const user = {
  name: "Alice",
  greet: function () {
    console.log(this.name);
  }
};

user.greet();

How it’s invoked

• Called as a method of the object: user.greet()

What this is

• this = the object before the dot → user

• So this.name → "Alice"

👉 Key point: When a function is called as a method, this refers to the owning object.

call, apply, and bind in JavaScript

All three do the same core thing: let you borrow a function and control what this refers to inside it. The difference is how and when the function runs.

The Setup — why do we need them?

const person = { name: "Alice" };

function greet(greeting, punctuation) {
  console.log(`\({greeting}, \){this.name}${punctuation}`);
}

greet uses this.name, but this isn't set. These three methods let us inject person as this.

1. call — borrow & run immediately, args comma-separated

greet.call(person, "Hello", "!");
// → "Hello, Alice!"

Syntax: fn.call(thisArg, arg1, arg2, ...)

🧠 Mental model: Think of it as a phone call — you dial (call) someone right now, and you pass each thing you want to say one at a time.

2. apply — borrow & run immediately, args as an array

greet.apply(person, ["Hey", "?"]);
// → "Hey, Alice?"

Syntax: fn.apply(thisArg, [arg1, arg2, ...])

🧠 Mental model: Same as call, but you apply a whole list of arguments at once — like handing someone a sheet of paper with everything on it, instead of saying each thing one by one.

3. bind — borrow & get back a new function (doesn't run yet)

const greetAlice = greet.bind(person, "Hi");

// ... later ...
greetAlice("!!");
// → "Hi, Alice!!"

Syntax: const newFn = fn.bind(thisArg, arg1, ...)

bind lets you pre-fill some arguments too (called partial application).

🧠 Mental model: Think of bind as a sticky note — you write down who this is and pre-fill some args, then stick it on the function. The function doesn't run until you decide to call it later.

Side-by-side comparison

The one-line summary for each

• call → "Run this function NOW, with this this, passing args separately"

• apply → "Run this function NOW, with this this, passing args as an array"

• bind → "Give me a new function with this (and maybe some args) locked in — I'll call it later"

Every JavaScript environment has a global object, but it has different names:

1. window in browsers

2. global in Node.js,

3. and self in Web Workers.

This forced developers to write messy environment-detection code just to access it reliably. globalThis, introduced in ES2020, solves this by providing one universal name that works everywhere. Use it when you need cross-environment compatibility - but use it sparingly, as polluting the global scope leads to bugs and messy code.

What is scope?

Almost every modern programming language has the concept of scope, and JavaScript is no exception. At its core, scope answers simple question:

Think of a code which has 10000 lines, if a variable defined once, is accessible throughout the huge code, is it a good practice?
The scope here sets the boundary of the variables - when you create a variable, it's not always everywhere, scope defines the boundaries of where that variable lives and who can access it.

Global & Function Scope

let globalVar = 'This is global variable';

function localScope() {
  let localVar = 'This is local variable';

  console.log('Inside function: ', localVar);  // ✅ This is local variable
  console.log('Inside function: ', globalVar); // ✅ This is global variable
}

localScope();

console.log('Outside function: ', globalVar); // ✅ This is global variable
console.log('Outside function: ', localVar);  // ❌ ReferenceError: localVar is not defined

Global Scope - visible everywhere in your code
Function Scope - visible only inside that function

Block Scope

Block Scope - visible only inside that block { }

let localFlag = true;

if (localFlag) {
  let blockVar = 'This is in if block';
  console.log('Inside block: ', blockVar); // ✅ This is in if block
}

console.log('Outside block: ', blockVar); // ❌ ReferenceError: blockVar is not defined

What is the Global Object?

We just saw that variables declared outside any function are accessible everywhere. But have you ever wondered what 'everywhere' actually means in JavaScript? There's a container that holds all of these global variables, and it's called the global object.

In each JavaScript environment, there's always a global object defined. The context of global's interface depends on the execution context in which the script is running -

The Problem: global, window, self

The real problem is this: the global object means the same thing in every JavaScript environment, but it goes by a different name in each one. To write code that worked everywhere, developers either required to write environment specific code or had to manually check which environment they were in:

function getGlobalObject() {
  if (typeof window !== 'undefined') return window;   // Browser
  if (typeof global !== 'undefined') return global;   // Node.js
  if (typeof self !== 'undefined') return self;       // Web Workers
  throw new Error('Unable to locate global object');  // Unknown environment
}

const globalObj = getGlobalObject();

This approach was error-prone. In strict mode, this is undefined instead of the global object, silently breaking the fallback. It was too much boilerplate just to do one simple thing , access the global object.

What is globalThis and what problem does it solve?

Remember that function we just wrote to detect the environment? globalThis makes it completely unnecessary. Introduced in ES2020, it gives JavaScript a single standardised way to access the global object, no environment checks, no fragile fallbacks. It just works, everywhere.

Benefits of globalThis:

1. Easy Access - Available out of the box in every JavaScript environment. No imports, no setup, no configuration needed.

2. Simplified Code - Replaces lengthy environment detection code with a single, consistent reference. What used to take 5 lines now takes one.

3. Maintainable Code - Any developer, regardless of their background, immediately understands what globalThis refers to. No guessing, no environment-specific surprises.

How to Use globalThis?

Setting a global variable

globalThis.myVar = 'Hello World';
console.log(globalThis.myVar); // Hello World

Sharing data across modules

// module-a.js
globalThis.config = { debug: true, version: '1.0.0' };

// module-b.js
console.log(globalThis.config.version); // 1.0.0

Checking if a feature exists

if (typeof globalThis.fetch !== 'undefined') {
  console.log('fetch is supported');
} else {
  console.log('fetch is not supported');
}

Comparing with global

// ❌ Before — complicated environment detection
function getGlobalObject() {
  if (typeof window !== 'undefined') return window;   // Browser
  if (typeof global !== 'undefined') return global;   // Node.js
  if (typeof self !== 'undefined') return self;       // Web Workers
  throw new Error('Unable to locate global object');  // Unknown environment
}

const globalObj = getGlobalObject();
globalObj.myVar = 42;
console.log(globalObj.myVar); // 42


// ✅ After — simple and universal
globalThis.myVar = 42;
console.log(globalThis.myVar); // 42

When should you use it? (+ avoid polluting globals)

globalThis is powerful, but that doesn't mean you should reach for it often. Here's a simple rule:

Use globalThis only when you genuinely need something to be accessible across your entire application and across different environments.

Good use cases:

• Writing a library or utility that runs in both browser and Node.js

• Feature detection across environments

• Polyfilling missing features

• Sharing configuration across modules

Avoid it when:

• A regular variable or module export would do the job

• You're tempted to use it just to avoid passing data around properly

⚠️ Don't Pollute the Global Scope

Every property you add to globalThis is available everywhere in your entire program. This sounds convenient but causes real problems:

javascript

// ❌ Bad — polluting the global scope
globalThis.username = 'Alice';
globalThis.fetchData = function() { ... };
globalThis.config = { debug: true };

// ✅ Good — keep things scoped with modules
export const username = 'Alice';
export function fetchData() { ... }
export const config = { debug: true };

Polluting globals leads to:

• Name collisions : two files accidentally overwrite each other's variables

• Harder debugging : variables change from unexpected places

• Messy codebase : nothing is predictable

global vs globalThis

Wrap up

If you learnt something new about the global and globalThis concept in Javascript, share it with your friends and teammates :) Follow me for more content

JavaScript operators work exactly the same way. They sit between two values, do something with them, and give you back a result. The only difference? JavaScript's calculator is a lot smarter. It doesn't just do math - it compares things, makes decisions, and remembers values.

In this post, we'll use a calculator as our mental model to understand every type of operator in JavaScript. By the end, none of this will feel foreign, because it isn't.

What Are Operators?

Pick up a basic calculator. It has two things: numbers and buttons. The numbers are your raw data. The buttons — +, -, =, % — are your operators.

An operator is a symbol that tells JavaScript to perform a specific action on one or more values. Those values are called operands. Press 5 + 3 on a calculator and you get 8. In JavaScript, it's exactly the same:

let result = 5 + 3;
console.log(result); // 8

🧮 Calculator Analogy: The numbers on the screen are your values. The buttons you press are your operators. Without the buttons, the numbers just sit there doing nothing.

Arithmetic Operators (+, -, *, /, %)

This is your calculator in its most basic form, standard mode. You have your four classic operations and one sneaky one that trips beginners up every time.

let a = 10;
let b = 3;

console.log(a + b);  // 13 → addition
console.log(a - b);  // 7  → subtraction
console.log(a * b);  // 30 → multiplication
console.log(a / b);  // 3.33 → division
console.log(a % b);  // 1  → remainder

The first four are obvious. But %? Most calculators have this button and most people never touch it. Here's the secret, it doesn't give you a percentage. It gives you the leftover remainder after a division.

🧮 Calculator Analogy: Imagine dividing 10 sweets equally among 3 friends. Each gets 3 sweets. But you have 1 left over. That leftover is exactly what % returns. 10 % 3 = 1.

Modulo is surprisingly useful in real code, checking if a number is even or odd, cycling through a list, building a clock that resets to zero, and much more.

Comparison Operators (==, ===, !=, >, <)

Now imagine your calculator has a compare mode. Instead of calculating a result, it looks at two values and answers one question: true or false?

Is 10 greater than 5? True. Is 3 equal to 7? False. That's exactly what comparison operators do , they always return either true or false, nothing else.

console.log(10 > 5);   // true
console.log(3 < 1);    // false
console.log(5 != 3);   // true (they are NOT equal)

Now here's the part that confuses almost every beginner, == versus ===. Two equal signs vs three.

🧮 Calculator Analogy: Imagine you type "5" (as text) and 5 (as a number) into two calculators. They display the same thing on screen. == looks at the screen and says "same!" But === peeks inside the machine and says "one is text, one is a number , they're NOT the same."

console.log("5" == 5);   // true  ← dangerous!
console.log("5" === 5);  // false ← correct and safe

As a rule of thumb, always use === in your code. It checks both the value and the type, making your comparisons reliable and bug-free.

Logical Operators (&&, ||, !)

Your calculator can now compare. But what if you need to check two conditions at the same time? What if one condition being true is enough? What if you want to flip a result?

That's logic mode. Logical operators combine true/false values to make bigger decisions.

🧮 Calculator Analogy: Think of a calculator that only turns on if you enter the right PIN AND it has battery. Both must be true. But a low-battery warning fires if the battery is low OR the charger is unplugged — either one triggers it. And ! is the on/off toggle. It flips whatever state you're in.

let hasBattery = true;
let isCharged  = false;

console.log(hasBattery && isCharged);  // false → both must be true
console.log(hasBattery || isCharged);  // true  → at least one is true
console.log(!hasBattery);              // false → flips true to false

A simple way to remember them:

• && — strict bouncer. Everyone in the group must qualify.

• || — easy bouncer. Anyone qualifies, the whole group gets in.

• ! — the invert button. Flips true to false, and false to true.

Assignment Operators (=, +=, -=)

Every calculator has a memory button , M+ to add to memory, MR to recall it. Assignment operators are JavaScript's memory system. They store values into variables and update them over time.

let score = 0;     // store 0 in memory

score += 10;       // same as: score = score + 10 → 10
score += 5;        // same as: score = score + 5  → 15
score -= 3;        // same as: score = score - 3  → 12

console.log(score); // 12

🧮 Calculator Analogy: When you hit M+ on a calculator, you're not replacing what's in memory, you're adding to it. That running total in memory is exactly what += does to a variable.

The shorthand operators aren't just lazy shortcuts — they make your code more readable and less error-prone. score += 10 says exactly what you mean in half the characters.

Putting It All Together

Let's write a tiny score tracker that uses every operator we've covered, just like a real calculator uses all its modes together.

// Assignment: store starting values
let playerScore = 0;
let targetScore = 50;
let lives = 3;

// Arithmetic: calculate points for this round
let pointsEarned = 20 + 15;         // 35
let bonus = pointsEarned % 10;      // 5 (remainder)

// Assignment shorthand: update the score
playerScore += pointsEarned + bonus; // 0 + 40 = 40

// Comparison: has the player won?
let hasWon = playerScore >= targetScore; // false (40 < 50)

// Logical: game continues if not won AND has lives left
let gameContinues = !hasWon && lives > 0; // true

console.log("Score:", playerScore);      // 40
console.log("Won?", hasWon);             // false
console.log("Continue?", gameContinues); // true

Wrapping Up

You've been using operators your whole life, in school, on your phone, in your head. JavaScript just gives you a more powerful set of buttons. Arithmetic crunches the numbers. Comparison checks the results. Logic makes the decision. Assignment remembers it all.

The calculator analogy holds all the way through. Once you internalise it, operators won't feel like syntax anymore, they'll feel like tools you already know how to use.

TCP (Transmission Control Protocol) is one of the core protocols of the Internet Protocol Suite. It operates at the Transport Layer (Layer 4) and provides a reliable, ordered, and error-checked delivery of data between applications running on networked devices.

Think of TCP as a postal service with tracking and confirmation. When you send a package, you want to know:

• Did it arrive?

• Did it arrive intact?

• Did it arrive in the right order (if you sent multiple packages)?

TCP provides these guarantees for data packets traveling across the internet. Without TCP, applications like web browsers, email clients, file transfers, and SSH connections wouldn't work reliably.

Why TCP is needed:

• The underlying Internet Protocol (IP) is unreliable - packets can be lost, duplicated, delayed, or arrive out of order

• Applications need a reliable communication channel without worrying about the chaos of the underlying network

• Developers need a simple interface - they can write data to a stream and trust it will arrive correctly

Problems TCP is Designed to Solve

Step-by-step working of SYN, SYN-ACK and ACK

Imagine you're trying to start a phone conversation with a friend:

You: "Hey, can you hear me?" (This is the SYN - you're initiating contact)
Friend: "Yes, I can hear you! Can you hear me?" (This is the SYN-ACK - they acknowledge hearing you AND check if you can hear them)
You: "Yep, I hear you too!" (This is the ACK - you confirm you received their response)

Now you both know the line is working in both directions, and you can start your actual conversation.

If we translate this into technical -

Step 1: SYN (Synchronize)

• Client sends a TCP segment with the SYN flag set

• Includes an initial sequence number (ISN) - let's say seq=1000

• This says: "I want to establish a connection, and my starting sequence number is 1000"

Step 2: SYN-ACK (Synchronize-Acknowledge)

• Server receives the SYN

• Server responds with both SYN and ACK flags set

• Sends its own initial sequence number - say seq=5000

• Acknowledges the client's sequence number: ack=1001 (client's seq + 1)

• This says: "I received your request, my starting sequence number is 5000, and I'm expecting your next byte to be 1001"

Step 3: ACK (Acknowledge)

• Client sends an ACK back to the server

• seq=1001 (as expected by the server)

• ack=5001 (server's seq + 1)

• This says: "I received your response, and I'm expecting your next byte to be 5001"

Connection is now ESTABLISHED! Both sides have synchronized their sequence numbers and are ready to exchange data.

Data Transfer in TCP

TCP breaks data into segments, each with a sequence number. The sender transmits segments, and the receiver acknowledges them.

Example: You send "Hello World" (11 bytes)

• TCP breaks it into segments: [SEQ=1, "Hello"] and [SEQ=6, " World"]

• Receiver gets segment 1 → sends ACK=6 (expecting byte 6 next)

• Receiver gets segment 2 → sends ACK=12

How TCP Ensures Reliability, Order & Correctness

TCP Connection Termination

Either side can initiate closing. It uses FIN (finish) flags.

    Client                    Server
       |                         |
       |-------- FIN ----------->|   1. Client: "I'm done sending"
       |<------- ACK ------------|   2. Server: "Got it"
       |                         |
       |<------- FIN ------------|   3. Server: "I'm done too"
       |-------- ACK ----------->|   4. Client: "Got it, closing"
       |                         |
    CLOSED                    CLOSED

Example: Closing an HTTP connection

1. Browser finishes request → sends FIN

2. Server acknowledges with ACK

3. Server finishes response → sends its FIN

4. Browser sends final ACK → both sides close

The client then enters a TIME_WAIT state (typically 2 minutes) to handle any delayed packets before fully closing.

Conclusion

• TCP (Transmission Control Protocol) is a fundamental protocol of the Internet Protocol Suite that ensures reliable, ordered, and error-checked data delivery between applications on networked devices.

• It overcomes issues such as packet loss, out-of-order delivery, data corruption, duplicate packets, and congestion through mechanisms like acknowledgments, sequence numbers, checksums, and congestion control algorithms.

• TCP also involves a three-step process (SYN, SYN-ACK, ACK) to establish connections and ensures orderly data transfer with its sequence and acknowledgment features.

• Lastly, it provides a structured method for connection termination using FIN and ACK flags.

If you find this blog interesting, feel free to share it across. Follow me on LinkedIn

Every website has an IP address (like 192.0.2.1), but nobody wants to memorise numbers. DNS (Domain Name System) is the internet's phonebook, it translates human-friendly names into machine-readable addresses. When you type a domain, your browser asks a DNS server: "What's the address for this name?" The server looks it up and responds. Your browser then connects to that IP address. All of this happens in milliseconds, invisibly.

Why records exists?

Think about a contact in your phone. You don't just store one piece of information, you save their mobile number, work number, email, maybe even their home address. Each serves a different purpose, but they all belong to the same person.

DNS records work the same way. A domain name isn't just one thing, it's an identity that needs to handle multiple jobs. Your website needs to load. Emails need to arrive. Subdomains need to work. Security needs to be verified. A single IP address can't communicate all of that.

That's why DNS uses records, different types of entries that tell the internet how to handle different requests for your domain.

Types of DNS records

A Record

A → “Address”, the most fundamental type of DNS record type. It contains the IP address of a given domain. When a DNS resolver queries for a domain name, the A record returns the 32-bit IPV4 address attached to it.

example.com.    3600    IN    A           93.184.216.34

• TTL (Time To Live): 3600 seconds

• Class: IN (Internet)

• Type: A

• Value: IPv4 address

Majority of websites will have only one A record, however some high profile websites might have several different A records as a part of technique called round robin load balancing.

Imagine you're looking up "Krishna's Kapi Shop" in a city directory. The A Record is like finding the entry that says "Krishna's Kapi Shop → 742 Evergreen Terrace." When you want to visit (send a request), you now know exactly which building (server) to go to. Without this address, you know the name but can't find the actual location.

When and Why Used

• Primary use: Pointing your domain to your web server

• When: Every website needs at least one A Record for the root domain

• Why: Without it, browsers can't find your website - they need the IP address to establish a connection

• Example scenario: You host your website on a server at IP 203.0.113.50. You create an A Record so mysite.com points to that IP

AAAA Record

An AAAA Record maps a domain name to a 128-bit IPv6 address. It's functionally identical to an A Record but uses the newer IPv6 addressing scheme. The "AAAA" name comes from IPv6 addresses being four times larger than IPv4 (128 bits vs 32 bits).

example.com. 3600 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Think of international phone numbers. The old system had 7-digit local numbers (IPv4), but we ran out. Now we have longer international format numbers with country codes and more digits (IPv6): +1-555-0123-4567-8901. Both get you to the same place, just different numbering systems.

When and Why Used

• Primary use: Enabling IPv6 connectivity to your services

• When: Increasingly necessary as IPv4 addresses are exhausted; major sites have both A and AAAA records

• Why: Future-proofing your infrastructure; some networks are IPv6-only; better performance in IPv6 networks

• Example scenario: Your hosting provider gives you an IPv6 address. You add an AAAA Record so visitors on IPv6 networks can reach you directly without IPv4 translation

CNAME Record

The GitHub Pages -

Default Setup - When I create a GitHub Pages site, GitHub automatically hosts it at:

• Personal site: username.github.io

• Project site: username.github.io/repository-name

Example: Lets say my GitHub username is vibhavari, so your site lives at vibhavari.github.io

The Problem?

You want your professional blog at www.vibhavari.com instead of vibhavari.github.io because:

• Custom domain looks more professional

• Easier to remember

• You control the branding

• You can migrate away from GitHub Pages later without breaking links

How CNAME Solves This

GitHub's Infrastructure GitHub Pages hosts your content on their servers with a generic address:

• Your content actually lives at: vibhavari.github.io

• GitHub's servers are at specific IP addresses they control

In your DNS provider (Cloudflare, GoDaddy, Route53, etc.), you create:

www.vibhavari.com.  3600  IN  CNAME  vibhavari.github.io.

this means:

• "When someone visits www.vibhavari.com, go look up vibhavari.github.io instead"

• The DNS resolver follows the chain: www.vibhavari.com → vibhavari.github.io → (GitHub's A records) → IP address

In your GitHub repository settings, you tell GitHub:

• "Accept traffic for www.vibhavari.com"

• GitHub creates a CNAME file in your repository root containing: www.vibhavari.com

So what does CNAME record do? A CNAME Record creates an alias by mapping one domain name to another domain name (the canonical name). When a DNS resolver encounters a CNAME, it performs another lookup for the target domain. CNAMEs cannot coexist with other record types at the same name level (this is a critical DNS protocol requirement).

NS Record

An NS Record delegates a DNS zone to a specific authoritative name server. It tells DNS resolvers which server(s) are authoritative for answering queries about a particular domain. Every domain must have at least two NS records (for redundancy) pointing to name servers that host the domain's DNS information.

example.com. 86400 IN NS ns1.nameserver.com.

Think of a corporate directory: The main receptionist doesn't know everyone's extension. When you call asking for the Marketing department, they say: "Marketing is handled by Extension 5000, transfer there." The NS Record is that transfer.

When and Why Used

• Primary use: Delegating DNS authority for a domain or subdomain

• When: Setting up a domain, delegating subdomains to different DNS providers, using a CDN

• Why: Enables distributed DNS management; allows different teams/services to control their own subdomains

• Example scenario 1: You register example.com at a registrar. You must point NS records to your DNS hosting provider (like Cloudflare, Route53, etc.)

MX Record

An MX Record specifies the mail servers responsible for accepting email on behalf of a domain. It includes a priority value (lower numbers = higher priority) to enable fallback mail servers. When someone sends email to user@example.com, their mail server queries the MX records to find where to deliver the message.

example.com. 3600 IN MX 10 mail1.example.com.

• Priority: 10 (lower is preferred)

• Mail server: mail1.example.com

Think of a corporate mail room hierarchy. Your company receives physical mail, but there's a priority system:

• Priority 10: Main mail room (handles 95% of mail) - mail1.example.com

• Priority 20: Backup mail room (if main is full/closed) - mail2.example.com

• Priority 30: Emergency off-site facility - mail3.example.com

The postal service tries the Priority 10 location first. If it's unavailable, they try Priority 20, and so on.

When and Why Used

• Primary use: Directing email to the correct mail servers

• When: Setting up email for your domain; using email services like Google Workspace, Microsoft 365

• Why: Separates email infrastructure from web hosting; enables redundancy and load balancing for email

• You use Google Workspace for email. You create MX records:

  example.com. IN MX 1 aspmx.l.google.com.
  example.com. IN MX 5 alt1.aspmx.l.google.com.
  example.com. IN MX 5 alt2.aspmx.l.google.com.

If the primary server is down, email automatically routes to backups.

TXT Record

A TXT Record stores arbitrary text data associated with a domain. Though originally intended for human-readable notes, TXT records are now primarily used for machine-readable data like domain verification, email security policies (SPF, DKIM, DMARC), and site ownership verification. The data is stored as a string (up to 255 characters per string, but multiple strings can be concatenated).

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

Think of a bulletin board outside your house with various notices:

• "This is indeed the Johnson residence" (domain verification)

• "We only accept mail from USPS and FedEx" (SPF)

• "Packages should be left with neighbor at #125" (special instructions)

When and Why Used

• Primary use: Domain verification, email authentication, security policies

• When: Proving domain ownership, preventing email spoofing, setting up third-party services

• Why: Provides a flexible mechanism for adding metadata to domains without creating new DNS record types

Common Use Cases:

1. Domain Verification

• When: Setting up Google Workspace, Microsoft 365, or any service that needs to verify you own the domain

• Example: example.com. IN TXT "google-site-verification=abc123xyz"

• Why: Proves you control the domain before the service activates

2. SPF (Sender Policy Framework)

• When: Configuring email to prevent spoofing

• Example: example.com. IN TXT "v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all"

• Why: Lists which servers are allowed to send email from your domain; reduces spam/phishing

• Translation: "Only these mail servers can send email claiming to be from @example.com"

So in summary, if you think of it as a city:

• NS Records → City charter (who governs)

• A/AAAA Records → Building addresses (where things are)

• CNAME Records → Street signs & aliases (how to find things)

• MX Records → Post office system (mail delivery)

• TXT Records → Business licenses & permits (verification & security)

If you like the blog, please share it with others. Follow me on linkedin

What is DNS?

Domain Name System ( DNS ) is is a hierarchical and distributed name service that provides a naming system for computers, services, and other resources on the Internet or other Internet Protocol (IP) networks, in layman words - is a process where it helps internet users to search using the host names instead of numeric IP address. DNS is like a phonebook of internet, it transforms human readable host names into numeric IP address for computers to communicate through network.

As we know, each device connected to internet has a unique IP address which other machines can find and communicate to. Name resolution is process in converting hostnames ( simple english string ) to IP address for network communication. Human always understand descriptive names, but machine communication through network using IP address.

What is the dig command and its uses

dig stands for Domain Information Groper, think of it as a tool that lets peek whats happening in DNS. It is a diagnostic tool, it performs interrogation with DNS name servers. It performs DNS lookups and display the answers that returned from the queries name server(s).

When you type google.com in your browser, DNS quietly works in the background to find the IP address. dig lets you manually ask those same DNS questions yourself and see all the details of what happens.

Usually DNS administrators use dig command to troubleshoot DNS problems because of its flexibility, easy to use and provides clear output.

When you run dig google.com you get a detailed report with sections like:

**1. Question Section** - What you asked
```
;; QUESTION SECTION:
;google.com.                    IN      A
```
Translation: "What is the A record (IP address) for google.com?"

**2. Answer Section** - The actual answer
```
;; ANSWER SECTION:
google.com.             300     IN      A       142.250.185.46

The DNS Hierarchy: A Three-Tier Architecture

The sequence in which query resolves describes the hierarchial path of a DNS. The sequence is Root → TLD → Authoritative Servers.

Root Servers →
The root of the DNS tree, represented by a dot (.). It is the starting point for all DNS queries. The root servers do not know the IP address of a domain but direct queries to the appropriate TLD server. There are 13 logical root server addresses, with hundreds of actual servers worldwide.

Top-Level Domains(TLD) →

If a website address is like a street address, the TLD is like the city, state, or country at the end. It tells you the general "location" or category that the website belongs to. Lets say, in the address www.google.com, the TLD is just the .com part.

Why do we need them?

The internet is too big to be one giant list. TLDs help organize websites into different categories so they are easier to manage and understand.

They act like big labels that give you a hint about what a website is for:

• .com usually means it is a commercial business (like Amazon or Google).

• .in is for the India.

• .edu means it is an educational institution (like a university).

• .gov means it is a government agency.

Authoritative Servers →

Think of authoritative servers as the official source of truth for a specific domain, holding the actual DNS records ( A, AAAA, MX, etc ) for a specific domain name. They provide the final IP address to the resolver

                    [ROOT]
                      |
        +-------------+-------------+
        |             |             |
      [.com]        [.org]        [.net]  ← TLD level
        |
    +---+---+
    |       |
 [google] [facebook]  ← Authoritative level
    |
 [IP: 142.250.185.46]

Why this Layered System Exists?

Scalability - If one person tried to memorise every address in the world - is it ever possible? they’d fail. But if you divide the worlds into countries, then cities, then streets - each level only needs to know about their piece. The internet has billions of domain names. No single server could handle all those requests. By splitting it up, each layer handles a manageable portion.

Decentralisation - What if the master directory gets destroyed or hacked? The whole internet breaks. Instead, DNS spreads the responsibility:

• 13 root server systems (actually hundreds of physical servers)

• Different organisations manage different TLDs (.com, .org, .uk, etc.)

• Individual companies manage their own authoritative servers

If one piece fails, the rest keep working.

Behind the Scenes: How Recursive Resolvers Work

A recursive DNS server is a key part of DNS hierarchy, which handles the domain lookups. Let’s see how the recursive DNS works behind the scenes:

1. Request initiated → When you type a website URL (e.g., www.asample.com) into your browser, your device sends a request to a recursive DNS resolver to find the corresponding IP address.

   1. Cache Check: If this URL was recently requested, the resolver checks its cache first and immediately returns the IP address if found.

2. Query to the Root Server → If the IP address isn't in cache, the recursive resolver begins searching through the DNS hierarchy starting with root DNS servers.

   • Root servers don't store domain IP addresses, but they direct the resolver to the appropriate Top-Level Domain (TLD) server based on the domain extension.

3. Querying the TLD Server → The TLD server manages all domains within a specific extension (.com, .in, etc.) and directs the recursive resolver to the authoritative DNS server responsible for the specific domain.

4. Querying the authoritative DNS server: → The authoritative server holds the official DNS records for the domain, including the IP address. It responds with the exact IP address for the requested domain.

5. Returning the result to your device → The recursive DNS resolver returns the IP address to your device, allowing your browser to connect to the website. The resolver also caches this IP address temporarily to speed up future requests for the same domain.

Conclusion

The DNS resolution process efficiently translates domain names into IP addresses through a hierarchical lookup system. While multiple servers are involved, caching at each level ensures most requests are resolved within milliseconds. This distributed architecture makes DNS both scalable and reliable, serving as the foundational addressing system that keeps the internet accessible and performant for billions of users worldwide.

If you like the blog, please share it with others. Follow me on linkedin