DEV Community: Naman Raj

Learning Istio the Hard Way: A Real Service Mesh Lab with Canary, mTLS, and Tracing.

Naman Raj — Thu, 04 Dec 2025 22:12:16 +0000

Why I Built a Service Mesh Lab Instead of Just Reading Docs
The 3RVision Platform: Real App, Real Traffic
Setting the Stage: Kind + Terraform + Namespaces
How Istio Fits In: Sidecars, Gateways, and the Data Plane
Traffic Management 101: VirtualServices, DestinationRules, and Subsets
Implementing Canary Releases with Headers and Weights
Enforcing Zero-Trust with STRICT mTLS
Load Balancing, Connection Pools, and Circuit Breaking
Observability: Metrics, Dashboards, and Traces
Walking Through a Single Request
Key Takeaways

Why I Built a Service Mesh Lab Instead of Just Reading Docs

This project started as a personal lab to really understand what a service mesh does beyond the buzzwords. Instead of using sample apps, the goal was to take a real 3-tier app (Next.js frontend, Go backend, Flask ML service) and see how Istio changes the way traffic, security, and observability work in practice.

The idea was simple: if this setup feels like something that could ship to production one day, then the learning will stick and this repo becomes a living reference for future work.

The 3RVision Platform: Real App, Real Traffic.

3RVision is split into three logical services, each running in its own Kubernetes namespace:

frontend → Next.js UI
backend → Go API server
ml → Flask ML inference service

The frontend talks to the backend, and the backend calls the ML service for model inference, exactly the kind of hop-by-hop traffic that benefits from a service mesh.

Each service has two deployment variants:

stable version (production)
canary version (testing new features)

This is where Istio’s traffic management features come into play.

Setting the Stage: Kind + Terraform + Namespaces

To avoid dealing with cloud accounts, Terraform provisions a local Kind cluster with:

1 control plane node
2 worker nodes
Port mappings for HTTP (80) and HTTPS (443)

Cluster Setup Workflow

# Provision the cluster
terraform init
terraform apply

# Create namespaces
kubectl create namespace frontend
kubectl create namespace backend
kubectl create namespace ml

# Enable Istio sidecar injection
kubectl label namespace frontend istio-injection=enabled
kubectl label namespace backend istio-injection=enabled
kubectl label namespace ml istio-injection=enabled

This gives you a clean separation:

Terraform → cluster lifecycle
Kubernetes → application resources
Istio → traffic shaping and security

How Istio Fits In: Sidecars, Gateways, and the Data Plane

Istio works by injecting an Envoy sidecar proxy next to each application container. All inbound and outbound traffic flows through this sidecar, which means you can add routing, retries, mTLS, and telemetry without changing application code.

Architecture Overview

                            ┌─────────────────────┐
                            │    User/Client      │
                            └──────────┬──────────┘
                                       │
                                       ▼
┌──────────────────────────────────────────────────────────────────────────┐
│                        KIND KUBERNETES CLUSTER                            │
│                        (Terraform Provisioned)                            │
│  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐              │
│  │ Control Plane  │  │   Worker #1    │  │   Worker #2    │              │
│  └────────────────┘  └────────────────┘  └────────────────┘              │
├──────────────────────────────────────────────────────────────────────────┤
│                          ISTIO SERVICE MESH                               │
│                                                                           │
│    Gateway ──────► VirtualService ──────► DestinationRule                │
│   (Ingress)          (Routing)           (mTLS + Load Balancing)         │
├──────────────────────────────────────────────────────────────────────────┤
│                           MICROSERVICES                                   │
│                                                                           │
│   ┌──────────────┐    ┌──────────────┐    ┌──────────────┐               │
│   │   FRONTEND   │    │   BACKEND    │    │   ML MODEL   │               │
│   │   (Next.js)  │───►│     (Go)     │───►│   (Flask)    │               │
│   │  Port: 3000  │    │  Port: 8080  │    │  Port: 5001  │               │
│   │              │    │              │    │              │               │
│   │ stable/canary│    │ stable/canary│    │ stable/canary│               │
│   └──────────────┘    └──────────────┘    └──────────────┘               │
├──────────────────────────────────────────────────────────────────────────┤
│                        OBSERVABILITY STACK                                │
│                                                                           │
│   ┌──────────────┐    ┌──────────────┐    ┌──────────────┐               │
│   │  Prometheus  │    │    Jaeger    │    │   Grafana    │               │
│   │   (Metrics)  │    │  (Tracing)   │    │ (Dashboards) │               │
│   │  Port: 9090  │    │ Port: 16686  │    │  Port: 3000  │               │
│   └──────────────┘    └──────────────┘    └──────────────┘               │
└──────────────────────────────────────────────────────────────────────────┘

At the edge, an Istio Ingress Gateway receives external requests, applies routing rules defined by VirtualServices, and forwards traffic deeper into the mesh.

Traffic Management 101: VirtualServices, DestinationRules, and Subsets

The main Istio building blocks used in this project are:

Resource	Purpose
Gateway	Exposes services to external traffic on specific ports
VirtualService	Defines how requests are routed (by header, weight, path)
DestinationRule	Defines policies for traffic (subsets, load balancing, connection pools)

Example: Frontend VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: frontend-vs
  namespace: frontend
spec:
  hosts:
    - "frontend.local"
  gateways:
    - frontend-gateway
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: frontend-service
            subset: canary
          weight: 100
    - route:
        - destination:
            host: frontend-service
            subset: stable
          weight: 90
        - destination:
            host: frontend-service
            subset: canary
          weight: 10

Each service (frontend, backend, ml) has:

A VirtualService that decides which version handles the request
A DestinationRule that defines two subsets based on the version label: stable and canary

Implementing Canary Releases with Headers and Weights

The canary strategy is intentionally simple but powerful.

Traffic Routing Logic

If request has header x-canary: true → 100% to canary version.
If header is missing → Split by weight (for example, 90% stable, 10% canary).

This pattern makes it easy to:

Send only internal testers to canary by setting the header.
Gradually increase canary weight without touching deployment specs.
Roll back instantly by adjusting VirtualService weights.

Testing Canary Deployment

# Send request to canary version
curl -H "x-canary: true" http://frontend.local

# Send request with default routing (weight-based)
curl http://frontend.local

Because the same pattern is applied to all three services (frontend, backend, ML), a single user journey can be fully on canary or fully on stable.

Enforcing Zero-Trust with STRICT mTLS

To move toward a zero-trust model, each namespace has a PeerAuthentication resource that sets mTLS mode to STRICT.

What This Means

Services only accept encrypted traffic from other sidecars in the mesh plain HTTP between pods is rejected.

Benefits of Istio mTLS

Encryption → Nobody can sniff requests or responses in transit.
Mutual authentication → Prevents unknown workloads from accessing services.
Automated cert management → No manual cert rotation or key generation.

Example: PeerAuthentication

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: backend
spec:
  mtls:
    mode: STRICT

Istio documentation shows similar namespace-level policies to enforce strict mTLS for all workloads in a namespace.

Load Balancing, Connection Pools, and Circuit Breaking

Load balancing: Round-robin across all healthy pods in a subset.
Connection pools: Limits on TCP connections and HTTP pending requests.
Outlier detection: After N consecutive errors, a pod is temporarily ejected from the pool.

Example: DestinationRule with Circuit Breaking

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: backend-dr
  namespace: backend
spec:
  host: backend-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 3
      interval: 10s
      baseEjectionTime: 30s
  subsets:
    - name: stable
      labels:
        version: stable
    - name: canary
      labels:
        version: canary

This means if a canary version starts throwing errors, Istio automatically reduces its impact by isolating bad instances, without waiting for a rollback.

Observability: Metrics, Dashboards, and Traces

The observability stack is built around Istio’s built-in telemetry.

Components

Tool	Purpose
Prometheus	Scrapes metrics from Envoy sidecars (request counts, errors, latency)
Grafana	Visualizes mesh metrics (success rate, p99 latency per route)
Jaeger	Distributed tracing with high sampling for end-to-end visibility

Deployment

# Deploy observability stack
kubectl apply -f k8s/observability/

# Access Grafana
kubectl port-forward -n istio-system svc/grafana 3000:3000

# Access Jaeger
kubectl port-forward -n istio-system svc/jaeger-query 16686:16686

# Access Prometheus
kubectl port-forward -n istio-system svc/prometheus 9090:9090

Grafana Dashboard

Request Rate Per Service

Distributed Tracing

Istio provides ready-made metrics and dashboards so you can quickly monitor mesh traffic, latency, and error rates.

Walking Through a Single Request

When a user hits the frontend through the Istio Ingress Gateway, the flow looks like this.

Request Flow

1. User → Istio Ingress Gateway
   ↓ (VirtualService matches host/path)

2. Gateway → Frontend pod (stable or canary based on x-canary header/weight)
   ↓ (Frontend calls backend via Kubernetes DNS)

3. Frontend Envoy → Backend pod (VirtualService applies routing again)
   ↓ (Backend calls ML service)

4. Backend Envoy → ML pod (same routing logic)
   ↓ (ML inference completes)

5. Response flows back through the chain

What Happens at Each Hop

mTLS encryption between all services.
Metrics emission to Prometheus.
Trace spans sent to Jaeger.
Circuit breaking and outlier detection enforced by DestinationRules.

Seeing this full path in Jaeger, with timing for each hop, is one of the most useful parts of the setup.

Key Takeaways

Building this lab taught me:

Service mesh adds zero-downtime deployments and fine-grained traffic control without code changes.
mTLS enforcement is straightforward with Istio and significantly improves security posture.
Observability becomes a first-class thing with minimal instrumentation effort.
Understanding Istio’s primitives (Gateway, VirtualService, DestinationRule, PeerAuthentication) unlocks powerful traffic patterns.

For deeper reading, check out:

Istio Official Docs – Traffic Management
Istio Security – PeerAuthentication
Visualizing Metrics – Istio + Grafana Dashboard
Full project README on GitHub: 3RVision-Platform

If this Istio lab setup helped you, consider ⭐ starring the repo or opening an issue/PR with improvements or ideas. Every bit of feedback, bug report, or contribution helps make this a better reference for anyone learning service mesh in the real world.

Model Context Protocol (MCP): Explained & Built from Scratch.

Naman Raj — Tue, 03 Jun 2025 05:20:34 +0000

Hi, I’m Naman a full stack developer.
In this blog, I’m diving into the Model Context Protocol (MCP): what it is, why it matters, and how I went about building my own MCP server from the ground up.
This will be a detailed breakdown: first, we’ll explore all the core concepts of MCP, and then we’ll put that knowledge to work by building a functional MCP server from scratch.
Whether you're just hearing about MCP or looking to implement it yourself, this post breaks it down both conceptually and practically

🧩 What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is basically a way for different parts of a system to talk to each other but with context.

It’s not just about asking the system to do something, it’s about helping it understand the situation around that action. So instead of just saying “do X,” you're saying “do X, knowing that Y and Z are also true right now.”

dimage ke upar se gya(sounds a bit vague), here’s a simple example:

Let’s say you walk into a coffee shop and say, “I’ll have a latte.”
A regular system gives you a latte, no questions asked.
But a system using context? That’s the barista who notices it’s raining, sees you’re soaked, and decides to make your latte extra hot and finds you a warm seat inside.
That’s what context does. And that’s the idea behind MCP, it helps systems make better decisions based on what’s going on around them.

🧭 Where Did MCP Come From?

MCP actually started off in the Minecraft modding scene yeah, really. Developers used it to understand and tweak how the game behaved internally.

Over time, the concept became more general. Now, it's useful in things like AI systems, backend workflows, and apps where understanding the bigger picture matters

🔍 Why MCP?

Most systems work in a straightforward way. You send a request, they do something.

For example:
“Give me the user data”
“Update this post”
“Delete that file”

That works fine when everything is simple. But when your system needs to make decisions based on what’s happening, those basic calls fall short.

That’s where MCP comes in. It asks questions like:
What’s the current state of the system?
What just happened before this command?
Should we respond differently depending on the situation?

System ko thoda samajhdaar banane jaisa hai, jaise backend ko bol diya ho, "bhai, thoda dimaag laga."
(It’s like giving your backend a bit more awareness as if you’ve told it, “bro, use your brain a little.”)
Aur jab system fast changing ho, jaise AI tools ya complex workflows fir to bhai waha yeh samajh bohot kaam aata hai.
(And when your system is fast changing like AI tools or workflow engines that extra awareness really helps.)

🛠 Real Life Example: Your Desi Smart Assistant

Imagine you’ve got a smart assistant at home let’s call it “Marco AI.”
Now you say:

“Marco, light band kar de.”
(“Marco, turn off the lights.”)

If it’s a basic assistant, it'll just go:
Poof. Lights off. Kaam khatam.

But if it's context-aware using something like MCP, here’s how it might think:

Time check: Oh, it’s 11:30 PM.
Motion detection: There’s still someone moving in the kitchen.
Recent command: You just said “Good night” 2 minutes ago in the bedroom.

So now instead of killing all the lights like a power cut:

It only turns off the bedroom light, not the kitchen one (because someone's still grabbing water).
It starts your night routine: turns on DND on your phone, lowers fan speed, and maybe even plays that lo-fi playlist you always fall asleep to.
And yeah, it doesn’t turn off the bathroom light because you left it on and MCP knows you always forget.

Yeh wahi baat hai — ek normal banda bolta hai “light band kar,” aur doosra poochta hai, “kaunsi? sab ki?”
(It’s the difference between someone who follows orders and someone who thinks before acting.)

🔧 2. Core Concepts of MCP

The beauty of MCP lies in how it structures communication between models, making them aware of the environment they’re operating in. Think of it as building systems that “know what’s going on” instead of blindly executing commands.

🧠 2.1 Model-Context Design
In MCP, a “context” is a set of facts or environmental data that helps a model understand what’s happening right now. This includes things like:

The current state of the system
Recent events or actions
Inputs from other models
External data like time, user info, etc

Why it matters:
Instead of just saying "do task X", you're saying:

“Do task X, but keep in mind we’re in state Y, action Z just happened, and model A is waiting on your output.”

Example: If a user says “cancel my subscription” in an app, the model doesn’t just delete the plan it checks:

Did the user already initiate a refund request?
Are there any active services running?
Is there a promotion that could retain them?

🧾 2.2 Command-based Architecture
MCP systems rely on a command driven flow like a structured conversation where each action is a clearly defined message.

A command is not just an API call or function; it’s a semantic instruction:

CreateOrder UpdateInventory NotifyUser EvaluateResponse

Each command carries:

Intent: What action is requested
Context: What the system knows right now
Payload: Any required data (e.g., user ID, product ID)

This makes it easy to track, test, and extend behavior. Think of it like building with Lego blocks each command has a clear shape and job and can plug into other parts cleanly.

📦 2.3 State Handling
MCP treats state as a first-class citizen. That means each model doesn’t just operate in isolation, it shares and consumes state via a central context manager or store.

Key aspects of state handling:

Models read from shared context
They update the context with new outcomes
The context flows with the execution kind of like a memory that travels

Let’s say you’re using GitHub Copilot in Agent mode, and you switch between different models during the session say from GPT-4 to Claude 3 Sonnet, or Gemini 2.5.

Despite switching models, your session context stays intact:

Your previous code
The task you're working on
The error you just ran into
Even the last thing you asked the assistant

“Model badal gaya, par yaadein wahi rahi. 😂”
(The model changed, but the memories stayed the same.)

That’s basically how MCP handles state like a central memory bank all models read from and write to. So whether it’s one model or many, they all operate with a shared understanding of ‘what’s going on’

This is what allows things like:

Chaining responses across models
Smarter multi-agent reasoning
Being able to "pause and resume" with full context

🧩 2.4 Decoupling Logic
This is where MCP really shines. By using commands + shared context, MCP naturally leads to modular and decoupled system design.

What this means in practice:

Each model (or agent) focuses on its specific job
No model needs to know how others work internally
Communication happens only via commands and context not direct calls or dependencies

This makes systems:

Easier to scale
Easier to test (you can unit-test models independently)
Easier to swap in new models (AI version A to version B, for example)
Less fragile one model crashing doesn't break the others

🧠 MCP Server Architecture Explained

The Model Context Protocol (MCP) Server is a modular system designed to handle model driven command execution with a focus on tools, resources, and prompt management. This architecture is scalable, extensible, and supports multiple transport protocols and storage backends.

Here is the architecture diagram (Zoom in) ⬇️

📦 Components Breakdown

1. Transport Layer
The Transport Layer handles the actual communication between the AI client and your MCP server. Think of it as the "delivery method" for messages.

STDIO Transport:

const transport = new StdioServerTransport();

Uses standard input/output streams
Most common for local MCP servers
No network configuration required
Direct process-to-process communication

HTTP Transport:

const transport = new HTTPServerTransport();

Uses HTTP protocol over network
Useful for remote MCP servers
Requires port and URL configuration
Can handle multiple concurrent clients

WebSocket Transport:

const transport = new WebSocketTransport();

Real-time bidirectional communication
Good for streaming data
Maintains persistent connections
Lower latency than HTTP

Custom Transport:

You can implement your own transport method
Must follow MCP protocol specifications
Useful for specialized communication needs

2. Command Dispatcher
The Command Dispatcher is the "traffic controller" of your MCP server. It receives all incoming requests and decides where to send them.

Request Analysis: Examines the incoming JSON-RPC message
Route Determination: Decides which handler should process the request
Schema Validation: Ensures request format is correct

Example Request Routing:

// Incoming request
{
  "method": "tools/call",
  "params": { "name": "get_completed_payments" }
}

// Router logic
if (method === "tools/call") {
  route_to_tools_handler();
} else if (method === "resources/read") {
  route_to_resources_handler();
}

This code is like a traffic cop 🚦:

If the request says "tools/call" → send it to the Tools Handler
If it says "resources/read" → send it to the Resources Handler

3. Handler Components
The server has three main types of handlers, each responsible for different MCP capabilities:

3.1 Tools Handler
Processes executable functions that perform actions.

Handles Two Request Types:
tools/list: Returns available tools
tools/call: Executes a specific tool

Example Implementation:

// tools/list response
{
  "tools": [
    {
      "name": "weather_forecast",
      "description": "Get weather forecast for a location",
      "inputSchema": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "City name"
          }
        },
        "required": ["location"]
      }
    },
    {
      "name": "calculator",
      "description": "Perform basic math calculations",
      "inputSchema": {
        "type": "object",
        "properties": {
          "operation": {
            "type": "string",
            "enum": ["add", "subtract", "multiply", "divide"]
          },
          "num1": { "type": "number" },
          "num2": { "type": "number" }
        },
        "required": ["operation", "num1", "num2"]
      }
    }
  ]
}

// tools/call execution
// Example 1: Weather forecast tool
async function executeWeatherForecast(params) {
  const { location } = params;

  // Get weather data (simplified)
  const weather = {
    location: location,
    temperature: "72°F",
    condition: "Sunny",
    forecast: "Clear skies all day"
  };

  return { 
    content: [
      { 
        type: "text", 
        text: `Weather for ${location}: ${weather.temperature}, ${weather.condition}. 
               Forecast: ${weather.forecast}`
      }
    ] 
  };
}

// Example 2: Calculator tool
async function executeCalculator(params) {
  const { operation, num1, num2 } = params;
  let result;

  // Perform calculation
  switch(operation) {
    case "add": 
      result = num1 + num2;
      break;
    case "subtract":
      result = num1 - num2;
      break;
    case "multiply":
      result = num1 * num2;
      break;
    case "divide":
      result = num1 / num2;
      break;
  }

  return { 
    content: [
      { 
        type: "text", 
        text: `${num1} ${operation} ${num2} = ${result}`
      }
    ] 
  };
}

3.2 Resources Handler
Manages static data and content that can be read.

Handles Two Request Types:
resources/list: Returns available resources
resources/read: Retrieves resource content

Example Implementation:

resources/list Response:

{
  "resources": [
    {
      "uri": "recipes://breakfast",
      "name": "Breakfast Recipes",
      "description": "Collection of breakfast recipes",
      "mimeType": "application/json"
    },
    {
      "uri": "notes://shopping-list",
      "name": "Shopping List",
      "description": "Current shopping list items",
      "mimeType": "text/plain"
    }
  ]
}

resources/read Execution:

// Example resource handler
async function readResource(uri) {
  // Breakfast recipes resource
  if (uri === "recipes://breakfast") {
    const breakfastRecipes = [
      { name: "Scrambled Eggs", ingredients: ["eggs", "butter", "salt"] },
      { name: "Pancakes", ingredients: ["flour", "milk", "eggs", "sugar"] }
    ];

    return { 
      contents: [
        { 
          uri: uri,
          text: JSON.stringify(breakfastRecipes, null, 2),
          mimeType: "application/json" 
        }
      ] 
    };
  } 
  // Shopping list resource
  else if (uri === "notes://shopping-list") {
    const shoppingList = 
      "1. Milk\n" +
      "2. Bread\n" +
      "3. Eggs\n" +
      "4. Apples\n" +
      "5. Coffee";

    return { 
      contents: [
        { 
          uri: uri,
          text: shoppingList,
          mimeType: "text/plain" 
        }
      ] 
    };
  }
}

3.3 Prompts Handler
Manages pre-defined prompts that can be used by the AI client.

In your architecture, the Prompt Handler is the part of the server that deals with prompts aka the messages or instructions that you send to the AI to make it do something.

Think of prompts like the script you give an actor. The AI is the actor, and your prompt tells it what to say or do.

The Prompt Handler helps:

List all available prompts
Fetch a specific prompt
Inject variables into prompts (dynamic prompts)
Send these prompts to the AI client (like Claude, GPT, etc.)

prompts/list: Returns a list of all available prompts.
Example response:

["generate_invoice", "summarize_text", "write_lawyer_reply"]

prompts/get: Fetches the full prompt template for a given name.
Example request:

{
  "method": "prompts/get",
  "params": { "name": "summarize_text" }
}

Example response:

{
  "template": "Summarize the following text:\n\n{{input_text}}"
}

You can then plug in dynamic input like:

"input_text": "The Supreme Court ruled in favor of the plaintiff in a landmark decision..."

And the final prompt becomes:

Summarize the following text:

The Supreme Court ruled in favor of the plaintiff in a landmark decision...

4. Model Registry
The Model Registry is the "rulebook" for your MCP server. It stores schemas, validation rules, and metadata.

Three Main Components:
Tool Schemas:

{
  "name": "convert_temperature",
  "description": "Convert between Fahrenheit and Celsius",
  "inputSchema": {
    "type": "object",
    "properties": {
      "value": { 
        "type": "number",
        "description": "Temperature value to convert" 
      },
      "from": { 
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Source temperature unit" 
      }
    },
    "required": ["value", "from"]
  }
}

Defines input/output validation
Stores tool metadata and descriptions
Ensures type safety

Resource Schemas:

{
  "uri": "payments://done",
  "mimeType": "application/json",
  "description": "All completed payments"
}

Defines URI patterns
Specifies content types
Provides resource descriptions

Prompt Templates:

{
  "name": "payment_summary",
  "template": "Summarize {count} payments totaling ${amount}",
  "arguments": ["count", "amount"]
}

Stores reusable prompt templates
Manages dynamic prompt generation
Defines prompt arguments

6. Context Storage
The Context Storage layer manages data persistence and retrieval. Your MCP server can use multiple storage backends.

Storage Types:

In-Memory Storage:

const sessionData = new Map();
const cache = new Map();

Fast access for temporary data
Session management
Caching frequently accessed data
Lost when server restarts

Database Storage:

// MongoDB example
const payments = await db.collection('payments').find({}).toArray();

// PostgreSQL example
const result = await client.query('SELECT * FROM payments WHERE done = true');

Persistent data storage
Complex queries and relationships
ACID compliance (for SQL databases)
Scalable for large datasets

File System Storage:

const fs = require('fs');
const data = fs.readFileSync('/path/to/data.json');

Local file operations
Log storage
Configuration files
Simple data persistence

External APIs:

// REST API call
const response = await fetch('https://api.example.com/payments');

// GraphQL query
const result = await graphql(schema, query);

Integration with external services
Real-time data from third parties
Webhook processing
Microservices communication

ALRIGHT DEVS! I'M GLAD WE MAKE IT TILL HERE, BECAUSE IT'S TIME WE BUILD ONE 🔥

🧠Building Our Own MCP Server: A Step-by-Step Guide

In this guide, I'll walk you through creating a Model Context Protocol (MCP) server that exposes my MongoDB data to Large Language Models (LLMs) like Claude. We'll build a server that manages payment data and makes it accessible through both MCP Resources and Tools.

Prerequisites

Before we begin, make sure we have:

Node.js installed (v14 or higher)
MongoDB Atlas account (or a local MongoDB instance)
Basic understanding of JavaScript/Node.js
Claude Desktop installed (for testing with LLM)
MCP Inspector (for debugging and testing)

Step 1: Project Setup

mkdir mcp_server
cd mcp_server
npm init -y

Install the required dependencies:
npm install @modelcontextprotocol/sdk mongodb

Step 2: Server Implementation
Let's create our index.js file and break down each component in detail:

1. Basic Server Setup and Imports

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  ListResourcesRequestSchema,
  ReadResourceRequestSchema,
  ListToolsRequestSchema,
  CallToolRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { MongoClient } from "mongodb";

// Initialize the MCP server
const server = new Server(
  {
    name: "NextApp Payments Resource",
    version: "1.0.0",
  },
  {
    capabilities: {
      resources: {}, // We'll expose payment resources
      tools: {}, // We'll expose payment-related tools
    },
  }
);

This setup:

Imports necessary MCP SDK components
Imports MongoDB client
Creates a new MCP server instance with metadata
Defines server capabilities (resources and tools)

2. MongoDB Connection Setup

// MongoDB connection setup with error handling
const uri = process.env.MONGODB_URI;
if (!uri) {
  console.error(
    JSON.stringify({
      type: "error",
      message: "MONGODB_URI environment variable is required",
    })
  );
  process.exit(1);
}

// Helper function for MongoDB operations
async function withMongoDB(operation) {
  let client;
  try {
    client = new MongoClient(uri);
    await client.connect();
    const db = client.db("test");
    return await operation(db);
  } catch (error) {
    console.error(
      JSON.stringify({
        type: "error",
        message: "MongoDB Error",
        error: error.message,
      })
    );
    throw error;
  } finally {
    if (client) {
      await client.close();
    }
  }
}

This section:

Validates MongoDB connection string
Creates a reusable helper function for database operations
Implements proper connection handling and cleanup

3. Implementing MCP Tools

// Define and implement tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "get_completed_payments",
        description: "\"Get all payments where done is true\","
        inputSchema: {
          type: "object",
          properties: {},
          required: [],
        },
      },
      {
        name: "get_all_payments",
        description: "\"Get all payments from the database\","
        inputSchema: {
          type: "object",
          properties: {},
          required: [],
        },
      },
    ],
  };
});

// Handle tool execution
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name } = request.params;

  const handlePayments = async (query = {}) => {
    return await withMongoDB(async (db) => {
      const payments = await db.collection("payments").find(query).toArray();
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(payments, null, 2),
          },
        ],
      };
    });
  };

  switch (name) {
    case "get_completed_payments":
      return handlePayments({ done: true });
    case "get_all_payments":
      return handlePayments();
    default:
      throw new Error(`Unknown tool: ${name}`);
  }
});

This implements:

Tool registration with clear descriptions
Input schema definitions (empty in this case)
Reusable payment handling logic
Specific tool implementations

get_completed_payments

Description: Retrieves all payments where done is true
Input: No parameters required
Output: JSON array of completed payments

get_all_payments

Description: Retrieves all payments from the database
Input: No parameters required
Output: JSON array of all payments

4. Implementing MCP Resources

// Define available resources
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [
      {
        uri: "payments://done",
        name: "Completed Payments",
        description: "\"All payments where done is true\","
        mimeType: "application/json",
      },
    ],
  };
});

// Handle resource reading
server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  const { uri } = request.params;

  if (uri === "payments://done") {
    return await withMongoDB(async (db) => {
      const payments = await db
        .collection("payments")
        .find({ done: true })
        .toArray();

      return {
        contents: [
          {
            uri: uri,
            text: JSON.stringify(payments, null, 2),
            mimeType: "application/json",
          },
        ],
      };
    });
  }

  throw new Error(`Unknown resource: ${uri}`);
});

This section:

Defines a resource for completed payments
Implements resource reading logic
Uses our MongoDB helper function
Returns properly formatted JSON responses

5. Server Startup

// Main function to start the server
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);

  console.error(
    JSON.stringify({
      type: "info",
      message: "MCP server started with tools and resources",
    })
  );
}

main().catch((error) =>
  console.error(
    JSON.stringify({
      type: "error",
      message: "Server startup error",
      error: error.message,
    })
  )
);

Step 3: Configuration Setup

MCP Inspector Configuration

MCP Inspector is a development tool that helps you test and debug your MCP server. Here's how to set it up:

Start your server:
node index.js

Access MCP Inspector:

Open your browser and navigate to http://localhost:6274/#resources
The Inspector will automatically connect to your running server
You can test resources and tools directly from the interface

The image above shows the MCP Inspector interface displaying the payment records retrieved from MongoDB Atlas through the MCP server.

Claude Desktop Configuration
Let's walk through the process of configuring your MCP server in Claude Desktop:

Step 1: Access Settings

Open Claude Desktop application
Click on the hamburger menu (three lines) in the top-left corner
Select "File" → "Settings"

Step 2: Configure MCP Server

In the Settings window, select the "Developer" tab
Click on "Edit Config" button

This will open your Claude configuration file in your default text editor

Windows: C:\Users\<username>\AppData\Roaming\claude\claude_desktop_config.json

macOS: ~/Library/Application Support/claude/claude_desktop_config.json

Linux: ~/.config/claude/claude_desktop_config.json

Add your server configuration to the file:

{
  "mcpServers": {
    "PaymentsResource": {
      "command": "node",
      "args": ["C:/path/to/your/index.js"],
      "env": {
        "MONGODB_URI": "mongodb+srv://your-connection-string"
      }
    }
  }
}

Step 3: Apply Changes

Save the configuration file
Close the text editor
Close Claude Desktop completely
Important: Sometimes just closing the application isn't enough
- Windows: Open Task Manager (Ctrl + Shift + Esc)
- Find "Claude" in the processes
- Right-click and select "End Task"
Restart Claude Desktop

Step 4: Verify Server Connection

Open Claude Desktop
Go to Settings → Developer tab
You should see your MCP server listed as "running"

Step 5: Using Your MCP Server

Go to the main Claude chat interface
Look for the search and tools options at the top
You'll find your configured MCP server in the tools list

[NOTE: You will be asked to give the permission, to use those tools.]

To use resources:

Click the upload button (+) on the left sidebar
Select from your available resources
Query the resource as needed

Once you click on that "Add from Payment Resource"
You will be able to upload your Completed Payments resource

Step 4: Testing Your Implementation

Start your server:
node index.js
In Claude Desktop:

Verify server status in Settings → Developer
Your server should show as "running"

Test commands:

# Test resource access
Use the MCP resource payments://done and show me all completed payments

# Test tools
Use the MCP tool get_completed_payments to show me successful transactions
Use the MCP tool get_all_payments to display all payment records

USING TOOL

USING RESOURCE

Troubleshooting Guide

Common Issues and Solutions

Server Won't Start

Check Node.js version
Verify file paths in config
Check for syntax errors
Verify MongoDB URI

Claude Can't Connect

Check config file location
Verify absolute paths
Check environment variables
Restart Claude Desktop

MCP Inspector Issues

Verify server is running
Check port 6274 is available
Look for console errors
Check browser console

MongoDB Connection Failed

Verify connection string
Check network connectivity
Verify database permissions
Check IP whitelist

"SHEEESHHH!! NOW WE HAVE OUR OWN MCP SERVER"

Working on this project was honestly a fun deep dive into how we can make large language models a lot smarter with real world, live data. We built a custom MCP server that connects directly to MongoDB, giving Claude access to actual payment data using tools and resources and We designed from scratch. This whole thing isn’t just a tech demo; it’s a glimpse into how we can build AI apps that are actually aware of context and data that matters in the moment.

Conclusion

We've now built a fully functional MCP server that:
Exposes MongoDB data through MCP resources
Provides tools for querying payments
Integrates with Claude Desktop

That’s it from my end for now!
If you’ve made it this far thanks for checking it out. If you’re building something similar, playing around with MCP, or just wanna collaborate on AI ideas, feel free to fork the repo, drop a star, or hit me up on GitHub: @Denyme24 or LinkedIn: in/namanraj24.

🔗 Repo for reference: my-mcp-server

Catch ya in the next project.
Stay curious & keep building 🚀🧠

We Came. We Coded. We Cleaned the Planet (and Won).

Naman Raj — Tue, 15 Apr 2025 13:43:50 +0000

⚙️ Set the Scene

It all started with an open problem, a crew too stubborn to quit, and 24 hours to ship something real.

We entered this national-level hackathon with a clear goal: to build something that didn’t just work but mattered. The theme was Open Innovation, and while the freedom was exciting, we knew we had to be intentional. Instead of chasing trends, we focused on a problem that’s real, relevant, and way too often ignored- waste management.

That’s how 3RVision was born. An AI-powered platform designed to help users identify household waste and figure out whether it can be reused, recycled, or resold. It’s a practical, user-focused solution for a global issue. Built with machine learning, clean UI, and an emphasis on sustainability, we aimed to make responsible living more accessible and a little bit smarter.

We weren’t trying to impress with flashy features we wanted to solve a real-world problem in a way that actually sticks.

The 24 hours were intense. Between debugging models, designing flows, and juggling backend chaos, there were moments we genuinely thought we wouldn’t make it in time. But somehow, everything clicked just enough in the final stretch. And yeah that last-minute demo that somehow actually worked? Definitely one for the memory books.

👥 The Dream Team

Every winning project needs a team that just clicks, and we had that from the jump.

There weren’t strict roles or “you do this, I do that” energy. We were all in, all the time switching gears between frontend, backend, ML, and sometimes just keeping each other sane. Everyone wore multiple hats, and somehow, it worked.

Khushi – The team lead and the brain behind the idea. She steered
the ship, worked on the ML side, and constantly pushed the UI to
look and feel better. Super picky about the frontend—and yeah, she
kept me on my toes with it 😮‍💨.
Naman (me) – Took charge of the frontend, handled components, API stuff, Authentication and also chipped in on the backend. Made sure everything worked like it should, visually and under the hood.
Arpit – The utility player who pulled off two big wins building the Chrome extension and strengthening the backend. He was the kind of dev who quietly shipped features that just worked no fuss, no fluff, just clean execution.
Shreyansh – The wild card turned MVP. He went all-in on the ML side training our custom models, fine-tuning performance, and basically doing the kind of wizardry that made the AI magic real. He joined in a little later but made a massive impact in no time

🌱 Birth of 3RVision

The idea for 3RVision came from a simple realization: there’s a ton of waste out there, and people often don’t know what to do with it. With increasing environmental concerns, we wanted to create a practical solution that helps people identify whether an item can be reused, recycled, or resold right from their phone.

It was clear that the challenge of waste management wasn’t just about knowing what could be recycled, but how to make it easy for people to make informed, eco-friendly decisions. So, we decided to tackle this with AI, combining image recognition to offer suggestions for each item whether it was fit for recycling, resale, or reuse.

There were debates along the way could we expand beyond just waste management? Should we focus on something more abstract? But in the end, we locked onto this problem because it felt practical, relevant, and scalable. Plus, we could really make a difference with it. And let’s be real, who doesn’t love building something that can make a positive impact?

🛠️ Game Time – The Hack Begins

We kicked off the hack with all the enthusiasm in the world. The morning went pretty smooth frontend coming together, models being trained, vibes were solid.

Khushi and Shreyansh were deep into training the core ML models, I was locking in the frontend, and Arpit was busy setting up the Chrome extension getting those early pieces in place so we could integrate it all later.

Around evening, the organizers hit us with a surprise jamming session and not gonna lie, it was exactly what we needed. 10/10 would jam again.

Now, back to the grind. Post-jam, things got a bit… spicy.

There were some weird bugs in the extension it wasn’t properly classifying items into degradable vs. biodegradable. Me and Arpit tag-teamed it and squashed that mess before dinner. Clean fix, good vibes

But the real pain hit when Shreyansh’s model training crashed network issues mid-process. Bro left it training during the jam, and came back to find everything wiped. Khushi, on the other side, had another model training simultaneously, so Shreyansh had to restart from scratch. 🫠

By the time dinner rolled around, everything seemed set up frontend ✅, extension ✅, ML ✅.

But the backend? Not even close.
We didn’t know it yet, but we were about to enter chaos mode.

⚡ Clutch Moments – Bounce Back Energy

Okay, so here’s where things went full “will they make it or not” mode.

By 11 PM, the backend was the only thing standing between us and a fully functional system. And it wasn’t just one integration we had to:

Connect the frontend to the ML model
Connect the frontend to the backend (built in Go)
And finally, connect the backend to the ML model (running on a Flask server)

Basically, a full-on relay race with two different servers and a lot of bugs in between.

Me and Arpit sat down thinking, “Okay, couple hours max.”
Reality check: it took us till 6 AM.

There were CORS issues, data not syncing right, weird behavior when Go tried to communicate with Flask, and a bunch of edge cases that kept popping out of nowhere. But with each successful response, we got closer.

Finally, when we saw the frontend fully talk to Go, which then made a clean call to Flask and got back a prediction it was like…
inner peace unlocked.

Watching the entire pipeline run smoothly after 6 hours of chaos?
Yeah, that moment hit different.

🎤 The Pitch – It’s Show Time

We were riding on zero sleep and infinite adrenaline.
The product? Ready.
The presentation? Not so much.

We hadn’t prepped any fancy slides or rehearsed a pitch just raw conviction and a working build. Some features didn’t make it in due to time (rip to our extra functionalities).

First round, we were called to one of the labs.
Khushi and Arpit stepped up, laptops in hand.
Khushi took the lead and bro, she snapped.
Clear, confident, and straight to the point. It wasn’t just a walkthrough—it was a proper storytelling session of what 3RVision stood for and what it could do.

We walked the judges through the features—ML predictions, waste classification, the Chrome extension in action, clean UI, and smooth backend integration.
And the live demo? Bro… it actually worked. Like, everything just clicked at the right time. No bugs, no lags. It felt good- really good.

After wrapping up, we headed to the auditorium for another jamming session.
It was just what we needed. Chill vibes, music, and a moment to breathe after the storm.

🏁 The Final Lap – Top 6, Showdown & The Win

We were just vibing in the auditorium post-demo, soaking it all in, when Khushi got a call.
We were selected in the Top 6.
For a second, we just froze. Like wait, us?

The final round was calling, and we had to show up again. No room for error now.
We prepped in silence, running through key points, refining our story this time, it wasn’t just about features. It was about vision, scalability, and the “why us?” of it all.

Back to the same lab, but this time with more judges, and a slightly heavier vibe. The pressure was real.
Still, Khushi stepped up again and killed it. This round dove deeper into the business model, revenue possibilities, and future roadmap. We highlighted the packed set of features and why this wasn't just another hackathon build, it had potential. Real, tangible potential.

There were some solid cross-questions from the panel. We held our ground and answered them all.
No blank stares. No panic. Just a team that knew what it built.

After about 15 minutes, we were told to head for Lunch.
And on the way, something wild happened
The Professor of ISE came up to us and asked for a selfie.
We were like, “Uhhh… what just happened?”
That moment? Kinda confirmed what we were all feeling inside we might just take this.

Fast forward to auditorium, final results.

Started with the usual boring speeches 😒 (no offense, Chief Guest), but all we could hear was our own heartbeat.

Third place... not us.
Bittersweet. Still hoping.

Second place... also not us.
Now we’re fully in “it’s either us or nothing” mode.

And then...

🥇 “First Position… Team Quaternary!”

Bruhhh,we exploded. Screams. Hugs. Pure disbelief.
Out of 21 solid teams, we came out on top.
The sleepless night, the endless debugging, the full-stack hustle, the caffeine-fueled grind—all of it was worth it.

🚀 That’s a Wrap

From day-one brainstorming to that final pitch, the whole journey was wild in the best way.
We built, broke, fixed, and figured things out as a team, learning more in 24 hours than we probably did in weeks.

What started as just an idea turned into something we’re genuinely proud of.
Walking away with the win? Yeah, that felt amazing.
But honestly, it’s the grind, the laughs, the chaos, and the crew that made it all worth it.

Thanks for sticking around and reading our story! 🙌
This wasn’t meant to be a technical deep-dive but more of a raw, real peek into our hackathon journey.

Here’s to more late-night builds, good vibes, and taking ideas beyond the hackathon.

Till the next all-nighter. 👋

DNS Explained: From Basics to Building My Own DNS Server

Naman Raj — Sat, 29 Mar 2025 19:01:39 +0000

Hey everyone! 👋 I'm Naman, a full-stack developer passionate about networking and system design. Recently, I built my own DNS server using Go, and in this blog, I'll walk you through the fundamentals of DNS and how did i create my own DNS server from scratch. Let's dive in!

🌍 What is DNS and Why is it Important?

DNS (Domain Name System) is like the phonebook of the internet. It translates human-friendly domain names (like google.com) into machine-readable IP addresses (like 142.250.182.206).

Imagine if every time you wanted to visit a website, you had to type in a long, numeric IP address. DNS eliminates that hassle by handling the lookup for you!

💡 Example:
When you type namanraj.tech in your browser:

Your computer asks a DNS server: "What is the IP address of namanraj.tech?"
The DNS server replies with the correct IP (e.g., 76.76.21.93).
Your browser connects to that IP and loads the website.

🔄 How DNS Works (Step-by-Step Resolution Process)

1. Stub Resolver Initiates the Query

The Stub Resolver is a small built-in DNS client in your operating system (Windows, Linux, macOS).
Its job is to check if the domain’s IP is already cached in your local system.
If the IP is not found, the stub resolver forwards the request to a Recursive DNS Resolver for further lookup

2. Recursive Resolver Handles the Query

The Recursive Resolver is a DNS server that helps find the IP address on behalf of your device.
Common recursive resolvers include:
- Google Public DNS (8.8.8.8)
- Cloudflare DNS (1.1.1.1)
- Your ISP’s DNS resolver

3. Query to the Root DNS Server

The recursive resolver first asks a Root Name Server for guidance.
What is a Root Server?
- Root servers are the highest level in the DNS hierarchy, acting as the entry point for all DNS lookups.
- There are 13 root servers worldwide, and they know where to find the TLD (Top-Level Domain) servers for different domains.
- Since the root server does not store individual website IPs, it replies:
- "I don’t have the IP for namanraj.tech, but ask a .tech TLD server"

Here is a dig command that queries the root DNS server (a.root-servers.net) for the nameservers (NS records) responsible for the com top-level domain (TLD). It essentially asks the root server which DNS servers handle requests for domain names ending in .com.

It returns the list of nameservers that are authoritative for the com TLD. These are the servers that handle DNS queries for domains ending in .com.

4. Query to the TLD Name Server

The recursive resolver now asks the TLD Name Server for .tech
What is a TLD Server?
- A Top-Level Domain (TLD) Name Server manages all domains with a specific extension, like:
- .com domains → Managed by .com TLD servers
- .org domains → Managed by .org TLD servers
- .tech domains → Managed by .tech TLD servers
- Since the TLD server still does not store the IP of namanraj.tech, it responds:
  - "I don’t have the IP, but ask the Authoritative Name Server for namanraj.tech"

This dig command queries the DNS server at a.gtld-servers.net for the nameservers (NS records) responsible for the domain namanraj.tech. It essentially asks the a.gtld-servers.net server which DNS servers handle requests for namanraj.tech.

It will list the nameservers that are authoritative for the namanraj.tech domain. These are the servers that handle DNS queries for namanraj.tech

AUTHORITY SECTION: If the DNS server does not have the direct answer, it may provide a list of nameservers that are closer to the authoritative source

5. Query to the Authoritative Name Server

The recursive resolver now queries the Authoritative Name Server.
What is an Authoritative Name Server?
- It is the final authority for a domain.
- It stores and manages DNS records (A, CNAME, MX, etc.) for a domain (we will come to this later).
The authoritative name server for namanraj.tech (e.g., ns1.vercel-dns.com) replies:
- "The IP address for namanraj.tech is 76.76.21.93."

This dig command queries the DNS system to find the nameservers responsible for the domain namanraj.tech. It asks which DNS servers handle requests for this domain.

It will give the list of nameservers that are associated with namanraj.tech domain that stores and manages DNS records. Here, they are:

ns2.vercel-dns.com
ns1.vercel-dns.com

6. Recursive Resolver Returns the IP

The recursive resolver caches the response for future use.
It sends the final IP address (76.76.21.93) back to your device.
Now that your device knows the correct IP, it sends an HTTP request to 76.76.21.93.
The web server at that IP responds, and namanraj.tech loads in your browser!

🛠️ Visualizing DNS: The Complete Resolution Flow (Step-by-Step)

Let's say you visit namanraj.tech , here's what happens :

🗂️ Types of DNS Records

DNS records define how a domain functions by mapping domain names to IP addresses, handling emails, and managing domain settings. Here are the most important ones:

1. A Record (Address Record) 🏠

Maps a domain to an IPv4 address, allowing browsers to locate websites.
Example: namanraj.tech → 192.0.2.1
Use Case: When a user types namanraj.tech, the A record helps find the web server’s IP.

This dig command dig namanraj.tech A queries the DNS system to find the A (Address) record for the domain namanraj.tech. It asks for the IP address associated with this domain.

2. AAAA Record (IPv6 Address Record) 🌍

Similar to an A record but stores an IPv6 address instead of IPv4.
An AAAA (Quad-A) record is similar to an A record but maps a domain to an IPv6 address. IPv6 uses a 128-bit address format, supporting trillions of IP addresses solving the issue of IPv4 exhaustion.
Example: google.com → 2607:f8b0:4005:80b::200e
Use Case: Websites that support IPv6 use AAAA records for better future-proofing.

3. CNAME (Canonical Name Record) 🔗

Creates an alias by pointing one domain to another domain instead of an IP.
Example: www.namanraj.tech → namanraj.tech
Use Case: Ensures www.namanraj.tech always resolves to the same IP as namanraj.tech without maintaining separate A records.

4. MX Record (Mail Exchange Record) 📧

Defines the mail server responsible for handling email delivery for a domain.
Example: namanraj.tech → mail.google.com (Priority: 10)
Use Case: When someone emails you@namanraj.tech, the MX record ensures it reaches the correct mail server.

The answer section lists one MX record for google.com:

Priority: 10
Mail server: smtp.google.com

In MX records, the priority value determines the order of mail servers to be used. Lower values have higher priority. If the primary server is unavailable, the next server with a higher priority value is used.

5. NS Record (Name Server Record) 📡

Specifies the authoritative name servers that manage a domain’s DNS settings.
Example: namanraj.tech → ns1.vercel-dns.com, ns2.vercel-dns.com
Use Case: These servers handle all DNS queries for namanraj.tech.

6. TXT Record (Text Record) 🔒

A TXT (Text) Record is a DNS record that allows a domain owner to store text-based information in the DNS. Unlike A or MX records, which are used for website and email routing, TXT records do not affect how a domain functions directly. Instead, they are mostly used for verification, security, and authentication purposes

Stores arbitrary text, often used for security & authentication (SPF, DKIM, verification).
Example: "v=spf1 include:_spf.google.com ~all" (SPF record for email validation)
Use Case: Prevents email spoofing and domain ownership verification.

The answer section lists multiple TXT records for google.com, including:
- google-site-verification values
- docusign values
- onetrust-domain-verification value
- globalsign-smime-dv value
- v=spf1 include:_spf.google.com ~all (SPF record for email validation)
- facebook-domain-verification value
- MS (Microsoft) verification value
- apple-domain-verification value
- cisco-ci-domain-verification value

7. SOA Record (Start of Authority) 📜

The SOA (Start of Authority) record is a special DNS record that provides important administrative details about a domain’s DNS settings. It acts as the "boss" of the DNS zone and ensures everything is properly managed.

Contains administrative information about a domain, including the primary DNS server and refresh intervals
Example: Primary NS: ns1.vercel-dns.com, Admin: hostmaster.nsone.net
Use Case: Ensures DNS records are properly synchronized across name servers.

⚡ Building My Own DNS Server in Go: A Journey Through Networking Fundamentals 🚀

To truly understand how DNS works, I decided to build my own custom DNS server in Go—and in this Part, I’ll walk you through how I did it, the challenges I faced, and what I learned along the way.

GitHub Repo (Feel free to star ⭐ or contribute!)

Why Build a DNS Server?

How DNS queries/responses work (UDP vs. TCP)
Authoritative vs. Recursive DNS (mine is authoritative)
Real-world use cases (local development, ad-blocking, privacy)

This project was less about replacing Cloudflare and more about learning by doing.

Setting Up the Project

Installing Go & Fiber - Click Here
Dependencies Used (github.com/miekg/dns for DNS handling, Fiber for API).
In-memory storage (Simple map[string]string for records)
Project Structure Overview :

/my-dns-server
│── main.go        # Entry point of the DNS server
│── go.mod         # Dependency management
│── go.sum         # Dependency checksum file

Building the DNS Server: Core Implementation

1. Initializing the DNS Server (startDNSServer)

Before handling requests, we need to launch our DNS server. Here's the foundation:

func startDNSServer() {
    // Set up DNS server
    server := &dns.Server{
        Addr: "0.0.0.0:9090", // Bind to all interfaces
        Net:  "udp",
    }

    // Handle DNS requests
    dns.HandleFunc(".", handleDNSRequest)

    // Start server
    log.Printf("Starting DNS server on port 9090...")
    err := server.ListenAndServe()
    if err != nil {
        log.Fatalf("Failed to start DNS server: %v", err)
    } else {
        log.Printf("DNS server is running on port 9090")
    }
}

Key Decisions:

UDP Protocol: Chosen for performance (DNS mostly uses UDP for quick queries)
Port 9090: Avoids needing root privileges (vs standard port 53)
UDPSize: Supports large DNS responses (like DNSSEC)

2. Concurrent Operation with Fiber

Since DNS runs continuously, we launch it in a goroutine alongside our Fiber API:

func main() {
    go startDNSServer() // Run DNS in background
    startWebServer()    // Start Fiber API
}

Why This Matters:

The DNS server keeps running while:
- The Fiber API manages records
- You query DNS from multiple clients simultaneously

3. DNS Server (UDP Port 9090)

The core DNS functionality listens for UDP requests and responds with stored records.

func handleDNSRequest(w dns.ResponseWriter, r *dns.Msg) {
    m := new(dns.Msg)
    m.SetReply(r)
    m.Authoritative = true // Mark this server as authoritative
    found := false

    for _, q := range r.Question {
        log.Printf("Query: %s (%s)", q.Name, dns.TypeToString[q.Qtype])
        if q.Qtype == dns.TypeA {
            if ip, exists := dnsRecords[q.Name]; exists {
                rr, _ := dns.NewRR(fmt.Sprintf("%s A %s", q.Name, ip))
                m.Answer = append(m.Answer, rr)
                found = true
            }
        }
    }

    if !found {
        m.Rcode = dns.RcodeNameError // NXDOMAIN
    }

    w.WriteMsg(m)
}

Why Using UDP and not TCP?

DNS primarily uses UDP (User Datagram Protocol) instead of TCP for 3 key reasons:

UDP is connectionless (no handshake like TCP).
A DNS query + response fits in 1 UDP packet (usually < 512 bytes).
UDP’s lightweight nature lets them serve more queries with fewer resources.

4. Web Management API (Fiber, Port 3000)

A simple REST API to add DNS records dynamically:

    // Web interface to manage DNS records
    app.Get("/records", func(c *fiber.Ctx) error {
        return c.JSON(dnsRecords)
    })

    app.Post("/records", func(c *fiber.Ctx) error {
        type Record struct {
            Domain string `json:"domain"`
            IP     string `json:"ip"`
        }

        var record Record
        if err := c.BodyParser(&record); err != nil {
            return c.Status(400).SendString("Bad request")
        }

        // Ensure domain ends with dot (DNS standard)
        if record.Domain[len(record.Domain)-1] != '.' {
            record.Domain += "."
        }

        dnsRecords[record.Domain] = record.IP
        return c.SendString("Record added successfully")
    })

Challenges & Lessons Learned

1. DNS Queries Are UDP-Based (Mostly)

By default, DNS uses UDP (faster for small requests).

2. The Importance of the Trailing Dot

"example.com" ≠ "example.com." (fully qualified domain name).

3. Port Binding Permissions

Ports below 1024 require admin rights (sudo on Linux).
Used port 9090 for testing to avoid permission issues.

4. No Recursion (Yet!)

My server is authoritative-only (only answers for records it knows).
A recursive resolver would query other DNS servers if it doesn’t have an answer.

Practical Uses for a Custom DNS Server

Local Development
Ad-Blocking
Network Privacy

Try It Yourself!

1. Clone the repo:

git clone https://github.com/Denyme24/my-dns-server.git
cd my-dns-server
go run main.go

2. Start querying!

Final Thoughts

Building a DNS server was a fantastic learning experience—I now appreciate how much work goes into something we use daily without thinking.

What would you add to this project? Let me know in the comments! 🚀

(P.S. If you found this useful, consider starring the repo! ⭐)