The short version
A DNS change is not instant. Every resolver between you and your visitors caches the old answer for the TTL of the record. Until that cache expires, those resolvers serve the old answer.
Lower TTLs before you change
The single biggest deliverability mistake: changing a record at high TTL and expecting it to propagate fast.
Right pattern:
- Lower the TTL of the record you plan to change to 300 seconds (5 minutes).
- Wait one TTL of the previous setting (e.g. if it was 3600 seconds, wait an hour).
- Now change the record. Propagation completes in roughly the new TTL.
- After the change is stable, raise the TTL back to a normal value (3600 / 86400).
Checking propagation
- dnschecker.org — query the record from resolvers around the world.
dig +short <record> @8.8.8.8and@1.1.1.1— check directly against Google and Cloudflare.dig +trace <record>— walks the resolution path from root and shows you who answers what.
If our authoritative nameservers (ns1/ns2/ns3.photonspark.net) return the new answer but a public resolver still serves the old one, that resolver is caching. Wait for the cache to expire.
Common gotchas
- Browser cache. Chrome and Firefox cache DNS for ~60 seconds. Restart the browser to clear.
- OS-level cache. macOS:
sudo dscacheutil -flushcache. Linux: depends on resolver. Windows:ipconfig /flushdns. - CDN caching. If you front your site with a CDN, the CDN itself caches your origin's DNS resolution — often for 5+ minutes regardless of TTL.
- ISP resolver TTL clamping. Some ISPs ignore TTLs under 60 seconds. Most respect them.
If a record has been changed for more than 6 hours and at least one public resolver still serves the old answer, open a ticket — that is unusual and worth investigating.