Practical guide · verified against the real thing
Why does DNS not work — and why do changes 'take so long'?
In one line: Wrong records, caching layers, and the registry itself: how to find which layer is lying to you, and what propagation actually is.
The symptom: you changed a DNS record, and part of the world still sees the old one. Or a brand-new domain simply does not resolve at all. DNS feels mystical mostly because there are five layers between your typing and the internet's answering, and any one of them can be the one that is out of date. Name the layer, and the mystery dies.
Likely causes, most common first
1. The record itself is wrong (very common): a typo in the hostname or target; an A record where a CNAME was needed (or the reverse — CNAMEs cannot coexist with other records on the same name); an apex domain given a CNAME, which many providers forbid or flatten specially.
2. Caching, at the resolver (very common): records carry a TTL — "time to live" — and resolvers keep answers until it expires. A low TTL (60–300 seconds) spreads changes fast; a high one (hours to a day) is why your aunt still sees the old site.
3. Your own device's cache (common during testing): operating systems and browsers cache answers too; you are sometimes the stale one.
4. Nameservers not pointing where you think (common after a registrar or host change): the records you are editing live at one provider, but the domain's nameservers point at another. You are carefully updating a record nobody reads.
5. The registry itself (rare, but the deepest): the domain is expired, on hold, or not fully registered — no DNS anywhere can answer for it. We know this failure intimately: this site's own domain spent weeks not existing at the registry level while nameserver configuration sat correct at every provider — a reminder that the layer you can edit is not always the layer that is broken.
Diagnosis: interrogate each layer
Ask a public resolver directly: dig yourdomain.com @1.1.1.1 (or an online equivalent). If the authoritative nameservers answer correctly but resolvers do not, it is caching — check the record's TTL and wait it out, or lower TTLs before the next change (the professional's habit). If the authoritative servers answer wrongly, fix the record at that provider. If nobody answers, check the domain's status at a registry whois lookup (ICANN Lookup): clientHold, serverHold or a missing delegation means the problem is above DNS entirely. Then compare two independent resolvers (say 1.1.1.1 and 8.8.8.8) — agreement means propagation is done, however your browser feels.
The fix, in the right order
Lower TTLs a day ahead of planned changes → make the change at the provider the nameservers actually point to → verify at the authoritative nameservers → let caches age out (minutes for low TTLs, up to a day or more for high ones) → only then troubleshoot "downstream" things like certificates, which need working DNS before they can issue at all — see why your certificate will not issue.
When this fix will not work
A registry hold only your registrar can lift; DNSSEC configured at the registrar but wrong at the host (validation failures look like total non-existence); and enterprise networks pinning their own resolvers with long caches — nothing you control fixes the last one fast, which is why propagation checkers that sample many networks exist.
Official documentation (checked 11 September 2026): Cloudflare's DNS learning library (cloudflare.com/learning/dns), ICANN Lookup (lookup.icann.org), and your registrar's DNS status reference. The fuller primer: what DNS actually is, and the order-of-operations that avoids downtime in custom domains: the DNS order.
Next