Public DNS Is a Trade-Off, Not a Free Upgrade
Privacy, latency, filtering, and why “faster DNS” depends on where, and how, you connect.
Switching to a public DNS resolver is one of the most commonly repeated pieces of networking advice — and one of the most context-free.
Sometimes it genuinely helps. Sometimes you’d never notice the difference. And sometimes it quietly makes things worse: your CDN routing breaks, your ISP’s local caching advantage disappears, or you introduce a dependency on a resolver that blocks domains your app relies on.
Public DNS resolvers are useful tools. But “just switch to 1.1.1.1” skips the actual question: better for what? The right resolver depends on your network, your location, and what you’re optimizing for — speed, privacy, filtering, or predictability. Often those pull in different directions.
Why this advice became popular
The popularity of public DNS didn’t come from nowhere. Historically, many ISP resolvers were genuinely bad:
- Slow or unreliable responses
- DNS hijacking (search pages, injected ads)
- Poor security hygiene
- Broken caching behavior
Switching to a well-run public resolver often did feel like magic.
What changed is that ISP DNS has improved, while public DNS has grown more complex in behavior and policy. Today, switching resolvers can be a win, a wash, or a regression, and you won’t know which without testing on your network.
What DNS actually does
DNS is the internet’s address book. When you type example.com, DNS resolves that name into IP addresses so your device knows where to connect.
DNS handles things like:
- A / AAAA records (IPv4 / IPv6)
- MX records for email
- TXT records for verification and policy
- HTTPS/SVCB records in modern stacks
- Caching and policy enforcement
What DNS does not do:
- It does not guarantee fast page loads
- It does not control congestion
- It does not decide routing paths beyond the first hint
A fast DNS lookup can still lead to a slow site. Most latency lives after DNS: TCP/TLS handshakes, congestion, CDN selection, and server behavior.
The big public DNS options
Public DNS providers are not interchangeable; each is optimized for a different goal.
| Provider | Addresses | Primary intent | Trade-offs |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | Speed + privacy messaging | Excellent anycast, but routing still depends on your ISP |
| Google DNS | 8.8.8.8 | Reliability + global reach | Very stable, not always lowest-latency |
| Quad9 | 9.9.9.9 | Security filtering | Can block domains users expect to resolve |
| AdGuard DNS | varies | Ad / tracker blocking | Breakage is a feature, not a bug |
Choosing one is choosing policy, not just performance.
Why “faster DNS” is not guaranteed
Anycast ≠ closest
Most public DNS uses anycast. That means “you hit a nearby node,” not necessarily the best one. BGP decides where you land, and BGP follows business relationships, not geography.
Two users 20 km apart can see a 5× DNS latency difference simply because their ISPs peer differently.
Read more: Why Latency is Political, Not Just Physical
ISP resolvers often have the home-field advantage
Many ISPs operate resolvers inside their own network:
- Fewer hops
- Better local caching
- Closer alignment with local CDNs
In these cases, ISP DNS can outperform public resolvers consistently.
DNS can influence CDN behavior
Some CDNs make edge decisions based on resolver location. If your DNS resolver appears “far away,” you may get an edge node optimized for the resolver, not for you.
That’s how switching DNS can paradoxically increase page latency.
Caching hides the truth
DNS performance depends heavily on cache state:
- Device cache
- Router cache
- Resolver cache
One fast lookup proves nothing. Testing needs repetition and cold-cache awareness.
Privacy: you’re choosing who to trust, not escaping observation
Switching DNS doesn’t make queries invisible. It changes who can see them.
Depending on your setup, DNS may be visible to:
- Your device
- Your router or LAN admin
- Your ISP
- On-path operators (if unencrypted)
- The resolver provider itself
DoH and DoT help, but only partially
Encrypted DNS (DoH / DoT):
- Prevents casual on-path inspection
- Reduces tampering
- Does not hide destinations after resolution
- Does not prevent resolver logging
The real question is jurisdiction and policy, not protocol.
Filtering is policy enforcement, not magic
DNS filtering works by applying resolver-side rules, often implemented via concepts similar to DNS RPZ (Response Policy Zones):
- Queries are matched against policy lists
- Responses are altered:
- NXDOMAIN
- Sinkhole IPs
- Block pages (enterprise setups)
This is powerful and blunt.
The cost of filtering
False positives are inevitable:
- Auth flows break
- Payment scripts fail
- Apps behave inconsistently
- “Works on mobile, broken on Wi-Fi” confusion appears
That outcome is policy, not a DNS bug.
When ISP DNS is the right choice
ISP DNS can be the best option when:
- Local peering is strong
- Resolver infrastructure is nearby
- CDN locality matters
- ISP-managed services depend on it
Local optimization often beats global generality.
When DNS stops being your decision
VPNs sometimes enter the DNS discussion because they change the network context:
- DNS queries may route through the tunnel
- The resolver may change
- Local network interference disappears
This can help when:
- Wi-Fi networks block or tamper with DNS
- Captive portals behave poorly
- Travel causes unstable routing
But VPNs are not a DNS upgrade:
- Trust shifts to the VPN provider
- Latency can increase
- CDN routing can worsen
- Resolver visibility still exists
Think of VPNs as transport-layer tools, not privacy absolution. NordVPN is one commonly used option.
Choose DNS by intent, not hype
Instead of asking “What’s the fastest DNS?”, ask:
- Lowest latency on this network?
- Fewer moving parts?
- Malware filtering?
- Ad blocking?
- Reduced local network visibility?
There is no universal best. Only what fits your constraints.
DNS is not a one-time tweak
DNS performance is network-specific:
- Home broadband ≠ mobile ≠ office ≠ hotel
- Peak hours matter
- ISP routing changes
A practical mindset:
- Test per network
- Measure real app performance, not just lookup time
- Revisit decisions when conditions change
Closing
Public DNS isn’t a free upgrade. It’s a choice about who sees your queries, which domains get silently blocked, whether your CDN routing stays local, and what breaks when the resolver does something unexpected.
Physics doesn’t decide DNS outcomes. Routing, policy, and business incentives do.
Treat it like infrastructure. Test it on your actual network. Revisit it when conditions change.
Written by the Infra Atlas author
I work on infrastructure and software systems across layers: writing code, shipping products, and dealing with the practical trade-offs of hosting, memory, and network behavior in production. When this site says it covers “layer 3 to layer 9,” it’s half a joke and half a truth: from routing and packets, up through operating systems, applications, and the human decisions that actually cause outages.
Infra Atlas is a collection of field notes from that work. Some pages may include affiliate or referral links as a low-key way to support the site. Think of it as buying me a coffee while I write about why systems behave the way they do.