How to check DNS propagation

Where the waiting comes from

Picture the chain a lookup travels. Your device asks a recursive resolver, run by your ISP or a public provider. If that resolver has a recent answer cached, it returns the cached one without asking anybody. Only when the cache has expired does it walk down to the root servers, the registry for the top-level domain, and finally your authoritative nameservers, which hold the record you edited.

So when you change an A record, the new value exists the second your DNS provider saves it. Every resolver still holding the old answer keeps serving it until its copy times out. The TTL, time to live, is a number in seconds attached to the record telling resolvers how long they may cache it. A record with a TTL of 3600 can be served from cache for an hour after it was fetched, so an hour is the worst case for a resolver that fetched it just before your edit.

This is why two people in the same office can see different results, and why clearing your own cache does not help anyone else. There is no global spread to wait for, only a lot of independent timers running out at different moments.

How to check from multiple resolvers

The manual way is to ask several resolvers the same question and compare their answers:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # your own resolver
dig +short example.com @ns1.yourdns.example  # authoritative: the source of truth

The authoritative query is the important one. If it returns the new value, your change is correct and complete, and everything else is a caching question. If it returns the old value, the change did not save, you edited the wrong zone, or the domain's nameservers are not the ones you think.

To see the remaining cache time rather than just the value, drop +short and read the TTL column:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

The number before the record type counts down as the cached copy ages, which tells you exactly how much longer that resolver will serve the old answer. On Windows, nslookup example.com 8.8.8.8 does the comparison without extra tools. A web-based DNS lookup that queries from many locations at once does the same job faster, and it also covers resolvers you cannot reach from your own machine.

Why it can take hours

• The old TTL governs, not the new one. If the record had a TTL of 86400 and you lower it while making the change, resolvers that cached the old record are still entitled to a full day. Lowering the TTL only helps the next change.
• Some resolvers ignore short TTLs. A number of ISPs enforce their own minimum, commonly an hour or more, regardless of what your record says.
• Nameserver changes are slower. NS records at the registry level often carry a TTL measured in days, so switching DNS providers genuinely can take one to two days to settle everywhere.
• Negative caching counts too. If a name did not exist when someone looked it up, the "does not exist" answer is cached as well, for the period set by the zone's SOA minimum field.
• Chained caches. A browser caches DNS, the operating system caches DNS, and a corporate resolver may sit in front of the public one. Each layer adds its own delay.
• Long-lived connections. Applications that resolved a hostname once at startup keep using that address until they restart, no matter what DNS now says.

How to make the next change fast

1. Lower the TTL first, then wait. Drop the record's TTL to 300 seconds and leave it for at least the length of the old TTL before making the real change. By then every cached copy carries the short value.
2. Make the change. With a 300 second TTL, most resolvers pick it up within five minutes.
3. Keep the old server answering during the overlap. Do not shut it down the moment DNS is updated. Leave it serving until the traffic to it stops, and the migration passes without anyone noticing.
4. Verify against the authoritative nameservers and several public resolvers before declaring it done.
5. Raise the TTL back once the change has settled, so normal traffic benefits from caching again.

For a nameserver change there is no shortcut, because the registry's TTL is not yours to set. Plan for a day or two, and keep both DNS providers serving identical records throughout so it does not matter which one a resolver asks.

After the change has settled

Checking a few resolvers by hand tells you how far a change has spread at the moment you look, which is useful during a migration and useless the rest of the time. The failures worth catching are the later ones: a record that changes without anyone noticing, a nameserver that stops answering, a zone that expires. Continuous DNS monitoring queries from many locations on a schedule and alerts when the answer stops matching what it should be, which also catches the "works from here, broken from there" case a single lookup cannot see. Run a lookup now with the DNS query tool. If the site is unreachable for you but fine elsewhere, is it down for everyone or just me takes it from there.