Troubleshoot DNS Issues with PowerShell

DNS problems are annoying because they rarely announce themselves as DNS problems. An app says the server is down. A browser says the site cannot be reached. A file share times out. Then, after twenty minutes of poking at firewalls and services, you discover the client was asking the wrong resolver the whole time.

PowerShell gives you a faster path. Instead of guessing, you can test name resolution, inspect DNS client settings, check port reachability, clear stale cache entries, and compare answers from different DNS servers from one console.

In this tutorial, you’ll use PowerShell to troubleshoot the DNS issues Windows admins run into most: bad client configuration, stale cache, missing records, broken forwarding, and name resolution that works on one machine but not another.

Prerequisites

To follow along, you’ll need:

• A Windows 10, Windows 11, or Windows Server computer with PowerShell 5.1 or later.

• Permission to run PowerShell locally. Run as administrator for cache and adapter changes.

• The name of at least one internal host or public DNS name you can test.

• Optional access to a DNS server if you want to inspect server-side zones and records.

Related: Getting Started with PowerShell

Start With the Symptom

Before you run commands, write down what is actually failing. DNS troubleshooting goes sideways when you test the wrong thing.

Ask one question first: is the problem name resolution, connectivity, or the application?

Symptom	Likely area	First PowerShell command
Name does not resolve	DNS lookup	Resolve-DnsName
Name resolves to the wrong IP	Record or cache	Resolve-DnsName, Get-DnsClientCache
Name resolves but app fails	Network or service	Test-NetConnection
One computer works and another fails	Client config	Get-DnsClientServerAddress
Internal names fail but internet names work	DNS suffix, zone, or forwarding	Resolve-DnsName, Get-DnsClient

The rest of the workflow follows that order. Confirm the name, confirm the DNS server, confirm the cache, then confirm connectivity.

Test Name Resolution with Resolve-DnsName

The Resolve-DnsName cmdlet is the first command to reach for because it asks DNS a direct question and shows the answer. It is the PowerShell replacement for most quick nslookup checks.

Run a simple lookup first.

Resolve-DnsName -Name adamtheautomator.com

If DNS is working, you’ll see one or more records returned. For a web site, the useful fields are usually Name, Type, IPAddress, and NameHost.

Now test the exact record type you expect.

Resolve-DnsName -Name adamtheautomator.com -Type A
Resolve-DnsName -Name adamtheautomator.com -Type AAAA
Resolve-DnsName -Name adamtheautomator.com -Type MX

Specifying the record type matters. A domain can have working mail records and broken web records, or working IPv4 records and no IPv6 records. If you only run a generic lookup, you may miss the actual failure.

Related: Microsoft Resolve-DnsName documentation

Query a Specific DNS Server

A client’s default resolver may not be the server you think it is. To remove that uncertainty, query a specific DNS server.

Resolve-DnsName -Name fileserver01.contoso.com -Server 10.10.1.10

Then compare the answer with a public resolver.

Resolve-DnsName -Name adamtheautomator.com -Server 1.1.1.1
Resolve-DnsName -Name adamtheautomator.com -Server 8.8.8.8

If one DNS server returns an answer and another does not, the problem is not the client application. The problem is resolver-specific. That usually points to one of these issues:

• The internal DNS server is missing the record.

• A conditional forwarder is broken.

• A public resolver cannot see an internal-only zone.

• Replication between DNS servers has not completed.

• A stale record exists on one resolver but not another.

This comparison is especially useful during migrations. If one domain controller has the new record and another does not, clients will appear to fail randomly depending on which resolver they use.

Check Which DNS Servers the Client Uses

Once you know a lookup fails from one computer, check which DNS servers that computer is using.

Get-DnsClientServerAddress -AddressFamily IPv4

You’ll see each network interface and its configured DNS server addresses. Look for the active adapter. VPNs, Wi-Fi, Ethernet, and virtual adapters can all have their own resolver list.

For a cleaner view, filter to adapters that are up.

Get-NetAdapter |
  Where-Object Status -eq 'Up' |
  Get-DnsClientServerAddress -AddressFamily IPv4

If the client points to an old DNS server, a home router, or a public resolver when it should use internal DNS, name resolution will fail for internal hosts. Fix the adapter, DHCP scope, VPN profile, or network policy that supplied the wrong resolver.

Related: Microsoft Get-DnsClientServerAddress documentation

Inspect and Clear the DNS Client Cache

Windows caches DNS answers locally. That cache is useful until it preserves a bad answer.

Inspect the cache.

Get-DnsClientCache | Where-Object Entry -like '*fileserver*'

If you find an old address, clear the cache.

Clear-DnsClientCache

Then run the lookup again.

Resolve-DnsName -Name fileserver01.contoso.com

Clearing the cache is not a fix by itself. It is a way to prove whether the client had stale information. If the wrong answer returns immediately after clearing the cache, the bad data is coming from a DNS server, not the local client.

Related: Microsoft Clear-DnsClientCache documentation

Test Connectivity After DNS Resolves

A successful DNS lookup only proves that a name maps to an address. It does not prove the service is reachable.

Use Test-NetConnection after DNS resolves.

Test-NetConnection -ComputerName fileserver01.contoso.com -Port 445

For a web server, test HTTPS.

Test-NetConnection -ComputerName adamtheautomator.com -Port 443

Look at TcpTestSucceeded. If DNS resolves but the TCP test fails, move your troubleshooting to routing, firewall rules, service bindings, or the application. DNS already did its job.

This sequence prevents a common mistake: blaming DNS because a name was involved. If name resolution succeeds and the port is blocked, changing DNS records will not help.

Related: Microsoft Test-NetConnection documentation

Check DNS Suffix Search Behavior

Short names are convenient until they hide the real query. When a user types fileserver01, Windows may append DNS suffixes such as corp.contoso.com or contoso.local.

Check the DNS client configuration.

Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, RegisterThisConnectionsAddress

Then test the fully qualified domain name.

Resolve-DnsName -Name fileserver01.corp.contoso.com

If the fully qualified name works but the short name fails, the DNS record may be fine. The suffix search list or connection-specific suffix may be the problem.

This is common on VPN clients. A machine on the office network may append the right suffix, while the same laptop on VPN may not. The result feels random until you compare the exact names being queried.

Compare Working and Broken Clients

When one computer works and another does not, compare them side by side. PowerShell makes this quick.

On both machines, run:

$target = 'fileserver01.contoso.com'

[pscustomobject]@{
    ComputerName = $env:COMPUTERNAME
    DnsServers   = (Get-DnsClientServerAddress -AddressFamily IPv4 |
                    Where-Object ServerAddresses |
                    Select-Object -ExpandProperty ServerAddresses) -join ', '
    Lookup       = (Resolve-DnsName -Name $target -ErrorAction SilentlyContinue |
                    Where-Object IPAddress |
                    Select-Object -First 1 -ExpandProperty IPAddress)
}

You are looking for differences, not perfection. If the working client uses 10.10.1.10 and the broken client uses 192.168.1.1, you have your lead. If both clients use the same resolver but get different answers, check cache, DNS server load balancing, or record replication.

Troubleshoot Common DNS Failures

Use the table below as a quick decision guide.

Problem	What you’ll see	What to do
Wrong DNS server	Get-DnsClientServerAddress shows an unexpected resolver	Fix DHCP, VPN, or adapter settings
Stale client cache	Get-DnsClientCache shows an old record	Run Clear-DnsClientCache, then retest
Missing record	Resolve-DnsName returns no answer from the authoritative internal server	Create or repair the DNS record
Wrong record	Lookup returns an old IP address	Update the record and verify TTL behavior
Connectivity failure	DNS resolves but Test-NetConnection fails	Check firewall, routing, service state, or load balancer
Short name failure	FQDN works but short name fails	Fix DNS suffix search behavior
Inconsistent answers	Different DNS servers return different results	Check zone replication, forwarding, and stale data

The important habit is to prove each layer before moving on. DNS troubleshooting gets simpler when you stop treating every failure as one big problem.

Build a Repeatable DNS Test Script

Once you know the commands, wrap them into a small function you can reuse.

function Test-DnsPath {
    param(
        [Parameter(Mandatory)]
        [string]$Name,

        [int]$Port = 443,

        [string[]]$DnsServer
    )

    foreach ($server in $DnsServer) {
        Resolve-DnsName -Name $Name -Server $server -ErrorAction SilentlyContinue |
            Select-Object @{Name='Server';Expression={$server}}, Name, Type, IPAddress, NameHost
    }

    Resolve-DnsName -Name $Name -ErrorAction SilentlyContinue |
        Select-Object @{Name='Server';Expression={'ClientDefault'}}, Name, Type, IPAddress, NameHost

    Test-NetConnection -ComputerName $Name -Port $Port |
        Select-Object ComputerName, RemoteAddress, RemotePort, TcpTestSucceeded
}

Run it like this:

Test-DnsPath -Name adamtheautomator.com -Port 443 -DnsServer 1.1.1.1,8.8.8.8

This function does three things in one pass: compares resolvers, tests the client default resolver, and checks the target port. That is enough to separate most DNS failures from network failures without opening three different tools.

Keep DNS Troubleshooting Boring

DNS troubleshooting should be boring. Ask the same questions in the same order every time.

First, can the client resolve the name? Second, which DNS server answered? Third, is the client using the right DNS servers? Fourth, is the cache stale? Fifth, does the resolved address actually accept traffic on the expected port?

PowerShell gives you direct answers to each question. Use Resolve-DnsName for the lookup, Get-DnsClientServerAddress for resolver configuration, Get-DnsClientCache and Clear-DnsClientCache for local cache problems, and Test-NetConnection when DNS is done and the network path is the next suspect.

Follow that sequence and DNS stops feeling mysterious. It becomes just another layer you can test, prove, and move past.