Version 1 · Chapter 18Reading mode

Separate DNS, HTTP, and listening ports

By the end: Ask a precise network question and interpret the layer that answered it.

The idea

DNS returns records; HTTP returns application responses; a listening socket shows a local endpoint. None alone proves the whole journey works. Use known public example domains or your own systems, set request limits, and inspect downloads as data rather than executing them.

Your command toolkit

dig

What it solves: Query a DNS record explicitly.

bash

dig example.com A +short

Requests IPv4 address records. A short answer is convenient, but the full response contains status and resolver context when troubleshooting.

nslookup

What it solves: Perform a familiar DNS lookup.

bash

nslookup example.com

Shows which resolver answered and its result. Resolver caches and split DNS can make answers differ by environment.

whois

What it solves: Inspect registration records where available.

bash

whois example.com

Registration data may be redacted, rate-limited, or served through RDAP instead. Do not assume it reveals the current person operating a site.

curl

What it solves: Inspect an HTTPS response.

bash

curl --head --max-time 10 https://example.com

Requests response headers with a timeout. TLS verification stays enabled. A response code needs interpretation for the endpoint you requested.

wget

What it solves: Check a download endpoint.

bash

wget --spider --timeout=10 --tries=1 https://example.com

Spider mode checks availability without saving the page body. A real download should have an explicit destination and verification appropriate to its source.

nc

What it solves: Probe a specific authorized TCP endpoint.

bash

nc -z -w 2 127.0.0.1 3000

This OpenBSD-style netcat syntax checks one local port. Implementations differ; a refusal is expected when nothing listens there.

netstat

What it solves: Recognize older socket inspection.

bash

netstat -lnt

Lists listening TCP sockets numerically where net-tools is installed. Modern runbooks often use ss -lnt instead.

lsof

What it solves: Connect open files and sockets to processes.

bash

lsof -nP -iTCP -sTCP:LISTEN

Shows visible listening TCP sockets without DNS or port-name lookups. Permissions may hide other users' processes.

Before you move on

Try the guided lab below. Compare the result with the explanation, then record your reasoning in the workbook. A missing optional program or a restricted environment is something to explain, not a reason to change system settings blindly.

Practice with evidence

Predict the result
Run the guided lab
Compare the output
Explain your choice

A worked example

Guided lab

bash

dig example.com A +short
curl --head --max-time 10 https://example.com

What to expect: A DNS answer and an HTTPS header response if networking and the tools are available. Exact addresses and headers can change.

Make it yours: Describe how you would distinguish a DNS failure, a refused TCP connection, and an HTTP 404. Name the evidence for each rather than treating all three as 'offline'.

Read further

Debian reference: network setup ↗www.debian.org

Apply what you learned

Your private practice

Describe how you would distinguish a DNS failure, a refused TCP connection, and an HTTP 404. Name the evidence for each rather than treating all three as 'offline'.

An HTTP 404 response most directly tells you what?DNS must be brokenAn HTTP server responded that the requested resource was not foundThe host has no network connection

Answers are private. Completion requires the correct knowledge-check answer and a written response when an activity is included.

Restore a downloaded workbook

Choose a recovery file for this course and version. Review the recovered copy before saving it to your account.

Workbook recovery file

Ask a question or report a problem

Describe what needs attention. Your private answer is shared only if you select the option below.