DNS, sockets, and HTTP are separate
Distinguish name resolution, listening sockets, and application responses.
curl -I
25 min read, 35 min lab
operator
DNS resolution can succeed while the port is closed. A port can listen while HTTP returns an error. `dig`, `ss`, and `curl` prove different things.
A URL is failing. You need to determine whether DNS, socket binding, or HTTP response is the first failure.
Worked command
$ dig +short terminaldrill.com$ ss -tulpn$ curl -I https://terminaldrill.com$ curl -v http://127.0.0.1:8080/Do not treat one green check as proof of the whole path.
Resolve name, check socket, then test protocol response.
`dig +short` returns an address and `ss -tulpn` shows the port listening, but `curl -I` returns 502. Which layer is the first failure?
Show the answer
Correct: C. The HTTP layer: name and socket are fine, the server returned an error response
DNS resolved and the socket is listening, so those layers passed; a 502 is the server answering with an application-layer error. Treating one green check as proof of the whole path is the conflation to avoid.
Practice checklist
- Resolve a domain.
- Inspect local listening sockets.
- Fetch headers from a known URL.
Deliverable evidence
- DNS result, socket evidence, HTTP header result.
shows: The diagnostic ladder for a reachability symptom: address and route, then DNS name resolution, then listening socket, then HTTP response, with firewall audited separately, and each command proving only its own layer.
does not prove: It does not prove the failure is single-layer: more than one layer can be broken at once, and a green check at one step is evidence for that step only, not proof the whole path works.
Commit these to memory, then drill them until recall is automatic.
cue Request only the response headers from an HTTP server to test the protocol layer without downloading the body
show recall target
curl -I