Windows DNS resolution investigation cheat sheet
Separate resolver selection, stale cache, missing records and service reachability in a Windows DNS incident.
Windows 10/11 or Windows Server; PowerShell DnsClient and NetTCPIP modules.
Updated · Windows · 6 min read
| Command | What it does |
|---|---|
Get-DnsClientServerAddress -AddressFamily IPv4 | Identify configured IPv4 resolvers |
Resolve-DnsName app.corp.example -Type A -DnsOnly | Query the client DNS path |
Resolve-DnsName app.corp.example -Server 10.20.0.10 -Type A -DnsOnly | Ask a selected resolver directly |
Get-DnsClientCache | Where-Object Entry -eq "app.corp.example" | Inspect matching local cache entries |
Resolve-DnsName app.corp.example -Server 10.20.0.10 -Type AAAA -DnsOnly | Check the IPv6 answer separately |
Test-NetConnection 10.20.1.25 -Port 443 -InformationLevel Detailed | Test TCP against the expected address |
Walkthrough
Replace app.corp.example, 10.20.0.10 and 10.20.1.25 with your internal service, resolver and expected address. Run from the affected client; queries and connection tests send traffic.
Step 1: Identify configured IPv4 resolvers
Get-DnsClientServerAddress -AddressFamily IPv4
Match InterfaceAlias to the adapter carrying this connection. VPN and physical adapters can use different resolvers. These are configured addresses, not proof that a query reached a server; record the adapter and resolver before testing.
Step 2: Query the client DNS path
Resolve-DnsName app.corp.example -Type A -DnsOnly
Inspect the returned IPv4 addresses, aliases and TTLs. NXDOMAIN means the queried name does not exist according to that response; a timeout means no usable response arrived. Do not interpret those outcomes as the same fault.
Step 3: Ask a selected resolver directly
Resolve-DnsName app.corp.example -Server 10.20.0.10 -Type A -DnsOnly
Compare this answer with the default query. A difference can indicate resolver selection, split DNS, replication lag or cache state. Query the other intended internal resolver as well before deciding that a record is incorrect.
Step 4: Inspect matching local cache entries
Get-DnsClientCache | Where-Object Entry -eq "app.corp.example"
Compare cached data and remaining TTL with the intended record. An absent entry does not prove that the application has no cache of its own. Capture the evidence before considering an approved cache clear; this command changes nothing.
Step 5: Check the IPv6 answer separately
Resolve-DnsName app.corp.example -Server 10.20.0.10 -Type AAAA -DnsOnly
An application can prefer IPv6 even when IPv4 is healthy. Compare any AAAA answer with the supported application path. No AAAA record is normal for an IPv4-only service; investigate an unexpected record rather than disabling IPv6.
Step 6: Test TCP against the expected address
Test-NetConnection 10.20.1.25 -Port 443 -InformationLevel Detailed
Inspect TcpTestSucceeded, SourceAddress and InterfaceAlias. A successful IP-based TCP connection separates basic reachability from name resolution, but does not validate the certificate, HTTP host routing or application login.
WORKED INCIDENT
Practical case: The intranet works by IP but not by name
Fictional teaching scenario; observations are examples, not captured production output.
Situation
After a VPN change, a user cannot open app.corp.example. The expected internal IPv4 address is 10.20.1.25.
Investigation sequence
1. Identify configured IPv4 resolvers
Get-DnsClientServerAddress -AddressFamily IPv4Record the VPN and LAN resolver lists. Establish which connection is active and retain both lists for the network team.
2. Query the client DNS path
Resolve-DnsName app.corp.example -Type A -DnsOnlyCapture the default answer and error type. In this example the default lookup returns NXDOMAIN.
3. Ask a selected resolver directly
Resolve-DnsName app.corp.example -Server 10.20.0.10 -Type A -DnsOnlyQuery the intended internal resolver. It returns 10.20.1.25, so the name exists on that DNS path.
4. Inspect matching local cache entries
Get-DnsClientCache | Where-Object Entry -eq "app.corp.example"Check for a cached result before changing anything. An old negative answer may persist for its negative-cache lifetime.
5. Test TCP against the expected address
Test-NetConnection 10.20.1.25 -Port 443 -InformationLevel DetailedTest the expected IP and service port. A successful connection narrows the incident toward DNS selection or caching.
Example findings
Illustrative findings: default lookup = NXDOMAIN; selected internal resolver = 10.20.1.25; TcpTestSucceeded = True.
Interpret the findings
The internal record and TCP service are available in this example. The failing client DNS path deserves investigation; these findings do not prove whether the VPN policy, resolver order or a cache is responsible.
Verify the outcome
After the DNS or VPN owner applies the approved correction, repeat the default A and AAAA queries, then open the application by name and verify its certificate and login from the affected client.
Escalation handoff
Escalate with the query time, adapter, VPN state, both resolver answers and expected record. Ask the DNS owner to compare authoritative data and split-DNS policy.
Microsoft Resolve-DnsName reference