Use this DNS and network troubleshooting path to move from a domain-name symptom to records, address ownership, ports, and subnet boundaries.
Beginner to intermediate45–60 minutes5 steps
Why this workflow matters
“The website is down” can describe a DNS failure, an unexpected address, a closed service port, or a routing boundary. Random checks waste time. This path gives each check a question, expected evidence, and a next step.
The networking and sysadmin tools hub collects the DNS, IP, WHOIS, port, and subnet checks used throughout this workflow.
Work through the steps
0 of 5 complete
1
Start with the DNS answer
Uses DNS Lookup
What to understand
An A or AAAA record answers where a hostname points; MX and TXT records answer different questions. Query the record type that matches the symptom before changing anything.
Try it
Look up A, AAAA, MX, and TXT records for a domain you control or example.com. Write down what each answer can and cannot prove. Complete the exercise in the DNS Lookup, then return here to verify the checkpoint.
Checkpoint
You can identify the returned record type, value, and TTL.
2
Check the resolved address
Uses IP Address Lookup
What to understand
IP metadata can suggest the network and rough region serving an address. It is not proof of a user’s precise physical location and can be obscured by proxies or CDNs.
Try it
Look up the address returned by the DNS step and compare its network owner with the hosting provider you expected. Complete the exercise in the IP Address Lookup, then return here to verify the checkpoint.
Checkpoint
You treat geolocation as approximate and network ownership as a troubleshooting clue.
3
Separate registration from hosting
Uses WHOIS Lookup
What to understand
WHOIS/RDAP data describes registration and registry status. Nameservers link registration to DNS delegation, but the registrar is not necessarily the web host.
Try it
Inspect the domain status, dates, and nameservers. Compare the nameservers with the DNS provider you expected. Complete the exercise in the WHOIS Lookup, then return here to verify the checkpoint.
Checkpoint
You can explain the roles of registrar, registry, DNS provider, and host.
4
Map the service to a port
Uses Common Ports Reference
What to understand
A reachable IP is not the same as a reachable application. Services listen on ports, and HTTPS, SSH, DNS, and mail each have conventional ports and protocols.
Try it
Find the standard ports for HTTPS, DNS, SSH, SMTP submission, and IMAP over TLS. Note TCP or UDP where relevant. Complete the exercise in the Common Ports Reference, then return here to verify the checkpoint.
Checkpoint
You can translate “the host responds” into the next service-specific connectivity check.
5
Confirm the subnet boundary
Uses Subnet Calculator
What to understand
A prefix length divides an IPv4 address into network and host portions. The calculated range tells you whether two addresses are expected to communicate directly on the same subnet.
Try it
Calculate 192.0.2.64/27. Record the network, broadcast, first usable, last usable, and total address count. Complete the exercise in the Subnet Calculator, then return here to verify the checkpoint.
Checkpoint
You can determine whether 192.0.2.94 and 192.0.2.95 have different roles in that subnet.
Path complete
You finished every checkpoint. Revisit any tool with your own non-sensitive practice data, or choose another path to connect this workflow to a new topic.