DNS propagation and TTLs: why your change hasn't shown up yet

What "propagation" really is

When a resolver (your ISP's, your company's, or a public one such as 1.1.1.1) looks up a name, it caches the answer for the number of seconds in the record's TTL. Until that expires, it answers from its cache without asking your nameservers again.

So after you change a record:

• Your authoritative nameservers serve the new value immediately (or within seconds, depending on the provider's internal replication).
• Every resolver that cached the old value keeps serving it until its copy expires: anywhere from zero seconds to the full old TTL.
• Resolvers that never cached it get the new value right away.

That's why two people can see different results at the same moment, and why "it works for me" means little during a change.

The three caches that matter

1. The record's own TTL

www.example.com.  3600  IN  A  203.0.113.10

This answer can be cached for up to 3,600 seconds (one hour). If you change it now, some users may see the old address for up to an hour.

2. Negative caching

If someone looked up a name before it existed, resolvers cache the "doesn't exist" answer too. RFC 2308 sets that duration from the zone's SOA record: the lower of the SOA's TTL and its minimum field. If you create a record and some users still get NXDOMAIN, this is why. Check the SOA with the DNS Name Lookup.

3. Delegation (NS) caching

When you change nameservers at your registrar, resolvers keep using the old ones until the parent zone's NS TTL expires; that's two days for .com. Lowering TTLs in your own zone doesn't shorten this. See changing nameservers without downtime.

Planning a change

1. Find the current TTL with the DNS Name Lookup. It shows the remaining TTL as seen by the resolver.

2. Lower it in advance, to 300 seconds for example, and wait at least the old TTL before the change.

3. Make the change.

4. Verify at the source, by querying the authoritative nameserver directly:

   dig @ns1.yourprovider.example www.example.com A +short
   

5. Wait out the short TTL, then check public resolvers.

6. Raise the TTL again (one hour to one day for stable records). Long TTLs reduce query load and protect you briefly if your DNS provider has an outage.

Typical TTLs

Things that look like propagation but aren't

• Browser and OS caches. Browsers and operating systems cache DNS too. Try a private window or flush the OS cache (ipconfig /flushdns on Windows) before blaming DNS.
• Application caches. Java processes and some SDKs cache lookups for their whole lifetime unless configured otherwise.
• CDN or proxy in front. If a site is proxied (by Cloudflare, Azure Front Door and so on), public DNS returns the proxy's addresses. Changes to the origin don't show up in DNS at all.
• Edited the wrong zone. If the domain's nameservers point somewhere else, changes at your "usual" DNS host do nothing. Check with the Nameserver Lookup.
• Split-horizon DNS. Internal resolvers may serve a different zone from the internet.

Can I force propagation?

Not globally. You can't make other people's resolvers drop their cache. Some public resolvers offer a "purge cache" page for their own cache, which helps you test, but you can't flush every resolver on the internet. The only reliable control is to lower TTLs before the change.

From the field: Different DNS vendors have different propagation times. Some will take up to 24 hours, some are fairly instantaneous with changes. A tool to visualize that is extremely helpful when you are trying to troubleshoot.

Sources

• RFC 1035: Domain names, implementation and specification
• RFC 2308: Negative caching of DNS queries
• RFC 8767: Serving stale data to improve DNS resiliency