# How I Developed a DNS Server to Explore Networking: The NexoralDNS Story ### Why This Project Exists (The Real Reason) NexoralDNS didn’t start as a “product idea”. It started with **curiosity**. When I first tried to learn how DNS servers work—from blogs and YouTube—the explanations felt abstract: * *UDP call on port 53* * *recursive resolver* * *authoritative response* * *domain hierarchy* I understood the words, but not the **flow**. So I asked myself a simple question: > *If DNS is just a UDP server listening on port 53, what happens if I build one myself?* That question is where **NexoralDNS** was born. --- ## The First Curiosity That Changed Everything DNS uses **UDP**, and Node.js has `dgram`. So I thought: * What if I start a UDP server on port **53**? * What if I point my router’s DNS to my laptop’s private IP? * Will it actually resolve domains? I tried it. **It worked.** That single experiment changed my understanding completely. At that moment, DNS stopped being “magic infrastructure” and became: > **Packets → Buffers → Logic → Response** And once that clicked, I went deeper. --- ## What NexoralDNS Actually Provides NexoralDNS is a **LAN-focused, programmable DNS server** built to understand and control DNS behavior at a low level. It currently provides: * A custom DNS server handling **UDP 53** * Domain parsing from raw **Buffer data** * Recursive domain hierarchy understanding (`sub → root → TLD`) * Rule-based domain control (block, allow, redirect) * Admin panel to control DNS behavior * Internal service-to-service communication using a **custom TCP broker** * Automatic rebinding when IP changes via DHCP signals It’s not meant to replace Cloudflare or public resolvers. It’s meant for **offices, labs, learning, and internal networks**. --- ## Architecture (Why Multi-Folder Matters) The project is intentionally **multi-folder**, because I designed it for future evolution. ### Folder Breakdown * **Core DNS Engine** * Handles UDP packets * Parses DNS queries from raw buffers * Generates responses * Uses Node Cluster for concurrency * **DHCP** * Listens for IP changes * Detects when DNS server IP changes * Notifies other services to rebind port 53 * **Broker** * Custom TCP-based message broker * Built to understand service notifications * Replaced RabbitMQ *intentionally* to learn internals * **Server** * Admin APIs written in **Fastify** * Controls rules, domains, and configs * **Web** * Admin UI built with **Next.js** * Visual control over DNS rules and analytics This separation makes one thing very important: > **If I replace the Core DNS engine with Golang later, > I only need to change the core — not the Web or Admin layers.** That decision was deliberate. --- ## Why I Chose Node.js Over Golang or Rust (Honestly) Let me be blunt. I didn’t choose Node.js because it’s the “best” language for DNS. I chose it because: * I **know Node.js deeply** * I understand async behavior * I can move fast with logic * I trust myself to debug it At the beginning, **confidence matters more than performance**. I knew: * If I picked Golang *without deep networking confidence*, I’d stall * If I picked Rust, I’d fight the compiler instead of learning DNS My belief: > **Logic > Language** Languages can change. Understanding **packet flow, recursion, and hierarchy** is permanent. --- ## What I Learned While Building This This project taught me things no tutorial ever could: ### 1\. DNS Parsing from Raw Buffers * How queries arrive as binary * How to extract: * Domain name * Query type (A, AAAA, CNAME, etc.) * How compression pointers work ### 2\. Recursive Domain Hierarchy * Why DNS is not just a lookup * How delegation works * How recursion actually flows internally ### 3\. UDP Is Stateless (And That Matters) * No connection * No retry guarantee * You must respond **fast** ### 4\. Node Cluster for DNS To improve performance: * I used **Node.js Cluster** * Spread UDP load across CPU cores With this setup, NexoralDNS handled: > **~7,000 QPS**, measured using `dnsperf` That number surprised me. --- ## Performance Reality Check Let’s be honest again. * Node.js at ~7k QPS: **good** * Golang at the same logic: **10k+ QPS easily** I know this. That’s why my **future plan** is clear: * Rewrite the **Core DNS handler in Golang** * Keep Admin, Web, and Control layers intact Before that: > I need to *understand networking deeply* — not just write faster code. I’m learning Go now, slowly and correctly. --- ## Why I Built My Own TCP Broker Before using RabbitMQ, I asked: > *Do I really understand how message brokers work?* So I built one. A simple **TCP-based message broker** that: * Allows one service to notify another * Used by DHCP → Web → DNS engine * Handles rebinding and runtime coordination This taught me: * Why brokers exist * Where RabbitMQ adds value * Where custom solutions make sense This wasn’t about replacing RabbitMQ. It was about **earning the right to use it knowingly**. --- ## The Bigger Picture NexoralDNS is not about DNS alone. It’s about: * Understanding networking fundamentals * Removing fear from “core systems” * Proving that curiosity + experiments beat tutorials I didn’t build this to impress anyone. I built it because I wanted answers. And now I have them. --- ## What’s Next * Rewrite Core DNS engine in **Golang** * Improve rule engine performance * Better analytics for LAN usage * Hardening broker communication * Deeper recursion optimizations This project already did its job: > **It turned DNS from theory into intuition.** And that was the real goal.