How we measure DNS speed
An honest, detailed account of what this tool tests, how it calculates the numbers, and — just as important — what it cannot measure.
What we measure
When you run the test, your browser opens a secure connection to each resolver’s DNS-over-HTTPS (DoH) endpoint and asks it to resolve a series of hostnames. We measure the time between sending the request and receiving the answer. That round trip includes the network path from your device to the resolver plus the resolver’s own time to produce an answer — which is exactly the latency you experience when you browse.
Because the browser reuses one warmed-up connection for the measured lookups, the numbers reflect steady-state resolution latency rather than one-time connection setup.
Why a browser can’t do a “real” DNS benchmark
A native benchmarking tool sends raw DNS packets over UDP on port 53 and times the reply. Web pages cannot open raw UDP or TCP sockets — the browser sandbox forbids it for security. The closest a browser can get is DNS-over-HTTPS, which wraps the same DNS query in an HTTPS request. That adds a thin, consistent layer of HTTPS overhead, applied equally to every resolver, so the comparison between resolvers stays fair even though the absolute numbers run a little higher than a native UDP test would show.
How a single run works
- Warm-up. We send one to three throwaway lookups per resolver to establish the TLS connection. These are excluded from the result so a slow first handshake doesn’t unfairly penalize a resolver.
- Randomized lookups. We request unique, random hostnames (subdomains of the
IANA-reserved
example.com,example.net, andexample.orgdomains). A fresh name forces a genuine lookup instead of a cached shortcut, and no real service receives any traffic. - Repeats. We run several measured lookups per resolver — 4 in Quick mode, 8 in Standard, 16 in Detailed — so a single unlucky packet doesn’t define the score.
- Statistics. We reduce those samples to a median, average, minimum, jitter, and success rate, then rank the resolvers.
The statistics we report
- Median — the middle value, and the best single indicator of typical speed because it ignores outliers.
- Average — the mean; compared with the median it reveals whether slow outliers are present.
- Minimum — the best-case single lookup.
- Jitter — the standard deviation of the samples, i.e. how consistent the resolver is. Lower is better, especially for gaming and video calls.
- Reliability — the percentage of lookups that succeeded.
How results are rated
We label each resolver by its median latency. These thresholds are tuned for browser DoH round trips; edge measurements are faster, and the source is always shown alongside the rating.
| Rating | Median latency |
|---|---|
| Excellent | ≤ 30 ms |
| Good | ≤ 60 ms |
| Average | ≤ 120 ms |
| Slow | > 120 ms |
Two ways to measure: browser vs edge
Browser test (default). Runs from your device against every resolver that has a DNS-over-HTTPS endpoint (34 of them), in two classes:
- Verified — 13 resolvers expose a permissive cross-origin (CORS) endpoint, so we read and confirm the answer. These are the most precise.
- Approximate (≈) — the rest block cross-origin reads, so we send the query with an opaque request and time the round trip. The timing is a real network round trip to that resolver, but the browser will not let us read the response, so we cannot confirm the answer. These are flagged with a ≈ marker and a “round-trip” label.
A handful of resolvers offer no browser-reachable DoH endpoint at all (plain DNS or DoT only); those appear in the reference list but are measured only by the edge test below. All browser numbers reflect your connection.
Edge test (optional). Runs from a Cloudflare Worker, which is not bound by browser CORS rules, so it can measure every resolver with a DoH endpoint over wireformat DoH and read every answer. These numbers reflect the latency from a Cloudflare data center to each resolver, which is typically far lower than a home connection. We label them clearly and never present them as your local latency.
Limitations and sources of noise
- Your Wi-Fi, VPN, browser extensions, and current network load all affect the numbers. Results vary run to run — that’s normal.
- DoH adds a small, uniform HTTPS overhead compared with a native UDP query.
- The authoritative servers for our test domains add a little latency that isn’t the resolver’s fault; using several base domains averages this out.
- A resolver that filters content (malware, ads, family) does a touch more work, which can add a millisecond or two.
- We measure latency, not correctness, censorship, or filtering accuracy.
Privacy of the test
The browser test runs entirely on your device. We do not store your browsing history, the domains you resolve, or your full IP address. Results stay in your browser unless you choose to export or share them. The optional edge test and event counters store only rounded, aggregated, non-identifying data. See the privacy policy for specifics.
Getting the most accurate result
- Close bandwidth-heavy tabs and pause large downloads before testing.
- Prefer a wired connection, or sit close to your router on Wi-Fi.
- Run Standard or Detailed mode, and run it two or three times at different moments.
- Trust the resolver that is consistently fast — low median and low jitter — over a one-time winner.