Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Resolver checks · Beginner · 5 min

How to check DNS propagation — There Is No Propagation, Only TTLs Expiring

You changed a record an hour ago, it works from your phone and not from your laptop, and you need to know whether that is a fault or a countdown.

View Plesk Hosting plansBrowse more How-To Library

The short answer

Nothing is propagating anywhere. Your authoritative nameservers already hold the new answer; every resolver between them and your visitors is holding a copy of the old one until its TTL expires. Propagation is just the sum of those countdowns finishing.

So the diagnostic is two queries. Ask the authoritative server directly to confirm the change is real. Then ask the resolvers your visitors actually use and read the TTL field, because that number is the countdown, and it tells you precisely how long you have left rather than requiring you to guess.

By the HostingFast team · Reviewed 24 August 2026

Beginner

Skill floor

5 minutes

Hands-on time

4

Steps in total

24/7

Support on call

You need a terminal with dig, or nslookup on Windows. Five minutes, and no changes to anything — this is entirely a read-only exercise.

The one thing worth knowing before you start is the TTL that was on the record before you changed it, because that value is the upper bound on the whole wait.

What is actually happening while you wait

Every recursive resolver that answered a query for your name cached the answer along with the TTL you published. Until that TTL counts down to zero, it will keep serving the cached value without asking anyone. Different resolvers cached at different moments, so they expire at different moments.

That is the entire mechanism. There is no queue, no push, no distribution network deciding when to tell the world. It also means the wait is bounded and predictable: at most the old TTL, from the moment each resolver last asked.

Ask the authoritative server first

Start where the truth lives: dig A yourdomain.com @ns1.yourprovider.example +norecurse. That query goes straight to a nameserver that holds the zone and returns what it holds, with no cache in the path. If that answer is wrong, nothing else you check matters, because the change did not actually save.

The +norecurse flag stops the server doing lookups on your behalf, so you can be sure the answer came from the zone rather than from anywhere else. Run it for each record type you touched, and get this green before you look at anything else.

Then read the countdown on the resolvers visitors use

Query 1.1.1.1 and 8.8.8.8 with dig A yourdomain.com @1.1.1.1 and look at the number in the TTL column of the answer section. If it is showing the old value with a TTL of 3400, that resolver has roughly 3400 seconds to run and there is nothing to fix.

Run the same query twice a minute apart. If the TTL is decreasing, you are watching a cache expire and the only correct action is to wait. If it resets to the full value without the data changing, the resolver is being handed the old answer by something upstream, which is a genuine fault worth chasing.

Your own machine is the last cache in the chain

Even with every public resolver correct, your laptop can be wrong. The operating system keeps its own cache, browsers keep a separate one, and a hosts file entry from an earlier test overrides all of it. Clear them before drawing conclusions about anyone else's experience.

On Windows that is ipconfig /flushdns. On macOS, sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. On systemd Linux, resolvectl flush-caches. In Chrome, the net-internals DNS page has its own clear button, and it is remarkable how often that is the actual answer.

Hunting down the right domain name before someone else takes it

Fast platforms make for short guides

Every walkthrough here is run against the platform we operate — cPanel, LiteSpeed in front of NVMe, Softaculous, WP-CLI over SSH — so the field names in the instructions are the field names on your screen.

NVMe storage sits behind a LiteSpeed cache on every tier including the smallest, so speed is the baseline rather than the upsell.

  • The mechanism explained, not the metaphor
  • TTL read as a countdown you can act on
  • Every local cache named, with its command
  • Engineers on support at any hour

Why HostingFast

Standard on every plan

The mechanism, not the metaphor

Propagation is described as TTLs expiring, which is what it is, and that single reframing removes most of the anxiety from the wait.

Authoritative checked first

The first query bypasses every cache, so you learn immediately whether you are debugging a change or waiting for one.

TTL read as a countdown

Running the same query a minute apart tells you whether time is passing or something upstream is genuinely stuck.

4 steps, no padding

Four read-only checks, each producing a number, and no instruction to clear your browser and try again.

Every local cache named

Windows, macOS, systemd and Chrome each get their exact flush command, because your own machine is the usual culprit.

Engineers on call

If authoritative is right and a resolver never updates, support answers at any hour and can look at the zone with you.

Quick Start

From order to online

  1. 1

    Query the authoritative nameserver directly

    Run dig A yourdomain.com @ns1.yourprovider.example +norecurse for each record type you changed. This answer has no cache in front of it, so it tells you whether the edit saved at all. Fix anything wrong here before looking further.

  2. 2

    Query two public resolvers and read the TTL

    Run dig A yourdomain.com @1.1.1.1 and again against 8.8.8.8. Read the number in the TTL column: if it is the old data with a countdown running, that is the wait in seconds and there is nothing to do.

  3. 3

    Repeat a minute later and compare

    The same query again should show a TTL roughly sixty seconds lower. A decreasing countdown means a cache expiring normally. A TTL that keeps resetting with unchanged data means something upstream is refreshing the old answer, which is worth a support conversation.

  4. 4

    Flush your own caches before you conclude anything

    ipconfig /flushdns on Windows, sudo dscacheutil -flushcache and sudo killall -HUP mDNSResponder on macOS, resolvectl flush-caches on systemd Linux, plus Chrome's own DNS cache. Then check for a stale hosts file entry from an earlier test.

Built In

Loaded onto every plan

  • 99.9% uptime as the target, monitored around the clock
  • LiteSpeed caching in the server, not bolted on by plugin
  • DDoS filtering absorbed at the network edge
  • Staging environments for testing before you ship
  • Support staffed by humans, every hour of the day
  • NVMe storage on every tier, not only the expensive ones
  • Webmail in the browser plus IMAP, POP and SMTP
  • Money back: 30 days on hosting, 7 on reseller
  • Spam and virus screening on every mailbox as standard
  • Free SSL on every plan, renewed before it can lapse

Frequently Asked

What people ask us most often

dig shows the old IP with a TTL of 3400. Is something broken?

No, that is the system working exactly as designed. The resolver cached the old answer with a long TTL and has roughly 3400 seconds left before it asks again. Nothing you or your provider can do shortens it, because the resolver is not going to re-check. This is the argument for lowering TTLs before a planned change rather than after, and it is the only useful lesson from the wait.

Does flushing DNS on my laptop help my visitors?

Not at all. Your flush clears one cache on one machine — yours. Every visitor has their own operating system cache and their own ISP resolver, each with its own countdown. Flushing locally is worth doing so that you stop misdiagnosing your own stale cache as a global problem, which is genuinely useful, but it changes nothing for anyone else.

What is the actual worst case for a change to be everywhere?

For ordinary records, the old TTL is the bound: a resolver that cached one second before your change waits the full period. For a nameserver change there is a second wait, because the parent zone at the registry publishes the new delegation on its own refresh cycle, and that is outside your zone entirely. Watch that one with dig NS yourdomain.com @a.gtld-servers.net.

Which is authoritative: the registrar panel or dig?

dig, against the nameservers the delegation actually points at. A registrar panel shows a zone it believes it hosts, which is a different thing from the zone being queried — a domain delegated elsewhere will show edits in a panel nobody consults. Run dig NS yourdomain.com to find out who is really answering, and take that server's word over any interface.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Stop waiting on slow infrastructure.

NVMe behind a LiteSpeed cache, free SSL, free migration, and support that answers with a cause rather than an article link.

View Plesk Hosting plans