Why DNS changes can take hours to propagate

A web administrator in Brisbane updates the domain's DNS records and sees the new site appear within moments on a local desktop. Half an hour later a customer in Adelaide types the same address and lands on a broken page or an older version. This gap between expected and observed behaviour is DNS propagation, and the waiting period that follows a record change is one of the most misunderstood parts of how the internet routes traffic.

DNS is essentially the phonebook of the web, translating human-friendly domain names into the numeric IP addresses that servers actually use. When a URL is typed into a browser the request passes through a chain of resolvers, each of which keeps its own cached copy of the answer for a set window. The new record set at the authoritative source has to ripple outward through that chain, and every resolver in the chain checks back on its own schedule.

The Australian setting makes these delays especially visible. Long distances between population centres, the layered topology of the National Broadband Network, and a relatively concentrated pool of in-country DNS infrastructure all influence how quickly a change is noticed, and most of what makes propagation slow on this side of the world comes down to a handful of predictable patterns.

What propagation really refers to

Propagation is the gradual spread of an updated DNS record from the authoritative nameserver outward to every resolver, ISP cache, and end device that will eventually look it up. Nothing physically moves during this time. Each intermediate system holds onto the old answer until its cache expires, then refreshes on the next lookup.

The record change itself happens in seconds once an administrator saves it. The delay everyone notices is the time it takes for every caching layer to forget the old answer. So propagation is less about the internet updating and more about the internet politely forgetting on its own schedule.

TTL is the dial that controls the clock

Every DNS record carries a value called time to live, or TTL. TTL tells recursive resolvers how long they may cache the answer before they must ask the authoritative server again. A TTL of 3600 seconds means the answer can be reused for an hour, while a TTL of 60 seconds forces far more frequent checks.

When a planned move is on the horizon, the first practical step is to lower the TTL well before the change. Dropping the value from a day down to five minutes gives caches across the country a chance to expire quickly once the new record lands. The catch is that lowering TTL requires advance planning, since changing the value only after the cut-over has no effect on caches that already pulled the longer number.

Why Australia sometimes feels slower to update

Australia's geography plays an obvious role. A resolver in Perth, in Hobart, in Cairns, and in central Sydney all refresh independently, and the further an end user sits from the authoritative nameserver the more caching layers lie between them. Distance in this context is measured in network hops rather than kilometres, but the effect on patience is similar.

Local market conditions amplify the perception. Major residential ISPs such as Telstra, Optus, TPG, and Aussie Broadband each maintain their own recursive resolvers, and the cache lifetime on those resolvers may differ from the value set at the origin. Customers on the National Broadband Network often share connection points at the node level, which produces clusters of users who see the change at almost the same moment while neighbours on a different technology mix lag behind.

The .au namespace is administered by auDA, whose rules occasionally introduce brief registry-level delays on top of resolver caching. None of this is unique to Australian traffic, yet the combination of long routes, a handful of dominant ISPs, and a single regulator can make propagation feel slower here than in denser markets overseas.

Resetting your own cache is sometimes enough

For an end user staring at a stale page, the fastest fix is often the simplest: flush the local DNS cache. On Windows the command is ipconfig /flushdns. On macOS the equivalent is dscacheutil -flushcache. Mobile devices usually clear the cache automatically when the network type changes, such as toggling airplane mode.

Flushing only clears the local device's copy. It does nothing about the resolver on the ISP side, which is the layer most often responsible for the visible lag. Once the local cache is empty the next lookup will hit the ISP resolver, and if that one has also expired its copy the new answer is finally retrieved.

A quick sanity check during the wait is to point the device at a public resolver such as 1.1.1.1 or 8.8.8.8. Doing so side-steps the local ISP cache entirely and offers a near real-time view of what the authoritative server is currently returning.

When a cached version is the only version that works

Sometimes the goal is not to reach the live site but to confirm what a page looked like previously, which is where a cached snapshot proves useful. Browsers, search engines, and a handful of dedicated services all keep older copies of pages, and these archives can be retrieved even while DNS still points users at an old or broken host.

For readers curious about the mechanics of retrieving an older rendition while a domain is in flux, the walkthrough at browsing a cached copy explains the timing and the trade-offs. It is a useful fallback during planned migrations, particularly when downstream services depend on a known revision of the site for testing.

Why ISP resolvers tend to hold on longer

A common point of confusion is why one household sees the new site within minutes while a neighbour down the street still sees the old one hours later. The usual cause is resolver-level caching at the ISP. Residential connections are typically configured to use the provider's own recursive resolvers, and those resolvers obey the TTL on the old record until it naturally expires.

Some ISPs pre-fetch popular records and refresh them at intervals that ignore the origin TTL entirely, a practice that improves perceived speed for frequently visited sites but can stretch propagation delays. Toggling the network connection occasionally sends the next lookup elsewhere, which is part of why switching from Wi-Fi to mobile data and back appears to fix a stalled DNS change.

Planning a cut-over so users notice less

A change that catches an audience during Australia's evening browsing peak, between roughly seven and ten in the eastern states, tends to attract more support tickets than the same change made in the small hours of a Sunday morning. Where scheduling allows, low-traffic windows minimise the chance that anyone is actively trying to resolve the domain while caches are mixed.

Equally important is the pre-change TTL reduction mentioned earlier, which works best if the dial is turned down at least one full TTL period before the migration. With a record previously set to 24 hours that means a day of lead time. Communicating the planned window to stakeholders and posting a brief note on social channels give affected users a clear signal that the lag is expected rather than an outage.

If a handful of devices still refuse to cooperate the next morning, the remaining culprits are almost always a stubborn local cache, a stubborn ISP cache, or both. Working through that list in order usually finishes the job before lunch on the east coast.

When the next DNS change comes around, pre-emptively lowering TTL, clearing caches methodically, and timing the cut-over for a quiet window turn a frustrating wait into a manageable one. The main resource area gathers related guides worth keeping open during the next migration.