What happens behind the scenes when you type a domain name

You type example.com, press enter, and a page appears almost instantly. It feels like one action. It isn’t. In the few hundred milliseconds between your keypress and the first pixel, your request travels through a dozen independent systems — caches on your own machine, resolvers at your ISP, root servers, registry servers, the destination web server, and a cryptographic handshake in the middle of it all.

Most of the time you never think about any of it, because it works. But every one of those handoffs is a place where things can go wrong — an expired certificate, a changed DNS record, a lapsed domain — and when they do, the symptoms are weirdly hard to diagnose precisely because the machinery is invisible. So let’s make it visible. Here’s the entire journey, in order.

The 30,000-foot view

Before we zoom in, here’s the whole trip on one timeline. We’ll spend the rest of the post unpacking each stop.

1. Browser checks its own caches and rules (HSTS, DNS cache)
2. DNS resolution turns the name into an IP address
3. A TCP connection opens to that IP
4. A TLS handshake encrypts the connection
5. The browser sends an HTTP request
6. The server responds and the page renders

The key mental model: a domain name is not an address — it’s a lookup key. Computers don’t route traffic to example.com; they route to numeric IP addresses like 93.184.216.34. The entire first half of this journey exists just to translate the human-friendly name into a machine-friendly number.

Step 0: It starts before the network

The fastest network request is the one you never make, so your browser checks a few things locally before touching the internet at all.

  You type "example.com" + Enter
            │
            ▼
  ┌─────────────────────────────────────────┐
  │  Browser-local checks (no network)      │
  │  • Is this in my HSTS list? → force     │
  │    HTTPS before anything else           │
  │  • Do I have this name cached already?  │
  │  • Do I have an open connection to it?  │
  └─────────────────────────────────────────┘
            │  cache miss
            ▼
        Ask the network

Two things happen here that matter:

• HSTS (HTTP Strict Transport Security). If the site previously told your browser “always use HTTPS,” the browser rewrites http:// to https:// before it sends a single packet. This is why you often can’t force a plain HTTP connection to a major site even if you try.
• The browser and OS DNS caches. Your machine remembers recent lookups. If you visited example.com a minute ago, the answer is probably still cached locally and the next several steps get skipped entirely.

Step 1: DNS resolution — turning a name into a number

This is the part most people mean when they say “DNS,” and it’s a small relay race. Your computer doesn’t know where example.com lives, so it asks a recursive resolver (usually run by your ISP, or a public one like 8.8.8.8 or 1.1.1.1) to find out. The resolver then walks the naming hierarchy on your behalf.

  Your computer
       │  "What's the IP for example.com?"
       ▼
  ┌──────────────────────┐
  │  Recursive resolver  │   ← does the legwork for you
  └──────────────────────┘
       │  1. ask a ROOT server
       ▼
  ┌──────────────────────┐
  │  Root server (.)     │   "I don't know, but ask the
  └──────────────────────┘    .com servers — here's where"
       │  2. ask the TLD server
       ▼
  ┌──────────────────────┐
  │  TLD server (.com)   │   "I don't know the IP, but
  └──────────────────────┘    example.com's nameservers
       │                       are over here"
       │  3. ask the authoritative server
       ▼
  ┌──────────────────────┐
  │  Authoritative NS    │   "example.com is at
  │  (example.com's DNS) │    93.184.216.34"
  └──────────────────────┘
       │
       ▼
  Resolver returns the IP to your computer

Read the hierarchy right to left and it’s just a postal address in reverse. The root servers know who runs each top-level domain. The TLD servers (the .com registry, .org, .io, and so on) know which nameservers are responsible for each domain registered under them. The authoritative nameservers — the ones your domain actually points at — hold the real records and give the final answer.

It’s worth noting how few round trips this really is in practice. The resolver caches aggressively at every level, so the root and TLD steps almost never run on a typical lookup — those answers are already cached for hours. The authoritative lookup is usually the only fresh query.

The records that come back

The authoritative server doesn’t just return one kind of answer. Depending on what’s asked, it serves different record types — AAAAAMXTXTCNAME — each with a job:

• A / AAAA — the IPv4 / IPv6 address the browser actually connects to.
• CNAME — an alias that points one name at another (“www → the apex”).
• MX — where email for the domain should be delivered (not used for web page loads, but living in the same DNS).
• TXT — free-form text used for SPF, DKIM, and domain-ownership verification.
• NS — which nameservers are authoritative for the domain.

For loading a web page, the A/AAAA record is the prize. Everything up to this point existed to retrieve that single number.

TTL: why DNS changes aren’t instant

Every record carries a TTL (time to live) in seconds — how long resolvers are allowed to cache it before asking again. A TTL of 3600 means a resolver can serve the same answer for an hour. This is the entire reason “DNS propagation” feels slow: when you change a record, the authoritative server updates immediately, but resolvers around the world keep serving the cached old value until their TTL expires.

You can watch this resolution play out yourself: the DNS lookup tool shows a domain’s live records, the nameserver lookup shows which authoritative servers are answering, and the DNS propagation checker queries multiple resolvers at once so you can see whether a change has spread.

Step 2: Opening a connection (the TCP handshake)

Now your browser has an IP address. Time to actually connect. Before any web data moves, TCP performs a three-step handshake to establish a reliable connection between your machine and the server:

  Browser                         Server (93.184.216.34)
     │                                   │
     │ ──────  SYN  ──────────────────▶  │   "Can we talk?"
     │                                   │
     │ ◀─────  SYN-ACK  ──────────────── │   "Yes — can you hear me?"
     │                                   │
     │ ──────  ACK  ──────────────────▶  │   "Yes. Let's go."
     │                                   │
     │ ===== connection established ===== │

This is “SYN, SYN-ACK, ACK” — both sides confirm they can send and receive before any real data flows. It costs one round trip, and its duration is largely dictated by physical distance: a server two time zones away is faster to reach than one on another continent. This is why content delivery networks (CDNs) put servers physically close to users — they’re shortening this handshake.

Step 3: Securing the connection (the TLS handshake)

For any https:// site — which is nearly all of them now — there’s a second handshake right after the TCP one. This is TLS (the modern name for SSL), and it’s where the padlock in your address bar comes from. Two things happen at once:

1. Authentication. The server presents its TLS certificate, which proves it really is example.com and not an impostor. Your browser checks that the certificate was issued by a trusted authority, matches the domain, and hasn’t expired.
2. Encryption. The two sides agree on keys so that everything sent afterward is encrypted and unreadable to anyone in between.

  Browser                              Server
     │ ── "Hello, here's what crypto    │
     │     I support" ────────────────▶ │
     │                                  │
     │ ◀── "Hello, here's my            │
     │      certificate + chosen        │
     │      cipher" ─────────────────── │
     │                                  │
     │  [browser verifies certificate:  │
     │   trusted issuer? right domain?  │
     │   not expired?]                  │
     │                                  │
     │ ── key exchange ───────────────▶ │
     │ ◀── finished ─────────────────── │
     │ ===== encrypted channel up ===== │

This step is the single most common cause of a sudden, total, scary-looking outage — and it has nothing to do with your code or your server. A TLS certificate has a fixed expiry date. The day it lapses, every visitor gets a full-page browser warning (“Your connection is not private”) and most simply leave. The site is otherwise perfectly healthy; one date passed.

You can inspect any site’s live certificate — issuer, validity window, and days remaining — with the SSL certificate checker.

Step 4: The HTTP request and response

With an encrypted connection open, your browser finally asks for the page. It sends an HTTP request:

  GET / HTTP/2
  Host: example.com
  User-Agent: Mozilla/5.0 ...
  Accept: text/html ...

The server processes it and sends back a response, starting with a status code that tells the browser what happened:

• 200 OK — here’s your page.
• 301 / 302 — it moved; go here instead (a redirect, often http → https or apex → www).
• 404 Not Found — that path doesn’t exist.
• 500 / 502 / 503 — the server errored, a gateway failed, or the service is overloaded.

That status code is the heartbeat of the whole request. A page that loads is a 200; an outage is usually a 5xx or a connection that never completes. It’s also the simplest thing to monitor from the outside — you don’t need access to the server, you just need to ask for the page and read the first line of the answer. The HTTP status checker does exactly that.

Step 5: Rendering — the part you actually see

The first response is usually just the HTML skeleton. As the browser parses it, it discovers references to more resources — CSS, JavaScript, images, fonts — and for each one it may repeat much of this entire journey: another DNS lookup (if the resource is on a different domain), another connection, another TLS handshake, another request. A modern page can trigger dozens of these in parallel.

Then the browser assembles everything — builds the DOM, applies styles, runs scripts, lays out the page, and paints pixels. That’s the moment the page “appears.” From keypress to first paint, the whole sequence we just walked through typically completes in a few hundred milliseconds.

Where it breaks — and why the cause is hard to see

Step back and look at the full chain. The reason web outages are so frustrating to diagnose is that the failure and the symptom live at different layers:

  Layer            What breaks here              What the user sees
  ─────────────────────────────────────────────────────────────────────
  Domain (WHOIS)   Registration lapses           Site fully gone, DNS dead
  DNS              A record edited / NS changed   Wrong server, or nothing
  TCP              Server down / unreachable      Spinning, then timeout
  TLS              Certificate expires            "Not private" warning
  HTTP             App error / overload           500 / 502 / blank page

A lapsed domain, a fat-fingered DNS record, an expired certificate, and a crashed app server produce different failures, but to a visitor they can all look like “the site is down.” Without visibility into each layer, you waste an afternoon checking the app when the real problem was a certificate that expired at midnight or a DNS record a teammate changed without telling anyone.

This is exactly the gap monitoring closes — by checking each layer continuously, from the outside, the way a real visitor would:

Watch every layer with Domnr

Everything in this post is a layer that can fail silently between renewals and deploys. Domnr watches all of them in one place — so instead of learning about a problem from an angry customer, you get an alert within minutes and already know which layer to look at.

Curious about your own domain right now? Start with the domain health checker for a one-shot snapshot across all of these layers, then drill in with the WHOIS, DNS, and SSL tools. The machinery is invisible until it breaks — the trick is to watch it before it does.