DNSVerdictAll toolsGuidesHow it works

DNS propagation explained: it's cache expiry, not 48 hours

Published · Updated

“DNS propagation” is a misleading name. Nothing is pushed across the internet. Your authoritative name servers have the new record the moment you save it; the delay comes from resolvers that cached the old answer and keep serving it until its TTL runs out. The wait is therefore bounded by the TTL the old record had, usually minutes to a few hours, not a fixed 48 hours. To see who still has the old answer, run the DNS propagation checker.

What actually happens

When a resolver answers a query, it stores the record with a time to live. RFC 1035 §3.2.1 defines the TTL as the time interval the record may be cached. RFC 2181 §8 describes it as “a maximum time to live, not a mandatory time to live”, so a resolver may drop the entry sooner, or cap very large values at its own limit. Every record in a set (for example, all A records of one name) carries the same TTL (RFC 2181 §5.2).

Timeline for an A record changed from 192.0.2.10 to 192.0.2.20 with a TTL of 3600:

  1. You edit the zone. The authoritative servers answer with the new IP at once.
  2. A resolver that queried the name 10 minutes ago still holds the old IP for another 50 minutes.
  3. A resolver that never queried it, or whose entry expired, asks the authoritative server and gets the new IP.
  4. After an hour past your change, every resolver that honors the TTL shows the new value.

Each resolver counts down independently, which is why two people see different answers for a while.

Why 48 hours is a myth

The figure comes from older advice and from long TTLs on some delegations. A change to your own records waits on the TTL of those records. If the TTL was 300 seconds, the world sees the update within about five minutes. If it was 86400 (24 hours), it can take that long. Changing name servers at the registrar is different, because it involves parent-zone data with its own TTL; see lower the TTL before a migration. The delay is always the previous TTL, so you can read it from the old answer instead of guessing.

Negative caching: new records that “do not exist yet”

A resolver also caches failures. If someone looked up www.example.com before you created it and got NXDOMAIN, that “does not exist” answer is cached too. RFC 2308 §5 says negative answers have a TTL like normal ones, taken “from the minimum of the SOA.MINIMUM field and SOA’s TTL”. So a brand-new record can stay invisible for as long as the SOA minimum, often an hour or more.

To see this value, query the zone’s SOA record in the DNS lookup and read the last number. If you are about to create a record that people may already be querying, a shorter SOA minimum (your DNS host may set it for you) shortens the invisible period.

Why resolvers disagree even after the TTL

ReasonEffect
Different cache expiry timesResolvers expire at different moments; the normal case
Geographic or CDN answersA name can legitimately return different IPs from different regions, with no “wrong” resolver
Round-robin or load balancingRotating order or sets of A records
Resolver ignores a short TTLSome resolvers enforce a minimum cache time
Lagging secondary name serverIf the zone is hosted on several servers, a slow zone transfer leaves one with the old data
Browser or OS cacheYour own machine holds the old IP, separate from any resolver

The last row explains many “it works on my phone but not my laptop” reports. Flush the OS cache or restart the browser before assuming the DNS is wrong.

How to check

  1. Query your authoritative name servers directly (find them with an NS lookup) to confirm the new data is live at the source. If they are wrong, nothing will ever propagate.
  2. Run the DNS propagation checker for the record type you changed. It queries several public resolvers over DNS-over-HTTPS and shows each answer, so you can see which ones still return the old value.
  3. If a resolver shows the old value, compare its remaining wait with the old TTL. Waiting is the only fix; you cannot flush other people’s caches. Large public resolvers sometimes offer a cache-purge form for a single name; check each operator’s documentation.
  4. For mail, send a test after the old MX TTL has passed.

FAQ

Can I speed it up? Only by lowering the TTL before you make the change, not after. Setting a low TTL now does not affect copies already cached.

Why does the propagation checker show different IPs for one name? If the name is served through a CDN or geo-DNS, differing answers are expected and correct. Compare against what your DNS provider documents.

Does it matter which record type I changed? Each type has its own TTL and cache entry. Changing an A record does not clear a cached MX.

Sources

Tools used

DNS Propagation CheckerDNS Lookup