Troubleshoot Windows DNS Client Resolution

When a Windows application cannot reach a hostname, determine whether the client has the expected network configuration, whether its DNS server is reachable, and what answer the server returned. This sequence separates client configuration, transport, record, and cache problems before making changes.

Use an internal hostname and approved DNS server from your environment. Avoid changing DNS server addresses on a domain-joined device until you confirm the intended configuration source, such as DHCP or Group Policy.

---

Step 1: Record the Adapter and DNS Configuration

01

Check the Address, Gateway, Suffix, and DNS Servers

Configuration

Review the active adapter’s IPv4/IPv6 configuration and DNS suffix search list. On a domain client, verify that it is using the organization’s intended DNS resolvers rather than a public resolver that cannot answer internal zones.

Get-NetIPConfiguration
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientGlobalSetting | Select-Object SuffixSearchList

❯ View Expected Console Output

InterfaceAlias : Ethernet
IPv4Address    : 10.20.30.25
IPv4DefaultGateway : 10.20.30.1
ServerAddresses : {10.20.30.10, 10.20.30.11}

Figure 1: Review the adapter’s DNS server assignment in Windows Settings.

---

Step 2: Test DNS Server Reachability and the Record

02

Query the Intended Resolver Directly

Resolution Test

Query the name directly against the configured resolver. A timeout can indicate routing or firewall trouble; an authoritative negative answer points toward the zone or record instead. Test-NetConnection -Port 53 checks TCP port 53 only; DNS queries commonly use UDP, which the direct Resolve-DnsName test exercises.

$DnsServer = '10.20.30.10'
Resolve-DnsName app01.corp.contoso.com -Server $DnsServer
Resolve-DnsName example.com -Server $DnsServer
# Optional TCP-only check; this does not test UDP DNS.
Test-NetConnection $DnsServer -Port 53

❯ View Expected Console Output

Name       Type TTL Section IPAddress
----       ---- --- ------- ---------
app01...   A    300 Answer  10.20.40.15
TcpTestSucceeded : True

Figure 2: Confirm the DNS answer and resolver reachability from PowerShell.

---

Step 3: Compare the Cache with a Fresh Query

03

Inspect Cached Answers Before Flushing Them

Cache Check

Inspect the client cache for the failed name and compare it with the direct resolver response. After the authoritative record is corrected, clear the local cache only if it contains a stale or negative answer, then repeat the query. Clear-DnsClientCache clears the client’s DNS cache, not just this hostname.

$CachedEntries = Get-DnsClientCache | Where-Object Entry -like '*app01*'
$CachedEntries | Format-Table Entry, Type, Data, TimeToLive -AutoSize

if ($CachedEntries) {
  # Run after the authoritative record is corrected and the cached answer is stale.
  Clear-DnsClientCache
  Resolve-DnsName app01.corp.contoso.com
} else {
  Write-Host 'No matching client cache entry was found.'
}

❯ View Expected Console Output

The query returns the current record after the local cache is cleared.

---

Step 4: Confirm the Application Uses the Expected Name

04

Check the Full Name and Application Port

End-to-End

Confirm the application’s configured hostname and whether it uses a suffix. Once resolution is correct, test the actual service port separately; DNS success does not confirm that the server process or network path is accepting connections.

Test-NetConnection app01.corp.contoso.com -Port 443

❯ View Expected Console Output

RemoteAddress    : 10.20.40.15
RemotePort       : 443
TcpTestSucceeded : True

Keep a Before-and-After Record

Record the adapter, DNS servers, queried name, resolver, timestamp, and result before making changes. This helps distinguish client-side issues from authoritative DNS or application problems.

See Microsoft’s DNS client troubleshooting guide for additional checks.