DNS and CDNs — What Happens Between Enter and Pixels

In the second or so between pressing Enter and seeing a page, a name gets resolved down a tree, four layers of cache get consulted, and an edge server somewhere near you answers instead of the origin. Here is how DNS walks that tree, what a TTL does not promise, and how a CDN talks its way around the speed of light — from zero background.

The name you typed is not an address

You type example.com, press Enter, and in under a second there is a page. In that sliver of time the browser does three jobs in order: find out where the other party is, start a conversation with it, and receive the content. Almost every complaint about a "slow site" is really about waiting in one of those three.

Start with finding. example.com is a name built for humans to remember; it is not a destination. To actually deliver a packet you need an IP address — a numeric address like 203.0.113.10. The system that maps names to addresses is DNS, the Domain Name System.

The naive answer is to put every name-to-address pair in one file and hand it to everyone. The early Internet did exactly that. But names are created daily and addresses change when things move, and keeping a current copy on every machine on Earth turned out to be impossible. So the design flipped: do not hold one table anywhere, leave the answers with their owners, and go ask only when you need to. That flip is where DNS begins.

Read names right to left — the idea is delegation

Read www.example.com from the right. There is in fact an invisible dot on the end; written properly it is www.example.com.

• The rightmost . is the root. It knows only who is responsible for .com
• com is the TLD (top-level domain). It knows only who is responsible for example.com
• Whoever owns example runs the authoritative server. That one actually knows which address www has

The important part is that no level has to know the answer. Each one hands back a referral: "not me, ask this server." That referral is an NS record, and the arrangement is called delegation. Nobody holds the whole picture, yet the whole picture is queryable. The addresses that serve the root are a fixed set of thirteen (a through m), each of which is replicated across many machines worldwide.

The journey of a lookup — who asks whom

There are three characters.

1. The stub resolver — the small client built into your operating system, whose entire job is to delegate
2. The full-service resolver (also called recursive) — your ISP's, or a public one like 8.8.8.8 or 1.1.1.1
3. The authoritative server — the party that actually holds the answer

The stub asks exactly one question: "go find the address of www.example.com and bring it back." Because it hands off the whole problem, this is a recursive query.

The sweating happens at the full-service resolver. It asks the root, follows the referral to the .com servers, follows the next referral to the authoritative server, and finally gets an address. It walks down one level at a time under its own power, which is why these are called iterative queries. The questions travel over UDP, which is about as lightweight as networking gets; only when an answer will not fit in one packet does the resolver retry over TCP.

So a single page visit can hide three or more round trips before any content is requested. If every visit did this, the world's requests would pile onto the root and .com servers and the Internet would have collapsed on day one. It did not collapse because a mechanism for never asking the same question twice was baked in from the start.

Every answer arrives with a TTL (time to live): a statement from the publisher that says "you may reuse this answer for this many seconds." How much of Internet operations that single line governs is the subject of the next section.

Caching happens in layers

A TTL does not take effect in one place. The same answer ends up sitting in at least four.

• Inside the browser — kept briefly under the browser's own policy. The layer that confuses developers first
• The OS stub resolver — per-device retention
• The full-service resolver — the real workhorse, absorbing questions from tens of thousands of users at once
• The authoritative server — not a cache at all, but the original

The layering is what makes it work. Once one ISP's resolver holds an answer, every subscriber of that ISP shares it. The higher you go, the more you are shielded.

The layer people forget is negative caching. "That name does not exist" (NXDOMAIN) is cached too, for a duration taken from the zone's SOA record. So if you publish a typo in a record name and fix it minutes later, anyone who hit the typo keeps getting "does not exist" for a while. That is the usual explanation behind "I fixed it and it is still broken."

And one more thing: a TTL is not an enforceable promise. Many resolvers clamp absurdly short TTLs up to a floor, or cap long ones at a ceiling. Treat a TTL as an aspirational declaration, not as a guarantee that the world updates in lockstep the instant it expires.