DNS propagation: why it takes so long and how to check

You changed your domain's IP, saved, and the site still shows the old version (or nothing). A coworker loads it fine, you don't. The popular explanation is "DNS is still propagating", as if the change were traveling from server to server. Nothing travels. What exists is a collection of caches, each with its own countdown.

Knowing that changes what you do. Instead of waiting blindly, you find which cache still holds the old value, how long until it expires, and whether it is worth clearing by hand.

What is DNS propagation, really?#

When you edit a record in your DNS provider's dashboard, the change is live immediately on the authoritative server, the one that holds the truth about your domain. The rest of the internet only finds out when it has to ask again.

Nobody notifies the other servers. Resolvers (your ISP's, 8.8.8.8, 1.1.1.1) cache every answer for a while and return to the authoritative server only when that time runs out. "Propagation" is the informal name for the window between your change and the last relevant cache expiring.

That is why results differ from person to person. Two people on different networks query different resolvers, which fetched the record at different moments.

What is TTL and why does it set the timeline?#

TTL (time to live) is a number of seconds attached to every record. It tells a resolver how long it may reuse the answer without asking again. Cloudflare's documentation sums up the trade-off: a longer TTL means more cache hits and faster lookups, but slower propagation of record changes.

Example: the A record for example.com has a TTL of 3600. A resolver queried it at 10:00. If you change the IP at 10:05, that resolver keeps serving the old IP until 11:00. Another one that queried at 10:50 only refreshes at 11:50. The worst case is therefore the full old TTL counted from the change.

Two practical consequences:

• The TTL that counts is the old record's. Lowering the TTL after you switch the IP does not help resolvers that already cached the answer.
• 300 seconds (5 minutes) is a common default. Providers usually enforce a floor, which may vary by plan; check your provider's documentation.

Where is the old record stored?#

A lookup passes through several layers, and any of them can hold the stale value:

1. Browser. Keeps its own short-lived DNS cache.
2. Operating system. Windows, macOS and many Linux distributions run a local cache.
3. Home or office router. Many act as a DNS proxy and cache answers.
4. Recursive resolver. Your ISP's, or a public one like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). This is the most important cache, shared by thousands of users.
5. Authoritative servers. Not a cache: they answer with the current truth.

One case is slower: changing nameservers (the NS records your registrar publishes in the parent zone, such as .com). That delegation has its own TTL, set by whoever runs the TLD, and it is usually much longer than an A record's. When switching DNS providers, allow hours, sometimes up to two days, and keep identical records at both providers during the transition.

What if the name did not exist before (negative caching)?#

If someone looked the name up before you created the record, a resolver may have cached the answer "does not exist" (NXDOMAIN). This is negative caching, defined in RFC 2308: the cache time is the lesser of the zone's SOA record TTL and that SOA's MINIMUM field.

This is why a newly created name sometimes keeps failing for minutes or hours even though the authoritative record is already correct. If you saw this error in the browser, read DNS_PROBE_FINISHED_NXDOMAIN.

How do you check propagation?#

The reliable method is to ask every layer and compare. Use dig (Linux, macOS, Windows via BIND or WSL) or nslookup (built into Windows).

1. Find the authoritative servers and query them directly. They are the reference:

dig NS example.com +short
ns1.dns-provider.example.
ns2.dns-provider.example.

dig @ns1.dns-provider.example example.com A +short
203.0.113.10

If the new value shows up here (203.0.113.10 in this example), your configuration is right and the rest is caching. If you see the old one, the change was not saved, or you edited DNS at a provider that is not your current nameserver (the most common cause of "it never propagates").

2. Query public resolvers. Each has its own cache:

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

In the ANSWER section, the number between the name and the record type is that cache's remaining TTL. Run it twice and it goes down. When it hits zero, the resolver fetches the new record.

example.com.    1742    IN    A    198.51.100.7

Here, that resolver still returns the old IP for another 1742 seconds (about 29 minutes).

3. On Windows without dig:

nslookup example.com 8.8.8.8
nslookup -type=NS example.com

4. See the full path. dig +trace example.com starts at the root servers and shows each delegation down to the authoritative server, bypassing intermediate caches.

"Global DNS checker" websites run the same comparison from several countries at once. They give a wide view, but the result only covers the resolvers they query, not one specific person's ISP.

How do you speed it up or work around it?#

Flush the local cache. This fixes your computer, not the world.

On Windows:

ipconfig /flushdns

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux with systemd-resolved:

sudo resolvectl flush-caches

Restart the browser afterwards, or test in a private window. According to Microsoft's documentation, ipconfig /flushdns also discards negative cache entries.

Ask the public resolver to forget the name. Google has a Flush Cache tool for Google Public DNS, and Cloudflare has Purge Cache for 1.1.1.1. You enter the domain (Cloudflare also asks for the record type). It only affects that resolver, but it helps the many people who use 8.8.8.8 or 1.1.1.1.

Test from another path. Your phone's mobile data uses a different resolver, and so does a VPN. If it works there, your own cache is the culprit.

Skip the wait for testing. To test the server before DNS catches up, force the IP on your machine for that one request:

curl --resolve example.com:443:203.0.113.10 https://example.com/

How do you plan a change without downtime?#

The trick is to act beforehand, because the old TTL is what counts:

1. Ahead of time by as much as the current TTL (one day if it is 86400), lower the record's TTL to 300 seconds.
2. Wait for the old TTL to pass, so every cache is already on the short setting.
3. Change the record's value.
4. Confirm with dig against the authoritative server, 8.8.8.8 and 1.1.1.1.
5. Once everything is stable, raise the TTL again to cut query volume.

If you can, leave the old server running and answering normally until the window closes. Anyone who still sees the old IP then lands on a working site.

For more on the record types you will be editing, see what DNS records are and how to point a domain to your hosting.

How to do this on Square Cloud#

Custom domains on Square Cloud are available from the Standard plan. In the dashboard you see the DNS records you need, and you create them at your registrar. The domain stays registered in your name there, and Square Cloud is neither a registrar nor a DNS provider: the TTL and caching described above are those of your own DNS provider.

Validation status updates in real time: after you create the records, the dashboard tells you when it has found them, so you do not have to run dig blindly, although the command is still the best way to see what each resolver answers. TLS is issued automatically, and the dashboard also lets you purge cache.

While the domain is not validated yet, your web application stays reachable on its *.squareweb.app subdomain with HTTPS, available on every plan. See how to set it up in domains on Square Cloud.