--- title: "Troubleshoot DNS Issues with PowerShell" description: "Troubleshoot DNS issues with PowerShell by testing name resolution, DNS client settings, cache entries, and network connectivity in a repeatable workflow." canonical: "https://adamtheautomator.com/troubleshoot-dns-issues-powershell/" --- # Troubleshoot DNS Issues with PowerShell > Troubleshoot DNS issues with PowerShell by testing name resolution, DNS client settings, cache entries, and network connectivity in a repeatable workflow. Source: https://adamtheautomator.com/troubleshoot-dns-issues-powershell/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Troubleshoot DNS Issues with PowerShell](https://adamtheautomator.com/wp-content/uploads/2026/06/26995-troubleshoot-dns-issues-powershell-codex.webp) # Troubleshoot DNS Issues with PowerShell [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)15 June 20266 min. read Categories: [IT Ops](/category/it-ops/) Tags:[DNS](/tag/dns/)[Networking](/tag/networking/)[PowerShell](/tag/powershell/)[windows server](/tag/windows-server/) Table of Contents * [Prerequisites](#prerequisites) * [Start With the Symptom](#start-with-the-symptom) * [Test Name Resolution with Resolve-DnsName](#test-name-resolution-with-resolve-dnsname) * [Query a Specific DNS Server](#query-a-specific-dns-server) * [Check Which DNS Servers the Client Uses](#check-which-dns-servers-the-client-uses) * [Inspect and Clear the DNS Client Cache](#inspect-and-clear-the-dns-client-cache) * [Test Connectivity After DNS Resolves](#test-connectivity-after-dns-resolves) * [Check DNS Suffix Search Behavior](#check-dns-suffix-search-behavior) * [Compare Working and Broken Clients](#compare-working-and-broken-clients) * [Troubleshoot Common DNS Failures](#troubleshoot-common-dns-failures) * [Build a Repeatable DNS Test Script](#build-a-repeatable-dns-test-script) * [Keep DNS Troubleshooting Boring](#keep-dns-troubleshooting-boring) # 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](https://adamtheautomator.com/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. ```powershell 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. ```powershell 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](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) ## 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. ```powershell Resolve-DnsName -Name fileserver01.contoso.com -Server 10.10.1.10 ``` Then compare the answer with a public resolver. ```powershell 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. ```powershell 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. ```powershell 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](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientserveraddress) ## 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. ```powershell Get-DnsClientCache | Where-Object Entry -like '*fileserver*' ``` If you find an old address, clear the cache. ```powershell Clear-DnsClientCache ``` Then run the lookup again. ```powershell 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](https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache) ## 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. ```powershell Test-NetConnection -ComputerName fileserver01.contoso.com -Port 445 ``` For a web server, test HTTPS. ```powershell 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](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) ## 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. ```powershell Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, RegisterThisConnectionsAddress ``` Then test the fully qualified domain name. ```powershell 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: ```powershell $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. ```powershell 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: ```powershell 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. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Ftroubleshoot-dns-issues-powershell%2F&text=Troubleshoot%20DNS%20Issues%20with%20PowerShell)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Ftroubleshoot-dns-issues-powershell%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Ftroubleshoot-dns-issues-powershell%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/2023/03/powershell-ip-configuration.jpg) ### [PowerShell IP Configuration: A Beginner’s Guide to Windows Settings](/powershell-ip-configuration/) Master PowerShell IP Configuration: Learn to set up and troubleshoot network IPs on Windows effortlessly. A comprehensive guide for efficient network management. ![](https://adamtheautomator.com/wp-content/uploads/2019/06/photo-1516382799247-87df95d790b7.jpg) ### [Finding PowerShell Last Logon by User Logon Event ID](/user-logon-event-id/) Learn how to build a user activity PowerShell script that will pull information from the Windows event log for a local computer. ![](https://adamtheautomator.com/wp-content/uploads/2021/02/How-to-Create-Checksums-in-Windows-Built-in-and-Third-Party-Tools.jpg) ### [Create Checksum in Windows and Verify File Integrity](/checksum-windows/) Learn in this in-depth article that covers nearly all the ways to generate checksums in Windows using built-in and third-party tools. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)