# 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.)