There is a simple way to compare DNS servers.
Send the same query to several resolvers, measure the response time, and pick the one with the lowest number.
It sounds reasonable.
It is also incomplete.
A DNS resolver does more than answer a domain lookup. For many websites and online services, the answer it provides can influence which server or CDN edge your device connects to next.
That creates an unusual situation:
A DNS resolver can be faster at answering DNS queries while producing a slower overall path to the content.
This is one reason the phrase “fastest DNS” needs more explanation.
DNS speed is only the first measurement
When your browser needs to visit a domain, it first needs an IP address.
The DNS resolver handles that lookup.
If the resolver already has the answer cached, it may return it very quickly. If the answer is not cached, it has to perform additional queries through the DNS hierarchy before responding.
Google explains that DNS performance depends on several factors, including the network distance between the user and resolver, cache misses, packet loss, and the time required for the resolver to communicate with authoritative name servers.
That means a DNS benchmark is measuring a very specific part of the connection.
It tells us how quickly the resolver answered.
It does not automatically tell us how quickly the website itself will respond.
That distinction becomes important when CDNs enter the picture.
What happens after DNS?
Large websites rarely depend on one physical server.
They commonly use content delivery networks, or CDNs, which distribute content across servers in different geographical locations.
A visitor in Asia might be served from an Asian edge location. A visitor in Europe might receive content from a European location.
DNS can be involved in deciding which address the user receives.
Google’s Public DNS documentation explains that some CDN providers return an IP address based on the network location of the DNS resolver. If the resolver is far away from the user, this can potentially produce a less suitable CDN destination.
This creates a chain that looks roughly like this:
Your device → DNS resolver → DNS answer → CDN edge → website content
A normal DNS benchmark measures the second step.
The user experiences the entire chain.
That is why the two measurements can disagree.
A faster resolver can produce a worse result
Imagine two hypothetical resolvers.
Resolver A answers the DNS query in 8 ms.
Resolver B answers it in 15 ms.
At first glance, A wins.
But suppose A sends the user to a CDN server that is 90 ms away over the network.
Resolver B takes 7 ms longer to answer but directs the user to a CDN edge only 35 ms away.
The extra DNS time from B may be insignificant compared with the difference in the subsequent network path.
This is a simplified example, not a claim about a particular provider.
But the underlying mechanism is real.
A 2025 study specifically examined the interaction between public DNS resolvers and major CDNs. The researchers measured both DNS resolution latency and the latency between users and the CDN edge selected through each resolver. They found that the results could differ significantly depending on the resolver and CDN combination.
That finding changes how a “fastest DNS” test should be designed.
The resolver does not always know exactly where you are
There is another technical problem.
Suppose you are physically in Lahore, but your DNS query reaches a resolver location somewhere else.
A CDN authoritative DNS server may see the resolver’s location rather than your exact location.
It can then make a decision based on the wrong geographical reference point.
Google explains this problem in its Public DNS documentation and notes that it deploys resolvers globally to reduce the distance between users and DNS infrastructure. It also supports EDNS Client Subnet (ECS) for compatible domains, allowing part of the client’s network information to be passed to authoritative servers so they can make more location-aware decisions.
ECS is not simply “better DNS.”
It is a mechanism for providing more information to the authoritative DNS infrastructure.
And it also introduces a privacy consideration because part of the client’s network information can be included in the DNS process.
So even something as apparently simple as “where should this website send me?” can involve several technical trade-offs.
Anycast helps, but it doesn’t solve everything.
Large public DNS providers use globally distributed networks and anycast routing.
Cloudflare says 1.1.1.1 operates across hundreds of cities. Google says its Public DNS addresses are advertised from locations across its global network, with routing intended to send queries toward nearby serving locations.
This is one reason public DNS can perform well for users around the world.
But “global network” does not mean every user gets identical performance.
Routing between your ISP and the resolver still matters.
Google’s documentation specifically notes that the network distance between the client and resolver contributes directly to DNS resolution speed and that suboptimal routing can cause a query to be handled farther away than expected.
So two people using the same DNS address can experience different results.
Cache performance changes the picture again.
Caching is one of the biggest reasons DNS benchmarking is more complicated than it looks.
If a resolver already knows the answer, it can respond without performing the full recursive process.
Cloudflare explains that cache availability is one of the major factors determining resolver speed. Its infrastructure uses distributed caching and other techniques to reduce the amount of work required for repeated queries.
A popular domain may therefore produce a very different result from a relatively obscure domain.
This means a benchmark that tests only a handful of famous websites can accidentally measure how well a resolver serves those particular cached names.
It does not necessarily represent DNS performance across the wider internet.
Google recommends testing more than 5,000 domains when conducting serious Public DNS performance measurements because a larger sample reduces the influence of network variability and gives the resolver’s cache a more realistic workload.
That is a useful lesson for anyone testing DNS at home.
DNS and CDN performance can disagree
The 2025 research is particularly interesting because it did not stop at DNS resolution.
The researchers compared public resolvers including Cloudflare, Google, OpenDNS and Quad9 and examined both DNS latency and the quality of the resulting CDN mappings.
Their results were not consistent across every provider.
Google and OpenDNS were found to perform closer to ISP resolvers in CDN client-to-edge latency, while the study found a penalty for Cloudflare with Akamai and noticeable penalties for Quad9 with several of the CDNs examined. The researchers also found IPv6-related performance penalties in some locations.
This does not mean one of these providers is universally bad.
Quite the opposite.
It demonstrates why universal DNS rankings are difficult to defend.
A resolver’s performance depends partly on what you are trying to reach.
The same resolver can behave differently across different CDNs.
This is why DNS benchmarks can disagree
You may see one benchmark rank Cloudflare first.
Another may show a different result.
That does not automatically mean one benchmark is fake.
They may be testing different things.
One might measure:
DNS query latency
Another might measure:
cached DNS latency
Another might measure:
uncached recursive resolution
Another might measure:
CDN edge latency
And another might measure:
real website loading time
These are related measurements, but they are not interchangeable.
Calling all of them “DNS speed” creates confusion.
What should a real DNS test measure?
If the goal is to determine which DNS resolver is actually useful for a particular connection, I would separate the test into several layers.
Layer 1: DNS resolution
Measure:
- median lookup time
- slowest normal queries
- failure rate
- cached responses
- uncached responses
Layer 2: Resolver location
Determine where the resolver is actually handling the query.
Google provides an NSID mechanism that can identify the serving metro for Public DNS queries.
Layer 3: CDN destination
Check which IP addresses different resolvers return for the same CDN-backed domains.
Then determine where those destinations are located and how far they are from the user.
Layer 4: Actual network performance
Measure the connection to those destinations.
That gives us a much more useful picture than simply asking which DNS server answered first.
What this means for Cloudflare, Google and Quad9
It would be tempting to take the research and turn it into another provider ranking.
That would miss the point.
Cloudflare has an enormous global network and emphasizes resolver speed and cache performance.
Google operates a globally distributed Public DNS service and has invested heavily in resolver placement and location-aware CDN behavior.
Quad9 has a different focus, combining public DNS resolution with security filtering.
None of those facts tells us which resolver will produce the best result for every person.
The useful question is much narrower:
Which resolver works best for this network and these destinations?
The surprising lesson
The most interesting thing about DNS is that the fastest part of the process can sometimes be the least important part.
Saving 10 ms on DNS resolution is not particularly useful if the resulting connection takes a much longer route to the content.
This does not make DNS latency irrelevant.
It simply puts it in context.
DNS is the beginning of a chain.
A good resolver should answer reliably and quickly, but its interaction with the rest of the internet matters too.
The bottom line
The fastest DNS is not necessarily the DNS that gives you the fastest internet experience.
Resolver latency, cache behavior, geographic placement, and CDN mapping all contribute to what happens after you type a website address.
That is why Techziano’s DNS testing should not necessarily produce a single permanent “number one” resolver.
A better benchmark would show which resolver performs best for which type of workload and from which network.
That is a much harder answer to produce.
It is also a much more useful one.
You will also like:
Check our latest Blogs
AirTag Battery: Ultimate Guide to Battery Life & Replacement
iPhone 17e Review: Apple’s Cheapest iPhone Finally Feels Complete
Best Music Streaming Service Comparison: Which One Is Actually Worth Paying For ?
Samsung Galaxy Z Fold 7 Review: The Ultimate Test After a Year
Frequently Asked Questions
Can DNS affect which server a website uses?
Yes. Some CDN systems use DNS responses to help determine which edge server or IP address should be returned to a user.
Is the DNS with the lowest latency always the fastest?
No. DNS lookup latency is only one part of the overall connection. A different resolver may return a CDN destination that produces a better network path.
Why can two people get different results from the same DNS?
Resolver location, ISP routing, cache state, geography, and CDN behavior can all differ between users.
What is EDNS Client Subnet?
ECS is a DNS extension that allows a resolver to pass part of a client’s network address to an authoritative DNS server so it can produce more location-aware responses.
Does DNS affect website speed?
It can. DNS lookup time contributes to connection setup, while resolver choice can also influence CDN server selection for some services.
Should I choose DNS based on a global benchmark?
A global benchmark can provide useful context, but it cannot guarantee the same result on your network. For performance, testing from your own connection is more relevant.
Hi, I am the founder of Techziano and a technology enthusiast passionate about AI, software, web development, cybersecurity, and emerging technologies. I creates practical tutorials, software reviews, and technology insights to help readers stay informed and build valuable digital skills.
