DNS for People Who've Been Faking It

You change an A record. An hour later it's still resolving to the old IP on your machine, the client swears their site is fine, and someone says the magic word: "give it time to propagate." Everyone nods. Nobody's quite sure what propagated, or to where, or why it's your problem.

I faked my way through this for longer than I'd like to admit, so no judgment. But there's a model underneath it that's simpler than the guesswork, and once it clicks, every confusing DNS moment collapses into one of two questions. Let me give you the model.

A domain and its DNS are not the same thing

First untangle the two things "my domain" smushes together. The registrar is who you rent the name from. Separately, there's a set of nameservers that actually answer questions about that name, and the registrar's real job, once the name is yours, is to point at whichever nameservers are in charge.

This is the bug behind half of "I changed the record and nothing happened." You edited an A record in your registrar's DNS panel, but the domain's nameservers point at Cloudflare. So you carefully updated a zone that nobody is asking. The registrar isn't answering DNS questions, the nameservers it delegates to are, and you edited the wrong one. Before you touch a single record, know which nameservers are authoritative, because that's the only zone edits to which mean anything.

DNS is a lookup, and there's more than one kind of answer

Once you're editing the right zone, DNS is just a lookup: a name maps to records, and the record type is the question being asked. A and AAAA are "what IP for this name." CNAME is "actually, go ask about this other name instead." MX is "where does mail for this name go." TXT holds the SPF, DKIM, and DMARC strings that decide whether your mail is trusted or binned.

The practical point for the faking-it crowd: the website and the email are separate answers to separate questions on the same name. This is why a domain move can bring the site back perfectly and silently kill email. You remembered the A record and forgot the MX and the TXT records, and now mail is bouncing while the homepage loads fine. The site working tells you nothing about whether mail works. They're different records.

Nothing propagates. You're fighting caches.

Here's the one that matters most, because it's the one everybody says and nobody means. Nothing propagates. There is no wave of updates rolling across the internet. What actually happens is that every resolver between a user and your records keeps a cached copy of the old answer, and it holds that copy until its timer runs out.

That timer is the TTL, and it's a value you set on the record. Set an A record to 3600 and you're telling every resolver "cache this for an hour." So when you change it, anyone whose resolver grabbed the old answer forty minutes ago keeps getting the old answer for twenty more minutes, then re-asks and sees the new one. You're not waiting for the internet to update. You're waiting for caches to hit their TTL and admit they're stale. "Works for me, not for them" is just two caches at different points in that countdown.

Which hands you the actual tool. Before a planned migration, drop the TTL to something low, sixty or three hundred seconds, a day ahead of time. Let the old high TTL expire so the whole world is now caching for only a minute. Then cut over, and the change effectively takes hold in a minute instead of a day. Raise the TTL back afterward. The people who "just wait and hope" are the people who never lowered the TTL before the cutover.

The whole model, in two questions

That's the entire thing. DNS is a delegated, cached lookup from a name to a set of typed records. Every confusing symptom you'll ever hit is one of two questions.

Which server is actually answering? That covers wrong-zone edits, nameservers pointing somewhere you forgot, and delegation you didn't check.

Whose cache am I fighting, and what's its TTL? That covers every "it's not updating," every "works for me," and every launch that broke because someone cut over five minutes before go-live with a day-long TTL still in effect.

You don't need to have every record type memorized. You need to stop treating "propagation" as a force of nature and start seeing a cache with a timer you can read and, ahead of time, turn down. Do that and you're no longer faking it. You just know where the answer lives and whose copy is stale.