ced4568andClaude Sonnet 5
e007bcf000
Adds all 6 ROOT 02 modules (Linux system administration, storage & filesystems, the Networking Mental Model, Linux network inspection, DNS & HTTP, Linux troubleshooting) — 37 activities, each with a real lesson, demonstration/guided exercise, knowledge check, hands-on Lab, and reflection. The Networking Mental Model module (M3) gets deliberately extra depth per its "critical module" designation, with no lab by design — conceptual mastery via knowledge check and guided exercise, matching root-05-m00's own precedent. Adds 6 new hands-on Linux/networking scenarios plus 2 MCQs: linux-service-inspection (inspects the platform's own real nginx without touching it — a genuinely safe, real service-inspection target that avoids ever risking the Lab's own connectivity), linux-service-lifecycle (start/ verify/stop a fully controllable service), linux-storage-inspection, linux-network-inspection (ip/ss/getent/curl, each framed as answering one specific diagnostic question), linux-dns-http-diagnosis (a genuine DNS-resolves-but-wrong-port failure, diagnosed and fixed), and linux-troubleshooting-framework (a real missing-config-file failure, resolved via the RootNode Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework). All tested end-to-end via the real scenario-validation API, including negative tests confirming they fail when unsolved. Wires rootnode-linux-networking-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Co-Authored-By: Claude Sonnet 5 <[email protected]>
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
# DNS and HTTP
|
|
|
|
## The complete request path
|
|
|
|
Every time a browser or `curl` fetches a URL, it walks the entire Module 3 chain in order:
|
|
|
|
```
|
|
Application (curl / browser)
|
|
↓
|
|
DNS lookup — translate the name to an IP
|
|
↓
|
|
IP address obtained
|
|
↓
|
|
Routing — figure out the path to that IP
|
|
↓
|
|
TCP connection established — a three-way handshake, underneath curl
|
|
↓
|
|
HTTP request sent
|
|
↓
|
|
Server processes it
|
|
↓
|
|
HTTP response returned
|
|
```
|
|
|
|
Nothing here is new — this is Module 3's chain and Module 4's commands, just walked start to
|
|
finish as ONE continuous story instead of five separate checks.
|
|
|
|
## Four distinct failure categories, not one
|
|
|
|
Given this path, "it doesn't work" always decomposes into exactly one of four categories:
|
|
|
|
1. **DNS failure** — the name never resolved to an IP at all (`curl`'s "Could not resolve
|
|
host").
|
|
2. **Routing/connection failure** — the IP was found, but no TCP connection could be established
|
|
— either refused (something's there but nothing's listening) or timed out (no response at
|
|
all, usually unreachable or silently blocked).
|
|
3. **TCP succeeded, but the application never responds correctly** — a connection was
|
|
established, but the server hangs, drops the connection, or the request never completes.
|
|
4. **HTTP/application failure** — a full HTTP response comes back, but it's WRONG (a 500 error,
|
|
a 404, unexpected content) — everything below the application layer worked fine.
|
|
|
|
These are genuinely different problems requiring genuinely different fixes — conflating them
|
|
(treating a 404 the same as a DNS failure) wastes real diagnostic time.
|
|
|
|
## Instructor Notes
|
|
|
|
**Lesson goal:** Make the four-category failure taxonomy explicit and distinct — this is the
|
|
direct foundation for this module's diagnostic Lab and for Module 6's formal framework.
|
|
|
|
**Approximate timing:** 15 minutes read; 10 minutes live.
|
|
|
|
**Common misconception to watch for:** treating an HTTP 500 error the same category as "the
|
|
network is down" — a 500 means the ENTIRE network path worked; the failure is purely in the
|
|
application's own logic.
|
|
|
|
**Discussion question:** "A request returns HTTP 404. Which of the four categories is that, and
|
|
what does it rule out?" (Answer: category 4, application/HTTP — it rules out DNS, routing, AND
|
|
TCP connectivity entirely, since a real HTTP response came back at all.)
|