Speed Isn't Everything: Encrypted DNS Latency Facts

Encrypted DNS adds latency, with some resolvers averaging over a second due to distant routing paths.

Stop pretending DNS over HTTPS kills your network. It doesn't. The real culprit is often sloppy BGP routing and the lies your browser tells you via caching. Yes, Gregory Gibson is right: local ISP resolvers win on raw speed. But for most workflows, the privacy tax is negligible unless your traffic gets routed to the wrong continent. We need to stop looking at raw speed tests and start looking at how encrypted DNS metadata protection actually behaves under load.

This isn't about theory. It's about why your uncached lookup times look terrible compared to browser benchmarks. We're looking at Cloudflare's public DNS resolver, which keeps logs for roughly 25 hours before wiping them, a specific window detailed in their transparency reports. We also need to talk about how dns query protection clashes with Windows caching to create a false sense of speed.

Speed versus secrecy isn't a philosophical debate; it's a math problem involving geographic distance and cache states. If you ignore these variables, your dns query protection strategy is just security theater.

The Role of Encrypted DNS in Modern Privacy Architecture

How DNS over HTTPS Encrypts Payloads on Port 443

DNS over HTTPS wraps your queries in TLS sessions on port 443. To anyone watching the pipe, your domain requests look like generic HTTPS noise. Traditional DNS screams hostnames in plain text; this protocol encrypts the whole transaction. Providers like Cloudflare and Mullvad use DNS over HTTPS (DoH) specifically to stop ISPs from logging every domain you touch.

The magic relies on anycast DNS, where multiple servers share one IP address, letting BGP steer you to the "nearest" node. In theory. In practice, BGP path selection cares more about policy than geography. We've seen Australian connections hit London instead of Singapore. That's the friction: encryption secures the payload, but the transport path still obeys broken internet routing rules. You get privacy, but you pay for it in milliseconds. Industry efforts are shifting toward efficient address utilization to support the infrastructure this secure traffic demands, but the routing gaps remain.

Anycast Routing Realities in Mullvad's Global DNS Infrastructure

Anycast DNS broadcasts a single IP from multiple spots, trusting BGP to pick the winner. The goal is simple: route traffic to the topologically closest server to minimize latency. Mullvad operates free DNS servers in Dallas, United States; London, United Kingdom; Frankfurt, Germany; Stockholm, Sweden; and Singapore, Singapore.

Here's the glitch: testing from Australia, requests landed in London, not Singapore. Why? Because the Border Gateway Protocol (BGP) decided the path to the UK was "better" based on AS path attributes, not physical distance. Anycast promises proximity; BGP delivers policy.

The Privacy Over Speed Trade-off in Encrypted DNS Adoption

Encrypted DNS stops ISP surveillance by wrapping traffic, but that wrapper costs time. You get slower browsing. That's the deal. Users accept this latency hit to stop activity tracking. We call it "privacy over speed" because the increase in query latency is the price of admission.

While Cloudflare deletes resolver logs after 25 hours, the encryption handshake itself adds overhead. Data retention policies might promise no storage of source IPs in non-volatile storage, using anonymization instead, but the crypto math still takes cycles.

Network operators have to weigh this latency increase against reduced data exposure. If your threat model says "stop ISP data collection" matters more than milliseconds, enable it. But don't ignore BGP routing. If your provider routes you through a distant node, that remote resolver becomes useless for latency-sensitive work. Optimizing existing IPv4 resources helps build local resolution infrastructure, balancing privacy with the need for high-speed availability.

How BGP Routing and Caching Mechanisms Impact DNS Latency

BGP Anycast Routing Mechanics in DNS Resolution

Border Gateway Protocol decisions drive physical paths, often prioritizing routing policy over geography. Anycast logic can misdirect traffic; remember that Australia-to-London detour? That happens because BGP evaluates AS path attributes, not map distances. Packets traverse unnecessary continents. When you layer encryption on top of these inefficiencies, the latency penalty spikes.

Standard resolvers chase speed. Privacy tools chase secrecy. Encrypted DNS metadata protection doesn't fix broken routing tables.

Global redundancy often fights local optimization. Anycast tries to shorten paths; transit providers' BGP policies override it. Reducing dependence on distant nodes requires controlling announced prefixes. Architects need direct peering. Ignore BGP mechanics, and encryption won't save you from the lag. Users feel this when policies force traffic through distant nodes instead of closer options.

Measuring Uncached DNS Lookups with PowerShell

Browser caches lie. They distort latency measurements, so you must invalidate the cache explicitly before testing. Swapping DNS servers in Windows Network settings often fails to show real performance because browsers and Windows cache responses. You aren't measuring the resolver; you're measuring the cache.

To get real uncached lookup times, you must clear the local resolver cache and force fresh queries every time.

The testing methodology used two PowerShell commands: `Clear-DnsClientCache` and `Resolve-DnsName`.

1. Execute `Clear-DnsClientCache` to purge stored records.
2. Run `Resolve-DnsName` with the `-DnsOnly` flag to bypass host file checks.
3. Repeat this sequence across multiple rounds to gather statistical significance.

The script tested 10 geographically diverse domains over 5 rounds, resulting in 50 uncached lookups per resolver. This stops the OS from serving stale data. Every recorded millisecond reflects actual network round-trip time to the upstream resolver. Without this rigor, DNS caching mechanisms return near-instant results that hide the latency penalties inherent in encrypted protocols.

This sterile environment reveals the truth: privacy configurations cost time. Users accepting this trade-off prioritize privacy over speed to prevent ISP surveillance. Optimized routing helps, but the encryption process itself introduces processing time. Network architects must account for this baseline delay when designing high-availability systems reliant on encrypted resolution.

Latency Variance Risks in Encrypted DNS Providers

Suboptimal BGP paths inflate encrypted resolver latency, creating unpredictable experiences. Routing policies ignore physical proximity, forcing traffic through distant nodes. Mullvad DoH averaged more than a second due to these routing issues, making it sluggish for real-time applications. This isn't just encryption overhead; it's circuitous network paths. Users trying to fix slow DNS over HTTPS hit BGP topology constraints that dictate poor outcomes regardless of client config.

Response time variance introduces instability that median metrics obscure. The ISP's average was skewed by one ugly 777.6ms lookup, making the median a clearer indicator of typical performance. Encrypted providers face consistent delays when routing policies direct traffic through distant nodes rather than geographically closer options. Operators must weigh privacy benefits against tangible speed degradation.

A comparison of resolver performance highlights the trade-off between security and speed:

Optimizing existing IPv4 resources can help mitigate such routing inefficiencies. Redistributing unused IP blocks allows networks to establish closer peering points. This approach reduces dependence on distant resolvers and minimizes latency variance. Proper network configuration ensures that privacy enhancements maintain acceptable performance levels for most use cases.

Comparative Analysis of ISP, Cloudflare, and Mullvad Resolvers

Defining Resolver Performance Metrics: Median vs Average Latency

Median latency is the only metric that matters for DNS resolution because it filters the outliers that distort averages. Empirical testing reveals an ISP resolver averaging 42.1ms while maintaining a median of 7.4ms. That discrepancy? Caused by a single 777.6ms outlier. This skew proves why the middle value offers a more representative view than the arithmetic mean when evaluating resolver responsiveness. Unencrypted ISP paths typically deliver the fastest lookup times, yet they expose query payloads to surveillance. Encrypted alternatives like Cloudflare introduce necessary privacy but incur a latency penalty due to TLS handshakes and routing paths.

The table below contrasts the operational profiles of these three resolution methods:

Average metrics suggest significant degradation, yet the median often confirms that regular browsing remains unaffected by encryption overhead. Reliance on distant anycast nodes can cause persistent latency spikes unrelated to the encryption protocol itself. Routing played a significant role in the overall DNS speed test results, particularly when requests were directed to distant locations.

Real-World Browsing Impact of Cloudflare DoH Delays

Median resolution times for Cloudflare DoH reach 118.8ms, yet this latency penalty rarely impacts human perception during standard web navigation. While the ISP resolver delivers a faster 7.4ms median, it exposes query payloads to local network monitoring without encryption. The additional round-trip time required for TLS handshakes creates a measurable but operationally negligible delay for most HTTP requests. Regular browsing does not seem affected whatsoever by this tiny delay caused by using Cloudflare's DoH servers, validating the practical viability of encrypted transport for general users.

Sub-second delays in name resolution do not equate to degraded throughput once the TCP connection establishes. The cost is privacy preservation over raw speed, as the encryption overhead prevents ISP surveillance while maintaining acceptable load times. Some individuals explicitly choose to configure their systems for encrypted DNS, accepting the resultant decrease in browsing speed as a necessary compromise to prevent their ISP from tracking web activity. This configuration represents a functional equilibrium where user privacy is secured without rendering the network unusable.

As the internet infrastructure remains predominantly based on IPv4, efficient address management supports the underlying transport layer these privacy tools rely upon. Deploying secure resolvers requires stable IP allocation to maintain global network availability.

Comparative Latency: ISP Speed vs Mullvad Routing Overhead

Mullvad DoH averages 1159.1ms because anycast routing fails to select nearby servers, forcing Australian traffic through distant London nodes. This massive latency gap contrasts sharply with the ISP's 7.4ms median and Cloudflare's 118.8ms middle ground. While Cloudflare DoH was selected as a compromise, being slower than the ISP but notably quicker than Mullvad, the performance delta remains stark. The fastest Mullvad lookup took 1017.2ms, confirming that requests suffered from routing to distant nodes rather than isolated spikes.

Privacy-focused options are not automatically the best choice for latency-sensitive applications. Operators prioritizing speed must recognize that geographic routing failures notably impact performance in this context. Some users accept privacy over speed, yet the thousand-millisecond delay introduces tangible friction absent in local resolution. Regular browsing remains unaffected by Cloudflare's modest delay, yet Mullvad's configuration renders interactive sessions sluggish due to the specific routing path taken. The limitation for using encrypted DNS is qualitatively set as privacy over speed, indicating a measurable but accepted increase in query latency compared to unencrypted.

Implementing Secure DNS Configurations on Windows Systems

Why Windows DNS Cache Blocks Accurate Speed Testing

Standard `Resolve-DnsName` queries return cached entries, masking the true latency of encrypted resolvers. Browsers and the operating system store recent DNS responses to accelerate subsequent connections, causing benchmark tools to measure local disk retrieval rather than network resolution time. This behavior invalidates performance comparisons between unencrypted ISP servers and privacy-focused alternatives. To capture genuine round-trip times, the local database must be purged before every single lookup. The following procedure isolates uncached performance metrics using native PowerShell utilities.

1. Execute `Clear-DnsClientCache` to flush stored records immediately before measurement.
2. Run `Resolve-DnsName` with the `-DnsOnly` flag to force a fresh network query.
3. Repeat this cycle across multiple domains to account for transient routing anomalies.

Neglecting this step yields artificially low latency figures that hide the actual cost of encryption overhead. Validating resolver performance under strict uncached conditions ensures infrastructure decisions reflect real-world user experience. Accurate data reveals whether the privacy trade-off aligns with your specific network constraints.

Configuring PowerShell Scripts for Uncached Resolver Benchmarks

Accurate latency measurement requires flushing the local cache before every single query to prevent false positives from stored records. Standard Windows behavior retains DNS responses, causing benchmark tools to measure disk retrieval rather than genuine network resolution time for encrypted DNS protocols. A script should randomize domain order and clear the cache immediately prior to execution. This approach isolates the encryption overhead inherent in secure transport layers. The author used two specific commands for testing: `Clear-DnsClientCache` and `Resolve-DnsName -Type A -DnsOnly`.

1. Define an array of geographically diverse domains to test against potential routing inefficiencies.
2. Execute `Clear-DnsClientCache` within the loop to guarantee uncached lookups for each iteration.
3. Initialize a high-resolution timer before calling `Resolve-DnsName` with the `-DnsOnly` flag.
4. Capture success status and elapsed milliseconds, appending the row to a results object.
5. Export the final dataset to CSV format for analysis of median and average response times.

The primary trade-off involves the additional processing cycles required to encrypt query payloads, which prevents ISPs from viewing specific domains but increases round-trip duration. While some providers minimize data retention, the cryptographic handshake adds measurable latency compared to plaintext resolution. Routing plays a significant role in overall DNS speed test results, as physical distance and path selection impact latency. Network availability depends on balancing these security guarantees against the performance cost of encryption.

Validating DoH Implementation Against ISP and Mullvad Baselines

Operators must flush the local cache before every query to expose true resolution latency.

1. Execute `Clear-DnsClientCache` immediately prior to each lookup command.
2. Compare observed delays against the Cloudflare baseline, where the average is 136.8ms, the median is 118.8ms, the fastest is 102.4ms, and the slowest is 482.6ms.

The primary cost of deployment is increased query latency, which users weigh against enhanced privacy benefits. While some providers offer a zero-friction setup, others may route connections through distant locations, creating significant lag. This routing inefficiency demonstrates that anycast distribution does not guarantee optimal geographic proximity. Validating these paths helps ensure secure configurations do not introduce unacceptable operational delays. Network availability depends on balancing these encryption requirements with practical performance thresholds.

References

• Privacy-Focused DNS Providers in 2026: Either is a significant
• We’re making Bunny DNS free: We applied our traditional
• DNS Privacy Guide 2025: Stop Your ISP from Tracking