Nameservers not updated / DNS not propagated

What’s actually happening

You pointed the domain at a new host or edited a record, and it works from your phone but not your laptop — or vice versa. `dig` from one network returns the new IP, another still shows the old one. The change "isn't live" for hours even though the registrar saved it. Switching nameservers is the worst offender: the new NS host often starts empty, so the domain resolves to nothing at all.

Common causes

• TTL on the old record hasn't expired yet — recursive resolvers (your ISP, 8.8.8.8, your office) are still serving the cached answer.
• You changed nameservers at the registrar but didn't recreate the A/CNAME/MX records on the new DNS provider — switching NS does not copy existing host records.
• Registrar-level NS change is still propagating through the TLD (the .com/.net root), which can lag the registrar dashboard by hours.
• Edited the zone at the old provider after already moving NS to a new one — nobody is reading that zone anymore.
• Local OS or browser DNS cache is pinning the stale answer on your own machine.

How to fix it

1. Confirm which nameservers are authoritative right nowRun `dig NS example.com +trace` or `whois example.com | grep -i 'name server'`. Make sure the NS the TLD reports matches the provider where you actually created the records. If they don't match, you're editing the wrong zone.
2. Recreate every record on the new provider before cutting overA/AAAA, CNAME (www), MX, TXT (SPF/DKIM/DMARC), CAA. Changing NS gives you a blank zone unless the new host imported them. Verify each with `dig A example.com @new-ns-host`.
3. Query the authoritative server directly to bypass caches`dig A example.com @ns1.newprovider.com +short`. If that returns the correct value, the change is done and you're only waiting on downstream caches — there's nothing left to fix on your end.
4. Lower TTLs before a planned migrationDrop records to 300s a day or two ahead of the cutover. Resolvers then forget the old answer in 5 minutes instead of hours. Raise TTLs back afterward.
5. Flush your local cache while you waitmacOS: `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`. Windows: `ipconfig /flushdns`. Chrome holds its own cache too — clear it at chrome://net-internals/#dns.