DNS Propagation

DNS propagation is the time it takes for a change to a DNS record — updating where a domain name points — to become visible across all the resolvers and caches around the internet that might have the old value stored. It’s not a single, coordinated process but rather the natural consequence of how DNS caching works at many independent layers simultaneously.

Why It Isn’t Instant

DNS is a distributed, heavily cached system by design, for good reason: caching DNS lookups close to users dramatically reduces latency and load on authoritative name servers. Every DNS record has a Time To Live (TTL) value specifying how long a resolver is allowed to cache that record before checking for updates again. When a record changes, any resolver that already has the old value cached — whether it’s an ISP’s DNS resolver, a corporate network’s internal DNS cache, or even a user’s own operating system or browser cache — will continue returning that old, stale value until its cached copy’s TTL expires, at which point it will look up the record fresh and get the new value.

Practical Implications

Because different resolvers around the world cache the same record independently and at different times, a DNS change doesn’t appear everywhere simultaneously — some users might see the new value within minutes, while others (particularly those behind a resolver that happened to cache the record right before the change) might see the old value until their cache’s TTL expires, which could be minutes to days depending on the TTL that was configured on the record before the change.

Practical Guidance

Teams planning a DNS change that needs to take effect quickly and predictably — a migration to new infrastructure, for example — should lower the TTL on the relevant record well in advance of the actual change (ideally 24-48 hours ahead), so that by the time the change happens, cached copies with the old, longer TTL have already expired and been replaced with the new, shorter one, minimizing how long any resolver might serve a stale value after the actual cutover.

Negative Caching and Its Own Delay

A less commonly discussed aspect of DNS propagation involves negative caching: when a resolver queries for a domain that doesn’t yet exist (because a DNS record hasn’t been created yet, or was queried before it was set up), that “does not exist” answer itself gets cached for a period defined by the domain’s SOA (Start of Authority) record — meaning even after the correct record is finally published, some resolvers that cached the earlier negative response may continue returning a failure until that negative cache entry separately expires. This is a common, easy-to-overlook cause of DNS changes appearing to “not have propagated yet” even well after the actual record change was made and its own TTL should have expired.