DNS and Socket Diagnostics

Test Names Separately From Connections

Many tickets that read "the network is down" are really DNS, a blocked port, or a stopped local service. DNS and socket tools isolate those pieces. At CCST depth you are not expected to administer DNS or decode every packet, but you must know what evidence each command yields.

DNS maps names to addresses and other records. nslookup ships on Windows and most Unix-like systems; nslookup www.example.com shows whether the name resolves and to which address(es). "Server can't find" or an NXDOMAIN-style message points at the record or a typo; "request timed out"/"no response from server" points at the resolver setting or reachability to it. dig is the Linux/macOS favorite because its output is structured.

Useful dig fields are the status: line (NOERROR, NXDOMAIN, SERVFAIL), the ANSWER SECTION, the SERVER used, the TTL, and the query time. Remember split-horizon DNS: public, internal, and VPN views can intentionally return different answers depending on where the query originates, so comparing the internal resolver against a public one (8.8.8.8) is a powerful test.

Crucially, DNS success does not prove the application works: a name can resolve correctly while a firewall blocks TCP 443, the certificate is expired, or the service is down. DNS failure does not prove a total outage either, if IP works but names fail, you have narrowed the problem to resolution.

Socket and Connection Commands

Socket tools show local network activity, what the host is listening on and what it is connected to. On Windows, netstat -ano lists protocol, local address/port, foreign address/port, TCP state, and the owning process ID (PID) you can map in Task Manager. PowerShell adds Get-NetTCPConnection. On Linux, ss is the modern replacement for netstat: ss -tuln shows TCP/UDP listening sockets numerically, and ss -tunap adds processes when permitted. On macOS, netstat and lsof -i are common.

A listening socket means a local process is waiting for traffic on a protocol/port, for example a web server on TCP 80 or 443. An established connection means an active session exists. Other TCP states are clues but rarely worth deep analysis at this level:

Worked Scenario

A user cannot reach portal.example.com. You run nslookup portal.example.com and it returns 10.20.30.40, so DNS is fine. You then check whether the path to that service works. From the client, a Test-NetConnection 10.20.30.40 -Port 443 (PowerShell) or a browser test fails. You ask the server team to run ss -tuln on the host, and TCP 443 is not in the listening list, the web service is stopped or bound to the wrong interface. DNS pointed you to the right address, and the socket check proved the service, not the network, is at fault.

Had 443 been listening, you would then suspect a firewall between the client and server rather than the service itself.

Comparing DNS Answers

The single most powerful DNS technique at this level is comparing resolvers. Query the configured internal server, then query a public one: nslookup portal.example.com versus nslookup portal.example.com 8.8.8.8. If the internal server returns the correct internal address while the public server returns NXDOMAIN, that is expected split-horizon behavior. If the internal server fails but the public one succeeds for an external name, the internal resolver or its upstream forwarding is broken.

If both fail for a name that should exist, the record itself is missing or the authoritative zone has a problem, which is an escalation, not a client fix.

Common Traps and Privacy

• A port not listening on a server may mean the service is stopped, bound to the wrong address, blocked by host policy, or never installed, do not assume it is a network outage.
• A port that is listening can still be unreachable from afar because of host or network firewalls between client and server.
• Treating a cached DNS answer as authoritative; ipconfig /flushdns clears stale client entries after a record changes.
• Reading too much into transient TCP states like TIME-WAIT, which is normal connection teardown, not a fault.

Connection output exposes internal hostnames, IPs, services, and user activity, so collect only what you need and store it per policy. A useful ticket line: DNS for the intranet name returned 10.20.30.40 from server 10.20.1.10; the client then failed a TCP connection to 10.20.30.40:443 beats "website broken," because it separates the working resolution step from the failing connection step for whoever picks up the ticket next.