How Long Does DNS Propagation Take? What Actually Controls It

Anyone who has changed a DNS record knows the feeling: you edit it, reload the site, and see the old server. The usual advice is "wait 24 to 48 hours", which is unhelpful and often wrong. This guide explains what is actually happening, so you can predict how long your change will take to be visible, check it properly, clear your own caches, and plan migrations without guessing.

"Propagation" is really cache expiry

Nothing is pushed across the internet when you edit a DNS record. Your authoritative nameserver simply starts giving a different answer. The delay comes from recursive resolvers (ISPs, corporate networks, public DNS services) and operating-system caches that stored the old answer and are allowed to keep using it until its TTL runs out.

That makes the maximum delay for a record change straightforward in principle: it is roughly the TTL the old record had when a resolver last fetched it. A record with a 300-second TTL is stale for at most about five minutes in a well-behaved resolver. A record with a 86400-second TTL can be stale for up to a day.

A few consequences follow:

• Different people see the change at different moments, because each resolver fetched the old record at a different time and its countdown started then.
• Lowering the TTL after you change the record does not help. Resolvers that already cached the long-lived answer keep it. The TTL must be lowered before the change, by at least the old TTL's length. See the DNS explained guide for the safe procedure.
• Layers stack. A browser, the operating system, a local router and the ISP resolver may each hold their own copy.

Where stale answers hide

1. Browser cache. Browsers keep their own short-lived DNS cache and also keep open connections to the old server.
2. Operating-system resolver cache. Windows has a DNS client cache, macOS uses its own resolver services, and many Linux systems use systemd-resolved or nscd, while others cache nothing.
3. Router or local forwarder. Home routers and office DNS servers such as dnsmasq often cache.
4. ISP or enterprise recursive resolver. The big one. Large public resolvers run many caching instances, so two consecutive queries can hit different caches.
5. Application-level caching. Some runtimes, proxies and load balancers resolve a hostname once at startup and hold it for the life of the process. Nginx, for instance, resolves upstream hostnames at configuration load unless configured otherwise, and some JVM setups cache lookups aggressively.

Resolvers do not always honour your TTL

TTL is a ceiling on how long an answer may be cached, but resolver behaviour varies. Some implementations impose a minimum TTL (raising a value of 30 seconds to a higher floor) or a maximum TTL (shortening very long values). Policies differ by operator and are configurable, which is why a hard promise such as "five minutes" is not something you can rely on for every visitor. Treat your TTL as the expected behaviour, and your plan should tolerate stragglers.

Negative caching: when "does not exist" is remembered

Resolvers also cache failures. If someone queries new.example.com before you create it, the authoritative server answers NXDOMAIN (name does not exist), and the resolver may remember that for a period governed by the negative TTL, taken from the SOA record. Under the rules in RFC 2308, the cache time is the lower of the SOA record's own TTL and its MINIMUM field.

Practical effect: if you test a hostname before the record exists, or a monitoring probe asks for it early, you may see "not found" for a while even after creating it. Create records first, test afterwards, and look at your zone's SOA values:

dig SOA example.com +short
# ns1.dnshost.example. hostmaster.example.com. 2026100401 7200 3600 1209600 3600

The last number here, 3600, is the negative-caching value the zone suggests.

Nameserver changes: the slowest kind

Changing records inside a zone is bound by your record TTLs. Changing which nameservers are authoritative is different, because the answer lives at the parent. When you update nameservers at your registrar, the registry updates the delegation (NS records in the TLD zone) and any glue records (the IP addresses for nameservers inside your own domain, such as ns1.example.com). Resolvers cache those delegation records for the TTL the TLD operator sets, which you cannot change, and which is commonly measured in hours or days depending on the registry.

Resolvers that already know your old nameservers will keep asking them until that cache entry expires. So:

• Keep the old nameservers answering with correct, current data throughout the move. If both old and new serve identical zones, nobody notices the cutover.
• Do not cancel the old DNS hosting plan the moment you change the delegation.
• Verify the delegation with dig NS example.com @a.gtld-servers.net (replace with a nameserver of the relevant TLD, which dig +trace will show you).

dig +trace example.com NS

The Nameserver Lookup tool shows what the registry currently delegates.

How to verify a change properly

Test in the order the data flows, from source outward.

1. Ask the authoritative servers

First confirm the change was saved where it counts. Find the nameservers, then query them directly without recursion:

dig NS example.com +short
dig @ns1.dnshost.example www.example.com A +norecurse

If this still shows old data, the edit was not applied, or you edited a different provider's zone. Nothing else matters until this is right.

2. Ask specific public resolvers

dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A
dig @9.9.9.9 www.example.com A

Look at the TTL column. If it counts down on repeated queries, you are seeing a cached answer; its remaining time tells you when that resolver will refresh. A resolver showing the old value with a TTL of 1,200 will turn over within about 20 minutes (assuming it honours the value).

3. Check from several places

Because large resolvers have many caches, results can vary by location. The DNS Checker queries from multiple locations and shows where answers disagree, and Down From Where helps determine whether a problem is regional.

4. Confirm that the site itself responds

DNS may be correct while the new server is misconfigured. Bypass DNS to test the destination:

curl -I --resolve www.example.com:443:203.0.113.20 https://www.example.com/

Flushing your own caches

Flushing your machine only fixes your machine; it cannot refresh anyone else's resolver. It is still useful when your own view is stale.

Also close and reopen your browser, since it holds its own cache and persistent connections. Chromium-based browsers expose an internal DNS page you can clear, and a private window avoids some stale state. If a hosts file entry exists on your machine, it overrides DNS entirely, so check C:\Windows\System32\drivers\etc\hosts or /etc/hosts when behaviour makes no sense.

Planning a migration without a fixed deadline

Instead of waiting an arbitrary number of hours, plan around the numbers you can read.

1. Read the current TTL of the records you will change: dig www.example.com A against the authoritative server.
2. At least that long before the cutover, lower the TTL (300 seconds is a common choice).
3. Prepare and test the new server, and ideally make it accept traffic for the hostname in advance.
4. Change the record. Expect most traffic to move within the low TTL, and a tail of slower resolvers afterwards.
5. Keep the old server running, ideally redirecting or proxying to the new one, until logs show traffic has dwindled. For databases and write traffic, set the old system read-only or forward writes so no data is split across two places.
6. Restore a longer TTL after stabilisation.

For a nameserver move, schedule extra time because registry TTLs are outside your control, and run both sets of nameservers with identical data until the old one stops receiving queries. If you need to confirm what a hostname used to resolve to, DNS History is useful for comparing before and after.

Next steps

• Compare resolver answers with the DNS Checker.
• Confirm delegation using the Nameserver Lookup and the WHOIS Lookup.
• Check where the site is served with the Website Hosting Checker.
• Refresh the fundamentals in DNS explained for website owners.
• If things still look broken after a change, work through why is my website down.

FAQ

Is DNS propagation really 24 to 48 hours?

No fixed number applies. Record edits are bounded by the old record's TTL, which is often minutes to a few hours. Nameserver changes depend on registry-level caching and can take longer. The "24 to 48 hours" line is a cautious rule of thumb, not a measurement.

Why can I see the new site but my colleague still sees the old one?

You are probably using different resolvers or have different cached entries, each with its own expiry time. Compare dig results against the same public resolver on both machines, and flush local caches.

Does flushing DNS speed up propagation for everyone?

No. It clears only your own machine's cache. Other people's caches expire on their own schedule, which is set by the TTL the old record carried.

Can I force Google Public DNS or Cloudflare to refresh a record?

Some public resolvers offer a cache-purge form for a specific name, but availability and behaviour change over time, so check the provider's current documentation. Lowering the TTL ahead of time remains the dependable approach.

Why does a new subdomain show NXDOMAIN after I created it?

Likely negative caching: a resolver checked the name before the record existed and cached the "not found" answer. It will clear after the SOA negative TTL passes. Query an authoritative server to confirm the record exists.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.