Does DNS Affect Internet Speed?
DNS operates at a different layer than your bandwidth. Learn why DNS filtering rarely impacts speed tests, and how to measure actual DNS performance when something feels slow.
DNS operates at a different layer than your bandwidth. Learn why DNS filtering rarely impacts speed tests, and how to measure actual DNS performance when something feels slow.
This is the most important thing to understand: DNS does not affect your download or upload speed. They operate at completely different layers of the network stack.
google.com) into an IP address. This lookup typically takes 5–50 milliseconds.When you run a speed test on your Google Nest and get 860 Mbps, that's your raw bandwidth. When you run a speed test in a browser and get 26 Mbps, the bottleneck is almost certainly not DNS — it's more likely WiFi signal, browser overhead, the speed test server, or the device itself.
Think of it this way: DNS is like looking up a phone number in a directory. Bandwidth is the speed at which you can talk once the call connects. A slow directory lookup doesn't make your voice travel slower.
Every time you visit a website, your device performs a DNS lookup to find the server's IP address. Here's the timeline:
example.com in your browser93.184.216.34)After the first lookup, the result is cached — on the resolver, on your OS, and in your browser. Subsequent requests to the same domain skip the DNS step entirely until the cache expires (the TTL, typically 60–3600 seconds).
For a single domain, DNS adds a one-time cost of a few milliseconds. On a speed test, which measures sustained throughput to a single server, DNS has essentially zero impact.
While DNS doesn't affect raw bandwidth, there are real-world scenarios where DNS performance impacts the perceived speed of browsing:
A single webpage in 2026 doesn't just load from one domain. A typical page may contact 30–80 different domains:
example.com)cdn.example.com, static.cloudfront.net)accounts.google.com, login.microsoftonline.com)google-analytics.com, facebook.net, doubleclick.net)Each unique domain requires its own DNS lookup. If your DNS resolver is slow (say 100ms per lookup) and a page loads 50 unique domains, that's potentially 5 seconds of DNS overhead — even on a fast connection. With a fast resolver (10ms per lookup), that same page adds only 500ms.
When CleanBrowsing blocks a domain, it returns an immediate response (either a block page IP or NXDOMAIN). This is actually faster than resolving the domain normally, because the blocked response comes directly from CleanBrowsing's cache without needing to query upstream servers. Blocked tracking and ad domains can make pages load faster, not slower.
Using DNS over HTTPS or DNS over TLS adds a small overhead for the TLS handshake on the first connection. After the initial handshake, the persistent connection handles subsequent queries with minimal added latency (typically 1–5ms). This is negligible in practice.
Instead of guessing, measure your DNS performance directly. These commands show you exactly how long each DNS lookup takes.
The dig command shows query time in the output:
# Query CleanBrowsing directly
dig @185.228.168.168 google.com
# Look for the "Query time" line at the bottom:
# ;; Query time: 12 msecRun it a few times — the first query may be slower (cache miss), subsequent queries will be faster (cache hit).
# Measure DNS resolution time
Measure-Command { Resolve-DnsName -Name google.com -Server 185.228.168.168 } | Select-Object TotalMilliseconds# PowerShell wrapper for timing
$sw = [System.Diagnostics.Stopwatch]::StartNew()
nslookup google.com 185.228.168.168
$sw.Stop()
Write-Host "DNS lookup took: $($sw.ElapsedMilliseconds)ms"Test realistic DNS load by resolving multiple domains sequentially:
# macOS / Linux — test 10 common domains
for d in google.com facebook.com youtube.com amazon.com twitter.com \
reddit.com wikipedia.org netflix.com linkedin.com github.com; do
echo -n "$d: "
dig @185.228.168.168 +noall +stats $d | grep "Query time"
done# PowerShell — same test
$domains = @("google.com","facebook.com","youtube.com","amazon.com",
"twitter.com","reddit.com","wikipedia.org","netflix.com","linkedin.com","github.com")
foreach ($d in $domains) {
$ms = (Measure-Command { Resolve-DnsName $d -Server 185.228.168.168 }).TotalMilliseconds
Write-Host "$d : $([math]::Round($ms))ms"
}Healthy DNS resolution should be under 50ms for cached queries and under 150ms for uncached queries. If you see consistently high times (200ms+), there may be a routing issue — run a traceroute to investigate.
To see how much of a webpage's load time is DNS vs actual content download, use curl with timing variables:
# macOS / Linux
curl -o /dev/null -s -w "\
DNS Lookup: %{time_namelookup}s\n\
TCP Connect: %{time_connect}s\n\
TLS Done: %{time_appconnect}s\n\
First Byte: %{time_starttransfer}s\n\
Total: %{time_total}s\n" \
https://www.google.comExample output:
DNS Lookup: 0.012s
TCP Connect: 0.025s
TLS Done: 0.058s
First Byte: 0.089s
Total: 0.142sIn this example, DNS took 12ms out of a total 142ms page load — about 8%. The rest is TCP connection, TLS handshake, server processing, and data transfer. On most websites, DNS is a small fraction of total load time.
To completely isolate DNS from the equation, resolve the domain first, then connect by IP:
# Get the IP
dig +short google.com
# → 142.250.80.46
# Connect directly by IP (skip DNS entirely)
curl -o /dev/null -s -w "Total: %{time_total}s\n" \
--resolve www.google.com:443:142.250.80.46 \
https://www.google.comCompare the total time with and without DNS. The difference is your DNS overhead for that domain.
In Chrome/Edge, open DevTools (F12) → Network tab → reload the page. Click any request and look at the Timing tab. You'll see "DNS Lookup" as a separate segment. Sort by domain to see which third-party domains are adding DNS overhead. See our DevTools guide for more detail.
If you suspect DNS is slow, compare CleanBrowsing against other resolvers:
# macOS / Linux — compare 4 resolvers
for server in 185.228.168.168 8.8.8.8 1.1.1.1 9.9.9.9; do
echo -n "$server: "
dig @$server google.com +noall +stats | grep "Query time"
done# PowerShell
$servers = @{
"CleanBrowsing" = "185.228.168.168"
"Google" = "8.8.8.8"
"Cloudflare" = "1.1.1.1"
"Quad9" = "9.9.9.9"
}
foreach ($name in $servers.Keys) {
$ms = (Measure-Command {
Resolve-DnsName google.com -Server $servers[$name] -ErrorAction SilentlyContinue
}).TotalMilliseconds
Write-Host "$name ($($servers[$name])): $([math]::Round($ms))ms"
}Run each test 3–5 times and average the results. The first query will be slower (cache miss); subsequent queries show cached performance. CleanBrowsing uses an Anycast network across 70+ global data centers, so queries are routed to the nearest server.
Important: Small differences (5–15ms) between providers are imperceptible to users. A resolver that's 10ms slower but provides content filtering is a worthwhile tradeoff. Differences only matter if one provider is consistently 100ms+ slower than others.
This is rarely DNS. Common causes:
If you see a measurable speed difference after switching DNS, check:
Google Nest runs a speed test at the router level over a wired backhaul — measuring your raw ISP connection. A browser speed test runs over WiFi, through your device's network stack, through the browser engine. The difference (860 vs 26 Mbps) is almost certainly WiFi limitations, not DNS. Test with a device connected via Ethernet cable to isolate the variable.
This points to the website itself or specific third-party domains it loads, not DNS. Use the curl timing test from Step 5 on the slow domain. If DNS Lookup is under 50ms but Total time is high, the bottleneck is the server, not DNS.
If DNS resolution is genuinely slow (consistently 100ms+ per query), here are practical fixes:
When DNS is set at the router level, the router acts as a local DNS cache for all devices. After any device resolves a domain, the result is cached locally — subsequent lookups from any device on the network are near-instant. See our router setup guide.
Encrypted DNS keeps a persistent connection to CleanBrowsing's servers. After the initial TLS handshake, queries flow through the existing connection with minimal overhead. This can actually be faster than plaintext DNS for subsequent queries because it avoids per-query UDP overhead. See encrypted DNS setup.
If your device is querying multiple DNS providers (your ISP + CleanBrowsing), each query may go to a different server, preventing efficient caching. Run a DNS leak test to verify only CleanBrowsing is handling your queries.
CleanBrowsing's content filtering blocks many tracking and ad domains at the DNS level. This eliminates DNS lookups, TCP connections, and data transfer for those domains entirely — making pages load faster. If you're on the Family or Adult filter, you're already benefiting from this.
Occasionally, stale or corrupt DNS cache entries can cause delays. Clear your DNS cache if specific domains are consistently slow while others are fine.
Contact Support