DNS updates: not propagation, just cache expiry
The common phrase "DNS propagation" implies that when you update a DNS record, that change is slowly pushed out across the internet until every resolver has the new information. That mental model is wrong. DNS is a pull system: resolvers ask authoritative nameservers for records, and they cache what they get. The delay you experience after updating a record is not the time it takes for the record to spread — it's the time it takes for every cached copy of the old record to expire.
This distinction matters in practice. The standard advice for DNS changes is to "wait 24–48 hours." But that guidance is often overly cautious. If you understand why updates can be slow, you can sometimes skip the wait entirely.
Why new records are available instantly
Creating a DNS record that didn't exist before is instant. There's no old cached version to wait out. If you create a record and query for it seconds later, you'll get the new value — no delay at all. The reason is that the authoritative nameserver simply answers with the current record whenever it receives a query. It never pushes anything anywhere.
If a record is never queried, no resolver will ever know it exists. A DNS update doesn't need to "reach" resolvers; it only becomes visible when a resolver actually asks for it and finds no valid cached copy to reply from.
Why updates are slow: caches, not distribution
A DNS resolver like 8.8.8.8 caches the records it receives. While a cached record is still considered valid, the resolver will never request a fresh copy from the authoritative nameserver. An update to that record only takes full effect once every cached version of the old record has expired — which in theory is governed by the TTL ("time to live") value on the record.
In practice, several things can make that expiry take far longer than the TTL suggests.
Some resolvers ignore TTLs
Not every resolver respects the TTL you set. Some ignore it and cache records for as long as they please — sometimes 24 hours or more. You cannot control this, so your update can take longer to be visible than the record's TTL would lead you to expect.
Negative caching: when a record doesn't exist yet
A particularly frustrating case is when you query for a name before its DNS record exists. Resolvers can cache the absence of a record, and that absence can outlive the TTL you'd expect. The rules for this sit in RFC 2308: negative caching uses a TTL determined by the minimum of the SOA record's MINIMUM field and the SOA's own TTL. For jvns.ca subdomains, that works out to:
$ dig soa jvns.ca
jvns.ca. 3600 IN SOA art.ns.cloudflare.com. dns.cloudflare.com. 2264245811 10000 2400 604800 3600
That's the minimum of the SOA TTL (3600 seconds) and the last value in the SOA record (also 3600), giving a negative cache lifetime of one hour. If you make the mistake of visiting a URL before creating its record, you'll be waiting that full hour before the record suddenly starts working. Behavior varies by resolver — Cloudflare's 1.1.1.1 doesn't appear to do negative caching, but many ISP resolvers do.
Browsers and operating systems cache too
DNS isn't cached only by public resolvers. Your OS and browser keep their own DNS caches, and they may hold onto a stale record even after the resolver's cache has expired. Firefox, for example, sometimes requires a forced reload (Ctrl+Shift+R) to pick up a DNS change that is already resolvable from the resolver's perspective.
Nameserver changes are slower than record changes
Changing a record with a short TTL is relatively quick. Changing your domain's nameservers is a different story. Two things must happen: your registrar must inform your TLD's nameservers about the new nameservers, and any resolver caches holding the old nameserver records must expire. Those records typically carry a TTL of about a day, so the full change can easily take that long just for the cache expiry phase. The registrar-to-TLD step is not instant either.
Resolver caches behave a bit like CDN caches
Understanding resolver caching is easier if you already know how CDN caching works. Both have an origin server — for DNS it's the authoritative nameserver, for CDNs it's the HTTP origin. Both hold cached content for a finite period: DNS resolvers expire based on TTL (or their own policy, if they ignore it), CDNs based on the HTTP Cache-Control header or their own rules.
The critical difference is control. CDNs usually offer a way to purge cached content. DNS resolvers generally don't, and there's no central authority over the thousands of resolvers run by different organizations running different software. 8.8.8.8 does have a cache-flush feature, but most do not.
The word "propagation" is misleading, but it's also accurate
The phrase "DNS propagation" is so widespread that it shapes how people think about the mechanism. If the process were described as "waiting for cached records to expire," the concept would be immediately familiar to most programmers — they already deal with cache invalidation constantly. The misleading terminology is a plausible reason why otherwise experienced engineers end up with the wrong model.
That said, DNS records do propagate in a narrow sense. Large authoritative DNS providers run globally and synchronize updates across their servers, and that synchronization takes some time. But this delay is generally measured in minutes, not hours or days, and it isn't what people mean when they say they're waiting for "DNS propagation" to finish.
It's also possible the term is a historical artifact from the 1990s, when record distribution may have genuinely taken hours. Whatever the origin, "DNS propagation" is likely here to stay — it's recognizable and widely used. The distinction is worth keeping in mind, though, particularly when explaining DNS to someone who doesn't yet understand the underlying system.
