What DNS propagation is, how it works and why changes can take up to 24 hours

1. The basics – how a DNS lookup happens

1. You type a hostname (e.g. www.example.co.uk) into a browser.
2. Your computer asks its recursive resolver (usually your ISP’s DNS server or a public resolver such as Cloudflare 1.1.1.1).
3. The resolver checks its local cache. If it has a recent answer it returns it straight away.
4. If the answer is not cached, the resolver queries the authoritative name servers for the domain, walking the DNS hierarchy (root → .uk → .co.uk → example.co.uk).
5. The authoritative server returns the requested record (A, CNAME, MX, etc.) together with a TTL (Time‑to‑Live) value.
6. The resolver stores that record in its cache for the duration of the TTL and returns the data to your computer.

2. What “DNS propagation” really means

Propagation is the informal term for the time it takes for all recursive resolvers worldwide to receive the new data and replace the old cached records. When you change a DNS record (e.g. point a domain to a new IP address), the authoritative server starts answering with the new value immediately, but any resolver that already has the old value cached will keep using it until its TTL expires. Only after the cached entry expires will the resolver request fresh data and receive the update.

3. TTL – the key driver of propagation speed

Why TTL matters

• When you lower the TTL a few days before a planned change, you tell resolvers “don’t keep this record for long”. After the TTL expires, the next query will fetch the new data.
• After the change is live, you can raise the TTL again to reduce query load and improve performance.

4. Why you often hear “it can take up to 24 hours”

• Many domain owners leave the default TTL at 86 400 seconds (24 h).
• Even with a lower TTL, some intermediate caches (ISP DNS servers, corporate firewalls, routers) may ignore the advertised TTL or have their own refresh policies, adding a few extra minutes or hours.
• Propagation is not a single event – each resolver updates independently when its cache expires, so the worldwide “full” update is a gradual process.

In practice:

5. How to manage DNS changes effectively

1. Plan ahead

• Reduce the TTL at least 24 hours before the intended change (e.g. from 86 400 s to 300 s).
• Wait for the old TTL to expire (check with dig +nocmd example.co.uk +noall +answer +ttl or an online DNS checker).

1. Make the change

• Update the record on the authoritative server (A, CNAME, MX, etc.).

1. Verify

• Use tools like dig, nslookup, or web services (e.g. DNSChecker.org) to query different locations.
• Look at the TTL column to confirm the new value is being served.

1. Restore the original TTL (optional)

• Once you’re confident the change has propagated, raise the TTL back to a longer value to reduce DNS query traffic.

1. Consider caching on your own devices

• Flush the local DNS cache (ipconfig /flushdns on Windows, sudo killall -HUP mDNSResponder on macOS, sudo systemd-resolve --flush-caches on Linux).
• Restart browsers or clear their own DNS caches if you still see the old site.

6. Quick checklist for a smooth DNS migration

• [ ] Lower TTL (e.g., 300 s) ≥ 24 h before the change.
• [ ] Wait for the old TTL to expire (use dig to confirm).
• [ ] Update the required records on the authoritative server.
• [ ] Test from multiple DNS resolvers (public, ISP, mobile).
• [ ] Flush local and browser caches if needed.
• [ ] Raise TTL back to a comfortable value (e.g., 3 600 s or 86 400 s) once the new records are stable.

7. Common myths debunked

Bottom line: DNS propagation is simply the gradual expiry of cached records across the world’s recursive resolvers. The TTL value you assign to a record dictates the maximum time a resolver may hold onto old data. By managing TTLs—lowering them before a change and raising them afterwards—you can control how quickly your updates become visible, usually keeping the process well under the generic “24‑hour” rule.