DNS propagation: why it takes hours, and how to make it minutes

TL;DR: Propagation is a misleading word. Nothing travels across the internet when you change a DNS record. Your authoritative nameserver is updated instantly, and the delay you experience is thousands of independent caches around the world holding the previous answer until their countdown expires.

That countdown is the TTL you set, and it is entirely under your control. Lower TTL to 300 seconds two days before a planned change and the window shrinks from hours to minutes. Lower it at the moment of the change and it does nothing, because resolvers are still holding the old long-cached value. This single detail is the difference between a smooth migration and an afternoon of confused testing.

What actually happens when you change a record

The mental model most people have is that a DNS change is broadcast outward and gradually reaches servers around the world. That model produces bad decisions, because it suggests waiting is the only option.

What actually happens: you update a record at your authoritative nameserver. That change is live immediately. Any resolver asking your nameserver right now gets the new answer.

The delay comes from resolvers that are not asking, because they already have an answer cached and are not due to check again.

Every DNS response carries a TTL, a number of seconds telling the receiving resolver how long it may reuse this answer without asking again. A resolver that fetched your record with a TTL of 3600 will serve that cached answer for the next hour regardless of what you do at your nameserver.

There is no mechanism to reach into those caches and invalidate them. You wait for the countdown, and the countdown length is whatever TTL was in effect when they cached it.

So propagation is not distribution. It is expiry.

The practical consequence is that propagation time is a decision you made in the past, not a condition you are subject to now. If you set a long TTL and then made a change, you are living with your earlier setting. If you set a short TTL in advance, the same change completes in minutes.

The resolution path and where caching happens

Understanding where answers are cached explains most of the confusing behaviour people encounter.

Browser cache. Browsers keep their own DNS cache with short lifetimes, independent of the operating system. This is why a site can work in one browser and not another.

Operating system cache. Your machine caches lookups. On Windows this is the DNS Client service, on macOS the system resolver, and on Linux it depends on configuration. Flushing this is what most "clear your DNS cache" instructions refer to.

Local network resolver. Your router often caches, and it is a frequently overlooked layer. A phone and a laptop on the same network can both receive a stale answer from the router even after both device caches are cleared.

Recursive resolver. Your ISP's resolver, or a public one such as a well-known third-party service, serving many users. This is the layer where the TTL countdown genuinely matters, because it holds answers on behalf of everyone using it.

Authoritative nameserver. Yours. Always current.

The chain matters because a change looks incomplete when only one layer is stale. Someone tests, sees the old site, flushes their OS cache, still sees the old site because the router is caching, concludes propagation is slow, and waits — when in fact their ISP resolver updated ten minutes ago.

Testing properly, covered below, means querying at the layer you actually care about rather than accepting whatever your browser gives you.

TTL is the whole mechanism

TTL is a per-record value measured in seconds, set at your DNS provider.

Common values and what they mean in practice:

300 seconds (5 minutes). Changes take effect in minutes. Slightly higher query volume against your nameservers, and marginally more lookup latency for visitors whose resolver has to ask more often. Use during planned changes.

3600 seconds (1 hour). A reasonable default for stable records. Changes take up to an hour to be picked up universally.

86400 seconds (24 hours). Good for records that never change, and a serious problem if you need to change one urgently.

The trade-off is straightforward. Short TTL means agility and slightly more DNS traffic. Long TTL means efficiency and inflexibility.

The critical timing detail. Lowering TTL only affects resolvers that fetch the record after the change. A resolver holding a 24-hour cached copy will not see your new 300-second TTL until its existing countdown expires.

So lowering TTL two days before a change means: resolvers gradually re-fetch during those two days, each picking up the short value, and by the time you make the actual change nearly everyone is checking every five minutes.

Lowering TTL at the moment of the change means: resolvers holding the old long value continue holding it for its full duration, and you get no benefit at all.

Two days is comfortable for a 24-hour TTL. Twenty-four hours is usually sufficient for a one-hour TTL. The rule of thumb is to lower TTL at least as far in advance as the current TTL value.

Raise it back once the change is confirmed stable.

Why different people see different results

The most confusing part of any DNS change, and it follows directly from independent caching.

Different resolvers, different countdowns. Your ISP's resolver cached the record at a different moment from another ISP's, so their countdowns expire at different times. One person sees the new site, another sees the old one, and both are correct from their own position.

Different device and browser caches. Even two people on the same ISP will differ if their local caches were populated at different times.

Mobile networks cache aggressively. A phone on mobile data frequently sees a different answer from the same phone on Wi-Fi, which is a common source of confusion during migrations.

Some resolvers ignore short TTLs. A minority of ISP resolvers enforce their own minimum caching duration regardless of what you set, which is why a small tail of stale traffic can persist beyond your TTL. You cannot control this, which is the argument for keeping the old server running during a migration.

Corporate networks often run their own resolvers with their own policies.

The practical implication: during a change, assume some visitors reach the old destination and some the new one, simultaneously, for the duration of the window. If both destinations serve the site correctly, nobody notices. If the old one is switched off, those visitors see errors.

That is why keeping the previous server live during a migration matters more than the exact propagation timing, as covered in the migration guide.

Planning a change so the window is short

A sequence that reduces the window to minutes.

Two days before: lower the TTL on every record you intend to change to 300 seconds. Do not change anything else.

One day before: if you are switching DNS providers or nameservers, create the complete zone at the destination first. Every record: A, AAAA, CNAME, MX, TXT, SRV, CAA. A destination zone missing MX records means mail stops the moment the switch happens, which is the most common and most damaging omission.

Before the change: export and screenshot your current zone as a reference and rollback.

Make the change. Update the record at your DNS provider.

Verify at the authoritative nameserver first, which confirms your change is live regardless of any caching. If the authoritative answer is wrong, no amount of waiting helps.

Then check public resolvers to observe caches expiring.

Keep both destinations live through the window, so anyone still resolving to the old one gets a working site rather than an error.

After confirming stability: raise TTL back to a normal value.

Note that most of this work happens before the change. The change itself is a single edit, and the preparation is what determines whether it takes five minutes or five hours.

Change type	Controlled by	Typical window with 300s TTL	With 3600s TTL
A or AAAA record	Your TTL	Minutes	Up to an hour
CNAME	Your TTL	Minutes	Up to an hour
MX record	Your TTL	Minutes	Up to an hour
TXT record	Your TTL	Minutes	Up to an hour
Nameserver change	Registry TTL, not yours	Hours	Hours
New domain first setup	Registry publication	Minutes to hours	Minutes to hours
Registrar transfer	Not a DNS change	No DNS impact	No DNS impact

Nameserver changes take longer, and why

An important distinction that explains why some changes are quick and others are not.

Changing an A record is a change within your zone, governed by the TTL you set. You control it.

Changing nameservers is a change at the registry level, in the delegation records that tell the world which nameservers are authoritative for your domain. Those records carry a TTL set by the registry, not by you, and it is typically much longer than anything you would choose.

So a nameserver change takes hours regardless of what you set your own record TTLs to, because resolvers must first learn that the delegation changed before they will ask your new nameservers anything.

The practical implication: if you can achieve your goal by editing records rather than changing nameservers, do that. Moving hosting while keeping the same DNS provider is an A record change and completes in minutes with proper TTL preparation. Moving DNS providers as well is a nameserver change and takes hours.

If you must change nameservers: replicate the full zone at the new provider first, so that whenever a resolver switches over it receives complete and correct answers. During the transition, some resolvers use the old nameservers and some the new, so both zones must be correct and consistent.

This is also why the domain transfer guide recommends separating a registrar transfer from a DNS change: a registrar transfer alone touches neither your records nor your nameservers and causes no propagation at all.

Checking propagation properly

Most people check by loading the site in a browser, which is the least reliable method available.

Query the authoritative nameserver directly. This bypasses every cache and confirms your change is actually live at the source. If it is not, everything else is moot. Command-line tools let you specify which nameserver to query.

Query specific public resolvers. Checking against several widely used public resolvers shows you how caches are expiring at different points. This is a genuine progress indicator rather than a guess.

Use a global propagation checker. Web tools query resolvers in many locations and display which have the new value. Useful for a broad picture, though remember they check resolvers, not the specific one your customer uses.

Check the TTL in the response. Query tools show the remaining TTL on a cached answer, which tells you exactly how long until that resolver refreshes. A response showing 1800 seconds remaining means half an hour, not a guess.

Flush your own caches when testing locally. Browser, operating system, and remember the router. Testing from a different network entirely, such as mobile data, is often faster than clearing three layers.

Do not test only in your own browser. Between browser cache, OS cache and router cache, your machine is the least representative observer available, and it is where most false conclusions about slow propagation originate.

Common propagation mistakes

Lowering TTL at the moment of the change. Achieves nothing. The lead time is the entire mechanism.

Switching off the old server immediately. During the window some visitors still resolve there. If it is live and serving, nobody sees an error; if it is gone, they do. Keep it running for a week.

Incomplete zone at the destination. Especially missing MX records, which stops mail silently. Replicate every record before switching.

Assuming your browser reflects reality. Three layers of local caching sit between you and the truth.

Panicking at partial results. Different resolvers expiring at different times is normal and expected, not a sign of failure.

Changing several things at once. Nameservers, records and hosting simultaneously means that when something breaks you cannot tell which change caused it.

Forgetting to raise TTL afterwards. Leaving it at 300 seconds indefinitely increases query volume and adds a small amount of lookup latency for visitors.

Making changes on a Friday. If something goes wrong, you have discovered it at the start of the period when the fewest people are available to help.

FAQs

How long does DNS propagation take?

For record changes, as long as the TTL that was in effect when resolvers cached the previous answer, so minutes with a 300-second TTL and up to an hour with 3600. Nameserver changes take longer, typically hours, because they are governed by registry-level TTLs you do not control rather than by your own settings.

What is DNS propagation actually?

It is caching expiry, not distribution. Your authoritative nameserver updates instantly, and the delay is thousands of independent resolvers around the world continuing to serve a previously cached answer until their TTL countdown expires. Nothing spreads outward across the internet.

What is TTL in DNS?

Time to live, a value in seconds attached to every DNS response telling the receiving resolver how long it may reuse that answer without asking again. It is the single control over how quickly a change takes effect, and it is set per record at your DNS provider.

Can I speed up DNS propagation?

Only in advance, by lowering TTL before making the change. Once resolvers have cached an answer with a long TTL, nothing can invalidate it remotely; you wait for the countdown. Lowering TTL at the moment of the change has no effect on resolvers already holding the old value.

How far in advance should I lower TTL?

At least as long as your current TTL value. If your records are at 3600 seconds, lowering 24 hours ahead is comfortable. If they are at 86400, lower two days ahead. This gives every resolver time to re-fetch and pick up the shorter value before you make the actual change.

Why does my website work for some people and not others?

Because each resolver cached the record at a different moment, so their countdowns expire at different times. Someone on one ISP may see the new destination while someone on another still sees the old, and both are behaving correctly. Mobile networks often differ from Wi-Fi on the same device for the same reason.

Why do I still see the old site after propagation should be complete?

Most often local caching rather than actual propagation: browser cache, operating system cache, and the router, which people frequently forget. Test from a different network such as mobile data, or query a public resolver directly, rather than trusting your own browser, which is the least representative observer available.

Why do nameserver changes take longer than record changes?

Because delegation records at the registry level carry a TTL set by the registry rather than by you, and it is typically much longer than anything you would choose. Resolvers must learn that the delegation changed before they will query your new nameservers at all, which is why hours is normal regardless of your own record TTLs.

Should I turn off my old server after changing DNS?

Not immediately. During the window some visitors still resolve to the old address, and if it is live they see a working site rather than an error. Keep it running for about a week, since some resolvers enforce minimum caching durations beyond your TTL and a small tail of stale traffic persists.

How do I check if DNS has propagated?

Query your authoritative nameserver directly first to confirm the change is live at source, then query several public resolvers to observe caches expiring. A global propagation checker gives a broad picture. Query tools also show remaining TTL on a cached answer, which tells you exactly how long until that resolver refreshes.

Does changing my registrar cause DNS propagation delay?

No. A registrar transfer changes only who bills and manages the registration; your nameservers and records are untouched, so there is no DNS change and no propagation. Downtime during a registrar transfer only happens if you change nameservers or hosting at the same time, which is why separating those operations is worth doing.

What TTL should I use normally?

3600 seconds is a sensible default for stable records, balancing responsiveness against query volume. Lower to 300 during planned changes and raise it back once things are confirmed stable. Very long values such as 86400 are fine for records that genuinely never change but leave you inflexible in an emergency.

Conclusion

The word propagation causes the confusion. Nothing propagates. Your nameserver is correct the moment you save the change, and everything after that is caches counting down.

Which means the length of the window was decided by your TTL setting before the change, not by any process you are waiting on. That is good news, because it makes the whole thing controllable: lower TTL two days ahead and a change that would have taken an hour takes five minutes.

The timing is the part people get wrong. Lowering TTL as you make the change achieves nothing, because resolvers holding the old long value keep holding it. The lead time is the entire mechanism.

Two other things matter more than the propagation itself. Replicate the complete zone at the destination before switching, because a missing MX record stops mail silently and that is the most common serious migration failure. And keep the old server running for a week, because some resolvers ignore short TTLs and a working old server means those visitors see a site rather than an error.

Finally, stop testing in your browser. Three layers of local caching sit between you and reality, and querying the authoritative nameserver directly answers in one second what an afternoon of refreshing will not.

HostCloud includes DNS management in the same panel as your hosting, with per-record TTL control and full zone import so replicating a zone before a switch is a single step. Plans from ₹99 a month at https://hostcloud.in.