Public DNS Benchmark

Server assisted New Internet & Network

Sends up to three rounds of DNS-over-HTTPS queries to Cloudflare, Google, Quad9, OpenDNS, AdGuard, Control D, CleanBrowsing and NextDNS and ranks them by failed queries first and median response time second, with each resolver’s fastest and slowest answer. The queries leave from the Cloudflare edge that runs the Mutqan server, so the ranking describes that vantage point, not your own connection.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

How do you tell which public DNS resolver is fastest?

Time the same questions to each resolver several times and compare medians, counting failed queries first: a resolver that times out or answers SERVFAIL is worse than a slower one that always answers. The result depends on where you measure from, because public resolvers are anycast networks that answer from their nearest site, so a ranking taken in a data centre is a comparison of the services, not a verdict for your own connection.

How to use Public DNS Benchmark

  1. Leave the names empty to use example.com, wikipedia.org and cloudflare.com, or type up to three names of your own, one per line.
  2. Keep 3 rounds, which an ordinary visit has room for and which gives the steadiest median, or choose fewer for a quicker run. Each round asks one name, so with fewer rounds than names the later names are not queried.
  3. Press Run DNS benchmark and wait a few seconds while every round completes.
  4. Read the ranking with the vantage point in mind: these are times from the Cloudflare edge, not from your connection.

Public DNS Benchmark features

  • Eight public resolvers timed in one run: Cloudflare, Google, Quad9, Cisco OpenDNS, AdGuard, Control D, CleanBrowsing and NextDNS
  • One to three rounds, each asking every resolver one name in shuffled order, four resolvers at a time, so no resolver’s samples overlap
  • Ranking by failed queries first and median time second, with each resolver’s minimum, maximum and answered count
  • Your own names, up to three, or three widely cached defaults
  • Plain notes on the vantage point, on failures and on differences too small to matter
  • Ranking table downloadable as CSV

Inputs and outputs

Inputs

  • Names to query: up to three domain names, one per line, or empty for the defaults.
  • Rounds: 1, 2 or 3 (each round queries every resolver once).

Outputs

  • Benchmark: fastest and slowest median with the resolver, rounds run against rounds requested, and the vantage point.
  • Resolver ranking: rank, resolver, provider, median, minimum and maximum in milliseconds, answered queries and failures.
  • Notes on the vantage point, failures, near-ties and the resolvers left out of the list, and a warning when fewer rounds ran than you chose.

Public DNS Benchmark example

Benchmark with the default names, 3 rounds (values vary by edge location and time)

Input:

Names: (empty — example.com, wikipedia.org, cloudflare.com) · Rounds: 3

Output:

Fastest median: 3.2 ms (Cloudflare 1.1.1.1) · Slowest median: 41.6 ms (CleanBrowsing (security filter)) · Rounds run: 3 / 3 · Measured from: Cloudflare edge (not your connection)
Rank | Resolver | Provider | Median (ms) | Min (ms) | Max (ms) | Answered | Failures
1 | Cloudflare 1.1.1.1 | Cloudflare | 3.2 | 2.9 | 4.1 | 3/3 | 0
2 | Google Public DNS | Google | 9.8 | 8.7 | 12.4 | 3/3 | 0
3 | Quad9 | Quad9 Foundation | 11.5 | 10.1 | 13 | 3/3 | 0
…

How to read the Public DNS Benchmark results

Failures matter more than speed: a resolver that missed one round out of three is ranked after every resolver that answered all of them.

Medians within a few milliseconds of each other are a tie from this vantage point; network conditions between rounds move them by that much.

A resolver with a low minimum but a high maximum answered most queries quickly and one slowly, often because that query had to open a new HTTPS connection.

Cloudflare’s resolver runs in the same network as the measuring edge, so its first place says more about the vantage point than about your own connection.

When to use Public DNS Benchmark

  • Comparing the public resolvers’ service quality before recommending one for an office or a product.
  • Checking whether a resolver is failing or unusually slow right now, as seen from a major cloud edge.
  • Measuring how long resolvers take to answer for your own domain, cached or not, compared with popular names.

Troubleshooting

  • "The DNS benchmark can run 5 times per 10 minutes": each run sends up to 24 queries to third-party resolvers; wait for the time shown and run it again.
  • A warning that fewer rounds ran than you chose: your per-minute budget of DNS queries, which the other DNS tools share, ran out mid-run, or the run reached its 24-second limit. Each median then rests on fewer samples; run the benchmark again a minute later for all rounds.
  • A resolver with failures in every round: it may be blocking the name on purpose (Quad9, AdGuard and CleanBrowsing filter), or it was unreachable from this edge at that moment; try another name.
  • A name refused before the run: use public domain names only; addresses of private networks and single-label names are not accepted.

Frequently asked questions about Public DNS Benchmark

Does this tell me the fastest DNS for my home connection?

Not directly. The queries are sent from the Cloudflare edge that runs the Mutqan server, so the times describe the path from that data centre to each resolver. Your own ranking depends on your ISP and location; use this to compare the resolvers’ service, then confirm from your own device before changing your settings.

Why does Cloudflare usually come first here?

The benchmark runs inside Cloudflare’s network, and 1.1.1.1 is served from the same network, often the same data centre. That advantage is built into the vantage point, and the page says so instead of hiding it.

Why can I run it only 5 times in 10 minutes?

Each run sends up to 24 DNS-over-HTTPS queries (8 resolvers × 3 rounds) to third-party services. The limit keeps the tool from being used to load those resolvers; when you reach it, the page shows when you can run it again.

Which names should I query?

Popular names are already cached at every resolver, so they measure how fast each resolver answers from cache, which is what most everyday lookups are. A rarely visited name measures a full recursive lookup instead, which also depends on that domain’s own nameservers. Each round asks one name in the order you typed them, so with fewer rounds than names the later names are not queried.

Why did fewer rounds run than I chose?

Every round sends eight queries and counts against your per-minute budget for DNS queries, which the other DNS tools on this site share. An ordinary visitor has room for all three rounds, but if you used other DNS tools in the same minute the budget can run out mid-run, and a run also stops at its 24-second time limit. The page then says how many rounds ran and warns that each median rests on fewer samples; run it again a minute later for all three.

How are failures counted?

A query counts as answered only when the resolver replied NOERROR or NXDOMAIN. A timeout (3 seconds), an HTTP error, SERVFAIL or REFUSED is a failure, and resolvers are ranked by failures before latency, so one that refuses quickly never outranks one that answers.

Why are some of the resolvers filtering ones?

Quad9 blocks known-malicious domains, AdGuard’s default profile blocks advertising and tracking domains, and the CleanBrowsing endpoint used here is its security filter. For ordinary names this does not change the timing, but these resolvers answer differently for the names they block.

Technical notes

Each sample is one RFC 8484 DNS-over-HTTPS query for an A record, timed by the Mutqan server from the moment it is sent until the decoded reply arrives; a sample includes the HTTPS connection setup whenever the Worker has to open a new connection to that resolver.

Round r asks every resolver names[r mod n]; a reply counts only when its RCODE is NOERROR or NXDOMAIN (RFC 1035). A timeout of 3 seconds, an HTTP error, SERVFAIL or REFUSED is a failure. Resolvers are sorted by failures, then median, then minimum.

Every round is charged before it runs to the visitor’s per-minute budget of DNS queries (eight per round, shared with the other DNS tools; an ordinary visitor has room for three rounds), and the whole call has a 24-second budget. A run that stops early returns the rounds that ran, with a warning that the medians rest on fewer samples.

Limitations and methodology

Measured from the Cloudflare edge that runs the Mutqan server, not from your device or ISP. The ranking from your own connection can be different; Cloudflare’s resolver has a home advantage here.

At most three samples per resolver per run, which gives a quick comparison, not a statistically strong measurement. A run cut short by the query budget or the time limit has fewer, and with fewer rounds than names the later names are not queried.

Eight resolvers only. DNS4EU is left out because its terms provide the service to individual citizens only, and Mullvad because its endpoint could not be verified.

Five runs per 10 minutes per visitor.

Security and privacy

The names you enter are sent from the Mutqan server to the eight resolvers listed, which may log queries under their own policies. Mutqan stores nothing.

References