A café Wi-Fi test comparing the network’s default DNS, Quad9 over plain DNS, and Quad9 over DNS-over-HTTPS found encrypted Quad9 lookups averaging about 21.5 milliseconds, nearly matching the café resolver and beating plain Quad9 DNS at roughly 46.3 milliseconds in that session. That result does not prove DoH is universally faster than old-fashioned DNS. It does, however, puncture the lazy assumption that encryption automatically means a meaningful performance penalty. The real story is less about cryptography slowing things down and more about how modern networks reward persistent, well-routed connections.
For years, the mental model has been simple: plain DNS is fast because it is small, stateless, and usually carried over UDP; encrypted DNS is safer because it wraps the query in TLS, but that extra machinery must cost time. That model is not wrong in the abstract. Encryption has overhead, certificates must be checked, and TLS handshakes are not free.
But the internet does not run on protocol diagrams. It runs on routing, peering, resolver placement, caching behavior, congestion, Wi-Fi quality, operating-system choices, and whatever strange policy a café router inherited from an ISP five firmware versions ago. In that world, the clean “UDP fast, HTTPS slower” comparison can collapse surprisingly quickly.
The MakeUseOf test is useful precisely because it is modest. It was not a lab benchmark with controlled peering and hundreds of thousands of samples. It was a Windows laptop on public Wi-Fi resolving five familiar domains through three DNS configurations. That is also why it feels relevant: this is how most people actually encounter DNS performance, not as an RFC, but as the hidden prelude to opening a web page.
The more interesting number is plain Quad9 DNS at roughly 46.3 milliseconds. That is not catastrophic; DNS lookups measured in tens of milliseconds are still quick. But it is enough to challenge the reflexive claim that plain DNS must be the fastest option simply because it has fewer protocol layers.
A local or ISP-provided resolver often has a geography advantage. It may sit closer on the provider’s network, benefit from local caching, or travel over a shorter route than a public resolver. That explains why the café DNS performing well is not shocking. What is shocking is that encrypted Quad9 essentially caught it while unencrypted Quad9 lagged behind.
That gap suggests the deciding factor was not “encryption versus no encryption.” It was the path, session behavior, and resolver handling around the query.
The first DoH query can be slower because the client may need to establish a TCP connection, negotiate TLS, and validate the server certificate. If you measure only that cold start, DoH can look worse than UDP DNS. That is the benchmark people often imagine when they assume encrypted DNS must be slower.
But once the secure connection exists, it can be reused. Multiple DNS requests can travel over the same established HTTPS session instead of starting from scratch every time. In a short run of repeated lookups, that reuse can offset the initial handshake cost and produce results that look counterintuitive if you only think about encryption as overhead.
This does not mean DoH is inherently faster. It means encrypted and slower are not synonyms. The performance profile depends on whether the connection is cold or warm, whether the resolver is nearby, whether HTTP/2 or newer transport behavior is in play, and whether the client and resolver are configured well.
Windows 11 exposes DNS-over-HTTPS in its network settings, and major browsers can also make their own encrypted DNS choices. That creates a layered reality: the operating system may use one resolver, the browser may use another, and a VPN client may override both. For privacy-minded users, that flexibility is welcome. For administrators, it can become a visibility problem.
The café scenario highlights the tension. On an untrusted network, encrypted DNS is attractive because it prevents the local network operator from trivially reading or tampering with DNS queries. That matters in hotels, airports, cafés, conference centers, and any environment where the Wi-Fi password is printed on a receipt.
But DoH also changes who gets visibility. Instead of the local network or ISP seeing DNS queries, the chosen public resolver does. That may be an improvement, especially with a provider that makes strong privacy commitments, but it is not invisibility. It is a shift in trust.
A user switching from café DNS to Quad9 DoH is not merely shaving milliseconds. They are choosing a resolver with different policies, different logging practices, different threat intelligence, and different jurisdictional commitments. Those choices matter more than whether a single lookup returns in 21 milliseconds or 23 milliseconds.
The plain Quad9 result should not be overread. A one-session test from one café cannot diagnose Quad9’s global performance. Anycast routing can place different users on different resolver clusters, and local peering can make one provider brilliant in one city and mediocre in another. Still, the result illustrates a practical truth: the fastest DNS provider on paper may not be the fastest from your chair.
That is why DNS benchmarking is personal. Your ISP, router, Wi-Fi congestion, VPN, browser, operating system, and physical location all influence the result. The best resolver is not universal; it is contextual.
Even then, this kind of test has limits. Five domains and five runs can reveal a pattern, but they cannot establish a general law. DNS responses may be cached by the resolver, domains may have different record complexity, and the first lookup after changing settings may behave differently from subsequent lookups.
There is also the Windows factor. Depending on configuration, applications may not all use the same resolver path. Browsers can implement their own DoH settings, VPN clients can intercept DNS, and enterprise policy can force or block encrypted resolution. Measuring DNS on Windows increasingly requires knowing which layer is actually making the query.
That does not make the café test invalid. It makes it a good starting point rather than a final answer. The right lesson is not “DoH is faster.” The right lesson is “test the resolver path you actually use.”
Plain DNS exposes queries to the local network path. Anyone positioned appropriately on that path may be able to observe the domains being resolved, even if the web traffic itself is encrypted by HTTPS. That does not reveal the full contents of a browsing session, but it can reveal a lot about user behavior.
DoH encrypts the DNS query between the client and resolver. That helps against casual snooping and some forms of manipulation on untrusted networks. It is not a complete anonymity system, and it does not hide the destination IP address from the broader network path, but it closes a long-standing plaintext leak.
For home users, that means DoH is a reasonable default if the resolver is trustworthy and performance is acceptable. For road warriors, it is even more compelling. Public Wi-Fi is exactly where plaintext DNS feels most anachronistic.
For enterprises, the answer is more complicated. DNS is a security telemetry source, a policy enforcement point, and a troubleshooting tool. Unmanaged DoH can bypass corporate filtering or split visibility across resolvers. The enterprise answer is not to pretend encrypted DNS does not exist; it is to manage it deliberately.
That distinction matters because browsing is bursty. Opening a modern website can trigger many DNS lookups for content delivery networks, analytics services, fonts, images, scripts, login providers, and ad infrastructure. If those queries can ride an existing encrypted session, DoH overhead may shrink into the background.
Plain UDP DNS remains extremely efficient. It is simple for a reason, and on a good local resolver it can be difficult to beat. But efficiency at the packet level is not always the same thing as responsiveness at the user level.
Routing can overwhelm protocol purity. A theoretically lean UDP query sent along a worse path can lose to a heavier HTTPS query sent along a better one. That is the part of the story that should stick.
The Old DNS Assumption Has Outlived the Network It Describes
For years, the mental model has been simple: plain DNS is fast because it is small, stateless, and usually carried over UDP; encrypted DNS is safer because it wraps the query in TLS, but that extra machinery must cost time. That model is not wrong in the abstract. Encryption has overhead, certificates must be checked, and TLS handshakes are not free.But the internet does not run on protocol diagrams. It runs on routing, peering, resolver placement, caching behavior, congestion, Wi-Fi quality, operating-system choices, and whatever strange policy a café router inherited from an ISP five firmware versions ago. In that world, the clean “UDP fast, HTTPS slower” comparison can collapse surprisingly quickly.
The MakeUseOf test is useful precisely because it is modest. It was not a lab benchmark with controlled peering and hundreds of thousands of samples. It was a Windows laptop on public Wi-Fi resolving five familiar domains through three DNS configurations. That is also why it feels relevant: this is how most people actually encounter DNS performance, not as an RFC, but as the hidden prelude to opening a web page.
The Café Resolver Won, But Only Barely
The café’s default DNS averaged about 20.8 milliseconds across the tested domains. Quad9 with DoH averaged about 21.5 milliseconds. In practical browsing terms, that difference is invisible.The more interesting number is plain Quad9 DNS at roughly 46.3 milliseconds. That is not catastrophic; DNS lookups measured in tens of milliseconds are still quick. But it is enough to challenge the reflexive claim that plain DNS must be the fastest option simply because it has fewer protocol layers.
A local or ISP-provided resolver often has a geography advantage. It may sit closer on the provider’s network, benefit from local caching, or travel over a shorter route than a public resolver. That explains why the café DNS performing well is not shocking. What is shocking is that encrypted Quad9 essentially caught it while unencrypted Quad9 lagged behind.
That gap suggests the deciding factor was not “encryption versus no encryption.” It was the path, session behavior, and resolver handling around the query.
DoH Does Not Win Because Encryption Is Magic
DNS-over-HTTPS is sometimes discussed as if it were simply DNS with a privacy sticker on it. That undersells the architectural change. DoH moves DNS queries into HTTPS, which means the traffic can take advantage of the same mature transport and connection-management machinery used by the modern web.The first DoH query can be slower because the client may need to establish a TCP connection, negotiate TLS, and validate the server certificate. If you measure only that cold start, DoH can look worse than UDP DNS. That is the benchmark people often imagine when they assume encrypted DNS must be slower.
But once the secure connection exists, it can be reused. Multiple DNS requests can travel over the same established HTTPS session instead of starting from scratch every time. In a short run of repeated lookups, that reuse can offset the initial handshake cost and produce results that look counterintuitive if you only think about encryption as overhead.
This does not mean DoH is inherently faster. It means encrypted and slower are not synonyms. The performance profile depends on whether the connection is cold or warm, whether the resolver is nearby, whether HTTP/2 or newer transport behavior is in play, and whether the client and resolver are configured well.
Windows Users Should Care Because DNS Is No Longer Just Plumbing
For Windows users, DNS settings used to be one of those control-panel chores performed only when something broke. You accepted the router’s default, the router accepted the ISP’s default, and the browser got on with its day. That era is fading.Windows 11 exposes DNS-over-HTTPS in its network settings, and major browsers can also make their own encrypted DNS choices. That creates a layered reality: the operating system may use one resolver, the browser may use another, and a VPN client may override both. For privacy-minded users, that flexibility is welcome. For administrators, it can become a visibility problem.
The café scenario highlights the tension. On an untrusted network, encrypted DNS is attractive because it prevents the local network operator from trivially reading or tampering with DNS queries. That matters in hotels, airports, cafés, conference centers, and any environment where the Wi-Fi password is printed on a receipt.
But DoH also changes who gets visibility. Instead of the local network or ISP seeing DNS queries, the chosen public resolver does. That may be an improvement, especially with a provider that makes strong privacy commitments, but it is not invisibility. It is a shift in trust.
Quad9’s Result Is a Reminder That Resolver Choice Is a Security Decision
Quad9 is not just a speed play. Its public resolver is built around privacy and security filtering, including blocking known malicious domains on its protected service. That makes the comparison more interesting than a raw latency race.A user switching from café DNS to Quad9 DoH is not merely shaving milliseconds. They are choosing a resolver with different policies, different logging practices, different threat intelligence, and different jurisdictional commitments. Those choices matter more than whether a single lookup returns in 21 milliseconds or 23 milliseconds.
The plain Quad9 result should not be overread. A one-session test from one café cannot diagnose Quad9’s global performance. Anycast routing can place different users on different resolver clusters, and local peering can make one provider brilliant in one city and mediocre in another. Still, the result illustrates a practical truth: the fastest DNS provider on paper may not be the fastest from your chair.
That is why DNS benchmarking is personal. Your ISP, router, Wi-Fi congestion, VPN, browser, operating system, and physical location all influence the result. The best resolver is not universal; it is contextual.
The Measurement Is Useful, But It Is Not a Verdict
The PowerShell test usedResolve-DnsName and Measure-Command across Google, BBC, Reddit, Amazon, and GitHub, then averaged the results. Clearing the DNS client cache before testing is important because cached answers can make DNS appear absurdly fast while measuring almost nothing.Even then, this kind of test has limits. Five domains and five runs can reveal a pattern, but they cannot establish a general law. DNS responses may be cached by the resolver, domains may have different record complexity, and the first lookup after changing settings may behave differently from subsequent lookups.
There is also the Windows factor. Depending on configuration, applications may not all use the same resolver path. Browsers can implement their own DoH settings, VPN clients can intercept DNS, and enterprise policy can force or block encrypted resolution. Measuring DNS on Windows increasingly requires knowing which layer is actually making the query.
That does not make the café test invalid. It makes it a good starting point rather than a final answer. The right lesson is not “DoH is faster.” The right lesson is “test the resolver path you actually use.”
The Privacy Win Is More Durable Than the Speed Win
Speed results will vary. The privacy argument for encrypted DNS is steadier.Plain DNS exposes queries to the local network path. Anyone positioned appropriately on that path may be able to observe the domains being resolved, even if the web traffic itself is encrypted by HTTPS. That does not reveal the full contents of a browsing session, but it can reveal a lot about user behavior.
DoH encrypts the DNS query between the client and resolver. That helps against casual snooping and some forms of manipulation on untrusted networks. It is not a complete anonymity system, and it does not hide the destination IP address from the broader network path, but it closes a long-standing plaintext leak.
For home users, that means DoH is a reasonable default if the resolver is trustworthy and performance is acceptable. For road warriors, it is even more compelling. Public Wi-Fi is exactly where plaintext DNS feels most anachronistic.
For enterprises, the answer is more complicated. DNS is a security telemetry source, a policy enforcement point, and a troubleshooting tool. Unmanaged DoH can bypass corporate filtering or split visibility across resolvers. The enterprise answer is not to pretend encrypted DNS does not exist; it is to manage it deliberately.
The Real Performance Question Is Warm Versus Cold
The café test points toward one of the most misunderstood parts of DoH performance: the difference between a cold connection and a reused connection. The first lookup may pay setup costs. Later lookups may benefit from connection reuse.That distinction matters because browsing is bursty. Opening a modern website can trigger many DNS lookups for content delivery networks, analytics services, fonts, images, scripts, login providers, and ad infrastructure. If those queries can ride an existing encrypted session, DoH overhead may shrink into the background.
Plain UDP DNS remains extremely efficient. It is simple for a reason, and on a good local resolver it can be difficult to beat. But efficiency at the packet level is not always the same thing as responsiveness at the user level.
Routing can overwhelm protocol purity. A theoretically lean UDP query sent along a worse path can lose to a heavier HTTPS query sent along a better one. That is the part of the story that should stick.
The Little Café Benchmark Says More Than It Pretends To
The most concrete lesson from this test is not that everyone should copy the exact settings and expect the same numbers. It is that assumptions about DNS performance are now suspect. Encrypted DNS has matured enough that the old penalty may be negligible, nonexistent, or occasionally reversed.- Encrypted DNS should not be dismissed as automatically slower, because connection reuse and resolver routing can make DoH highly competitive.
- A nearby ISP or venue resolver can still be extremely fast, but speed alone does not make it the best privacy or security choice.
- Quad9’s encrypted result in this test suggests resolver path and session behavior mattered more than encryption overhead.
- Windows users should check whether DNS is being controlled by the operating system, browser, router, or VPN before trusting any benchmark.
- The practical reason to enable DoH is privacy and integrity first; any speed gain should be treated as a welcome bonus rather than a promise.
References
- Primary source: MakeUseOf
Published: 2026-06-20T15:01:08.178842
I tested encrypted DNS against plain old DNS, and the speed gap surprised me
It's not all about the extra privacy.
www.makeuseof.com