Your internet connection might feel sluggish not because of bandwidth, but because every website visit starts with a DNS lookup — and if your DNS resolver is slow, you feel it on every single page load. Namebench is a free, open-source DNS benchmarking tool that tests dozens of public DNS servers against your actual browsing history to find the fastest resolver for your specific location and ISP. This guide covers everything from downloading and running Namebench correctly to interpreting results, cross-platform differences, and how to apply those results to get real, measurable speed improvements.

What Is Namebench and Why Does It Matter

Namebench was originally built by Google engineers (released as an open-source project) to help users identify whether their ISP-assigned DNS resolver was actually the best choice. It works by querying a configurable list of DNS servers — including Google Public DNS, Cloudflare, OpenDNS, Quad9, and your ISP's own resolvers — using queries drawn from your browser history, Alexa top sites, or a built-in dataset. The result is a ranked report showing mean, median, and 95th-percentile response times for each server, plus checks for censorship, hijacking, and accuracy.

DNS resolution time directly affects time-to-first-byte for every new domain your browser visits. On a page with 30 third-party domains (ads, analytics, CDN assets), a 50ms difference per lookup can add 1.5 seconds of perceived latency. That's not theoretical — benchmarking tools like Namebench make this measurable.

💡 Want to verify which DNS server a domain is currently resolving to before you switch resolvers? Use the DNS Propagation Checker to see live results from multiple global vantage points.

Downloading Namebench in 2026

The original Namebench repository lives at Google Code Archive, but Google Code shut down years ago. The binaries are still widely mirrored, and the source code is available on GitHub. Here's what to grab based on your platform:

  • Windows: Download the namebench-1.3.1-windows.exe installer (self-contained, no Python required). Run as administrator for best results.
  • macOS (Intel): Download namebench-1.3.1-macosx.dmg. On Apple Silicon (M1/M2/M3/M4), run via Rosetta or use the CLI version with Python 3.
  • Linux: Install via source. Clone the GitHub mirror and run with Python 3 (the original targeted Python 2, but community forks support Python 3).
# Linux: Clone and run Namebench via Python 3 fork git clone https://github.com/dnstester/namebench.git cd namebench pip3 install -r requirements.txt python3 namebench.py

On Windows, right-click the installer and choose Run as administrator to allow it to read your browser history from protected profile directories. On macOS Ventura and later, you may need to go to System Settings → Privacy & Security → Open Anyway after the first blocked launch attempt.

Configuring Namebench Before Running a Test

The GUI launcher presents several key settings. Getting these right is the difference between a useful benchmark and a misleading one.

Query Data Source

This is the most important setting. Namebench can pull query targets from:

  • Browser history (Chrome, Firefox, Safari, Internet Explorer) — recommended. This tests DNS servers against domains you actually visit.
  • Alexa top sites — useful if you want a standardized comparison, but may not reflect your real-world usage.
  • Built-in data — a fallback if no browser history is available.

For Chrome on Windows, the history file path is %LOCALAPPDATA%\Google\Chrome\User Data\Default\History. Namebench reads this automatically when you select Chrome as the data source. On macOS, Chrome history lives at ~/Library/Application Support/Google/Chrome/Default/History.

Number of Queries

The default is 250 queries per DNS server. This is a reasonable balance between accuracy and test duration (typically 5–15 minutes). Increasing to 500 gives tighter confidence intervals; dropping to 100 is fine for quick comparisons.

DNS Servers to Test

Namebench pre-loads a list of well-known public resolvers. Make sure these are included:

  • Google Public DNS: 8.8.8.8 / 8.8.4.4
  • Cloudflare: 1.1.1.1 / 1.0.0.1
  • OpenDNS: 208.67.222.222 / 208.67.220.220
  • Quad9: 9.9.9.9 / 149.112.112.112
  • Your ISP's resolver: Check your router's WAN settings for the assigned DNS IP addresses.

You can manually add servers by typing IPs into the "DNS Servers" field, separated by commas.

Include System DNS

Always check this box. Your current system DNS (often your ISP's resolver or your router acting as a forwarder) becomes the baseline. Every result is more meaningful when compared against what you're currently using.

Running the Benchmark

Click Start Benchmark. The tool will cycle through each DNS server, sending queries in parallel and recording response times. A progress bar shows estimated time remaining. Do not use the internet heavily during this period — streaming video or large downloads will skew latency measurements.

When complete, Namebench opens an HTML report in your default browser. It also saves a CSV of raw data to your home directory or the application folder, depending on OS.

Interpreting the Namebench Report

The report can look dense at first. Here's how to read what matters:

The Recommendation Header

At the top, Namebench states something like: "Namebench recommends 1.1.1.1 (41.2ms) over your current 192.168.1.1 (87.4ms), which is 112% faster." This headline uses mean response time. Don't stop here — dig into the detailed table.

Mean vs. Median vs. 95th Percentile

  • Mean (average): Most useful for general comparison. A few very slow outlier responses can inflate this.
  • Median: The midpoint. More resistant to outliers. If mean and median diverge significantly, the server has inconsistent performance.
  • 95th percentile: The worst-case experience for 1 in 20 queries. A server with a fast mean but high 95th percentile will feel janky under load. This is the most important number for perceived performance.

Accuracy and Hijacking Checks

Namebench sends test queries for known domains and checks whether responses are correct. ISP resolvers are notorious for returning fake IP addresses for NXDOMAIN (non-existent domain) responses, redirecting you to a search/ad page. Any resolver flagged with "Incorrect" or "Hijacking" should be eliminated regardless of speed. A fast resolver that lies to you is worse than useless.

Caching Behavior

The report includes a section showing how often each server returned cached responses versus freshly resolved ones. A resolver with a high cache hit rate naturally appears faster — this is valid behavior (caching is good), but it means the numbers represent real-world performance accurately.

💡 After switching DNS servers, use our DNS Lookup tool to confirm your domains are resolving correctly from the new resolver before and after the change.

Applying the Results: Changing Your DNS Server

Once you've identified the fastest, most accurate resolver, apply it at the right layer. Router-level changes affect every device on your network. Device-level changes affect only that machine.

Router-Level DNS Change

Log into your router's admin panel. The correct URL depends on your hardware:

  • Most home routers: http://192.168.1.1 or http://192.168.0.1
  • TP-Link: http://tplinkwifi.net or http://192.168.0.1 → Advanced → Network → DHCP Server → Primary/Secondary DNS
  • ASUS: http://asusrouter.com → WAN → WAN DNS Setting → Connect to DNS Server Automatically → No → enter IPs
  • Netgear Orbi: http://orbilogin.com → Advanced → Setup → Internet Setup → Domain Name Server (DNS) Address
  • Linksys: http://linksyssmartwifi.com → Connectivity → Internet Settings → DNS
  • Netgear Nighthawk/standard: http://routerlogin.net → ADVANCED → Setup → Internet Setup → Domain Name Server (DNS) Address
  • Xiaomi/Mi: http://miwifi.com → Settings → Network → DNS

OpenWrt: Navigate to Network → DHCP and DNS → General Settings → DNS forwardings. Add your chosen server IPs. Optionally enable DNS-over-TLS (DoT) under the Upstream DNS servers section using Stubby or Unbound packages.

DD-WRT: Go to Setup → Basic Setup → Network Address Server Settings (DHCP). Enter Static DNS 1 and Static DNS 2 fields with your chosen IPs.

Windows Device-Level

Open Settings → Network & Internet → [your connection] → DNS server assignment → Edit → Manual. Enter your preferred IPv4 and IPv6 DNS server addresses. For Cloudflare, that's 1.1.1.1 (IPv4) and 2606:4700:4700::1111 (IPv6). For Google, it's 8.8.8.8 and 2001:4860:4860::8888.

# Verify active DNS on Windows (Command Prompt or PowerShell) ipconfig /all | findstr "DNS Servers" # Flush DNS cache after changing ipconfig /flushdns

macOS Device-Level

Go to System Settings → Network → [interface] → Details → DNS. Click the + button to add server IPs. Remove existing ISP entries if you want the new servers exclusively.

# Verify DNS on macOS scutil --dns | grep nameserver # Flush DNS cache on macOS Ventura/Sonoma/Sequoia sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Linux Device-Level

On systemd-based distros (Ubuntu 20.04+, Fedora, Debian 12+), DNS is managed by systemd-resolved. Edit /etc/systemd/resolved.conf and set the DNS line:

# /etc/systemd/resolved.conf [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 # Verify with resolvectl resolvectl status | grep "DNS Servers"

iOS

On iPhone/iPad: Settings → Wi-Fi → tap the (i) next to your network → Configure DNS → Manual → Add Server. iOS does not expose DNS settings for cellular connections without a configuration profile (MDM or manual .mobileconfig installation).

Android

Android 9+ supports Private DNS (DNS-over-TLS): Settings → Network & Internet → Private DNS → Private DNS provider hostname. Use 1dot1dot1dot1.cloudflare-dns.com for Cloudflare or dns.google for Google. For per-network DNS on older Android, you must set a static IP on the Wi-Fi connection and enter DNS servers manually in the connection details.

CLI Verification After Switching

Don't just trust the settings screen — verify with command-line tools that your resolver change actually took effect.

# Linux/macOS: Test resolution time with dig dig @1.1.1.1 example.com A +stats | grep "Query time" # Compare against old resolver dig @8.8.8.8 example.com A +stats | grep "Query time" # Windows: nslookup test nslookup example.com 1.1.1.1 # Linux: Check what resolver resolvectl is using resolvectl query example.com

Common Misdiagnoses and Namebench Caveats

"Namebench Says My ISP Is Fastest — Should I Trust It?"

Sometimes yes. ISP resolvers are geographically close, which produces low latency. But check the accuracy column. ISP resolvers frequently hijack NXDOMAIN responses. Even if they're 10ms faster, returning wrong data for failed lookups makes them unsuitable as a sole resolver.

Results Vary Between Runs

DNS performance varies by time of day, network congestion, and cache state. Run Namebench at least twice — once during peak hours and once during off-peak. Use the result that represents typical usage conditions.

Router as DNS Proxy

Many home routers act as a local DNS proxy: they intercept port 53 queries from devices, forward them to the ISP, and cache results. When Namebench tests 192.168.1.1 as your current DNS, it's testing the router's forwarding overhead plus the ISP resolver — not purely the ISP. If the router is slow or its cache is undersized, bypassing it with device-level DNS settings will show dramatic improvements even with the same upstream resolver.

Namebench on macOS Apple Silicon

The pre-built macOS DMG is x86 only. On M-series Macs, Rosetta 2 handles it transparently in most cases. If the GUI crashes, use the Python CLI version from the GitHub source instead — it runs natively under Python 3 with no architecture issues.

2026 Considerations: IPv6, DoH, DoT, and DNSSEC

Namebench was built in the UDP-over-port-53 era. Modern DNS infrastructure has evolved significantly, and Namebench's results don't account for all of this:

  • DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT): Namebench only benchmarks traditional port 53 UDP/TCP. DoH and DoT add TLS handshake overhead on first connection but benefit from connection reuse and improved privacy. If you care about DoH/DoT performance, use tools like dnsperftest or q (a modern CLI DNS client) for encrypted resolver benchmarking.
  • IPv6: Namebench can test IPv6 resolver addresses. Include 2606:4700:4700::1111 (Cloudflare) and 2001:4860:4860::8888 (Google) in your server list if your network has working IPv6 connectivity. IPv6 DNS paths often differ substantially from IPv4 in latency.
  • DNSSEC: Quad9 (9.9.9.9) validates DNSSEC by default. This adds a small amount of overhead but prevents DNS spoofing attacks. For security-sensitive environments, this tradeoff is worth it. Learn more about DNSSEC validation at the Cloudflare DNS Security Learning Center.
  • Encrypted Client Hello (ECH) and DNS: ECH relies on correct HTTPS record (type 65) resolution. Verify your chosen resolver supports HTTPS record queries — most major public resolvers do as of 2025–2026.

How to Confirm the Fix Worked

After switching DNS servers, run a simple before/after comparison. The easiest method is timing a full page load in your browser's DevTools Network panel (F12 → Network tab → Timing column) and looking at the DNS lookup row. Alternatively, run a quick batch test with dig:

# Batch test: time 10 queries to different domains for domain in google.com youtube.com github.com reddit.com twitter.com; do dig @1.1.1.1 $domain +noall +stats 2>&1 | grep -E "Query time|SERVER" done

If mean query time drops by 30% or more compared to your old resolver, the switch is working. Browser-visible improvements may take a day or two to feel fully consistent because OS and browser DNS caches will need to cycle.

Preventing DNS Slowdowns Long-Term

  • Re-run Namebench quarterly. Resolver performance changes as providers scale or degrade. What was fastest six months ago may not be today.
  • Use two resolvers. Always configure a primary and secondary. If your primary resolver experiences an outage (it happens — even Cloudflare and Google have had incidents), your secondary takes over automatically.
  • Avoid single-provider dependency. Using 1.1.1.1 as both primary and secondary means both point to the same infrastructure. Mix providers: 1.1.1.1 (Cloudflare) primary + 9.9.9.9 (Quad9) secondary gives redundancy across different networks.
  • Monitor with periodic dig checks. Set up a simple cron job on Linux or a Scheduled Task on Windows to time DNS queries and log results. Alert if median latency exceeds 200ms.