Does Changing DNS Actually Make Your Internet Faster?

Changing DNS is one of the most common internet speed tricks.

The advice sounds simple: replace your ISP’s DNS with Cloudflare, Google, or another public resolver, and your internet should become faster.

There is some truth behind it.

But the claim becomes misleading when “faster DNS” is treated as if it means a faster internet connection.

DNS can affect how quickly a domain is resolved. It can also influence which CDN server your connection is directed toward. But it does not increase your broadband speed or automatically reduce the latency of every website.

So I looked at the question differently:

What actually changes when you replace your ISP’s DNS resolver with a public one?

The first problem with most DNS tests

A normal internet speed test measures things such as download speed, upload speed, and latency to a test server.

DNS is different.

When you enter a website address, your device first needs to discover the IP address associated with that domain. A DNS resolver performs that lookup.

Google’s own documentation points out that simply pinging a DNS server does not tell you how quickly it resolves domain names. A resolver can have a relatively high network round-trip time and still return a cached DNS answer quickly.

That means a proper DNS test should measure actual DNS resolution time, not just the ping to a resolver’s IP address.

This distinction is easy to miss.

What should actually be tested?

For a useful comparison, I would test the ISP’s default resolver against major public alternatives such as:

• Cloudflare 1.1.1.1
• Google Public DNS
• Quad9
• NextDNS
• The ISP’s default DNS

The important part is not simply which providers are included.

The important part is keeping the other variables constant.

The same internet connection should be used. The same device should perform the queries. The same domains should be tested. The resolver should be the main variable.

That turns the exercise into an experiment rather than a collection of random speed numbers.

Measurement 1: DNS resolution latency

The first measurement is DNS resolution latency.

Ask each resolver to resolve the same collection of domains and record the response time.

There is an immediate complication, though:

DNS caching.

A popular domain may already be stored in a resolver’s cache. Another domain may require a recursive lookup before the resolver can return an answer.

Google recommends using a large domain sample when comparing DNS performance and specifically warns against concluding small tests. Its documentation recommends testing more than 5,000 domains when benchmarking.

This makes sense.

A test involving only five websites can be heavily influenced by cache state and temporary network conditions.

A better benchmark should report at least:

Median latency, p95 latency, and failure rate.

The median represents the typical result.

The p95 reveals what happens during slower requests.

The failure rate tells us whether the resolver is consistently usable.

Measurement 2: Website loading performance

This is where the experiment gets more interesting.

Imagine that Cloudflare resolves a domain in 10 ms while another resolver takes 20 ms.

It would be tempting to declare Cloudflare the winner.

But those numbers describe only the DNS part of the process.

Modern websites can require many DNS lookups as they request different resources. Google notes that a web page may involve numerous lookups before its content has completely loaded.

More importantly, DNS can influence what happens after the lookup.

That is because many websites use content delivery networks.

The CDN problem most DNS lists ignore

A CDN can serve content from different servers around the world.

DNS can be involved in deciding which server or edge location a user receives.

Google explains that some CDN systems return an address based on the location of the DNS resolver rather than the end user. This means the resolver’s location and network position can influence the resulting CDN destination. Google uses a globally distributed resolver network and also supports EDNS Client Subnet to help CDNs make more location-aware decisions.

This creates an important possibility:

A resolver that is slightly slower at DNS resolution can sometimes produce a better overall result.

And the opposite can also happen.

A resolver can answer DNS queries very quickly while producing a less favorable CDN path for a particular user.

This is why “fastest DNS” is not as simple as comparing two millisecond figures.

Research shows the difference.

This is not just a theoretical concern.

A 2025 study examining public DNS resolvers and major CDNs measured both DNS resolution latency and the latency between users and the CDN edge servers selected through those resolvers. The researchers found meaningful differences between resolvers.

Among their findings, Google and OpenDNS lagged Cloudflare in some DNS-resolution measurements, while Cloudflare showed a penalty with Akamai in some CDN mappings. Quad9 also showed noticeable penalties with several CDNs in the study.

That result is especially useful because it demonstrates why a DNS ranking based on lookup latency alone can be incomplete.

DNS speed and real-world network performance are related, but they are not the same measurement.

The ISP’s DNS deserves a fair test.

Public DNS services are often presented as an automatic upgrade over ISP DNS.

That should also be tested rather than assumed.

An ISP resolver can have an important advantage: its network location.

If it is close to the user and has useful cached records, it can perform very well.

Public resolvers have another advantage.

Cloudflare says 1.1.1.1 operates across hundreds of cities and uses regional caches to improve performance and cache hit rates.

Google also operates Public DNS as a globally distributed service and explains how its infrastructure is designed to reduce the distance between users, resolvers, and CDN infrastructure.

So the meaningful question is not:

Is public DNS faster than ISP DNS?

It is:

Which resolver performs better from this particular network?

That is something an actual benchmark can answer.

Measurement 3: Cached vs uncached DNS queries

Another problem with simple DNS tests is that they often mix different cache conditions.

A first lookup can require more work from a recursive resolver.

A repeated lookup may be served directly from cache.

Those are different situations.

A useful experiment should therefore distinguish between cold or less-cached queries and repeated queries where possible.

Cloudflare explains that when an answer is not in its cache, 1.1.1.1 contacts authoritative nameservers and uses measured performance to help select which nameserver to query.

That shows why resolver performance is not simply a matter of how close the resolver’s IP address appears to be.

There is a substantial system operating behind the final DNS response.

What DNS cannot fix

This is probably the most important part of the experiment.

Changing DNS does not increase your internet package speed.

If your connection is 100 Mbps, changing from your ISP’s DNS to Cloudflare does not turn it into a 500 Mbps connection.

DNS also cannot repair:

• weak Wi-Fi
• packet loss
• network congestion
• a slow website server
• poor cellular coverage
• a long physical route to a game server

DNS operates at a different stage of the connection.

It can affect name resolution and, in some cases, server selection.

It is not a universal internet-speed booster.

What about gaming?

DNS is frequently recommended as a way to reduce gaming ping.

That needs some caution.

DNS can affect the initial lookup of a game service or hostname. It may also influence certain server-selection processes.

But once a connection to a game server is established, DNS is generally not responsible for the ongoing latency between your device and that server.

So if changing DNS appears to reduce in-game ping, the result should be investigated rather than automatically attributed to DNS.

A proper experiment would need to compare the actual game-server route and latency before and after the DNS change.

So, does changing DNS make the internet faster?

It can make parts of the browsing process faster, but it is not a guaranteed internet-speed upgrade.

The strongest evidence points to several variables working together.

DNS lookup time matters.

Cache performance matters.

Resolver location matters.

CDN mapping matters.

Your ISP and network location matter.

That is why two people can use the same DNS provider and experience different results.

Cloudflare itself describes 1.1.1.1 as a fast public resolver and says it has been measured as the fastest public DNS resolver, but even provider documentation does not eliminate the need to consider local network conditions.

The DNS test that actually matters

If I were choosing a DNS resolver for my own connection, I would not select it simply because another website called it the fastest.

I would test it from my actual network.

The benchmark should measure:

Measurement	What it tells us
Median DNS latency	Typical lookup performance
P95 latency	Slow-request behavior
Failure rate	Reliability
Cold-cache results	Recursive resolution performance
Warm-cache results	Cached performance
CDN destination	Possible server-selection effects
Website loading	Real-world impact

That produces a much more useful result than one average number.

It also makes the experiment repeatable.

The conclusion

Changing DNS is not a magic internet-speed upgrade.

But saying DNS does not matter would also be wrong.

The resolver sits at the beginning of the connection process, and its behavior can affect more than the time needed to answer a domain lookup. Caching, resolver location, and CDN mapping can all influence what happens next.

The biggest mistake is looking for one global winner.

The better question is:

Which DNS resolver performs best on my network, for the websites and services I actually use?

That requires testing.

And that is why the next generation of DNS comparisons should look less like a list of IP addresses and more like a proper experiment.

Frequently Asked Questions