DNS Propagation, TTLs, and Caching: What Actually Happens When You Change a DNS Record

When you change a DNS record, the change doesn't happen "everywhere at once" — and the gap between "I changed it" and "everyone sees the change" is governed by a number most people never think about until something breaks

DNS propagation — the process by which a DNS change becomes visible across the internet — is often described in vague terms ("it can take up to 48 hours"), which is both true and unhelpfully imprecise. The actual mechanism is governed by TTL (Time To Live) values, DNS caching behaviour at multiple layers, and the specific type of change being made — and understanding this mechanism explains both why some changes feel instant and others genuinely take time.

What TTL actually controls

Every DNS record has a TTL value — a number of seconds that tells any system that looks up and caches that record: "you may keep using this cached answer for up to this many seconds before checking again."

The basic mechanism:

1. You (or your DNS provider) publish a record with TTL=3600 (1 hour)
2. A resolver (e.g., your ISP's DNS resolver, or a public resolver like 8.8.8.8) looks up your domain and receives this record along with its TTL
3. The resolver caches this answer for up to 3600 seconds
4. Any queries to that resolver for your domain during this window receive the cached answer — without re-querying your authoritative DNS server
5. After the TTL expires, the next query triggers a fresh lookup, which would retrieve your new record if you've changed it

The critical implication: if you change a record that previously had TTL=86400 (24 hours), resolvers that cached the old value before your change might continue serving that old value for up to 24 hours after your change — not because your change didn't propagate to authoritative servers (which can happen quickly), but because caching resolvers are still serving their cached copy of the old answer until that cache entry's TTL expires.

"Propagation" is really "cache expiration," distributed across the internet

There's no single global moment when a DNS change "propagates" — instead:

• Your authoritative DNS servers update essentially immediately (or very quickly) when you make a change
• Every DNS resolver around the world that has previously cached the old record will continue serving that cached old record until that specific resolver's cached copy expires (based on the TTL that was in effect when that resolver cached it)
• Resolvers that haven't cached your record yet (or whose cache has already expired) will get the new record on their next query

This means different users, querying through different resolvers, can see different results (old vs new) for the same domain during the "propagation" window — not due to any error, but simply because different resolvers cached the old answer at different times and have different remaining cache lifetimes.

Lowering TTL before a planned change

A common best practice before a planned DNS change (e.g., migrating a website to a new server, changing an MX record for email): lower the TTL of the relevant record well in advance of the actual change (e.g., reduce TTL from 86400 to 300 seconds, and wait at least the duration of the original TTL before making the actual change).

Why this works:

• If you lower the TTL today from 86400 to 300, but a resolver cached the record yesterday with the old 86400 TTL, that resolver will still hold onto its cached copy (with the old TTL) for up to 24 hours from when it cached it — your new lower TTL value doesn't retroactively affect already-cached entries
• After waiting long enough (at least the duration of the original TTL) for old cached entries to expire, resolvers will re-query and receive your record with the new, lower TTL
• Now, when you make the actual change (e.g., changing the IP address), the lower TTL means any resolver's cache of this record will expire quickly — minimising the window during which some users see the old value and others see the new value

After the change has fully propagated and you're confident everything is working, you can raise the TTL back to a more normal value (very low TTLs increase query load on your DNS servers and slightly increase latency for resolvers that must query more frequently, so they're not generally left in place permanently without reason).

Negative caching (NXDOMAIN caching)

A related but distinct mechanism: when a DNS query results in NXDOMAIN (no such domain/record exists), resolvers can also cache that negative result for a period — governed by a different value (often called the SOA record's "minimum TTL" or negative caching TTL, depending on DNS server software and specification version).

Why this matters: if you're setting up a new record (e.g., adding a subdomain that didn't exist before), and something queried for that subdomain before you created it, that resolver might have cached the NXDOMAIN response — meaning even after you create the record, that resolver might continue returning NXDOMAIN until its negative-cache entry expires, separate from any TTL on the record you just created (since from that resolver's perspective, it hasn't yet learned the record exists at all).

Different record types and their typical propagation considerations

While the TTL mechanism applies to all record types, some types come with additional considerations:

NS records (nameserver delegation): changing which nameservers are authoritative for your domain involves updates at the domain registry/registrar level, which has its own propagation characteristics (often related to how frequently the parent zone — e.g., the relevant TLD's nameservers — is queried and cached) — this is sometimes why nameserver changes specifically are described as taking longer than typical record changes, involving propagation considerations beyond just the TTL of the records within your zone.

MX records (mail routing): because email delivery often involves systems that may cache MX lookups for the duration of their TTL, and because email delivery attempts may be retried over a period if initial attempts fail, MX changes during a transition period can result in mail being delivered to either the old or new mail server depending on which cached MX data a given sending system has — this is part of why MX changes often warrant particular care with TTL planning and sometimes a period of running both old and new mail systems in parallel.

Tools and techniques for checking propagation status

Querying multiple resolvers directly: rather than relying on your own system's DNS cache (which reflects only what your resolver has cached), querying multiple different public resolvers directly (e.g., explicitly querying 8.8.8.8, 1.1.1.1, and others) can show whether the new record is available from authoritative-adjacent sources, distinguishing "has my change reached the DNS system at all" from "have all caching resolvers picked it up yet" (the latter being inherently variable and not something any single check can definitively confirm for "everyone").

Checking TTL values directly: looking at the TTL value returned with a DNS query result indicates how long that specific answer (from that specific resolver, at that specific moment) will remain cached — a TTL value close to the record's configured maximum suggests this resolver recently cached it; a TTL value close to zero suggests it's about to expire and re-query.

How to use the DNS Lookup tool on sadiqbd.com

1. Check current record values and their TTLs — understanding the TTL tells you how "sticky" the current cached values might be for resolvers that have already queried
2. Verify a change has reached authoritative servers — querying directly can confirm your authoritative DNS is serving the new value, even if some caching resolvers haven't picked it up yet
3. Plan TTL changes ahead of major DNS changes — lower TTLs in advance (waiting out the old TTL period) before making time-sensitive changes, to minimise inconsistency windows

Frequently Asked Questions

Why do some DNS changes seem to take effect almost instantly while others take hours? This is almost entirely explained by TTL values and caching state — if a record had a low TTL (or hadn't been recently queried/cached by the resolvers you're checking with), a change can appear nearly instant. If a record had a high TTL and was recently cached by the resolvers in question, the old value persists until that cache expires, regardless of how quickly your authoritative servers updated.

Does flushing my own computer's or router's DNS cache help others see my DNS change faster? No — flushing your local DNS cache only affects what your own device has cached; it has no effect on the millions of other resolvers around the world that may have independently cached your old record. It can be useful for you to see your own change sooner (bypassing your local cache), but it doesn't accelerate propagation for anyone else.

Is the DNS Lookup tool free? Yes — completely free, no sign-up required.

Try the DNS Lookup tool free at sadiqbd.com — query any DNS record type for any domain, including TTL values, instantly.