Explainer

What DNS latency actually costs you

DNS resolution happens before a connection is made, so it is invisible to every download-speed test — and for the same reason it is often smaller than people expect.

Where the time goes

Opening a page begins with turning a hostname into an address. If your resolver already has the answer cached, that takes a few milliseconds. If it does not, the resolver walks the hierarchy — root, top-level domain, then the domain’s own name servers — which can take tens or occasionally hundreds of milliseconds. Only then does the browser open a connection.

A modern page pulls resources from several hostnames, so a page load can involve a handful of lookups. Most of them hit a cache somewhere: your browser’s, your operating system’s, your router’s, or your resolver’s. The uncached case is the exception, not the rule — which is exactly why our benchmark separates a cached lookup from an uncached one instead of reporting a single blended figure.

The honest size of the effect

Suppose you switch to a resolver that is 20 ms quicker on cached lookups. On a page needing four uncached lookups you might save something under 100 ms on first visit, and close to nothing on subsequent visits because the answers are already cached locally. That is a real improvement in responsiveness and it is worth having. It is not the difference between a slow connection and a fast one.

The cases where DNS genuinely dominates are more specific: a resolver that is failing and forcing retries; a resolver so distant that every uncached lookup costs hundreds of milliseconds; or a resolver with high variability, where the occasional two-second stall is what you actually notice. Consistency usually matters more to the felt experience than the median does — which is why the benchmark reports spread alongside every median rather than a single number.

What DNS latency is not

It is not bandwidth. No amount of DNS tuning changes how fast bytes arrive once a connection is open. A speed test measures throughput after resolution has already happened.
It is not your ping to a game server. Game latency is the round trip to the server during play. DNS is involved once, at the start.
It is not fixed. The same resolver measured twice on the same connection will give different numbers depending on cache state, congestion, radio conditions and which of the provider’s sites you reach.

TTL: why the same lookup is fast the second time

Every DNS answer carries a time-to-live telling caches how long they may keep it. A record with a one-hour TTL will be served from cache for up to an hour without any resolver being contacted at all. This is why a benchmark that only measures cached lookups flatters every resolver equally, and why one that only measures uncached lookups reports a number you rarely experience. Both are worth knowing; neither on its own is “your DNS speed”.

Why our numbers are not your operating system’s numbers

The benchmark on this site measures HTTPS requests from your browser to a provider’s DNS-over-HTTPS endpoint. When you configure a DNS server in Windows, macOS or your router, you are normally configuring that provider’s classic service on UDP/TCP port 53. Those are different endpoints with different network paths, different caches and, in the DoH case, a TLS session your browser may already have open from a previous request.

The two are usually correlated, because they are the same provider’s anycast network. They are not the same measurement, and we do not present them as one. If you need port-53 numbers specifically, a native tool that queries port 53 directly is the right instrument — a web page cannot do it, because browsers cannot open arbitrary UDP sockets.

A sensible way to use the results

Run the benchmark more than once, at different times of day. A single run tells you about one moment on one network.
Ignore differences smaller than the spread shown next to each median. The tool labels statistically indistinguishable resolvers as tied for exactly this reason.
Weigh consistency and success rate alongside the median. A resolver that answers every time in 30 ms is usually preferable to one averaging 20 ms with occasional failures.
Consider filtering and privacy policy as first-class criteria, not tie-breakers. They affect your experience far more than a few milliseconds will.

Last reviewed 2026-08-15. Provider configuration comes from RESOLVER-REGISTRY.json, which records the official source and verification date for every entry.