What is DNS propagation?

The word suggests something spreading across the internet. Nothing is.

When you change a DNS record, the change is live at your nameservers immediately. The delay is everywhere else: every resolver that asked recently is still holding the old answer, and will keep giving it out until its copy expires.

So the site is live for you, because you checked after the change, and not for your client, because their office resolver asked an hour before. Nothing is broken. Something is cached.

It is governed by the TTL on the record — the number of seconds a resolver may keep the answer. A TTL of 3600 means an hour. A TTL of 86400 means a day.

Typical experience:

• Record changes — minutes to a few hours
• Nameserver changes — a few hours, occasionally up to a day, because the registry record has its own caching on top
• Worst case — 48 hours, usually because something between you and the internet is ignoring TTLs, which some ISP resolvers do

Plan ahead and it is almost instant.

1. A day before the change, lower the TTL on the records you will edit to 300 seconds 2. Wait for the old TTL to expire, so resolvers pick up the short one 3. Make your change. It now takes five minutes to reach everyone 4. Put the TTL back to something sensible afterwards, so your nameservers are not answering the same question constantly

This is the single most useful DNS trick there is, and almost nobody does it.

Do not use your browser. It caches on top of everything else and will mislead you.

• Query directly: dig yourbusiness.co.ke or nslookup yourbusiness.co.ke shows what a resolver is actually returning
• Ask a public resolver: dig @8.8.8.8 yourbusiness.co.ke skips your own ISP
• Use a phone on mobile data, which goes through a different resolver from your office
• Flush your own cache if you must test locally

If dig returns the new answer and your browser does not, the change is done and your browser is the one lying to you.