Before anything else, split the problem in half. Ask the authoritative nameserver directly. If it returns the new value, your change is correct and everything remaining is caching — a waiting problem. If it returns the old value or nothing, the change never landed where it needed to — a configuration problem. Nearly every wasted hour of "DNS propagation" debugging comes from not making this distinction first.
# 1. Who is actually authoritative for the zone?
dig +short example.com NS
# 2. Ask one of those nameservers directly — no recursion, no cache
dig @a.iana-servers.net +noall +answer example.com A
# 3. Now compare against a public resolver
dig @1.1.1.1 +noall +answer example.com ADid you edit the zone that is actually in use?
This is the number one cause, and it costs people days. Your registrar, your web host, and your DNS provider can be three different companies, and each of them offers a DNS editing screen. Only the one whose nameservers appear in your delegation is authoritative — edits anywhere else are written into a zone that nobody queries.
Run the NS Record Lookup and compare the result against the DNS panel you have been editing. Classic mismatches: nameservers point at Cloudflare while you edit records at GoDaddy; nameservers point at the host's ns1. / ns2. pair while you edit "DNS management" at the registrar; a www record was added at one provider and the apex at another. The WHOIS Lookup shows the nameservers the registrar has on file, which is useful when the delegation itself looks wrong.
Has the delegation itself moved yet?
If you changed nameservers at the registrar, you are not waiting on your own TTL — you are waiting on the parent zone. The TLD registry publishes the new NS set, and those delegation records carry the registry's TTL, commonly 86400 seconds for .com. Until that expires, resolvers that already cached your delegation keep asking your old nameservers. Query the parent directly to see what the registry has actually published:
# What the TLD servers hand out for the delegation
dig @a.gtld-servers.net example.com NS
# Full path from the root, hop by hop
dig +trace example.com AWhile the delegation is in flight, both the old and the new nameservers will be receiving real queries. Keep the old zone accurate and serving until the parent TTL has fully expired, or some users will get the old answers and some will get the new ones.
Is the old TTL simply still running?
Query a public resolver twice, a few seconds apart. A TTL that counts down means the resolver is serving from cache and will re-ask when it reaches zero. A TTL that stays at its full value means you are getting a fresh answer. There is no way to shorten someone else's cache — see How Long Does DNS Propagation Take? for why, and Lower Your TTL Before a DNS Migration for how to avoid this next time.
Is a negative answer cached?
If the hostname did not exist before you created it, and anyone queried it in the meantime, resolvers cached the NXDOMAIN. That negative answer lives for up to the minimum field of your zone's SOA record — the last number in the SOA — capped by each resolver's own limit. The record's own TTL is irrelevant here; the resolver is not caching your record, it is caching the absence of it. Read your value with the SOA Record Lookup.
Is a CDN or proxy sitting in front of the record?
When a record is proxied — Cloudflare's orange cloud, or any similar reverse-proxy product — public DNS returns the proxy's anycast address, not your origin. Changing the origin IP in the DNS panel changes nothing that any resolver can see, because the published answer was never your origin in the first place. The traffic swap happens inside the proxy, and the record you are staring at will never reflect it.
Two symptoms give this away: the returned address belongs to a CDN rather than your host (check it with the ASN Lookup or a Reverse DNS lookup), and the TTL is a fixed provider value like 300 no matter what you set. To test the origin during a migration, resolve directly against the origin address rather than through the proxied name.
Or is it just your own machine?
If public resolvers return the new value and your browser does not, the problem is one laptop, not the internet. Both your operating system and your browser keep their own caches, and browsers additionally hold open keep-alive connections that survive a DNS change entirely. Flush both before you conclude anything:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows (Command Prompt or PowerShell, as Administrator)
ipconfig /flushdns
# Linux with systemd-resolved
sudo resolvectl flush-caches
# Linux running nscd or dnsmasq instead
sudo systemctl restart nscd
sudo systemctl restart dnsmasq- In Chrome, open
chrome://net-internals/#dnsand clear the host cache, thenchrome://net-internals/#socketsand flush socket pools — an open connection will ignore a fresh DNS answer. - Firefox:
about:networking#dnshas a Clear DNS Cache button. - Test outside the browser entirely with
digorhost— those tools bypass every browser cache and, with an explicit@resolver, most OS caching too. - If your router or corporate gateway runs a forwarding resolver, it caches as well; a device on cellular data is a fast way to prove whether the network is the variable.
- VPNs and split-DNS setups can resolve internal names from an entirely different zone. Disconnect and retest before blaming the public record.
If the browser shows DNS_PROBE_FINISHED_NXDOMAIN specifically, the dedicated guide Fix DNS_PROBE_FINISHED_NXDOMAIN separates the server-side from the client-side causes.
When the answer is an error rather than stale data
If lookups return SERVFAIL rather than an old value, this is not a propagation issue at all — the zone is failing to resolve. A broken DNSSEC chain after a nameserver move is the classic cause: the DS record at the registry still points at keys the new provider does not have. Test with the DNSSEC Checker, and read SERVFAIL vs NXDOMAIN to interpret the response code. If mail broke at the same time, start with Mail Bouncing After a DNS Change?.