---
title: How DNS Works (and What 'Propagation' Really Means)
description: DNS is the internet's phonebook — and one of the most common causes of outages nobody understands. Here's how a domain name becomes an IP address, in plain English, plus what 'propagation' actually is.
canonical: https://watchfor.io/blog/how-dns-works
---

# How DNS Works (and What 'Propagation' Really Means)

2026-06-12 · WatchFor Team · Networking · dns, networking, basics

DNS is the internet's phonebook — and one of the most common causes of outages nobody understands. Here's how a domain name becomes an IP address, in plain English, plus what 'propagation' actually is.

You update a DNS record to point your domain at a shiny new server. You refresh — and it works! You text a colleague to check. For them, it's still showing the *old* server. Cue an hour of "but it works on my machine" confusion.

Welcome to **DNS** — the quiet system that turns `yoursite.com` into a number computers can actually use, and a frequent, baffling source of outages. Once you understand how it really works (and what "propagation" actually means), that confusing hour disappears.

## DNS is the internet's phonebook

Computers don't talk to `yoursite.com`. They talk to IP addresses like `192.0.2.10`. **DNS (the Domain Name System)** is the directory that translates the friendly name humans type into the number machines need.

Every single time you load a website, send an email, or call an API, DNS quietly does this lookup first. Which is exactly why, when DNS breaks, *everything* breaks.

## The journey from name to IP

When you type a domain, your computer doesn't magically know the answer. It asks around, in a quick relay:

| Step | Who answers | What happens |
| --- | --- | --- |
| 1 | **Your resolver** (usually your ISP or a public one like 1.1.1.1) | "Do I have this cached? If not, I'll go find out." |
| 2 | **Root servers** | "I don't know `yoursite.com`, but here's who handles `.com`." |
| 3 | **TLD servers** (`.com`) | "Here's the authoritative name server for `yoursite.com`." |
| 4 | **Authoritative name server** | "Here's the actual answer: `192.0.2.10`." |

The resolver then hands the IP back to your browser, which finally connects. All of this usually happens in **milliseconds** — and then gets **cached** so it doesn't have to repeat. Hold on to that word *cached*; it's the key to the whole "propagation" mystery.

## The record types you'll meet

DNS stores more than just addresses. The common record types:

| Record | What it does |
| --- | --- |
| **A** | Points a name to an IPv4 address |
| **AAAA** | Points a name to an IPv6 address |
| **CNAME** | An alias pointing one name at another name |
| **MX** | Says which mail servers receive email for the domain |
| **TXT** | Free-form text — used for SPF, DKIM, domain verification |
| **NS** | Names the authoritative name servers for the domain |

## TTL: the timer that controls everything

Every DNS record carries a **TTL (Time To Live)** — how many seconds a resolver is allowed to *cache* the answer before asking again. A TTL of 3600 means "reuse this for an hour."

TTL is the single most important DNS concept for avoiding surprises:

- **High TTL** (e.g. 24 hours) — fast, fewer lookups, but changes take a long time to take effect.
- **Low TTL** (e.g. 5 minutes) — changes apply quickly, at the cost of more lookups.

> **Pro move:** before a planned DNS change (like a server migration), *lower the TTL a day in advance*. Then when you flip the record, the change rolls out in minutes instead of hanging around for a day.

## What "propagation" really means

Here's the myth-buster. People imagine a DNS change has to "spread across the internet" like ripples in a pond. It doesn't.

**There's no global broadcast.** When you change a record, the authoritative server updates *instantly*. What actually causes the delay is **caching**: resolvers around the world are still holding the old answer until its **TTL expires**. Your colleague saw the old server because *their* resolver's cache hadn't expired yet.

So "propagation time" is really just **"the longest TTL anyone cached, counting down."** That's why pre-lowering TTL works, and why a change can look instant for you and slow for someone else.

## Why DNS breaks (and how to catch it)

DNS problems are sneaky because the rest of your stack is fine — the server is up, the code is good, but nobody can *find* it. Common causes:

- A **typo** in a record (wrong IP, missing trailing dot).
- A **deleted or expired** record.
- An **expired domain registration** (the ultimate DNS failure).
- A change that **hasn't finished caching out** (TTL).

Because DNS sits *before* everything else, monitoring it is essential: watch that your domain resolves, that it returns the **records you expect**, and that resolution is fast — from multiple places, so you can see a change rolling out (or a problem) across regions.

## The bottom line

| Concept | In one line |
| --- | --- |
| DNS | The phonebook turning names into IP addresses. |
| The lookup | Resolver → root → TLD → authoritative, then cached. |
| TTL | How long an answer is cached before re-checking. |
| "Propagation" | Not a broadcast — just old caches expiring on their TTL. |

DNS feels like dark magic until you see the relay and the caching behind it. Then "propagation delays" stop being mysterious and become something you can plan around.

You can inspect any domain's records right now with the free [DNS lookup](/dns-checker), watch a change roll out worldwide with the [DNS propagation checker](/dns-propagation-checker), and set up continuous checks with our [DNS monitoring guide](/docs/monitors/network).

---

Canonical page: https://watchfor.io/blog/how-dns-works · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt