DNS propagation

When you save a record, your DNS host writes it into the zone and its authoritative nameservers start answering with the new value almost immediately. That part takes seconds.

What takes time is everyone else's memory. Recursive resolvers, the ones run by ISPs, companies and public services like 1.1.1.1 or 8.8.8.8, cache every answer for the TTL it came with. A resolver that asked an hour ago may keep serving the old value until that TTL runs out, and nobody can expire its cache from outside. A resolver that never asked gets the new value on its first query. That is why a change can look live to one person and stale to another in the same minute, with nothing wrong anywhere.

A TTL is a number of seconds attached to every answer. It is a ceiling, not a schedule: each resolver's clock starts when it asked. For a changed record, the worst-case wait is the previous TTL, because that is the promise resolvers were given about the old value.

• Lower the TTL on the records you plan to change, for example to 300 seconds.
• Wait one full old TTL, so every cached copy of the old promise has expired.
• Make the change. The worst case is now five minutes.
• Raise the TTL again once the new value is stable.

Absence is cached too. If a resolver asks for a name before you create it, it caches the "no such name" answer for a period set by the zone's SOA record (RFC 2308). Creating the record then seems to do nothing for a few minutes. Looking a record up before it exists is the most common way to make a new record "slow".

Changing nameservers is the slow case. The delegation lives in the parent zone at the registry, with a TTL typically measured in a day or two that you cannot lower. Keep the old DNS host serving correct records until the change has settled. The registrar vs DNS host entry explains where that delegation lives.

A useful definition has two parts: the authoritative nameservers return the new value, and the public resolvers you care about agree with them. A check that polls only public resolvers can call a record propagated while the source is wrong, or call it stale while the source is already right.

The DNS propagation checker reads one record from the zone's authoritative nameservers and from Cloudflare, Google and Quad9 at once and says whether they agree. It does not claim to poll the world: geographic maps matter only for setups that deliberately answer differently by location.

If the authoritative answer itself is wrong, waiting will not help. The usual causes: editing records at a DNS host that is not the one the domain is delegated to, a proxy rewriting the answer, a record created at the wrong name because of a missing trailing dot, or a stale record left beside the new one.

• DNS propagation checker

  Compare the authoritative answer with three public resolvers for any record.

• Registrar vs DNS host

  Why records edited in the wrong place never appear, however long you wait.

• DNS provider detector

  Check which host actually serves the zone before you wait on a change made elsewhere.