Why your DNS change isn't propagating: the five timers that actually govern it

A previous post argued that DNS doesn't really propagate — there's no synchronous update, just a million independent caches expiring at their own pace. This post is the practitioner's companion. If you actually need to predict when a record change will be live for your users, you need to know which caches stand between you and them, and the timer governing each one.

There are five. Most of the time only two or three matter. But you need to know all five because the cause of your specific delay is whichever one happens to be longest in your case.

Timer 1: registrar / registry serial (1 minute to several hours)

The first hop is the slowest you don't think about. When you edit a record in your registrar's control panel:

1. The registrar updates its zone file.
2. The registrar pushes the change to the registry (Verisign for .com / .net, PIR for .org, etc.).
3. The registry distributes the new zone serial to its global anycast nameservers.

For most modern registrars this whole chain runs in seconds. For some older ones it runs on a 15-minute or hourly schedule. For a few obscure ccTLDs (we're looking at you, .it) it can take hours.

How to check. Compare the serial number returned by the registrar's nameserver against the one in the registry's zone:

$ 

The first number in the SOA record (the serial) increments on every update. If your edit doesn't show up in this serial within a minute, the registrar hasn't pushed yet.

Timer 2: authoritative TTL (whatever you set)

This is the value you set on the record. It's the only one you control. It tells every downstream cache: "feel free to hold this answer for up to N seconds."

• Short TTLs (60–300 seconds) — fast updates, but high traffic to the authoritative nameservers and worse performance for end users.
• Medium TTLs (1–4 hours, 3600–14400) — most production traffic. Reasonable balance.
• Long TTLs (24 hours, 86400) — content-stable records like MX. Bad choice for anything you might want to change quickly.

The pre-change move. A day or two before you plan to update a record, drop its TTL to 300 seconds. Then wait the original TTL. Now you can change the record and downstream caches will only hold it for 5 minutes max.

Timer 3: recursive resolver cache (TTL respected, but not exactly)

Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9, your ISP's resolver. These are the actual machines your users' devices talk to. They cache the authoritative record for up to the TTL.

The two surprises:

1. Many resolvers cap maximum cache time. Even if you set TTL = 86400, some resolvers won't hold longer than 24 hours of their own internal limit. Helpful, mostly.
2. Some resolvers cache longer than TTL. ISP-grade caching DNS servers sometimes ignore TTL entirely in favour of their own retention policy (often hours longer). This is the dominant reason users on a specific ISP see "old DNS" long after everyone else has updated.

How to check. Query the major resolvers explicitly and compare answers:

$ 

If 1.1.1.1 sees the new record but 8.8.8.8 doesn't, you're observing different cache expiries. Wait, or check the DNS Lookup tool which queries all four major public resolvers from our infrastructure in parallel.

Timer 4: OS stub-resolver cache (seconds to tens of seconds)

Your operating system runs a tiny in-process resolver between applications and the recursive resolver. macOS, Windows, and modern Linux distros all cache DNS lookups for some default window.

Defaults you'll see in practice:

• macOS (mDNSResponder) — typically respects TTL up to 30 seconds, then re-queries.
• Windows (dnscache service) — defaults to TTL with a 10-minute ceiling.
• systemd-resolved (most modern Linux) — respects TTL, configurable in /etc/systemd/resolved.conf.

Why this matters. If you're testing on your own machine and seeing stale results, this is often the culprit — not the upstream resolver. Flush before you escalate:

$ 

Timer 5: browser cache (60 seconds is typical)

Modern browsers cache DNS results in-process for a short window — usually 60 seconds, though Chrome's behaviour has changed several times. This is on top of every other cache.

The fastest way to bypass it is to test in a private/incognito window, which uses a separate cache. Hitting reload doesn't always invalidate this cache; closing all windows for the affected hostname usually does.

In Chrome you can inspect and clear the browser DNS cache at chrome://net-internals/#dns.

A worked example

You changed www.example.com from 192.0.2.10 to 192.0.2.20 at 14:00 UTC. The current authoritative TTL is 3600 (1 hour). What time will every user see the new IP?

The takeaway: the TTL you set is a floor on the upper-bound of cache lifetime, not a ceiling. Real-world results vary by ±50%.

The pre-flight checklist

When you're planning a DNS change you actually need to land cleanly:

1. One to two days before. Lower the TTL to 300 seconds (or whatever's tolerable for your traffic).
2. Wait one full old TTL. Now every downstream cache will refresh within 5 minutes.
3. Make the change. Update the record at the registrar.
4. Probe immediately. Query each major public resolver. They should show the new value within seconds (registry serial push + 5-minute TTL).
5. Watch for ISP-cache stragglers. Some ISPs run their own caching layer beyond the public resolver. If your customer base is regional, sample from a few ISPs in the relevant geography.
6. Raise TTL back up. Once the change has been live for a day and you're confident, raise the TTL back to its production value to reduce load on the authoritative nameservers.

The whole flow takes 24 to 48 hours of clock time for a few minutes of actual work.

DNS-over-HTTPS and DNS-over-TLS

Modern browsers increasingly bypass the OS resolver entirely via DoH. Firefox uses Cloudflare DoH by default in many regions. Chrome uses upgrade-when-supported. This means:

• Your OS resolver settings don't matter for that browser.
• The browser's DoH provider's cache governs.
• Flushing the OS cache won't help.

For most users this is invisible. For diagnosis it adds another timer to think about.

Negative caching: the underappreciated case

If a domain returns NXDOMAIN (doesn't exist), that negative answer also gets cached. The TTL for negative responses is set by the SOA record's minimum field — typically 1 hour.

Why this matters: if you fix a misconfigured zone, users who tried during the broken window will keep seeing NXDOMAIN until the negative cache expires. The fix isn't visible immediately even after the zone is correct.

Tools that help

• DNS Lookup tool — query A/AAAA/MX/NS/TXT against four resolvers from our infrastructure. Catches mid-propagation states.
• DNS Propagation Checker — same idea but specifically designed for comparing answers across providers in a single view.
• dig +trace — walks from the root nameservers down to your authoritative servers. Useful when you suspect the chain itself is broken (delegation issue).
• DNSViz — visualises the delegation chain and DNSSEC chain of trust.

The mental model

There is no single "DNS propagation timer." There is a sequence of independent caches, each obeying its own rules. The total delay your users experience is the maximum of the timers that apply to their specific path through the network.

Plan changes around the longest plausible timer. Probe from multiple vantage points after the change. Don't trust your own machine — flush every cache between you and the authoritative server before declaring victory.