DNS and Socket Diagnostics

Test Names, Ports, and Connections Separately

Many user complaints sound like the network is down when the actual problem is DNS, a blocked port, or a stopped local service. DNS and socket tools help you test those pieces separately. For CCST-level troubleshooting, you do not need to become a DNS administrator or packet analyst, but you should know what evidence each command provides.

DNS maps human-friendly names to IP addresses and other records. If a user says a website will not open, test both the name and the address when possible. nslookup is available on Windows and many Unix-like systems. It can query the configured DNS resolver by default or a specified DNS server. A simple nslookup www.example.com shows whether the name resolves and what address or addresses are returned. If it says the server cannot be reached, check the client's DNS server settings and connectivity to that resolver.

If it returns a non-existent domain style error, check the spelling, search suffix behavior, and whether the record should exist.

dig is common on Linux and macOS and is often preferred by DNS-focused technicians because its output is structured and detailed. dig example.com A queries IPv4 address records. dig example.com AAAA queries IPv6 address records. dig @8.8.8.8 example.com queries a specific DNS server. Useful fields include status, answer section, server used, query time, and record time to live. When comparing DNS answers, remember that public, internal, VPN, and split-DNS environments may intentionally return different answers depending on where the query comes from.

DNS success does not prove the application works. A name can resolve to the correct address while a firewall blocks TCP 443, the server is down, the certificate is invalid, or the application rejects the user. DNS failure also does not prove the whole network is down. If IP connectivity works but names fail, the technician has narrowed the issue meaningfully.

Socket and connection commands show local host network activity. On Windows, netstat can show active TCP connections, listening ports, protocol, local address, foreign address, and state. Common options include netstat -ano, which shows addresses, ports, connection states, and process IDs. PowerShell also offers cmdlets such as Get-NetTCPConnection, but netstat remains widely recognized. On Linux, ss is the modern replacement for many netstat uses. ss -tuln shows TCP and UDP listening sockets using numeric addresses and ports.

ss -tunap may show active connections and processes when permissions allow. On macOS, netstat and lsof -i are common tools.

A listening socket means a process on the local host is waiting for traffic on a protocol and port. For example, a web server might listen on TCP 80 or TCP 443. An established connection means the host has an active session with another endpoint. Other TCP states, such as SYN-SENT, TIME-WAIT, or CLOSE-WAIT, can be clues, but avoid jumping too far at entry level. A port not listening on a server may mean the service is stopped, bound to another address, blocked by local policy, or not installed. A listening port does not guarantee that remote clients can reach it through host firewalls or network firewalls.

Use these tools with privacy and authorization in mind. Connection output can reveal internal hostnames, IP addresses, services, and user activity patterns. Do not collect more than needed. In a ticket, summarize relevant facts: DNS query for intranet name returned 10.20.30.40 from DNS server 10.20.1.10; client then failed TCP connection to 10.20.30.40:443. That is better evidence than website broken.

Study Checkpoint

• Topic: DNS and Socket Diagnostics.
• Verify the official Cisco concept before memorizing a shortcut.
• Practice the technician action: observe, document, test, fix when supported, or escalate.