DNS and a first diagnostic

When a service appears down, test one layer at a time. The message site unavailable does not tell you whether DNS, routing, a firewall, the process, TLS, or the application failed.

Use a sequence that moves from name to behavior.

1. Resolve the name

Use the system resolver:

getent ahosts notes.example

Use dig when you need DNS details:

dig notes.example A
dig notes.example AAAA

Confirm that the returned address is the one the service should use. If different resolvers disagree, caching or delegation may be involved.

2. Check the network path and port

ping can show IP reachability when the destination permits ICMP, but many healthy servers block it. A failed ping does not prove the web service is down.

Test the actual TCP port:

nc -vz notes.example 443

A timeout suggests filtering or an unreachable path. Connection refused normally means the host answered but nothing accepted that port.

3. Check the service locally

On the server:

systemctl status nginx --no-pager
sudo ss -lntp
curl -v http://127.0.0.1/

This separates process state, listening socket, and application response.

4. Check the complete public request

curl -v https://notes.example/

Read the resolved address, connection, TLS handshake, status code, and response headers. A 500 response proves that DNS and the connection worked; the application failed later.

Change only the failing layer

Changing DNS will not fix a stopped process. Restarting the process will not fix a record pointing to the wrong IP. Opening every firewall port can turn diagnosis into a security incident.

Write down the first failing check and the last successful one. That boundary tells you where to investigate next.

Try this: choose a public site and run only read-only checks for DNS, TCP port 443, and HTTP. Explain what each successful result proves—and what it does not.