Web Infrastructure — Domains, DNS, Hosting & Email
Everything that has to be true before your code ever runs for a user. When someone types
ayrisglobal.com, a dozen systems cooperate to turn that text into your app on their screen. This track is that dozen systems.
How this track is built
Each lecture follows the same shape so your brain knows where to look: 🎯 objectives → mental model → core content → ⚠️ misconceptions → 🧪 lab → ✅ self-check → 📚 graded resources → key terms. Read once for the model, do the lab, then answer the self-checks out loud. That’s the MIT rhythm: lecture, then problem set.
Why this subject exists
You can be a strong backend developer and still be mystified by:
- “Why does the site work for me but not my friend?” → DNS caching
- “I changed the record an hour ago, why is it still old?” → TTL / propagation
- “Why did our email suddenly land in spam?” → SPF/DKIM/DMARC
- “Do I have to move the domain to change hosts?” → No — and knowing why saves you from disasters
None of these are application bugs. They’re infrastructure. Every senior engineer carries this model in their head. By the end of this track, so will you — and you’ll be able to read your own production stack (we do exactly that in the final lecture).
The two diagrams to rule them all
Visiting a website:
You type: ayrisglobal.com
│
▼
[1] DNS lookup ─► "what IP is ayrisglobal.com?" ─► 104.21.x.x
│
▼
[2] Browser opens a connection to that IP (TCP handshake)
│
▼
[3] TLS handshake ─► the 🔒, keys agreed, now encrypted
│
▼
[4] HTTP request ─► CDN/proxy (Cloudflare) ─► your hosting/server
│
▼
[5] HTML/JS/CSS comes back ─► page renders
Receiving email — same internet, different records:
Someone emails darshan@assure.ayrisglobal.com
│
▼
[1] Sender looks up the MX record for assure.ayrisglobal.com
│
▼
[2] Connects to that mail server, delivers over SMTP
│ (checks SPF / DKIM / DMARC to prove it's not spam)
▼
[3] You read it via webmail or IMAP
Every lecture zooms into one box of these two diagrams. Keep this page open as your map.
The lectures (basics → advanced)
| # | Lecture | After it, you can explain… | Level |
|---|---|---|---|
| 1 | How the Internet Works | IP, ports, packets, TCP, the request lifecycle | 🟢 |
| 2 | Domains & Registrars | What you actually “buy”, TLDs, ICANN, WHOIS, renewals, lifecycle | 🟢 |
| 3 | DNS Deep Dive | Resolvers, the 4 server types, every record (A/CNAME/MX/TXT…), TTL, propagation | 🟡 |
| 4 | Web Hosting | Shared vs VPS vs cloud vs serverless vs static; how a request reaches a server | 🟡 |
| 5 | Email Infrastructure | SMTP/IMAP, MX, mailbox vs alias vs forwarding, deliverability | 🟡 |
| 6 | HTTPS, TLS & CDNs | Certificates, the TLS handshake, what a CDN/proxy does, caching, DDoS | 🔴 |
| 7 | Case Study: ayrisglobal | Reading a real production stack end-to-end + the email-migration decision | 🔴 |
Difficulty key
🟢 Beginner — no prerequisites · 🟡 Intermediate — builds on earlier lectures · 🔴 Advanced — read after you’re comfortable with the basics.
How to study this (don’t skip)
- Read once for the mental model. Don’t memorize record syntax — understand the shape.
- Do every 🧪 lab. Infrastructure clicks the moment you watch a real command respond. Reading about DNS ≠ running
dig. - Answer the ✅ self-checks out loud. They’re collapsible — try first, then reveal. If you can’t answer, that section needs a re-read.
- Triage the 📚 resources by colour. 🟢 now, 🔴 later. You don’t need all of them today — you need to know they exist for when you do.
The anchor resources for the whole track
Your “textbook”
- 🟢 Cloudflare Learning Center — cloudflare.com/learning — free, clear, mostly vendor-neutral. The single best starting point for DNS, SSL, and CDN topics.
- 🟢 Julia Evans — wizardzines / blog — wizardzines.com · jvns.ca — the friendliest deep technical explainers anywhere.
- 🟡 MDN Web Docs — developer.mozilla.org — the reference for anything HTTP/web.
- 🔴 High Performance Browser Networking (free) — hpbn.co — the advanced text for TCP/TLS/HTTP. Save for after lecture 6.
One-line summary
Infrastructure is everything that must work before your code runs. Learn the two diagrams above cold, and most “weird internet problems” stop being weird.
Check Yourself
Cover the answers. Say each out loud before you reveal it — if you can’t, that’s the box to re-read.
1. In one sentence, what does "infrastructure" mean in this track?
Everything that has to be true before your application code ever runs for a user — DNS, the connection, TLS, hosting, email records. Not application bugs; the layer underneath.
2. Put the five steps of "visiting a website" in order.
DNS lookup → TCP connection to the IP → TLS handshake (the 🔒) → HTTP request through the CDN/proxy to your server → HTML/JS/CSS comes back and the page renders.
3. "It works for me but not my friend." Which box of the map is the usual suspect?
DNS / caching. Your resolver has a fresh (or stale-but-correct) answer; theirs has a different cached one. This is the TTL / propagation box.
4. Which record type does *receiving email* start from, and what does it point at?
The MX record — it points the sender at the mail server responsible for that domain. The sender looks it up, then delivers over SMTP.
5. Name the three records that decide whether your email is trusted or marked spam.
SPF, DKIM, DMARC. They prove the mail genuinely came from your domain and was not spoofed — the deliverability box.
6. Do you have to move your domain to change hosting providers? Why or why not?
No. The domain and the host are separate. You just repoint DNS records at the new host. Knowing this saves you from needless, risky migrations.
7. What is the difference in viewpoint between the Web Infrastructure track and the Networking track?
Web Infrastructure is the ops/owner view (domains, DNS, hosting, email you configure). Networking is the engineer-at-keyboard view (the wire at runtime — packets, TCP, sockets). Same internet, different altitude.
8. Why does the order of the lectures go DNS before Hosting before HTTPS?
Because that’s the request lifecycle order. You can’t reach a host until DNS resolves the name; you can’t add the 🔒 until there’s a connection to the host. Each lecture zooms into the next box of the map.
Still Unclear?
Paste one of these into Claude and push until it clicks:
I'm starting a Web Infrastructure track. Walk me through exactly what happens,
step by step, from the moment I type "ayrisglobal.com" until the page renders.
Stop after each step and ask me to explain it back before continuing.
Explain the difference between a domain, a DNS record, and a hosting server
as if I keep confusing them. Give me one real analogy and one concrete example
for each, then quiz me on which is which.
Why AI Can’t Do This For You
AI can recite what DNS or an MX record is, but it cannot hold your stack in its head at 2am when the site is down and you have minutes to decide which box of the map is broken. That triage instinct — “this smells like caching, not a code bug” — only forms by building the mental model yourself and watching real commands respond. The map on this page has to live in your memory, not in a prompt, or you’ll be copy-pasting fixes you don’t understand into a production outage.
Module done? Add it to today’s tracker