Every time you open a browser tab, your device fires off a DNS query before a single byte of page content moves. If your DNS resolver is slow, sluggish, or geographically distant, you pay that penalty on every new connection, every redirect, and every third-party resource load. Switching to a faster DNS server is one of the highest-return, lowest-effort network tweaks available, yet most people are still using the default resolver their ISP assigned years ago. This guide walks through exactly how to benchmark DNS resolvers, interpret the results, and apply the change on every major platform so you stop leaving free speed on the table.

Why DNS Speed Actually Matters

DNS resolution happens before the TCP connection, before TLS negotiation, and before the first HTTP request. A slow lookup does not just delay one asset, it delays the entire chain that follows. Modern web pages typically trigger 20 to 80 DNS lookups as the browser loads analytics scripts, CDN assets, fonts, and ad networks. Even if each lookup only costs an extra 30 ms compared to a faster resolver, that compounds quickly across a page load.

The primary metrics you care about are:

  • Latency (RTT): The round-trip time from your machine to the resolver and back with an answer. Lower is better. Measured in milliseconds.
  • Cache hit rate: Popular resolvers like Google and Cloudflare serve millions of users globally, so popular domains are nearly always pre-cached. A cache hit can return in single-digit milliseconds.
  • Reliability and uptime: A fast resolver that occasionally drops queries or returns SERVFAIL errors is worse than a slightly slower one with 99.99% uptime.
  • DNSSEC validation: Some resolvers validate DNSSEC signatures, adding marginal latency but improving security against cache poisoning.

The Main Public DNS Resolvers Worth Testing

Before running any benchmarks, you need a shortlist of candidates. These are the resolvers most worth measuring:

  • Cloudflare (1.1.1.1 / 1.0.0.1): Consistently fastest in independent benchmarks for most North American and European locations. Privacy-focused, no query logging for advertising.
  • Google Public DNS (8.8.8.8 / 8.8.4.4): Enormous anycast footprint, excellent cache hit rates, reliable uptime. Slightly slower than Cloudflare in raw latency tests but rarely by more than 5 to 10 ms.
  • Quad9 (9.9.9.9 / 149.112.112.112): Blocks known malicious domains using threat intelligence feeds. Slightly higher latency in some regions but adds meaningful security value.
  • OpenDNS (208.67.222.222 / 208.67.220.220): Long-standing alternative with optional content filtering. Owned by Cisco. Good anycast coverage.
  • NextDNS: Configurable per-account resolver with logging, filtering, and analytics. Variable latency depending on your selected node.
  • Your ISP default: Always include this as a baseline. ISP resolvers are sometimes the fastest option if the ISP has a node nearby, though they often monetize NXDOMAIN responses and log queries.

Method 1: Command-Line Benchmarking on Windows

The quickest manual approach on Windows is Resolve-DnsName in PowerShell combined with timing, or the classic nslookup with multiple resolvers. For a proper statistical sample, use the open-source tool namebench or run a timed loop in PowerShell.

To get a rough latency figure for a single resolver in PowerShell:

$resolver = "1.1.1.1" $domain = "www.google.com" $start = Get-Date Resolve-DnsName -Name $domain -Server $resolver | Out-Null $elapsed = (Get-Date) - $start Write-Output "Resolved in $($elapsed.TotalMilliseconds) ms"

Run this block replacing 1.1.1.1 with each resolver IP in your list. For a more repeatable measurement, loop 10 times and average the results:

$resolvers = @("1.1.1.1","8.8.8.8","9.9.9.9","208.67.222.222") $domains = @("www.youtube.com","www.amazon.com","www.reddit.com","www.github.com","www.netflix.com") foreach ($r in $resolvers) { $total = 0 foreach ($d in $domains) { $start = Get-Date Resolve-DnsName -Name $d -Server $r -ErrorAction SilentlyContinue | Out-Null $total += ((Get-Date) - $start).TotalMilliseconds } Write-Output "$r avg: $([math]::Round($total / $domains.Count, 1)) ms" }

This script tests five popular domains per resolver and prints the average. The domains were deliberately chosen because they are widely cached on major public resolvers, so you are measuring network latency and anycast routing rather than upstream resolution time.

Method 2: Command-Line Benchmarking on macOS and Linux

On macOS and Linux, dig from the bind-utils package (or pre-installed on macOS) is the standard tool. The +stats flag outputs query time at the bottom of each response.

# Single query timing dig @1.1.1.1 www.youtube.com +stats | grep "Query time" # Loop across multiple resolvers for resolver in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do total=0 for domain in www.youtube.com www.amazon.com www.reddit.com www.github.com www.netflix.com; do ms=$(dig @$resolver $domain +stats 2>/dev/null | grep "Query time" | awk '{print $4}') total=$((total + ms)) done avg=$(echo "scale=1; $total / 5" | bc) echo "$resolver avg: ${avg} ms" done

Run this in Terminal. On macOS, bc is pre-installed. On Ubuntu or Debian, install dig with sudo apt install dnsutils. On Fedora or RHEL, use sudo dnf install bind-utils.

Method 3: Using namebench for a Full Automated Report

If you want a comprehensive benchmark without scripting, namebench is a free open-source utility that tests dozens of resolvers from your actual location, uses your real browser history as the query dataset, and generates an HTML report with a ranked list. Download it from the Google Code archive or its GitHub mirror. It runs on Windows, macOS, and Linux with Python.

After launching namebench, the defaults are usually fine: it will pull your current DNS settings, add a built-in list of public resolvers, and run 250 queries per resolver. The report shows mean, median, and minimum response times plus a recommendation for the fastest configuration from your network.

If you have already changed your DNS and want to confirm the new resolver is returning correct records globally, run a check with our DNS Propagation Checker to verify resolution from multiple worldwide vantage points.

Interpreting Your Benchmark Results

Raw millisecond averages tell most of the story, but look at a few additional factors before committing to a resolver:

  • Outliers and spikes: A resolver with a 5 ms average but occasional 300 ms spikes will feel slower in practice than one with a consistent 15 ms. Check the maximum values in your results.
  • Cache miss performance: If you benchmark with obscure or newly registered domains, you are testing the resolver's ability to perform full recursive lookups. For most users, cache hit performance on popular domains is more representative of real browsing.
  • IPv6 performance: If your network supports IPv6, test AAAA record resolution separately. Some resolvers have better IPv6 anycast coverage than IPv4.

How to Change Your DNS Server

Once you have identified the fastest resolver, apply the change at the operating system level or on your router. Changing it on the router propagates the setting to all devices on the network automatically.

Windows 11 and Windows 10

  1. Open Settings, then Network and Internet.
  2. Click your active connection (Ethernet or Wi-Fi), then click Hardware properties (Win11) or Change adapter options (Win10).
  3. Right-click the adapter, select Properties, then double-click Internet Protocol Version 4 (TCP/IPv4).
  4. Select Use the following DNS server addresses and enter your preferred and alternate resolver IPs.
  5. Click OK, then repeat for IPv6 if needed using the Internet Protocol Version 6 (TCP/IPv6) entry.

macOS

  1. Open System Settings (or System Preferences on older macOS), then Network.
  2. Select your active connection and click Details (or Advanced on older macOS).
  3. Click the DNS tab and use the plus button to add your preferred resolver IPs.
  4. Click OK, then Apply.

Linux (systemd-resolved)

On modern Ubuntu, Fedora, and most systemd-based distributions, edit the resolved configuration:

sudo nano /etc/systemd/resolved.conf # Add or modify these lines under [Resolve]: DNS=1.1.1.1 1.0.0.1 FallbackDNS=8.8.8.8 8.8.4.4 DNSSEC=yes # Restart the service sudo systemctl restart systemd-resolved

Router-Level Change (Recommended for All Devices)

Changing DNS at the router means every device on your network, phones, smart TVs, consoles, benefits without individual configuration. Access your router admin panel using the appropriate address for your hardware:

  • TP-Link: tplinkwifi.net or 192.168.0.1
  • Netgear: routerlogin.net or 192.168.1.1
  • ASUS: asusrouter.com or 192.168.1.1
  • Linksys: 192.168.1.1
  • D-Link: 192.168.0.1

Log in, navigate to the DHCP or LAN settings section (sometimes labeled DHCP Server or Local Network), and look for the Primary DNS and Secondary DNS fields. Enter your two resolver IPs, save, and let the router restart if required. Existing device leases may need to be renewed; on most devices a Wi-Fi toggle or ipconfig /release && ipconfig /renew on Windows handles that.

Verifying the Change Worked

After applying the new resolver, confirm your device is actually using it rather than falling back to a cached or overridden setting.

On Windows:

nslookup whoami.cloudflare.com 1.1.1.1 # Should return your IP if using Cloudflare's resolver

A cleaner verification uses the Cloudflare and Google resolver diagnostic domains:

# Verify Cloudflare resolver nslookup whoami.cloudflare.com # Verify Google resolver nslookup o-o.myaddr.l.google.com ns1.google.com

You can also use our DNS Lookup tool to check how your chosen records resolve from outside your network and confirm global visibility.

DNS over HTTPS and DNS over TLS

Standard DNS queries travel in plaintext over UDP port 53. Anyone between your device and the resolver, your ISP, a coffee shop access point, a compromised router, can see every domain you query. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query stream, preventing interception.

Windows 11 supports DoH natively in the DNS settings dialog, where you can select Encrypted only (DNS over HTTPS) for any configured resolver. Cloudflare's DoH endpoint is https://cloudflare-dns.com/dns-query and Google's is https://dns.google/dns-query. Firefox has its own DoH implementation under Settings, Privacy and Security, that operates independently of the OS resolver.

The latency overhead of DoH compared to plain DNS is typically 5 to 20 ms for the initial connection due to TLS handshake, but subsequent queries over the same connection are fast. For most users, the security benefit outweighs this marginal cost.

How to Prevent DNS Latency Problems Going Forward

  • Use two resolvers from different providers. Set your primary to Cloudflare and your secondary to Google, or vice versa. If one has an outage or routing issue, the system automatically falls back.
  • Test periodically. ISP network topology changes, new anycast nodes come online, and resolver performance shifts over time. Re-run your benchmark every six to twelve months.
  • Enable DNSSEC validation. Cloudflare and Google both validate DNSSEC by default, protecting you from cache poisoning without requiring client-side configuration.
  • Avoid using only one resolver. A single-resolver setup with no fallback means any resolver-side issue causes total DNS failure for your network.
  • Consider split DNS for remote work. If you VPN into a corporate network, confirm your VPN client is routing internal domain queries through the corporate resolver while external queries go through your fast public resolver. Leaking all DNS over a slow corporate tunnel is a common cause of perceived DNS slowness.

Quick Reference: Top Public DNS Resolver IPs

  • Cloudflare: 1.1.1.1 and 1.0.0.1 (IPv6: 2606:4700:4700::1111 and 2606:4700:4700::1001)
  • Google: 8.8.8.8 and 8.8.4.4 (IPv6: 2001:4860:4860::8888 and 2001:4860:4860::8844)
  • Quad9: 9.9.9.9 and 149.112.112.112 (IPv6: 2620:fe::fe and 2620:fe::9)
  • OpenDNS: 208.67.222.222 and 208.67.220.220

DNS speed is one of those infrastructure details that is invisible when it works well and infuriating when it does not. Spending twenty minutes running a benchmark and applying the optimal resolver to your router is a permanent improvement that every device on your network benefits from immediately. The scripts and steps above give you everything needed to make a data-driven decision rather than a guess.