DNS for Humans: Records and Propagation

DNS has a reputation as dark magic, sustained by the industry's favorite proverb: it's always DNS. The reputation is only half-earned. The system itself is small — a distributed phone book mapping names to addresses, with about six record types you'll ever touch. What makes it feel cursed is caching: DNS changes don't happen everywhere at once, so mistakes surface unevenly, hours later, for some people and not others. Mysterious-seeming, entirely explicable.

This post is the working knowledge a site owner or non-specialist developer actually needs: what happens during a lookup, what each record type does, what 'propagation' really means (and the TTL trick that makes changes fast and safe), and the specific mistakes that account for most self-inflicted DNS outages.

What happens when someone types your domain

When a browser needs example.com, it asks a resolver — typically run by the visitor's ISP, or a public one like 1.1.1.1 or 8.8.8.8. If the resolver doesn't already know the answer, it walks down a hierarchy: the root servers point it to the .com servers; the .com servers point it to your nameservers (this pointer is called the delegation, set via your registrar); your nameservers give the actual answer — 'example.com is at 203.0.113.7'. The resolver hands that to the browser and, crucially, remembers the answer for a while so the next thousand visitors get it instantly.

Two consequences of that design run through everything else. First, there are two different places you configure things: the registrar (where you bought the domain, and where the delegation to nameservers is set) and the DNS host (whose nameservers hold your actual records — often the registrar too, or Cloudflare, or your web host). Half of all DNS confusion is editing records at one provider while the delegation points at another; the edits are correct and completely ignored. Before touching anything, check where your delegation actually points: dig NS example.com +short (or an online lookup). Edit records there.

Second, caching at the resolver is why changes take time to be seen — the subject of the propagation section below.

The records that matter (and the ones you can ignore)

A few working rules that prevent real mistakes:

• CNAME means 'ask over there instead' — for every record type. Which is why a CNAME can't coexist with other records on the same name, and why you can't put a CNAME on the bare domain (it would swallow your MX records and break email). This is the rule behind a classic outage: pointing the root domain at a platform via CNAME and discovering mail stopped. Providers offer workarounds — ALIAS/ANAME records or CNAME flattening — for exactly this; use those at the root, real CNAMEs on subdomains.
• Web and email are completely independent. A/AAAA records route web traffic; MX routes email. You can host the website anywhere and email anywhere else — and this independence is precisely what makes email survivable during a website migration, if you leave the MX records alone (see mistakes, below).
• TXT records are where modern email deliverability lives. SPF (which servers may send as your domain), DKIM (cryptographic signing), and DMARC (policy for failures) are all TXT records. Miss them and your invoices land in spam. One syntax trap worth knowing: a domain must have at most one SPF record — adding a second one (a common move when adding a newsletter tool) doesn't extend the first, it invalidates both. Merge the mechanisms into a single record instead.

Propagation: what's actually happening

Here's the truth behind the scary phrase 'DNS can take 24–48 hours to propagate': nothing is propagating. Your change is live on your nameservers the moment you save it. What takes time is resolvers around the world expiring their cached copies of the old answer. Each record carries a TTL — time to live, in seconds — that tells resolvers how long they may reuse an answer. A resolver that cached your old A record with an hour of TTL left will keep serving the old address for up to that hour, no matter what you've changed since.

Everything strange about DNS changes follows from this:

• Changes appear unevenly. Your office sees the new site (your resolver's cache happened to expire); a customer sees the old one (theirs hasn't). Neither observation tells you whether the change is 'done' — only whether one particular cache has turned over.
• You can check the source of truth directly. Query your nameservers themselves — dig @your-nameserver example.com — and you see the live record, no caching involved. If the answer is right there, your change is correct and the rest is just waiting. Online propagation checkers do the sibling trick: querying many public resolvers worldwide and showing which have picked up the change.
• The waiting is schedulable. This is the professional's move, and it's embarrassingly simple: lower the TTL before the change, not during the panic after it. If your records sit at a 24-hour TTL, drop them to 300 seconds (5 minutes) at least one full old-TTL-period before the migration — the old, long-lived cached copies need time to expire before the short TTL governs. Make the change; the world converges within minutes; verify; then raise the TTL back to something sane (an hour to a day) so resolvers aren't hammering your DNS host forever. A migration with TTL pre-work is a five-minute cutover. Without it, it's a day of 'works for me, broken for you.'

One honest caveat: a small minority of resolvers ignore TTLs and cache longer than they should. The overwhelming majority comply, so plan around TTLs and shrug at the stragglers — the 24–48 hour figure is mostly a relic of nameserver delegation changes, which involve caching layers above your control and genuinely can take a day or two. Which suggests its own rule: when migrating, prefer changing records over changing nameservers when you have the choice — record changes obey your TTLs; delegation changes obey the registry's.

The mistakes that cause most DNS outages

DNS incidents are highly repetitive. In rough order of frequency:

1. Killing email during a website migration. The champion. Someone moves a website to a new host, and — via the new host's 'let us manage your DNS' onboarding, or a well-meaning cleanup — the MX and email-related TXT records get dropped or replaced. Email fails slowly and quietly: sending servers retry for a day or more before bouncing, so the damage surfaces days later, unlinked to its cause in anyone's memory. The defense: before any migration, export or screenshot the full zone; afterwards, verify MX, SPF, DKIM, and DMARC survived; and prefer changing the A record over changing nameservers, because a nameserver change moves every record to whatever the new host has configured — which, for email, is usually nothing.
2. Editing records at the wrong provider. Covered above, worth its ranking: if changes seem to have zero effect anywhere even after TTL expiry, check the NS delegation. You're probably editing a zone nobody is reading.
3. Forgetting the second cutover during migrations. The old server keeps serving cached-DNS stragglers for hours after a cutover. If you take the old server down at the moment you flip DNS, everyone whose resolver still holds the old answer gets an outage. Keep the old destination alive (ideally proxying or redirecting to the new one) until the old TTL has fully expired.
4. Deleting records you don't recognize. That weird TXT record is verifying your Google Workspace ownership. That odd CNAME with a random-looking name is validating your TLS certificate. Zone cleanup feels hygienic and is a leading cause of 'why did unrelated service X break.' Rule: never delete a record you can't attribute; annotate records with comments/names where your provider allows it, and keep the zone export from rule 1 as your undo button.
5. Pointing at rented infrastructure by IP. Hardcoding an A record to a platform's current IP (instead of the CNAME they told you to use) works until the platform rotates addresses — theirs to rotate — and your site dies mysteriously. If a provider documents a CNAME target, use it; they're keeping that name pointed at the right place so you don't have to.
6. Wildcards and typos with big blast radius. DNS has no draft mode: a fat-fingered A record or an overbroad wildcard (*.example.com) is live the moment you save. For consequential changes, the TTL-lowering ritual doubles as a safety net — mistakes also expire in five minutes instead of a day.

A small operational kit

Habits that turn DNS from folklore into routine: keep a current export of your zone somewhere findable (most providers have an export button; a text file in your docs is fine); document what each non-obvious record is for; check delegation before editing; use dig (or an online equivalent) against your own nameservers to separate 'my change is wrong' from 'caches haven't expired'; do the TTL dance before every planned change; and after anything touching the zone, send yourself a test email from an external account — the cheap smoke test for the failure mode that hurts most. Optionally, an external monitor that alerts on unexpected DNS answer changes covers the mistakes you didn't know you made.

That's the whole subject at working depth: a phone book, six record types, caches with countdown timers, and a short list of well-worn ways to trip. 'It's always DNS' will stay a proverb — but mostly for people who change records at the wrong provider, on a 24-hour TTL, during business hours, with the MX records in the blast radius. Now you're not one of them.

Photo: Diogo Miranda on Pexels