Skip to main content

Command Palette

Search for a command to run...

I Stress-Tested My Own DNS Server This Weekend (8K QPS 🚀)

Updated
•2 min read

This weekend, I didn’t binge-watch anything.
I stress-tested my own DNS server.

For the past few months, I’ve been building NexoralDNS — a UDP-based DNS server focused on performance, analytics, and control. Not a wrapper. Not a proxy. A real packet-level DNS implementation.

This weekend was about one thing:
Can it survive real load?

So I fired up dnsperf.

First, I tested a single-node instance.

It sustained ~3,700–3,800 QPS with 500 concurrent clients. Packet loss stayed under 0.2% even at saturation. Average latency hovered around ~12ms. No crashes. No memory leaks. No unexpected SERVFAIL storms.

Then came the real test — the 9-worker production cluster.

~8,050 QPS sustained.
0.00% packet loss (3 packets out of 80k+).
~10ms average latency.

That’s over 230+ million requests per day at current capacity.

But the numbers weren’t the most satisfying part.

The real win was architectural validation.

  • UDP socket handling under concurrency

  • Worker clustering

  • Redis-backed caching

  • Async logging pipeline

  • Clean DNS packet parsing

  • Forwarding + blocking logic under stress

Everything behaved predictably.

When you build infra software, benchmarks are brutal. They don’t care about your effort. They expose weak assumptions immediately.

This weekend confirmed something important:

If you understand the protocol deeply enough, even high-throughput network systems become manageable engineering problems — not magic.

Still optimizing. Still profiling. Still breaking it intentionally to make it stronger.

Building infra from scratch teaches you things frameworks never will.

And honestly — that’s the fun part. ⚡