Troubleshoot DNS on Windows with Resolve-DnsName

A server responds when you use an IP address, but fails when you use its name. Checking the addresses returned for that name helps separate a DNS problem from a service connection problem. On Windows, Resolve-DnsName provides a useful starting point.

Look up an IPv4 address

Open Windows PowerShell and replace example.com with the hostname you want to check. Enter the hostname alone, without https:// or a URL path.

Resolve-DnsName -Name example.com -Type A -DnsOnly -NoHostsFile

In an A-record answer, IPAddress is the returned IPv4 address. A service can have several addresses, and answers can change between queries.

The example asks for DNS answers and skips the local hosts file. An application’s normal name resolution can involve other conditions, so this test isolates part of the process rather than reproducing every application’s behavior.

Check IPv6 separately

Resolve-DnsName -Name example.com -Type AAAA -DnsOnly -NoHostsFile

AAAA records contain IPv6 addresses. Separate A and AAAA queries make differences easier to see. An absent AAAA record does not by itself mean that a service is unavailable: some services intentionally have only IPv4 records.

See which DNS servers are configured

For a name that should exist only on a company network, check the network interfaces and their configured DNS servers:

Get-DnsClientServerAddress

Look at InterfaceAlias and ServerAddresses. If a VPN or several network connections are active, interpret the list alongside your network’s routing and DNS configuration. The list alone does not prove which path every application used.

Compare a specified DNS server

If your network administrator provides a DNS server for the name, query that server explicitly. The address below is documentation-only; replace it with an appropriate server you are allowed to use.

Resolve-DnsName -Name server.example.com -Type A -Server 192.0.2.53 -DnsOnly -NoHostsFile

This selects the destination of this query. It does not change the PC’s system-wide DNS settings. Internal names may be available only through internal DNS, so querying an external resolver need not produce the same answer.

Use the result to choose the next check

• An address is returned: check that it is the expected destination, then test the service’s TCP port.
• The name is not found: check its spelling and whether it is intended for public or internal DNS.
• The query times out: check access to the resolver and whether a required VPN is connected.

A DNS answer and a successful SSH or web connection are separate results. After checking name resolution, use Test-NetConnection to test the relevant TCP port. Accessing a website directly by IP address also changes hostname-dependent routing and certificate checks, so that comparison alone cannot establish a DNS fault.

Local verification and limits

The commands were run on Windows build 26200 with Windows PowerShell 5.1.26100.9444. A temporary DNS responder listened only on 127.0.0.1; the test used fixture.example.invalid and explicitly selected that responder with -Server 127.0.0.1. The A query returned 192.0.2.10, and the AAAA query returned 2001:db8::10. These are documentation addresses supplied by the fixture.

Get-DnsClientServerAddress also executed successfully and returned objects with the documented ServerAddresses field. No system DNS setting was changed. The normal public or corporate resolver path, VPN routing, and application-specific resolution were not tested in this fixture.

References

• Microsoft Learn: Resolve-DnsName
• Microsoft Learn: Get-DnsClientServerAddress