Curious Pandas
Explorer0 XP

What happens when you press Enter

Four stages - DNS, TCP, TLS, HTTP - stand between you and every web page. Break each one and learn to read where a request died from how it died.

Runs in your browserOn your machine
14 min+35 XP for finishing

You type shop.bamboo.example and press Enter. Before a single pixel of the shop shows up, your computer has to get through four separate stages, in order. Each can fail on its own, and each fails in its own way:

  1. DNS turns the name into an address. Computers route packets to numbers like 203.0.113.10, not names, so your machine asks a DNS resolver, which may ask other servers, and caches the answer for a while.
  2. TCP opens a connection to that address and port. Three messages go back and forth (SYN, SYN+ACK, ACK) before either side sends any real data. RFC 9293 calls it the three-way handshake.
  3. TLS proves you’re talking to the real shop.bamboo.example and encrypts everything after. The server shows a certificate; your machine checks the name on it and who signed it.
  4. HTTP finally asks for the page (GET /) and gets an answer: a status code, some headers and a body.
Visual guideFour stages, and how each one fails
Four stages, and how each one failsA request passes DNS, then TCP, then TLS, then HTTP, each handing the next what it needs. Under each stage is how curl reports a failure there: exit 6 for DNS, exit 7 or 28 for TCP, exit 60 for TLS. An HTTP 4xx or 5xx is an answer, so curl still exits 0.DNSname -> addressTCPSYN, SYN+ACK, ACKTLScertificate checkedHTTPGET / -> statusexit 6Could not resolve hostexit 7 or 28refused / timed outexit 60cert not verifieda 4xx or 5xxcurl still exits 0addressconnectedverifiedFour stages, and how each one failsA request passes DNS, then TCP, then TLS, then HTTP, each handing the next what it needs. Under each stage is how curl reports a failure there: exit 6 for DNS, exit 7 or 28 for TCP, exit 60 for TLS. An HTTP 4xx or 5xx is an answer, so curl still exits 0.DNSname -> addressTCPSYN, SYN+ACK, ACKTLScertificate checkedHTTPGET / -> statusexit 6Could not resolve hostexit 7 or 28refused / timed outexit 60cert not verifieda 4xx or 5xxcurl still exits 0addressconnectedverified
  1. DNS turns the name into an address. Fail here and nothing after it is even attempted: curl exits 6.
  2. TCP knocks on that address. A fast "refused" (7) means a machine answered; a slow timeout (28) means nothing did.
  3. TLS checks the certificate: the right name, signed by someone you trust. Fail either and curl exits 60.
  4. Only now does HTTP ask for the page. A 401 or a 500 is an answer, so every stage before it worked - and curl exits 0.

The useful skill isn’t memorising the stages. It’s reading where a request died from how it died. A failed DNS lookup and a crashed server both mean “the site is down”, but one is a typo in a record and the other is a 3 a.m. phone call.

Break it

Pick a failure. The stage tracker shows how far the request got, and the terminal shows what curl -v actually prints. The exit codes and messages are real curl output, captured for this lesson.

One request, four stagesreal curl output
    $ curl -v https://shop.bamboo.example/
    


    Check yourself+10 XP
    curl fails with exit code 6, 'Could not resolve host'. Which of these could NOT be the cause?
    

    Check yourself+10 XP
    One request fails with 'Connection refused' (exit 7) after 3 ms. Another fails with a timeout (exit 28) after 10 seconds. Which is more likely a firewall silently dropping traffic?
    


    Check yourself+10 XP
    A request gets a 401 Unauthorized. Which stages definitely worked?
    

    Do it for real · your machine+50 XP bonus
    Everything above ran in your browser. Now do it on a real cluster with tilt lab 02-route-a-hostname (profile minimal). You need Docker, kind and Tilt, about 15 GB of free disk and 8 GB of spare RAM. Setup guide · Can my machine run it?
    With the tilt platform up, watch all four stages against a real service:
    curl -v https://hello.localhost/
curl -v https://no-such-name.invalid/       # stage 1 fails: exit 6
curl -v http://127.0.0.1:9/                 # stage 2 fails: exit 7
echo $?                                     # the exit code of the last command
    On macOS, if this fails with exit 60 while the browser works, your curl is using a different trust store than the browser: pass the platform’s CA with --cacert (the platform’s labs/lib.sh shows how).
    Names ending in .localhost point at your own machine (RFC 6761), and that’s how the platform gets real hostnames with no DNS setup. Lab 02 then has you route a second hostname.
    Self-reported. We can't see your machine, and we don't want to. This is a bonus, never required.
    Sources
    Finished reading?
    Missions and quizzes above earn their own XP. This marks the lesson done.