Locate the failing layer
The statement "the website is down" may describe a name-resolution failure, inability to reach an address, a refused TCP connection, a TLS handshake problem or an application returning an error. Each failure class needs a different test. Begin by recording the URL, client, network, clock time, response text and whether the problem affects all users or one location.
Avoid jumping directly from an application error to changing a DNS record. The fact that a hostname resolves does not mean the destination is reachable; a successful TCP connection does not prove HTTPS or application health.
Test name resolution with a known resolver
Use diagnostic commands on an authorized machine:
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
getent ahosts example.com
Compare the answers from the system resolver with any explicitly selected diagnostic resolver when policy allows. Multiple A/AAAA answers may be intentional. Empty answers can reflect no record, an unsuitable query type, split-horizon DNS, NXDOMAIN, or other resolver conditions; preserve the response status, not just the IP list.
If a client uses a corporate VPN or security resolver, public DNS may not reflect the application’s private service records.
Test the transport separately
Once an expected address is established, check route reachability and the specific service port. Use a narrowly scoped authorized target; avoid broad scanning.
ip route get 192.0.2.10
curl -Iv --max-time 10 https://example.com/
openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
An ICMP ping failure is not definitive evidence of an outage because ICMP may be filtered. A connection refusal often indicates that the endpoint actively rejected a TCP attempt; a timeout may involve routing, a firewall, a service, or congestion. An HTTP status proves the application replied, even when it reports an error.
For HTTPS, distinguish certificate validation failures, SNI mismatch and server-side application issues. Be aware that curl can use proxy variables and that connecting by bare IP might change virtual-host routing and certificate selection.
Turn findings into an escalation packet
Record resolver and query type, returned addresses, test source network, destination port, precise timestamps and the lowest layer shown to be failing. Capture only sanitized output. Include which tests succeeded as well as failed; this shortens triage and prevents repetitive changes.
Use the Network Port Reference to understand common port assignments and the DNS Record Review utility for pasted zone text. Neither utility proves live network state.