DNS Propagation: How Long It Takes and Why
You changed the nameservers an hour ago. Your phone still loads the old site, your business partner in Perth swears the new one is already live, and there is no obvious way to tell which of you is right.
That gap is what people call DNS propagation. The word is half the problem. It suggests something is being pushed out across the internet, and nothing is.
Once you know what is really happening the wait becomes predictable, and you can shrink it before you make the change.
Short answer: Most DNS changes on an .au domain are visible within a few hours, and often within minutes on your own connection. The commonly quoted worst case is 48 hours. That delay comes from resolvers holding a cached copy of the old record until its TTL expires, not from any central update process.
What is DNS propagation actually doing?
Nothing is being pushed anywhere. When you update a DNS record, the change is live at your authoritative nameservers straight away. Every other resolver on the internet keeps serving the copy it already holds until that copy expires. Propagation is simply the sum of all those caches timing out.
The chain is short. Your computer asks a resolver, usually one run by your internet provider, for the address behind a domain. The resolver either has a recent answer in memory or asks the domain’s authoritative nameservers for a fresh one, then keeps it for a set period before discarding it.
That set period is the TTL, and it is the whole story. If the mechanics are still fuzzy, the walk through of how a domain name turns into a server address covers the same chain from the start.
How long does DNS propagation take in Australia?
For .au domains, registry and nameserver changes are typically visible within a few hours. The number quoted everywhere is up to 48 hours, and that is a genuine worst case rather than a normal one. What decides your real wait is the TTL that was sitting on the record before you touched it.
A record with a five minute TTL updates for almost everyone inside five minutes. One that has sat at a full day for years can keep feeding the old answer to some visitors until that day is up, no matter how often you save the change. Neither your registrar nor your host can reach into a resolver in Melbourne and make it forget.
What is a TTL, and why does it decide the wait?
TTL stands for time to live. It is a number of seconds set on each individual DNS record, and it tells any resolver how long it may keep the answer before asking again. A record with a TTL of 86,400 seconds can be served from cache for a full day after you have changed it.
| TTL value | In plain English | What it means when you change the record |
|---|---|---|
| 300 seconds | 5 minutes | Old answers clear almost immediately. Set this before a planned move. |
| 3,600 seconds | 1 hour | Most resolvers pick up the change within the hour. |
| 14,400 seconds | 4 hours | A comfortable everyday setting. |
| 86,400 seconds | 24 hours | Some visitors reach the old server all day. |
How do I make a DNS change take effect faster?
Lower the TTL before you make the change, not after. Set the records you plan to move to 300 seconds, wait a day or two so every cached copy of the old high TTL has expired, then switch. From that point the longest anyone waits is about five minutes.
- Two days out, drop the TTL on the records you are changing to 300 seconds.
- Wait out the old TTL. If it was a day, resolvers need a full day to hold the shorter value.
- Get the new server ready and tested, then change the records.
- Leave the old server running for another day or two.
- Put the TTL back to an hour once you are happy.
The registrar side of a move is covered in the guide to shifting a domain to a new registrar, worth reading before you start rather than halfway through, along with the other domain names guides. Current pricing sits on the GoodHost domains page.
Why does the new site load for me but not for a colleague?
Because you are almost certainly using different resolvers. Your connection may have already expired its cached copy while theirs has not, and mobile networks often cache separately again. Browsers and operating systems hold their own smaller caches on top of that, which is why one device updates and another does not.
It is also why asking five people whether they can see it yet gives you five answers and no information. You are sampling caches, not measuring anything.
How do I check whether a DNS change has gone through?
Query the authoritative nameservers directly rather than trusting your browser. A lookup tool that lets you choose which server to ask will show you what the domain’s own nameservers are handing out right now, which is the only answer that really matters. Everything else you see is somebody’s cache.
- Check the record at the authoritative nameservers first. If it is wrong there, waiting will not fix it.
- Check it again through a public resolver to see what a typical visitor gets.
- Flush your local DNS cache before treating your own machine as evidence.
What should I do on the day I move a site to a new host?
Have the new server working before you point anything at it. Upload the site, test it on a temporary address, confirm the database and the mail records are right, and only then change the DNS. If you switch first and fix afterwards, visitors land on a broken site during the exact window you cannot control.
Keep the old hosting active for a couple of days afterwards. Stragglers still reaching it will see a working site. If the move also involves a different domain name, the redirect plan matters far more than DNS timing, and that is covered in the guide to changing a domain name without losing search rankings.
Frequently asked questions
Can I speed up DNS propagation by clearing my browser cache?
Flushing your browser and your operating system’s DNS cache will fix your own machine if it is holding an old answer. It does nothing for anyone else. The caches that control the wait sit at your internet provider’s resolvers and at every other resolver between your visitors and your nameservers, and none of those are yours to clear.
Will changing nameservers stop my email from arriving?
It can, if the MX records are not recreated at the new nameservers before you switch. Mail follows the MX record, so if the new nameservers have no MX entry or the wrong one, messages bounce or land on the old server. Copy every record across first, change the nameservers, then test that mail still flows.
Does transferring a domain to a new registrar cause propagation?
Not by itself. A transfer moves who manages the licence, not where the domain points. If the new registrar keeps the same nameservers and the same records, visitors notice nothing. Propagation only enters the picture when the transfer also changes the nameservers, which is common when you move hosts at the same time.
What do visitors see while a DNS change is still spreading?
They see whichever server their resolver sends them to, and they get a normal page either way. Some land on the old server, some on the new one, and neither group sees an error unless the old server has been switched off. That is the reason to leave the old site running for a couple of days.
Should I lower the TTL on every record or only the one I am changing?
Lower it on the records that will change, plus anything that depends on them. For a full host move that usually means the root A record, the www record and the MX records. There is no harm in dropping the whole zone to a short TTL for a few days and putting it back afterwards.
Set every record you intend to touch down to a 300 second TTL, then leave it alone for two full days before you change anything else. Nothing you do on the day shortens the wait as much. If the switch is also a registrar move, read the .au transfer terms at GoodHost domains first, because a transfer already in flight is an awkward time to be editing a zone.