Summary
I assumed NextDNS would be the winner before I even started. That’s because it’s the encrypted DNS service that everyone loves, while Control D gets a mention further down on most recommendation lists. Both promise privacy filtering and faster lookups, but their performance still depends on how my home network routes my traffic to their servers. I knew that a handful of nslookup commands wasn’t going to cut it. That’s because shared caches can prop up some results, and a latency spike could punish the other. So I built a repeatable DNS-over-HTTPS benchmark on a Debian 13 VM and made both resolvers answer the same queries over and over. Control D was faster, but its victory came with a reliability problem I’m not sure if I can ignore. I made both resolvers answer the same 1,000 questions One Linux VM, one protocol, and no easy excuses I kept this test away from my router because DNS caching would have skewed the results. I also didn’t use separate clients because that would introduce more uncertainty by adding applications into the test. Instead, I queried both personalized DNS-over-HTTPS endpoints directly from the same Debian 13 virtual machine hosted on a home server. That meant that the OS, virtual hardware, and my trusty Starlink connection all looked identical for the DNS benchmarking test. I also created brand-new benchmark profiles in both Next DNS and Control D where I disabled the following:
- Blocklists
- Parental controls
- Custom rules
- Filters
- Redirections
- Third-party security filtering For the workload itself, I downloaded a fixed snapshot from Tranco, which maintains an active research ranking of popular domains. I extracted the first 1,000 entries and saved the download date and SHA-256 hash as a fingerprint: unzip -p data/tranco-top-1m.zip | head -n 1000 | cut -d, -f2 > data/domains-1000.txt I was aware that NextDNS and Control D likely have already cached popular domains, and that clearing my VM’s cache couldn’t also clear theirs. So, I treated these domains as a list of 1,000 mixed popular-domain lookups instead. used dnspyre to send the requests and save both a JSON summary and every individual duration: dnspyre —server “{list}” HTTP/2 kept one encrypted connection open, while a single worker and a 10-query-per-second limit stopped limitations of my compute from affecting the results. Finally, I ran four tests in an ABBA order. NextDNS went first in runs one and four, while Control D got to go first in runs two and three. That way, neither provider benefits from always going first. NextDNS is a customizable encrypted DNS service that blocks ads, trackers, malware, phishing, and unwanted content across devices. It also provides parental controls, allowlists, analytics, and query logs. NextDNS
- Developer(s)
- NextDNS
- Price model
- Free and paid tiers Control D was faster across the entire latency curve The median started the story, but p95 and p99 made the winner obvious I ran the tests four times, and once I had finished and collated the results, it was clear that Control D hadn’t just scraped ahead. Its advantage grew as lookups slowed, which is, unfortunately, where I’d expected Starlink’s frequent latency spikes to start poisoning the results. | Clean results | NextDNS | Control D | | Median | 96.4 ms | 75.7 ms | | p95 | 576.6 ms | 380.1 ms | | p99 | 1,042.3 ms | 651.1 ms | Here’s a breakdown of what those measurements mean:
- Median, or p50, means half the lookups finished faster, and half took longer. This is probably the closest measurement to a typical request.
- p95 means 95% finished within this time, while the slowest 5% took longer.
- p99 means 99% finished within the time, and the remaining 1% represents extreme delays that can be hidden in averages. Lower was better across all three. Control D’s median was 21.5% lower than NextDNS. Its advantage widened to 34.1% at p95 and 37.5% at p99. It also completed 66.9% of the 3,938 successful matched pairs, significantly faster. This wasn’t a one-off fluke, either. Control D recorded the lower median in every single test. I also wanted to separate network distance from the work involved in just resolving the domains. I queried cloudflare.com 500 times, so after the first request, both NextDNS and Control D should’ve already cached the result. Any timings after this should have measured the round trip to each resolver rather than the resolver searching through the DNS hierarchy again: yes cloudflare.com | head -n 500 > data/domains-warm.txt Both services completed every request, but Control D retained a smaller lead this time around. Its median was 71.2 ms compared with 84.4 ms for NextDNS. These results did suggest that my Starlink connection to each resolver contributed slightly to Control D’s advantage. Control D is an encrypted DNS service that blocks ads, trackers, malware, and unwanted content with custom rules, analytics, and traffic redirection.
- Publisher(s)
- Control-D
- Free trial
- Yes
- Price model
- Paid - Subscription Enabling the same OISD filter didn’t reverse the result Control D kept its lead when I turned privacy blocking back on Clean profiles helped me test while isolating resolver performance, but they don’t really represent how I’d actually use DNS in real life. After all, barely anyone would pay for NextDNS or Control D just to leave every single DNS privacy filter turned off. However, enabling each provider’s native ads and trackers filter wouldn’t have been fair because they each contain different domains and rules. OISD is an independent, community-maintained domain blocklist that is intended to prevent access to advertising, tracking, and other potentially harmful hosts. Both providers offered their full list, so I could turn OISD on for both and be confident the same filtering workload was on either side. I enabled OISD in NextDNS and OISD Full in Control D. I then gave both profiles time to update, and ran another two alternating 1,000-domain tests: run_test nextdns “$NEXTDNS_DOH” filtered-r1 data/domains-filtered-r1.txt Both providers received the same shuffled file during each matched run, and I reversed which one came first: | OISD-filtered results | NextDNS | Control D | | Median | 101.2 ms | 75.7 ms | | p95 | 640.3 ms | 408.1 ms | | p99 | 1,112.7 ms | 707.4 ms | The original ranking still survived at every percentile. However, I can’t really blame filtering alone for the differences between the clean and filtered figures because they were run at different times on a Starlink connection. Finally, I sampled 200 OISD domains without opening them. Both resolvers returned all 200 responses without issue, and Control D won the median and p95 at 71ms and 79ms. NextDNS came in at 88ms and 100ms and narrowly reclaimed p99 at 109ms against Control D’s 125ms. The fastest resolver wasn’t automatically the one I trusted most Sixty-two failed queries made Control D’s victory much less comfortable Control D was the clear winner in the speed stakes, but it came with a catch I just couldn’t really ignore. Across the 4000 clean requests, it recorded 58 three-second timeouts and four SERVFAIL responses. That means the resolver replied, but couldn’t actually complete the lookup. That produced a significant failure rate of 1.55%, or 62 failures. NextDNS only failed four requests, or 0.10%. Matching OISD didn’t fix the pattern either, with Control D failing 24 times, and NextDNS only missing five. The temptation to blame Starlink for this was definitely there, but both providers used the same standardization throughout, with both environment and tools. Some domains also failed repeatedly, and both providers struggled heavily with ack.de , which also failed testing with Starlink’s DNS servers. That reliability gap doesn’t really erase Control D’s speed advantage, though. Among the 3,938 queried domain pairs that both providers answered successfully, Control D was faster 66.9% of the time. That leaves me with two different winners. Control D was clearly the fastest resolver for my network, while NextDNS was far more reliable during the same test. I wouldn’t personally want to that failure rate more closely over a longer timeframe.Still, the less popular service beat NextDNS by more than a few milliseconds. It just goes to show that popular recommendations are useful as a starting point, but the best-performing DNS resolver still depends on where I am and how my ISP actually reaches it.