DNS or connectivity? Prove which one.

A hostname failing does not automatically mean DNS is broken. Test resolution and the actual service connection separately so you know which layer to investigate.

1. Inspect the DNS answer

Resolve-DnsName -Name example.com -Type A

Check the address returned against the expected destination. An unexpected answer may point to an incorrect record, split DNS or a stale cache. A failure can also mean the record does not exist.

2. Query a specific resolver

Resolve-DnsName -Name example.com -Type A -Server 192.0.2.53

Replace the documentation address with your actual DNS server. Comparing resolvers helps reveal inconsistent answers. Internal names should be checked against the intended internal resolver, rather than sent to a public service.

3. Test the service port

Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel Detailed

Inspect RemoteAddress and TcpTestSucceeded. A successful DNS lookup with a failed TCP test shifts attention towards routing, filtering, the destination host or its listener.

Interpret the result

• DNS fails: check the queried name, DNS server configuration and resolver reachability.
• DNS works, TCP fails: check the route, firewall and destination service.
• TCP works, the application fails: investigate TLS, authentication and application behaviour next.

A TCP connection test does not validate TLS certificates or prove the application is healthy. Testing port 53 with this tool checks TCP, not UDP DNS behaviour.

References

Resolve-DnsName documentation · Test-NetConnection documentation