Everything in this class has been about where work runs. This final lesson is about how a human finds it. A stranger types a name into a browser, and seconds later your application answers — across DNS records, encrypted connections, and hosting layers you chose in Lessons 25.1 through 25.5. That short journey deserves one careful explanation, because the one step beginners treat casually — DNS — is the step that can take a working product offline.

Four plain definitions

Domain. The memorable name: yourproduct.com. Humans remember names; networks route by numbers. The domain is the human handle for your product's front door.

DNS (Domain Name System). The directory that points the name toward the service. When a browser needs yourproduct.com, it asks DNS: "where does this live?" DNS answers with records — an A record pointing to an address, a CNAME pointing to another name — and the browser goes there. You control these records at your DNS provider; whoever holds that account holds the signpost for your entire product.

HTTPS certificate. The credential that lets a browser and your server open an encrypted connection *and* proves the server is entitled to speak for that domain. The padlock is not decoration: without HTTPS, traffic between visitor and app travels readable by intermediaries, and browsers warn users away. Managed platforms typically issue and renew certificates for you; on a VPS, you arrange it. Either way, an expired certificate reads to visitors as "this site is broken."

Reverse proxy. A server that receives visitor traffic first and forwards it to your application behind it. It can terminate encryption, cache responses, block abuse, and route /api/* to one service and everything else to another. Cloudflare's edge and Vercel's frontend layer both act as proxies in this sense: the visitor talks to the edge, the edge talks to your app, and your app never faces the raw internet alone.

The route, one line

browser → yourproduct.com → DNS → hosting platform → application → response

Unpack it with a concrete visit. A reader types yourproduct.com/research/acme and presses Enter. The browser asks DNS where yourproduct.com lives. DNS returns the record pointing at the hosting platform (often via Cloudflare as the edge). The platform's proxy receives the request, terminates HTTPS, and forwards it to the application — a function that wakes, reads cached facts from Postgres, and returns the page. The response travels back encrypted. Total time: a second or two. Total systems involved: five, each owned by someone your STACK-OWNERSHIP.md names.

Cloudflare appears here as the recognizable example of DNS-plus-edge infrastructure — but learn the *roles*, not one dashboard. Any DNS provider points names; any edge proxy forwards traffic. If Cloudflare's interface changes next year, the route above still reads the same.

Why DNS changes are consequential

Every other lesson taught safe iteration: branches, previews, retries. DNS is the exception, so hear this clearly. A wrong record sends customers to the wrong place or takes a working app offline — instantly, globally, and visibly. There is no preview URL for "I pointed the root domain at the wrong address." Propagation delay then stretches the mistake: fixes take time to spread, and during that window some visitors see the old destination and some see the new one.

The discipline is planning and review, not speed. Before touching DNS: write down the current records, state the intended change and why, have a second pair of eyes (human or a careful AI session) confirm it, make the change, and verify with a lookup. Lesson 25.4's table says who owns the DNS credentials; this lesson says *how* that owner behaves — deliberately, with a rollback note (the previous values) in hand.

Reading a deployment or a log is safe inspection. Changing DNS, production secrets, database records, or deployment settings is a production change. The course has drawn that line since Part V; DNS is where it matters most visibly.

Credentials close the class

Domains, deployment platforms, and DNS accounts are powerful keys — they control what the public sees when they ask for your product. That connects directly to Class 14's key discipline: scoped secrets, named owners, no broad unreviewed authority. In particular, do not hand an AI agent broad authority over DNS or production deployment without review. An agent that can "fix the site" and can also rewrite your root DNS records is an incident waiting for a misunderstood instruction. Least privilege applies to agents exactly as it applies to people: read access for inspection, narrow write scope for defined tasks, human confirmation for consequential changes.

Practical exercise: draw one visitor route

Pick one live app you actually use — your own project if it is deployed, otherwise any product you admire. Draw its route in one line:

visitor → domain → DNS owner → hosting layer → app → data service → response

Example shape (labels, not claims — mark guesses honestly):

visitor → byebuy.ai [known] → Cloudflare DNS [guessing] → Vercel hosting [guessing]
  → serverless functions [guessing] → Supabase Postgres [guessing] → response

Annotate every hop with [known] or [guessing]. "Known" means you verified it — a DNS lookup, a response header, the project's own docs. "Guessing" means inference. The marks are the exercise: they separate evidence from an AI's unsupported guess, a distinction this course requires everywhere.

Finish line: one annotated line naming domain, hosting layer, app, and data service, with every hop marked known or guessing.

Verify: for each "[known]" hop, state the evidence in one clause ("known — dig shows Cloudflare nameservers"). A "known" without evidence is a guess wearing a costume.

Common failure mode: drawing the route entirely from confident guesses and then acting on it — e.g., advising a DNS change based on an assumed provider. Guesses guide curiosity; only evidence guides changes.

Check your understanding

1. In one sentence each, define domain, DNS, HTTPS certificate, and reverse proxy. 2. Why does an expired certificate look like a broken site to visitors? 3. What makes a DNS change different from deploying a preview? 4. Why should an agent's authority over DNS be narrower than its authority to read logs?