How long does DNS propagation take?

Authoritative changes are often visible in minutes; recursive resolvers may cache the old answer until TTL expires. Plan for up to the old TTL, not a blanket 48 hours.

Why does dig show the new IP but Chrome does not?

Browsers, OS stub resolvers, corporate DNS, and DoH can all cache independently. Test with dig @8.8.8.8 and a private window on another network.

What is the difference between dig and nslookup?

dig exposes TTL, authority sections, and explicit resolver targets more clearly. nslookup is fine for a quick peek; dig is better during incidents.

Does flushing my local DNS fix everyone?

No. You only clear one cache on one machine. Users on other resolvers still wait out their TTL unless you lowered it before the cutover.

DNS Propagation Check from the CLI —

You updated the A record. Half the team sees the new site. The other half still hits the old VPS. Someone says “wait 48 hours for propagation.” That folklore wastes weekends. What you are usually fighting is TTL plus which resolver you asked — not a mystical global weather system that takes two days to notice your zone file.

Propagation is a cache tree, not magic

DNS answers travel through layers that each may remember the previous value:

Authoritative name servers for your zone (source of truth after the update)
Recursive resolvers (1.1.1.1, 8.8.8.8, ISP DNS, company DNS)
Stub resolvers on the OS
Application caches (browsers, some language runtimes, sticky mobile networks)

A change is “propagated” for a user when their path has fetched the new answer — often right after that path’s cached TTL expires. Public resolvers can disagree with each other for exactly that reason.

dig recipes that end Slack arguments

# Ask Google Public DNS explicitly
dig example.com A @8.8.8.8 +short

# See TTL and the answer section
dig example.com A @1.1.1.1 +noall +answer

# Ask your authoritative NS directly
dig example.com A @ns1.your-dns-host.com +short

# CNAME chain for www
dig www.example.com CNAME @8.8.8.8 +short

Compare @8.8.8.8, @1.1.1.1, and the office resolver. If they disagree, you do not have a mysterious “broken DNS” — you have stale cache on one path. Confirm the authoritative NS first so you know whether the zone itself updated.

For a quick browser-side cross-check while you keep dig open, use a DNS lookup tool — then treat CLI output as the incident source of truth.

TTL planning before you cut over

Phase	TTL advice
Days before cutover	Lower TTL to 300 (5 minutes)
Cutover	Change records; verify authoritative
After stable	Raise TTL again (3600+)

If you leave TTL at 86400 and flip the record, some clients can legally keep the old answer for a day. That is not Google being slow; that is you asking for a long cache window. Lower early, change, then raise — the boring playbook still works.

DoH, CDNs, and other false twins

DNS-over-HTTPS (Chrome Secure DNS, Firefox DoH) may not follow the same path as dig on your LAN. When “dig is right, browser is wrong,” check DoH settings and try phone LTE versus office Wi‑Fi.

Also separate CDN cache from DNS. Purging Cloudflare/Fastly does not rewrite A records, and updating DNS does not empty edge HTML. Incidents often mix both; label which layer you are testing in the ticket.

IPv6 surprises belong here too: you fixed A but forgot AAAA, so dual-stack clients still land on the old host. Check both record types on the same resolvers.

Cutover checklist that survives on-call

Lower TTL ahead of time and wait at least one old TTL before the flip if you can.
Update the authoritative record; verify with dig against the authoritative NS.
Spot-check major public resolvers and one corporate resolver.
Purge CDN separately — CDN ≠ DNS.
Keep the old origin warm until the longest relevant TTL window closes.
Watch for split A/AAAA and leftover CNAMEs pointing at retired hosts.

What “48 hours” was really about

Old advice assumed very high TTLs, slow secondary name servers, and ISPs that ignored TTL. Modern public DNS is usually faster; your risk is still “someone’s resolver has hours left on a 86400 cache.” Measure with dig, plan TTL deliberately, and retire the calendar superstition.

Stop waiting two days by default. Verify authoritative answers, compare resolvers, respect TTL, and remember CDNs are a second layer. CLI dig against a known public resolver beats vibes every time.

Prep the TTL before the cutover

The quiet win is operational: lower TTL ahead of time, wait out the old TTL, change records, verify authoritative dig, then raise TTL again. Skipping the prep step guarantees a long tail of old answers no matter how good your checker screenshots look. Write the dig commands into the runbook next to the registrar UI clicks so the on-call person is not improvising under pressure. When executives ask if it is propagated, answer with authoritative vs resolver vs office DNS — three different truths — instead of a single yes.

Tools

DNS Propagation Check from the CLI — dig, DoH, and Why 'It's Cached'