TTL, propagation and common mistakes
What TTL really controls, how to migrate a domain safely, and the misconfigurations that cause outages.
TTL decides how long you are stuck
TTL is not a delay - it is how long resolvers may reuse an answer without asking again. There is no such thing as "DNS propagation"; there is only caches expiring at different times, which is why a change appears to roll out gradually across the world.
| TTL | Sensible for |
|---|---|
| 60 s | A record you are about to change during a migration |
| 300 s | Load-balanced hosts and endpoints that move |
| 3600 s | Steady-state website addresses |
| 86400 s | MX and TXT records that change once a year |
# before a migration, lower the TTL and wait at least one old TTL
dig example.com A +short # confirm the new TTL is live everywhere
# ... cut over ...
# then raise it again once the change is proven
# how long is left on a cached answer?
dig example.com A | grep -E "^(example|www)"The mistakes that cause real outages
- Missing trailing dot on a target name, so the resolver appends the zone again.
- A CNAME at the apex, which breaks the records the zone needs at that name.
- Two SPF TXT records: receivers must choose one, and an invalid result can send mail to spam. Merge into a single record.
- Changing name servers and records at once: no way to tell which change broke it.
- MX pointing at a name inside the same zone with no A record: the mail server can never be reached.
- CAA restricting issuance while certificates come from a different authority - renewals start failing silently.
- DNSSEC enabled at one party only: the zone is signed but the registrar has no DS record, producing SERVFAIL instead of an answer.
⚠️
Changing name servers invalidates the old zone's records at whatever TTL they had, and there is no rollback that is faster than a TTL. Copy every record across, compare the two zone listings, and only then switch the delegation.
Verifying before you announce it
A change is not verified until you have asked several independent resolvers and the authoritative server. Browsers and operating systems will keep lying to you from their own caches.
# 1. authoritative answer (the source of truth)
dig @ns1.example.com www.example.com A +short
# 2. two independent public resolvers (cache state)
dig @1.1.1.1 www.example.com A +short
dig @8.8.8.8 www.example.com A +short
# 3. mail routing and a live delivery test
dig example.com MX +short
# then send a real message from an outside account
# 4. certificate issuance permission
dig example.com CAA +short- Check from a network you do not control - a phone hotspot bypasses your office resolver.
- Keep a short TTL during the change window and raise it afterwards.
- Record the intended state somewhere; the next person debugging will not remember which IP was correct.
FAQ
How long does DNS take to update?
As long as the old TTL, plus resolver behaviour. With a 300 s TTL, expect most of the world within minutes and the tail within a few hours. Providers offering "instant propagation" are only lowering TTLs for you.
A new record does not resolve at all - why?
Usually a missing trailing dot, a record created in the wrong zone, or a name server that has not been updated yet. Query the authoritative server directly to rule out caching.
Related
Record types that matter How name resolution works
Last refreshed 2026-09-18.