Run test

Free DNS speed test

Measure how fast each public DNS resolver answers from your own connection, then see the fastest, most reliable option for you. No account, nothing stored.

DNS Speed Test

Each resolver is queried 8 times (plus 2 warm-up, excluded) — more lookups give a steadier, more accurate median but take longer. Measures 34 resolvers in your browser: verified where the resolver allows it, otherwise an approximate round trip.

Runs entirely in your browser. We measure how quickly each resolver answers a fresh lookup over encrypted DNS-over-HTTPS — no downloads, no account, nothing stored.

How to read your results

Each resolver is scored on five numbers. Here is what they mean and which to trust.

Median
The middle latency across all lookups. It ignores the occasional slow outlier, so it is the single best number for “how fast is this resolver, usually.”
Average
The mean of every lookup. Useful alongside the median — if the average is much higher, a few slow responses are dragging it up.
Minimum
The fastest single lookup — a resolver’s best case when everything lines up.
Jitter
How much the times vary (standard deviation). Low jitter means consistent, predictable responses — which matters more than raw speed for gaming and calls.
Reliability
The share of lookups that succeeded. A resolver that is fast but occasionally fails is worse than one that is slightly slower but always answers.

Resolver features at a glance

Speed is only half the decision — here is what each resolver offers.

Feature comparison of public DNS resolvers
Provider Primary DNS No logsDNSSECMalwareAdsFamily
Cloudflare DNS 1.1.1.1 Yes Yes No No No
Cloudflare for Families 1.1.1.3 Yes Yes Yes No Yes
Google Public DNS 8.8.8.8 No Yes No No No
Quad9 9.9.9.9 Yes Yes Yes No No
OpenDNS 208.67.222.222 No Yes Yes No Yes
AdGuard DNS 94.140.14.14 Yes Yes Yes Yes No
CleanBrowsing 185.228.168.9 Yes Yes Yes No Yes
Control D 76.76.2.0 Yes Yes Yes Yes Yes
Alternate DNS 76.76.19.19 Yes Yes No Yes No
AliDNS 223.5.5.5 No Yes No No No
DNSPod Public DNS 119.29.29.29 No No No No No
DNS.SB 185.222.222.222 Yes Yes No No No
Mullvad DNS 194.242.2.2 Yes Yes No No No
360 Secure DNS 101.226.4.6 No No Yes No No
Restena Public DNS 158.64.1.29 Yes Yes No No No
DNS4EU (Protective) 86.54.11.1 No Yes Yes No No
UncensoredDNS 91.239.100.100 Yes Yes No No No
LibreDNS 116.202.176.26 Yes Yes No Yes No
dns0.eu 193.110.81.0 Yes Yes Yes No No
NextDNS 45.90.28.0 Yes Yes Yes Yes Yes
Digitale Gesellschaft 185.95.218.42 Yes Yes No No No
SWITCH Public DNS 130.59.31.248 No Yes Yes No No
Comcast Xfinity DNS 75.75.75.75 No Yes No No No
CIRA Canadian Shield 149.112.121.20 No Yes Yes No No
DNS for Family 94.130.180.225 No Yes Yes Yes Yes
Yandex DNS 77.88.8.8 No No No No No
Level 3 / Lumen (4.2.2.x) 4.2.2.1 No No No No No
Vercara UltraDNS Public 64.6.64.6 No Yes No No No
Comodo Secure DNS 8.26.56.26 No No Yes No No
Hurricane Electric DNS 74.82.42.42 No No No No No
DNS.WATCH 84.200.69.80 Yes Yes No No No
Quad101 101.101.101.101 Yes Yes No No No
DNSforge 176.9.93.198 Yes Yes Yes Yes No
FDN (French Data Network) 80.67.169.12 Yes Yes No No No
BlahDNS 78.46.244.143 Yes Yes Yes Yes No
Tiarap 174.138.21.128 Yes Yes Yes Yes No
Freifunk München (ffmuc) 5.1.66.255 Yes Yes No No No
Nawala ChildProtection 180.131.144.144 No No Yes No Yes
SafeDNS 195.46.39.39 No No Yes No Yes
Gcore Public DNS 95.85.95.85 Yes No No No No
CZ.NIC ODVR 193.17.47.1 No Yes No No No
OpenBLD DNS DoH only No Yes Yes Yes No
IIJ Public DNS DoH only Yes Yes No No No
Applied Privacy DoH only Yes Yes No No No
RethinkDNS DoH only Yes No No No No
Comss.one DNS 83.220.169.155 No Yes Yes Yes No
FlashStart 185.236.104.104 No No Yes No Yes

Cached vs uncached lookups

Every lookup this test times is one no resolver has ever seen before, and that is deliberate.

Ask a resolver for a domain it answered a moment ago and it hands back the stored answer from memory. No recursion, no trip to the domain’s authoritative servers, no real work — just a copy of a record it already holds, returned in roughly the time the network takes to carry it. Time that and every resolver on earth looks the same, because you are not measuring the resolver at all. You are measuring the wire between you and it.

So the test never asks the same question twice. Each lookup uses a freshly generated hostname — a random label under example.com, example.net, or example.org, the domains IANA reserves for exactly this sort of use. Nothing is repeated within a run, no resolver holds the answer, and no real service receives your traffic. We rotate between the three base domains as well, so one slow authoritative server does not colour a whole run.

What is left is the uncached path: your device to the resolver, the resolver’s work to find an answer it does not have, and the answer back. That is the number that decides how a site feels the first time you open it — the pause before anything appears on screen. One honest caveat: after the first lookup of a run, the resolver already has example.com’s nameservers in its own cache, so what we time is its hop to the authoritative server rather than a full walk down from the root. That is the same shortcut a genuinely cold lookup takes for any popular domain, which is what makes it the fair comparison.

The warm-up lookups exist for the same reason in reverse. One to three throwaway queries per resolver open the TLS connection first — one in Quick mode, two in Standard, three in Detailed — and they are thrown away before the maths starts, so a one-off handshake is never charged to a resolver’s score. Every counted lookup is a cold cache over a warm connection. That is the only combination that tells you anything.

Tail latency: why the slowest 5% decides how fast the web feels

A resolver with a good median and a bad tail feels worse than its headline number suggests, because a web page does not perform one lookup — it performs dozens.

The median is the middle of your samples: half the lookups came back faster, half slower. It is the best single answer to “how fast is this resolver, usually”, and it is what we rank on. But “usually” is not what you experience. Opening one modern page fires lookups for the site itself, its CDN, its fonts, its analytics, its embedded video, its consent and ad providers — often twenty to fifty distinct names. The page is not ready when the median lookup finishes. It is ready when the last one does.

That last one lives in the tail: the slowest few per cent. A resolver that answers in 18 ms nine times out of ten and stalls at 300 ms on the tenth has a lovely median and a browsing experience full of small, unexplained hesitations. A resolver that answers in 30 ms every single time has a worse median and feels faster. Cost you can predict disappears into the background; cost you cannot does not.

We do not publish a literal p95, and that is honesty rather than an omission. A run collects 4, 8, or 16 measured samples, and a 95th percentile drawn from eight numbers is just the slowest of the eight wearing a statistical hat. Instead the tail is reported in three readable pieces: jitter, the standard deviation of the samples, which climbs the moment a resolver turns inconsistent; the gap between the average and the median, which widens when slow outliers drag the mean upwards; and the slowest single sample, carried in the CSV and JSON exports.

Read them together. A low median, low jitter, and an average sitting close to the median describe a resolver that will be fast every time you touch it. A low median with high jitter and an average well above it describes a resolver that is fast on paper and occasionally makes you wait — and the waiting is the part you actually notice. When two resolvers finish within a few milliseconds of each other on the median, take the steadier one.

Why we test more resolvers than anyone else

The registry behind this test holds 47 public DNS resolvers, and that is not completeness for its own sake — it is that the fastest resolver for you may not be one of the famous four.

Most DNS speed tests ship a shortlist: Cloudflare, Google, Quad9, OpenDNS, and perhaps two more. That is a reasonable default if you live in a large city on a major network, where the big anycast operators keep a point of presence nearby and win on distance alone. It is a poor default anywhere else. In Prague, Taipei, Vienna, Luxembourg, or Munich, a national registry’s resolver or a non-profit two hops away can beat a global giant outright — and you will never find that out from a list of five.

So the list includes them: CZ.NIC’s ODVR, Quad101 from Taiwan’s TWNIC, Restena in Luxembourg, FDN and Freifunk München, Digitale Gesellschaft in Switzerland, DNS4EU and dns0.eu across the EU, IIJ in Japan, AliDNS and DNSPod in China — alongside the household names and the filtering specialists such as AdGuard, Control D, NextDNS, and CleanBrowsing. Twenty-six filtered variants are documented too (family, malware, ad-blocking, unfiltered), so you can point at the tier you actually want instead of the default one.

Not all 47 can be timed the same way, and we do not pretend otherwise. 34 have a DNS-over-HTTPS endpoint a browser can reach, so those are measured live from your own connection. 13 of them serve permissive cross-origin headers, which lets us read and confirm each answer — those are marked verified. The rest are timed as opaque round trips: the milliseconds are real, the response cannot be read, and they carry a ≈ to say exactly that. The remaining resolvers are plain-DNS or DoT-only and appear in the reference tables rather than the ranking.

Breadth costs you almost nothing, since the test measures resolvers in parallel a few at a time. Occasionally it hands you a winner you would never have thought to try.

What to do once you have a winner

A ranking is only worth having if you act on it, and acting on it takes about four minutes on most devices.

Start with the addresses. Take the primary and secondary of whichever resolver finished top, and use both from the same provider — mixing two providers works, but it complicates troubleshooting and buys you nothing. Every address is listed on the public DNS servers reference at /public-dns-servers, and the CSV and JSON exports carry the primary for each ranked resolver, so you can copy rather than retype.

Then pick your device. Windows 10 and 11 is /guides/change-dns-windows. macOS is /guides/change-dns-macos. iPhone and iPad is /guides/change-dns-iphone. Android is /guides/change-dns-android, which uses Private DNS and wants a hostname rather than an IP address. Linux is /guides/change-dns-linux, and Chromebooks are /guides/change-dns-chromebook.

Setting it on the router is usually the better move: it covers every device on the network at once, including the ones with no DNS setting of their own. The general walkthrough is /guides/change-dns-router, with brand-specific steps for ASUS at /guides/change-dns-asus-router, Netgear at /guides/change-dns-netgear-router, and TP-Link at /guides/change-dns-tp-link-router. If a firewall does your routing, use /guides/change-dns-pfsense or /guides/change-dns-opnsense.

Consoles have their own path and it is worth taking: /guides/change-dns-ps5 and /guides/change-dns-xbox shorten how long the store, downloads, and game services take to resolve — though not your ping inside a match, which DNS never touches. If you run Pi-hole, you are choosing an upstream rather than a resolver for your devices, and /guides/change-dns-pihole covers where that setting lives and why it only shows up on a cache miss.

Whatever you change, run the test again afterwards from the same connection. The winner should still be the winner. If the numbers barely moved, DNS was not your bottleneck — which is worth knowing too, and cheaper to learn now than after you have changed the setting on nine devices.

What a DNS speed test cannot tell you

It is a narrow measurement, and it is far more useful once you know exactly where its edges are.

It is not a bandwidth test. A faster resolver shortens the pause before a page begins loading; it does not add a megabit to your connection, and it cannot speed up a large download, a video stream already playing, or a site that is slow because its own servers are slow. If a page takes eight seconds to render, DNS was perhaps thirty milliseconds of that. Changing resolver will not find you the other 7.97 seconds.

It is not a raw UDP benchmark. Browsers are not allowed to open raw sockets on port 53, so we time DNS-over-HTTPS instead. That wraps the same query in an HTTPS request and adds a thin, uniform layer of overhead — applied equally to every resolver, so the comparison between them stays fair, but the absolute numbers sit a little above what a native tool on the same machine would report. Compare resolvers against each other here, not our milliseconds against a desktop benchmark’s.

It cannot tell you a resolver’s cache hit rate for everyone else. We force a cache miss deliberately, because that is the only way to compare resolvers on equal terms, but it means the test says nothing about how often a given resolver already holds the popular domains you will actually visit. A resolver serving millions of people carries a warmer cache than these numbers imply — real speed that you will get and we will not show you.

It is a snapshot of one moment. Wi-Fi contention, a VPN, a busy uplink, a congested path, or a resolver having a bad ten minutes all move the result. Run it two or three times at different points in the day and trust whichever resolver keeps winning, not the one that won once.

And it measures latency only — not whether a resolver answers correctly, what it blocks, whether it honours the privacy policy it publishes, or how it behaves during an outage. Speed is one input into that decision. The feature comparison above, the privacy note on each resolver’s page, and the methodology page cover the rest.

Set your winner on any device

DNS speed test — questions

How long does the DNS speed test take?

A Quick test is over in a few seconds — 4 measured lookups per resolver. Standard runs 8 and Detailed runs 16, testing four resolvers at a time across every resolver with a browser-reachable DoH endpoint, so even Detailed usually finishes inside a minute. Each mode also fires one to three warm-up lookups per resolver that are thrown away, so a slow first TLS handshake doesn't unfairly punish anyone.

What is DNS-over-HTTPS, and why does this test use it?

DoH wraps an ordinary DNS query inside an encrypted HTTPS request, so it travels over port 443 like any other web traffic instead of plain UDP on port 53. It is the only kind of DNS query a web page is allowed to send, so it is what this test times. It adds a thin layer of HTTPS overhead — applied equally to every resolver, so the comparison between them stays fair even though the absolute numbers run a little higher than a native UDP test would show.

Why can't a browser measure raw UDP DNS on port 53?

The browser sandbox forbids web pages from opening raw UDP or TCP sockets, for security reasons that no site can work around. That means a browser cannot send the same packet your operating system sends when it resolves a name, and any tool claiming otherwise is not doing what it says. DoH is the closest honest substitute, and we label it as such rather than dressing it up as a port 53 benchmark.

How are results marked "verified" versus "≈ round-trip"?

Resolvers that allow cross-origin reads let us read and confirm each DNS answer — those are marked verified, and they are the most precise numbers here. The rest block cross-origin reads, so we send the query as 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 and flag it with a ≈.

Resolvers with no browser-reachable DoH endpoint at all are never given a browser number. They appear in the reference list and in the optional edge test only.

Does the test measure cached or uncached lookups?

Every measured lookup is deliberately uncached. We request a fresh random subdomain of the IANA-reserved example.com, example.net, and example.org domains, so no resolver can answer from its cache and each one has to do the real work of resolving a name it has never seen. That makes this a cold-lookup comparison — the case where a resolver's speed actually matters. In everyday browsing most lookups hit a cache somewhere and come back in well under a millisecond, so your typical experience is faster than these numbers.

Why do my results change every time I run the test?

DNS latency reflects whatever your network is doing at that second — Wi-Fi interference, a background download, VPN overhead, browser extensions, and the resolver's own load all move the numbers. Each run also uses a modest number of samples, so one unlucky packet shifts a median more than you would expect. That variation is normal and we would rather show it than smooth it away. Run the test two or three times at different moments and look for the resolver that keeps landing near the top.

Can I trust the ranking?

It reflects real latency measured from your own connection at the moment you tested, using several randomized, uncacheable lookups to cut down the noise — not numbers gathered somewhere else and reprinted. What it cannot tell you is how the same resolver behaves at a different hour, on a different network, or from a different city. When the top two medians are within about 5 ms we call them effectively tied, because a gap that small is inside normal noise.

Does a faster DNS server make my downloads faster?

No. DNS only translates a hostname into an IP address before a connection is opened, so a faster resolver shortens the brief pause before a page starts loading — most noticeable the first time you visit a site. It does nothing for your download or upload bandwidth, your speed-test figures, or a website that is slow for its own reasons. If you are chasing throughput, DNS is the wrong lever.

What does jitter mean, and does it matter for gaming?

Jitter here is the standard deviation of the measured lookups — how tightly a resolver clusters around its own median, not how fast it is. Low jitter means predictable answers, which is why the gaming recommendation weighs consistency alongside median instead of just crowning the fastest median. Be clear about the limit, though: DNS jitter is not your in-game ping. Once you are connected to a game server, DNS is out of the loop entirely — it affects the lookups around a session, not the packets during it.

Do you report p95 or tail latency?

Not on the results table, which shows median, average, minimum, jitter, and reliability. A run collects between 4 and 16 samples per resolver, and that is far too few for a p95 to mean anything — a percentile taken from 8 numbers is just the second-slowest sample wearing a statistician's hat. Jitter, and the gap between the average and the median, are the honest stand-ins: if the average sits well above the median, something is occasionally stalling. The CSV and JSON exports do include each resolver's slowest sample if you want to inspect the tail yourself.

Should I use the fastest resolver or the most consistent one?

Take the most consistent one whenever the two differ. A resolver at a 22 ms median with 3 ms of jitter will feel better than one at 19 ms with 15 ms of jitter, because the second one stalls now and then and you notice the stalls, not the average. Sort by "Most consistent" to rank on jitter, and glance at reliability while you are there — a failed lookup costs a full retry, which wipes out any few-millisecond win.

Is my ISP's DNS ever the fastest option?

Often, yes. Your ISP's resolver usually sits inside its own network, a hop or two away, so it can genuinely beat a public resolver on raw latency — the trade-offs are that it may log your queries, filter results, or hijack failed lookups into a search page.

This test cannot measure it, and we will not pretend otherwise. ISP resolvers almost never publish a DoH endpoint a browser can reach, so yours is not in the ranking. To compare it head to head you need a native tool that can send plain DNS on port 53.

Does the test cover IPv6?

Not as a separate measurement. The test connects to each resolver's DoH hostname, and your operating system and browser decide whether that connection runs over IPv4 or IPv6 — we do not control the choice and cannot see which one was used. So each result means "this resolver, over whatever path your device picked", not an IPv4-versus-IPv6 comparison. The reference tables do list every resolver's IPv6 addresses if you want to configure them.

Is a faster DNS server safe and private?

Switching resolvers does not expose you to anything new — it changes who sees your lookups, moving that view from your ISP to the operator you choose. That is a real decision: some keep no query logs, some block malware or ads, and some share part of your IP address with authoritative servers to improve CDN routing. The comparison table sets out each resolver's stated policy and features so you can weigh them. Note the boundary, though — we measure latency, not honesty, and we have not audited anyone's privacy claims.

How does this compare with a desktop tool like GRC's DNS Benchmark?

It measures a slightly different thing, not a lesser one. Native tools like GRC's DNS Benchmark or namebench send raw UDP on port 53, which is closer to how your operating system actually resolves names, and they can test your ISP's resolver and plain-DNS-only servers that no browser can reach. This test times encrypted DoH requests from your browser, which carries a small, uniform overhead but installs nothing and covers a lot of resolvers in seconds. If the decision matters to you, run both and see whether they agree.

What should I do once I have a winner?

Run the test once or twice more at a different time of day and confirm the same resolver keeps winning, rather than acting on a single run. Then set it — changing DNS on your router covers every device at once, while setting it per device is quicker to undo if something misbehaves; the setup guides walk through both. Keep the resolver's secondary address configured as a fallback, and remember that plain DNS is unencrypted — if that matters to you, set it up over DoH or DoT instead.