# Knowledge Check: DNS and HTTP

---

**1. Name the four failure categories this module introduced.**

*Answer:* DNS failure, routing/connection failure, TCP-succeeds-but-application-never-responds,
and HTTP/application failure (a full response comes back but it's wrong).

---

**2. A request returns HTTP 500. What does that tell you about DNS and TCP connectivity?**

*Answer:* Both worked completely — a 500 means a full HTTP response was received, so the failure
is purely inside the application's own logic, not the network path to reach it.

---

**3. Why is "connection refused" a MORE specific diagnosis than "timed out"?**

*Answer:* "Refused" means a packet reached the destination and was actively rejected (almost
always: nothing listening on that port) — you know the destination is reachable. "Timed out"
means no response at all, which could mean unreachable, no route, or silently blocked —
genuinely less specific.

---

**4. A teammate says "DNS must be broken" because a request fails. What should you check
BEFORE agreeing?**

*Answer:* Whether the name actually resolves at all (`getent hosts` or `dig`) — many failures
that "feel like DNS" are actually one layer downstream (routing, port, or application), and
DNS itself may be working perfectly.

## Instructor Notes

**Facilitation:** Question 4 mirrors this module's own Lab almost exactly — a good moment to
preview it if not already started.

**Approximate timing:** 5 minutes.