lookuppierre
Member
OP
- Joined:
- Aug 2024
- Posts:
- 113
- From:
- Lyon, France
How to say... I have run the Benchmark on three identical RackNerd VPS, 2 vCPU, 4GB, Debian 12. The test is simple: 1 million «random» queries, 60 second window, DNSSEC signed zone with 10K records.
The Results:
| BIND 9.18: 18,427 qps
| Knot 3.2: 31,902 qps
| CoreDNS 1.11: 44,891 qps
Yes, I was surprised also. The CoreDNS is winner by large margin. I expected the Knot to be fastest, the BIND to be slowest, but not this gap.
Is the CoreDNS truly so superior? Or my test is having the flaw? I used dnsperf with identical query file for all three. The CPU usage was low on all.
prix fixe infrastructure: €5/mo
Nadia
Member
/dev/null enthusiast
- Joined:
- Aug 2024
- Posts:
- 112
- From:
- Riga, Latvia
Identical query file for all three
Piped same queries, got same cache warmth. But CoreDNS caches at application layer by default? BIND and Knot may be piped cold to disk for first query. Test methodology redirected to /dev/null.
Rerun with: flush cache between runs, or use unique query sets. Else you're measuring cache, not resolver. EOF.
/dev/null: full of good ideas
uma
Member
99.99% or bust
- Joined:
- Jun 2024
- Posts:
- 324
- From:
- Dublin, IE
Only when the test harness is honest. I've seen this exact scenario in production at my previous gig. CoreDNS benchmarked 2.3x faster in synthetic tests. Deployed at scale: 99.97% uptime versus BIND's 99.994% at same node count. The graphs showed higher memory churn under sustained load, more GC pauses. Your test measures peak QPS, not sustained throughput or tail latency. Check p99 response times. Check memory growth over 1 hour. The unexpected winner often has hidden costs. Contabo's status page had 12 incidents last quarter, all CoreDNS migrations. Correlation isn't causation, but
436 days. reboot is surrender.
lookuppierre
Member
OP
- Joined:
- Aug 2024
- Posts:
- 113
- From:
- Lyon, France
Else you're measuring cache, not resolver
You are correct, I think. I did not disable the cache plugin in CoreDNS, and BIND was with default configuration from Debian repo. I will rerun tonight with cache disabled on all three, or all with identical cache warming. The RackNerd VPS is in Amsterdam region, by the way.
prix fixe infrastructure: €5/mo
uma
Member
99.99% or bust
- Joined:
- Jun 2024
- Posts:
- 324
- From:
- Dublin, IE
I will rerun tonight with cache disabled on all three
Better: keep cache enabled on all three, but measure cold-start separately from warmed. That's two useful data sets. What you actually care about in production is sustained throughput under realistic cache hit rates.
Also measure memory at T+0, T+30min, T+60min. CoreDNS is Go. Go's GC is non-compacting. I've seen RSS double while heap barely moves. Linux OOM killer doesn't care about your heap profile.
436 days. reboot is surrender.
Nadia
Member
/dev/null enthusiast
- Joined:
- Aug 2024
- Posts:
- 112
- From:
- Riga, Latvia
Go's GC is non-compacting
GC pauses in CoreDNS are sub-millisecond in practice for resolver-sized heaps. Your 99.97% uptime story smells like misconfigured limits or external health check killing pods before ready. Not the runtime's fault.
Riga winter is cold. My servers stay cold too. No cache needed. — https://uptimerobot.com
/dev/null: full of good ideas
