PacketTools exists for engineers who want DNS answers they can trust, and picking a resolver is one of the fastest wins you can get on a sluggish network. Every page load starts with name resolution. When your resolver is slow, overloaded, or dropping queries, everything after that first lookup waits, no matter how much bandwidth you pay for.
For Windows users who want the most thorough answer, GRC’s DNS Benchmark v2 is the strongest local option: it measures cached and uncached lookups across IPv4, IPv6, DoH, and DoT resolvers from your own location, and it costs $9.95 one time. If you need something quicker, a browser-based dns speed test gives you a rough ranking in seconds. A command-line tool fits macOS and Linux workflows where you want scripted, repeatable runs.
Whatever tool you choose, the result only holds for your network, your location, and the time you ran it. With the right metrics and a careful verification step, you can switch resolvers on evidence and confirm the change helped.
What Should You Measure Before Switching DNS Servers?
You should measure DNS response time for both cached and uncached names, plus how often each resolver times out or returns the wrong answer. Raw ping to a resolver and download speed tell you very little about lookup performance on their own.
DNS Response Time vs. Ping and Download Speed
DNS response time is the interval between your query leaving the machine and the answer arriving. Ping measures ICMP round trip to an IP address, which shows network distance but skips the resolver’s own work: cache lookups, recursion to authoritative servers, and validation.
A resolver can answer ICMP in 8 ms and still take 120 ms to resolve a name it has never seen. Download speed is even further removed, since a fast pipe does nothing for a slow lookup that happens before the first byte moves.
Treat a ping test as a sanity check for reachability and path length. Use a dedicated DNS tool to measure lookup timing. The impact is large: a slow resolver can add 300 ms or more to every request.
Cached and Uncached Lookups: Why Both Matter
A cached lookup returns a name the resolver already holds in memory, so you are measuring network distance plus a hash lookup. An uncached lookup forces full recursion through root, TLD, and authoritative servers.
Modern pages pull assets from dozens of third-party domains, so cold lookups happen constantly. GRC rebuilt its ranking logic in v2 because v1 exclusively prioritized cached performance, and the newer version weighs uncached lookups at least equally.
In practice, a large anycast resolver often wins on cached names, while your ISP’s resolver can be competitive on uncached ones because it sits close to you. Look at both columns before you decide.
Reliability, Timeouts, and Correct Answers
Speed means nothing if one query in fifty disappears. A lost DNS packet usually costs you a full client retry timeout, often a second or more, which you feel far more than a 10 ms difference in median latency.
Check three things for each candidate:
- Lost or timed-out queries during the run
- NXDOMAIN handling, meaning whether a nonexistent name returns an error or redirects you to an ad page
- Answer correctness for names you know, including internal names if you rely on split DNS
GRC’s tool flags resolvers that intercept and redirect bad domain names, which breaks scripts and monitoring that expect a clean failure.
How Do You Run a Repeatable Test on Your Network?
A repeatable test uses the same tool, the same domain list, and the same resolver set, run several times on an otherwise quiet network. You start by recording your current resolver, add a few public alternatives, and compare across different times of day and connection types.
Choose a Browser-Based or Local Testing Method
Browser-based tests are fast and need no install, but most of them can only send DNS over HTTPS from the browser. That means you are measuring encrypted performance, which differs from the plain UDP port 53 lookups your OS performs by default.
Local tools send real resolver queries. Your main options:
| Method | Platforms | Protocols | Best for |
|---|---|---|---|
| Browser test | Any | Usually DoH only | Quick first look |
| GRC DNS Benchmark v2 | Windows (Linux via WINE) | IPv4, IPv6, DoH, DoT | Deep comparison |
| net-benchmark CLI | Cross-platform | UDP, DoH, DoT, DNSSEC checks | Scripted, repeated runs |
dig / Resolve-DnsName loop |
Linux, macOS / Windows | Plain DNS | Custom domain lists |
GRC v2 tests every resolver with 250 query-sets instead of 50 by default to offset modern internet jitter. Its classic benchmark runs over UDP to port 53, so your firewall must allow that outbound traffic or results will look like total failure.
Identify Your Current Resolver on Windows, macOS, and Linux
You cannot judge an alternative until you know your baseline. Check which resolver each OS is using:
- Windows: run
ipconfig /alland read the DNS Servers line, orGet-DnsClientServerAddressin PowerShell. - macOS: run
scutil --dnsand look at resolver #1, or check System Settings > Network > Details > DNS. - Linux: run
resolvectl statuson systemd-resolved systems. If/etc/resolv.confshows127.0.0.53, that is the local stub, and the real upstream appears inresolvectloutput.
If the only address listed is your router, such as 192.168.1.1, the router is forwarding to the ISP. Log into it to see the true upstream, and include both the router and the upstream in your test.
Compare Your Existing DNS Servers With Public Alternatives
Keep the field small and relevant. Your ISP resolver, your router, and three or four large public resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) cover most decisions.
Add secondary addresses too. Your OS fails over to the secondary when the primary is slow, and a weak secondary drags down real-world experience. GRC notes that your ISP’s servers might be in the wrong order, with the second faster than the first.
Repeat the Same Workload Across Different Times and Network Conditions
Run the test at least three times: a quiet morning, an evening peak, and once over Wi-Fi if you normally test on Ethernet. Stop large downloads, backups, and video calls first, since a saturated link drops packets and makes the remote resolver look unreliable.
Save each run’s export with a timestamp. When evening numbers balloon across every resolver at once, the bottleneck is your link or ISP, and a quick network jitter test during that window helps confirm it.
How Do You Interpret Results Without Chasing the Lowest Number?
Pick the resolver with a low median, a tight p95, and near-zero failures across all your runs, even if another one posted a faster single average. A 4 ms win in one test is noise; consistent tail latency is what you feel while browsing.
Compare Median, p95, and Failure Rates
The median tells you what a normal lookup costs. The p95 shows the slow tail, the lookups that stall a page. Failure rate tells you how often you hit a retry timeout.
A resolver with a 15 ms median and a 300 ms p95 will feel worse than one at 22 ms median and 40 ms p95. GRC applies a 95% confidence threshold before recommending a change, which is why its conclusions sometimes list fewer faster resolvers than the bar chart suggests. Apply the same skepticism to your own numbers.
Account for Resolver Caching and Encrypted Connection Setup
Your first query to a resolver warms its cache for that domain, so the second run of the same list looks faster. Either clear and randomize names for cold tests or deliberately warm up and discard the first pass. Tools such as net-benchmark offer a warmup option whose results are tagged so you can filter them out.
Encrypted DNS adds a one-time TLS handshake. DoH and DoT reuse that connection, so steady-state latency approaches plain DNS, but a short test with few queries overweights the handshake. Flush your local resolver cache between runs as well; the steps to flush DNS cache differ per OS.
Understand Why Location, VPNs, and Test Origin Change the Ranking
Public resolvers use anycast, so “1.1.1.1” points to whichever site your ISP routes you toward. A colleague in another state, or on another carrier, can get the opposite ranking from yours.
A VPN moves your test origin to the VPN exit. Results measured over the tunnel describe the VPN path, and the VPN may override your resolver entirely. Test with the VPN off for your home resolver choice, then separately with it on, and run a DNS leak test to see which resolver answers when the tunnel is up.
Separate Faster Lookups From Better Gaming Ping
DNS resolves a game server’s name once, at connect time. After that, every packet goes straight to the server’s IP, and your resolver plays no part in in-match latency.
What a resolver can change is which CDN or matchmaking region you get, since some services hand out addresses based on resolver location. If gameplay lag is the complaint, look at internet latency and path quality to the game server instead of shaving milliseconds off lookups.
What Security and Privacy Checks Should Accompany Speed Tests?
Alongside speed, confirm whether each resolver performs DNSSEC validation, whether it supports encrypted transport, and what it logs or filters. A fast resolver that rewrites answers or sells query history is a poor trade.
DNSSEC Validation Checks Authenticity, Not Confidentiality
DNSSEC validation lets the resolver verify that signed records came from the zone owner and were not altered in transit. It protects against spoofing and cache poisoning.
It does nothing to hide your queries. Anyone on the path can still see every name you look up. Test validation by querying a deliberately broken signed domain: a validating resolver returns SERVFAIL, while a non-validating one hands back an address. With dig, the ad flag in a response to a signed domain also indicates validation.
Compare Plain DNS, DoH, and DoT Under Equivalent Conditions
Encryption hides your lookups from the local network and ISP. Plain IPv4 and IPv6 DNS offer no security and no privacy, which is why GRC added DoH and DoT benchmarking side by side in v2.
Compare protocols fairly: same resolver operator, same domain list, same number of queries, and connections allowed to stay open. Comparing Cloudflare over DoH against your ISP over UDP mixes two variables and tells you little about either.
Review Logging Policies, Filtering, and NXDOMAIN Behavior
Read each provider’s published privacy policy for how long query logs and source IPs are retained. Filtering resolvers block malware or adult domains, which is useful on purpose and confusing by accident when a legitimate SaaS domain disappears.
NXDOMAIN rewriting is the quiet one. Query a random nonexistent name like qz7x-test-nonexist.com; anything other than an NXDOMAIN response means the resolver redirects typos to its own page. That behavior breaks software that depends on clean failures and should rule a resolver out for admin work.
How Do You Apply and Verify a DNS Change Safely?
Change one device first, confirm it resolves both public and internal names, and only then roll the setting to the router. After the change, verify the active resolver and clear caches so you are testing the new path.
Update Device or Router Settings Without Breaking Internal DNS
On a corporate or homelab network, internal names like fileserver.corp.local live on your internal DNS server. Pointing a domain-joined Windows machine at 1.1.1.1 breaks Active Directory logon, group policy, and internal app access immediately.
For mixed environments, keep clients on internal DNS and change the forwarders on that server to the public resolver you chose. For home networks, set the resolver on one laptop first, then copy it to the router so every device inherits it. The menus differ per OS, and the steps to change DNS settings on Windows, macOS, and Linux cover each. Always set a secondary from a different operator or a second address from the same one.
Confirm the Active Resolver and Account for Local Caches
Settings screens show what you configured, which is not always what is in use. Verify the live path:
- Windows:
Resolve-DnsName example-domain -Type Aand checkipconfig /all; clear withipconfig /flushdns. - macOS:
scutil --dns, thensudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. - Linux:
resolvectl statusandresolvectl flush-caches.
Browsers keep their own cache and may use built-in DoH that bypasses the OS entirely. Check Chrome, Edge, or Firefox secure DNS settings before concluding the OS change failed.
Use PacketTools DNS Lookup and Propagation Checks to Investigate Unexpected Answers
When a site resolves to a different IP after the switch, compare answers instead of guessing. PacketTools DNS Lookup shows the records a name returns, and the DNS propagation checker shows what resolvers in other regions see.
If your new resolver returns an address nobody else does, you are looking at filtering, a stale cache, or geo-based CDN steering. If every region agrees and only your machine differs, the problem is local cache or a hosts file entry. For persistent failures, the broader steps to troubleshoot DNS issues narrow it down. PacketTools logs none of these queries, which keeps internal hostnames you test out of third-party records.
Check Routing and Latency When DNS Is Not the Bottleneck
If lookups are fast and pages still crawl, DNS is done and the path is the problem. Run a traceroute to the slow site and look for the hop where latency jumps and stays high, or where packet loss persists to the destination.
Loss that shows at one middle hop but clears afterward is usually ICMP rate limiting, not a fault. Steady loss from a hop onward points to congestion or a bad link, and knowing how to trace a route properly helps you hand your ISP evidence instead of complaints.
Choose Consistent DNS Performance Over a One-Time Win
The resolver worth keeping is the one with steady DNS response time across quiet hours, peak hours, and both wired and wireless connections. A single dns benchmark run captures one moment on one path; three or four saved runs show you the pattern.
Weigh results in this order:
- Failure rate near zero
- p95 latency low and stable
- Median latency for cached and uncached names
- Security behavior: DNSSEC validation, encrypted transport, clean NXDOMAIN responses
Apply the winner on one device, verify the active resolver, then move it to the router or your internal forwarders. Re-run the same test a week later with the same domain list; if the numbers hold, the change is settled, and if they drift, your saved exports show exactly when.
Leave a Reply