DNS Resolver Speed Report
Measured 2026-07-11 to 2026-08-29 · 50 days of latency data, 22 days of availability data · sampled every 4 hours
Most resolver comparisons are one person running dig a few times from their laptop. This one is 50 days of automated sampling against 14 public DNS resolvers, taken every four hours from the same Cloudflare edge that powers the WhereIsDNS lookup tool. The raw numbers are published as JSON, so anyone can check the arithmetic.
What the data shows
Cloudflare is not just first, it is a different order of magnitude
Cloudflare returns a median answer in 5 ms. The next fastest, OpenDNS, takes 42 ms — roughly 8× longer. A gap that large is unusual in a mature market, and it holds across the whole 50 days of sampling rather than showing up as one good week.
The field spans 181×
From Cloudflare at 5 ms to DNSPod at 903 ms, the measured range across all 14 resolvers is about 181×. Most of that spread is geography rather than engineering quality — read the caveats below before treating it as a league table.
5 resolvers did not answer every time
Over 22 days of availability tracking, 9 resolvers answered every query we sent. 5 did not:
- Hurricane Electric — 91.7% over 22 days
- OpenDNS — 94.7% over 22 days
- DNS4EU — 98.5% over 22 days
- Yandex — 98.5% over 22 days
- DNSPod — 98.5% over 22 days
None of these make a resolver unusable. They are worth publishing because almost nobody does: a resolver that quietly fails 8.3% of the time is invisible until it drops the query you actually needed.
Full results
Ranked by median (p50) response time, fastest first. Latency days and uptime days are listed separately on purpose: availability tracking began later than latency tracking, so the two columns rest on different amounts of evidence.
| # | Resolver | p50 latency | Uptime | Latency days | Uptime days |
|---|---|---|---|---|---|
| 1 | Cloudflare | 5 ms | 100.0% | 50 | 22 |
| 2 | OpenDNS | 42 ms | 94.7% | 50 | 22 |
| 3 | 47 ms | 100.0% | 50 | 22 | |
| 4 | Quad9 short window | 58 ms | 100.0% | 22 | 22 |
| 5 | AdGuard | 61 ms | 100.0% | 50 | 22 |
| 6 | NextDNS | 71 ms | 100.0% | 50 | 22 |
| 7 | CleanBrowsing | 82 ms | 100.0% | 50 | 22 |
| 8 | ControlD | 128 ms | 100.0% | 50 | 22 |
| 9 | Hurricane Electric | 195 ms | 91.7% | 50 | 22 |
| 10 | Mullvad | 368 ms | 100.0% | 50 | 22 |
| 11 | AliDNS | 535 ms | 100.0% | 50 | 22 |
| 12 | DNS4EU | 830 ms | 98.5% | 50 | 22 |
| 13 | Yandex | 890 ms | 98.5% | 50 | 22 |
| 14 | DNSPod | 903 ms | 98.5% | 50 | 22 |
Method
A scheduled job runs every four hours from a Cloudflare Worker. Each run sends the same query to all 14 resolvers over DNS-over-HTTPS and records the wall-clock time to a complete answer, plus whether an answer arrived at all. Daily figures are the median of that day's samples; the p50 above is the median of those daily medians, which stops one bad afternoon from dominating a resolver's score.
Availability is the share of attempts that produced a usable answer. A timeout, a transport error, and a SERVFAIL all count as failures. Days from before availability tracking existed are recorded as unknown rather than as 100% — scoring an unmeasured day as perfect would flatter every resolver equally and make the column meaningless.
How to read this honestly
These are latencies from a Cloudflare edge, not from your house. That single fact explains most of the table. A resolver with dense peering near our sampling point looks fast; one that is geographically distant looks slow, however well it serves its own users. DNSPod at 903 ms is not a badly run service — it is a service being measured from the wrong continent.
Treat the ranking as relative, not absolute. The supportable claim is "resolver A answers faster than resolver B from a well-connected Western edge." The unsupportable one is "you will see 5 ms if you switch." You will not: your path, your ISP, and your own recursive cache all sit in between.
1 resolver has a shorter measurement window and is marked in the table: Quad9 (22 days). Those figures are real but rest on less evidence than the rest of the field, so a close ranking against a full-window resolver should not be read as decisive.
The availability figures are a floor on quality, not an SLA. 22 days at four-hour granularity is roughly 132 observations per resolver — enough to catch one that fails regularly, nowhere near enough to characterise a rare outage.
Where the numbers come from
Everything above is generated at build time from /api/history/archive, the same permanent record that feeds the live leaderboard. That endpoint is public and unauthenticated. If you think a number here is wrong, the raw daily series is one request away — we would rather be corrected than cited incorrectly.
For a per-resolver write-up — who operates each one, what it filters, and where it makes a sensible default — see the resolver leaderboard and profiles. To check how a specific record resolves across all 14 of them right now, use the lookup tool.