DNS Speed TestIs your DNS
slowing you down?
Times how quickly 21 public resolvers answer from your own browser, names the fastest in each filtering category, and gives you the addresses to set it. Nothing to install.
No sign-up. Results appear on screen in full — leaving your email for a follow-up is optional.
Reading Your Results
Reading a DNS speed test — what each number means
Most DNS tests report one average and stop. An average hides the thing you actually notice, which is the occasional slow lookup. Here is what this test reports and why each one is on the page.
Cached vs first-time — the gap is the interesting part
Cached lookups use names the resolver already holds, so almost none of the time is work — that figure is effectively your latency to it, mostly a function of distance. First-time lookups use names nobody has ever requested, under 5 large domains hosted by different DNS companies, so the resolver has to ask each domain's own DNS servers instead of answering from memory. A resolver that is physically close but poorly connected upstream looks fast on the first number and slow on the second. Most tools only measure the cached case.
Median, not average
The middle value: half the lookups were faster, half slower. An average moves with every slow lookup. In one of our runs, Cloudflare answered most cached lookups in about 9 ms and a couple in about 30 ms — the average drifted up with those two, while the median stayed at 9 ms, which is what the connection felt like.
95th percentile — the slow tail
Nearly every lookup finished within this time. With 24 cached lookups it is the second-slowest; with 10 it is the slowest. It is the number that matches the moments you notice, because you do not remember the fast ones — in that same run, Cloudflare's median was 9 ms and its slow tail about 30 ms.
Variation between queries
How much each lookup differed from the one before it. Consistent timing matters as much as a low median, because the occasional slow lookup is the one you notice. Each round uses a different site, so this also reflects differences between sites, not only changes over time.
Success rate, shown as a count out of 10
How many lookups actually returned an answer, counted against the column being ranked. This matters more than it looks: public resolvers rate limit bursts, and one that answered a single query still produces a median. Without the count, a lucky sample looks exactly as trustworthy as 10 real ones. Anything under 5 successful lookups is excluded from ranking entirely and says so in place of a time.
12 hostnames, not one
Each cached round queries a different popular domain, and the list is walked 2 times so every name gets a repeat rather than a single lucky or unlucky sample. Repeating one name would measure one cache entry on one server, so a resolver that is quick for google.com and slow for everything else would score perfectly. Expand any row to see the per-hostname timings.
Methodology
DNS speed test methodology, and what it cannot see
Every speed test makes choices that change its results. Most bury them. Here are ours, including the things this test genuinely cannot measure — a tool that hides its limits is not one you should trust with a decision.
How it measures
- Runs entirely in your browser over DNS-over-HTTPS (RFC 8484 wireformat). Browsers cannot send UDP on port 53, so these figures sit above what a desktop tool reports — every resolver is measured the same way, so the comparison holds even though the absolute numbers do not match a port 53 benchmark.
- Twelve different widely-used hostnames for cached timing, one per round, rather than the same name repeatedly.
- First-time timing uses randomly generated names under 5 large domains, each hosted by a different DNS company: microsoft.com (Azure DNS), amazon.com (Amazon Route 53), wikipedia.org (Wikimedia), ebay.com (NS1 and eBay), and adobe.com (Akamai). No resolver has those names stored, so each has to ask that domain's own DNS servers, and every resolver gets the same mix of domains. The domains are unsigned, so no resolver can answer a made-up name from cached DNSSEC proofs. Endpoints that run on the same servers, such as Control D's five, share these lookups — querying each one separately got the test rate limited.
- Every answer is checked, not just received. When a filtering resolver blocks one of the test sites, that lookup is marked blocked and left out of its times rather than counted as a fast answer, and the row lists what it blocked.
- Each lookup is timed to the moment the resolver responds; the answer is then checked before the time is kept, so a server that delivers its reply in two steps is not penalised for it.
- Every resolver is queried in the same instant each round, so a momentary network stall lands on all of them equally instead of penalising whichever happened to go first.
- Rounds are spread across the whole run rather than fired in a burst, so the result samples a window of time instead of one instant — and is less likely to trip rate limiting.
- A resolver that returned too few answers is excluded from ranking rather than ranked on a lucky sample, and its row says why: no readable response, turned away as too many, errors, or too few answers.
- Resolvers whose results cannot be told apart are shown as tied: their medians are within 5 ms or 10% of each other, or, compared round by round, neither was faster often enough to rule out chance — with ten rounds side by side, one has to win at least nine. A gap that small changes from one run to the next, so naming a single winner would be a coin flip.
- Ad and tracker blocking, and Control D's social-media blocking, were checked by us directly. Malware and adult-content claims are what the operator states, and are labelled separately — this tool does not audit blocklists.
What it cannot see
- Only resolvers whose DoH endpoint permits cross-origin requests can be measured at all. AdGuard, OpenDNS and NextDNS answer normally but send no CORS header, so a browser cannot read their responses; they are listed with their addresses under the results. Mullvad, Wikimedia and CIRA Canadian Shield have the same limit and are not listed.
- Quad9 usually cannot be timed from a browser. After its first couple of answers, browsers switch to Quad9 over HTTP/3, and Quad9's HTTP/3 servers leave out the header a browser needs before a page may read a reply — so every later answer arrives but cannot be read. That is a Quad9 issue, not your network. Quad9 works normally when set on a device or router.
- It does not measure the resolver your own computer or router is set to use. Browsers do not reveal which one that is, and timing it needs a test server this site does not have yet — so the results compare public resolvers only.
- First-time lookups use made-up names under 5 large domains hosted by different DNS companies. They show how quickly each resolver reaches those DNS hosts — a fair stand-in for a first visit to a site, not a measurement of every site.
- Nothing inside your building is visible. Wi-Fi signal, switches, and cabling all sit past where a browser can see, and they cause far more everyday slowness than DNS does.
- No ICMP ping, jitter, or packet loss. Browsers cannot send ICMP at all, and the honest alternative needs a dedicated endpoint that is not deployed yet.
- One measurement, from one browser, at one moment. Response times shift with location, time of day, and the network you are on — re-run it a few times before drawing conclusions.
What this test measures
- Cached response timeHow quickly each resolver answers for a name it already holds in memory.
- First-time lookupsTiming for names never requested before, so the resolver has to look them up rather than answer from memory.
- How your domain is publishedOptional. Nameserver redundancy, DNSSEC signing, and certificate issuance policy on a domain you own.
- Resolver behaviorWhether four major public resolvers reject a deliberately invalid DNSSEC signature and agree with each other. These describe the resolvers, not your connection, so they do not count toward the grade.
Every result says what it means and what it does not, including when a measurement could not be completed.
Does this measure my connection or your server?
Yours. The measurements run in your browser and travel over your own network, router, and internet connection. The only parts handled by our server are checks on how a resolver or a domain behaves, which give the same answer no matter who asks.
What does DNS speed actually change?
DNS is the lookup that turns a name into an address. It happens once before a site starts loading, so a slow resolver shows up as a pause before anything appears — which reads as a slow connection even when the connection is fine. What it will not change is your bandwidth. If large downloads crawl or video buffers midway through, DNS is not the cause and switching resolvers will not help.
Is this measuring latency, or how long the lookup takes?
Both, and the two columns separate them. Every figure is the complete round trip from your browser: the time to reach the resolver, plus whatever work it does, plus the time for the answer to come back. The "cached" column uses names the resolver already holds in memory, so almost none of it is work — that figure is effectively your latency to that resolver, and it is mostly a function of distance. The "first-time" column uses names nobody has ever asked for, which makes the resolver ask the domain's own DNS servers, so it adds the resolution work on top. A resolver that is close but poorly connected shows a fast cached time and a slow first-time one.
Why are these numbers higher than my old DNS benchmark tool?
Desktop tools query resolvers over plain UDP on port 53. A browser cannot do that, so this test uses DNS-over-HTTPS, which adds encryption and HTTP overhead on top of the lookup. Every resolver is compared under identical conditions, so the ranking is meaningful even though the absolute numbers sit higher than a desktop tool would report.
Can it measure ping, jitter, and packet loss?
Not yet. Browsers cannot send ICMP ping packets at all, and the honest alternative — measuring real UDP round trips the way a game does — needs a dedicated endpoint we have not deployed. When it exists, this page will report round-trip time, jitter, and packet loss alongside the DNS results.
Should I change my DNS resolver based on this?
Only after thinking it through. A faster resolver reduces the wait before a new site starts loading; it does not increase bandwidth. On a business network the resolver often handles internal names, filtering, or split-DNS, so changing it can break things that have nothing to do with speed.
Why isn't NextDNS, AdGuard, or OpenDNS in the list?
Because a browser cannot read their answers, not because they were overlooked. A page is only allowed to read a response from another domain when that domain returns a CORS header granting permission. NextDNS, AdGuard, OpenDNS and Mullvad all answer the query normally — the page can send it, but it is never allowed to read the answer, so it cannot tell a real answer from an error, and an unconfirmed time is not worth ranking. Every resolver on this page was re-checked on 26 September 2026, and the ones above are the ones that permit it. NextDNS has a second obstacle: its filtering is configured per account, so two people using it would get different blocking and there would be no fixed profile to categorise or fairly rank. If you use one of these, the honest way to compare is a desktop tool that queries port 53 directly.
Why does Quad9 say its replies can't be read?
Because of a problem on Quad9's side, not yours. Quad9 advertises HTTP/3, so after the first couple of answers your browser switches to it — and Quad9's HTTP/3 servers leave out the header a browser needs before a page is allowed to read a reply. Every later answer arrives, but the browser will not hand it to the page, so there is nothing to time. Cloudflare and Google switch to HTTP/3 the same way and keep working, because they send the header. Quad9 itself works normally when you set it on a device or router; it is only this kind of browser measurement it breaks.
Why did a resolver show "no response"?
Nothing came back that this browser could read, which is a different result from being slow. Common causes are a VPN, a privacy extension, a filtering appliance, or the resolver being unreachable at that moment. It is reported as no response rather than scored as slow.
Why does a resolver say it was rate limited?
Because it turned some of this test's lookups away as too many — it answered with a "too many requests" error instead of an answer. Public resolvers limit how many lookups for made-up names they accept from one address in a short time, as a defence against a common attack, and this test deliberately asks for made-up names. It is a fact about the test, not about your connection or the resolver's everyday speed, so it is reported rather than scored as slow. Running the test again a minute later usually clears it.
Why does it say it cannot measure my current resolver?
Because this version does not measure it yet. Browsers do not reveal which resolver a computer uses, and timing it needs a test server we have not deployed. Until then, the results compare public resolvers only, and the page says so instead of guessing.
Do you store my results?
Not unless you ask us to follow up. Results are calculated in your browser and shown there. If you leave your email, we store it with a short summary of the findings so our team can get back to you. See the privacy policy for the detail.
Everything looks fine but my internet still feels slow. What now?
That is useful to know, not a dead end. A clean result rules out slow DNS from this browser right now. It does not test bandwidth, packet loss, or your Wi-Fi signal, switches and cabling — and those cause far more everyday slowness than DNS does. Calling us at (580) 448-0440 is a reasonable next step.
Built and maintained by Distributed Network Solutions. Call (580) 448-0440 if you want someone to read the results with you.