Benchmark DNS Servers with PowerShell on Windows: Compare Resolver Speed and Reliability

This is a 15-minute test, requires no third-party benchmark tool, and does not change your DNS settings. It simply asks specified resolvers to answer DNS queries.

What this test measures—and what it does not​

Resolve-DnsName is Windows’ PowerShell DNS query cmdlet. Its -Server parameter lets you target a particular DNS server rather than whichever resolver Windows currently uses. Measure-Command wraps that query and returns the elapsed time. Microsoft documents both cmdlets, and also documents Clear-DnsClientCache as the PowerShell equivalent of flushing the Windows DNS cache.

That makes this a useful real-world comparison, but keep the interpretation honest:

• It measures end-to-end query time from this PC, including local network delay, ISP routing, server response time, and some PowerShell/Windows overhead.
• It does not measure download speeds. DNS is the phone book lookup before the connection, not the connection itself.
• A resolver’s own cache remains part of the result. That is usually desirable: a warm recursive cache is one reason a resolver may feel quicker in ordinary use.
• One result proves almost nothing. The median and the slowest result matter more than a single lucky 8 ms query.

Before you start​

Open Windows PowerShell or PowerShell in Windows Terminal. You do not need to run it as Administrator for the test below.

First, identify the DNS servers currently assigned to your active adapters:

Get-DnsClientServerAddress -AddressFamily IPv4 |
    Where-Object { $_.ServerAddresses } |
    Format-Table InterfaceAlias, ServerAddresses -AutoSize

Include your current router or local resolver in the comparison. For example, a router address such as 192.168.1.1 may be the server your devices actually use. Testing it tells you whether changing DNS at the PC—or at the router—is likely to make a meaningful difference.

Run a quick one-domain check​

Before building a spreadsheet-worthy result set, make sure a candidate responds:

Resolve-DnsName -Name [www.microsoft.com](http://www.microsoft.com) -Type A -Server 1.1.1.1 -DnsOnly -NoHostsFile

Replace 1.1.1.1 with the server you want to test. If the command returns an A record, the target resolver is reachable and answering.

If it times out, do not immediately declare that provider “slow.” A firewall, a router policy, an IPv4/IPv6 mismatch, or an unreachable address may be the actual culprit.

Use the same domains and repeated tests​

The following script tests multiple resolvers against the same set of domains, repeats every query five times, flushes the local Windows DNS cache before each attempt, and records successes separately from failures.

Edit the $Servers list to match the DNS services—or local resolver—you want to compare.

$Servers = @(
    @{ Name = 'Home router'; Address = '192.168.1.1' },
    @{ Name = 'Candidate A'; Address = '1.1.1.1' },
    @{ Name = 'Candidate B'; Address = '8.8.8.8' },
    @{ Name = 'Candidate C'; Address = '9.9.9.9' }
)

$Domains = @(
    '[www.microsoft.com](http://www.microsoft.com)',
    '[www.bing.com](http://www.bing.com)',
    '[www.github.com](http://www.github.com)',
    '[www.cloudflare.com](http://www.cloudflare.com)',
    '[www.wikipedia.org](http://www.wikipedia.org)'
)

$Repeats = 5
$Results = foreach ($Server in $Servers) {
    foreach ($Domain in $Domains) {
        foreach ($Run in 1..$Repeats) {
            Clear-DnsClientCache

            try {
                $Elapsed = Measure-Command {
                    Resolve-DnsName -Name $Domain `
                        -Type A `
                        -Server $Server.Address `
                        -DnsOnly `
                        -NoHostsFile `
                        -ErrorAction Stop | Out-Null
                }

                [pscustomobject]@{
                    Server       = $Server.Name
                    Address      = $Server.Address
                    Domain       = $Domain
                    Run          = $Run
                    Success      = $true
                    Milliseconds = [math]::Round($Elapsed.TotalMilliseconds, 1)
                    Error        = $null
                }
            }
            catch {
                [pscustomobject]@{
                    Server       = $Server.Name
                    Address      = $Server.Address
                    Domain       = $Domain
                    Run          = $Run
                    Success      = $false
                    Milliseconds = $null
                    Error        = $_.Exception.Message
                }
            }
        }
    }
}

$Results |
    Sort-Object Server, Domain, Run |
    Format-Table -AutoSize

The script deliberately uses:

• -Server to test a chosen resolver directly.
• -Type A to request IPv4 address records consistently.
• -DnsOnly so Windows limits the lookup to DNS instead of falling back to name-resolution methods such as LLMNR or NetBIOS.
• -NoHostsFile so a local hosts-file entry cannot skew a result.
• Clear-DnsClientCache to avoid Windows instantly reusing an answer it already knows.

That last point matters. Without cache control, the second run may appear miraculously fast because it never needed to leave the PC. That is not benchmarking; that is timing Windows remembering something.

Turn raw runs into a useful comparison​

After the test, summarize the successful results by average, median, best, worst, and failure count:

$Results |
    Group-Object Server, Address |
    ForEach-Object {
        $Good = $_.Group | Where-Object Success
        $Bad  = $_.Group | Where-Object { -not $_.Success }
        $Times = $Good.Milliseconds | Sort-Object

        [pscustomobject]@{
            Server       = $_.Group[0].Server
            Address      = $_.Group[0].Address
            Queries      = $_.Count
            Successful   = $Good.Count
            Failed       = $Bad.Count
            AverageMs    = if ($Times) { [math]::Round(($Times | Measure-Object -Average).Average, 1) }
            MedianMs     = if ($Times) { [math]::Round($Times[[math]::Floor(($Times.Count - 1) / 2)], 1) }
            FastestMs    = if ($Times) { $Times[0] }
            SlowestMs    = if ($Times) { $Times[-1] }
        }
    } |
    Sort-Object Failed, MedianMs, AverageMs |
    Format-Table -AutoSize

For a fuller report, export every individual attempt:

$Results | Export-Csv -Path "$env:USERPROFILE\Desktop\dns-test-results.csv" -NoTypeInformation

Open that CSV in Excel and look for spikes by domain and resolver. A server that is 2 ms faster on average but occasionally stalls for seconds is not necessarily the better home-network choice.

How to interpret the numbers​

A sensible ranking starts with reliability, then considers typical latency.

Do not overreact to tiny gaps. A difference between 18 ms and 23 ms is measurable but unlikely to transform browsing. A pattern of failures, multi-second retries, or a resolver that is reliably 50–100 ms slower is more likely to be noticeable.

Cache testing: cold Windows cache versus normal browsing​

Flushing Windows’ local cache makes each attempt more comparable, but it does not create a truly cold Internet. The resolver may already have the domain cached, and content platforms often use geographically tailored DNS answers by design.

For a second, more everyday test:

1. Remove or comment out Clear-DnsClientCache.
2. Run the script once.
3. Run it again immediately.
4. Compare the warm-cache results with the first pass.

This shows two useful scenarios:

• First lookup performance: relevant after restarts, cache expiration, or visiting unfamiliar sites.
• Repeat lookup performance: closer to ordinary browsing when the Windows DNS client cache is populated.

Microsoft’s DNS troubleshooting guidance also recommends targeting a resolver directly with Resolve-DnsName when isolating where a resolution problem lives. That distinction is important: testing [www.example.com](http://www.example.com) with no -Server only tests your current configuration, which may be a router, a corporate VPN DNS server, a filtering product, or an ISP resolver—not necessarily the public service you meant to judge.

Common failure points​

Every public resolver times out​

Check whether outbound DNS is blocked or redirected by a router, VPN, security suite, workplace network, or parental-control service. Test a specific target’s basic reachability:

Test-NetConnection 1.1.1.1 -Port 53

A successful TCP port test is not identical to proving that ordinary UDP DNS works, but a failure is a useful warning sign. Microsoft identifies outbound UDP or TCP port 53 filtering as a common cause of Windows DNS resolution failures.

Your router is slower than every public resolver​

That may be normal—or it may mean the router is forwarding queries inefficiently. Before changing every device, rerun the comparison at different times and from a second PC. Wi-Fi interference, roaming, and a busy home network can create misleading outliers.

Results vary wildly by domain​

Keep the domains. Different sites use different DNS providers, record chains, TTL values, geographic steering, and CDN behavior. A resolver that only looks good on one highly cached household-name domain has not earned a gold medal yet.

The “winner” changes tomorrow​

It can. Routing conditions and resolver load are not carved into granite tablets. Test on a normal evening, repeat on another day, and choose the resolver that is consistently responsive rather than chasing a one-time benchmark crown.

Choose based on more than milliseconds​

Once testing identifies two or three reliable candidates, the decision is no longer purely a drag race. Consider:

• Whether the service offers DNS filtering you actually want.
• The provider’s privacy and logging policy.
• DNSSEC validation behavior, where relevant.
• Whether the resolver supports encrypted DNS in the way you plan to deploy it.
• Whether your router, Windows configuration, VPN, or security software will actually use the chosen resolver.

For a straightforward home setup, the best choice is usually the resolver with zero failures, a low median response time, and predictable worst-case performance from the devices and network you use daily. The runner-up separated by a few milliseconds is not a disaster. DNS tuning should remove friction, not become another hobby involving spreadsheets at 2 a.m.—unless, of course, that is the hobby.