You updated your DNS records. Your registrar says the change is active. But when you visit your domain, you still see the old site. Welcome to DNS propagation, the process that makes every domain change feel like it is stuck in limbo.
Understanding how DNS propagation actually works replaces anxiety with predictability.
What propagation really means
DNS is not one server. It is a hierarchical, distributed caching system with millions of resolvers worldwide. When you change a DNS record, the change happens immediately on your authoritative nameserver. But every recursive resolver that has cached the old record will continue serving it until the cache expires.
The TTL (Time to Live) on your DNS record determines how long resolvers cache it. If your A record has a TTL of 3600 seconds (1 hour), resolvers will serve the cached value for up to 1 hour before querying the authoritative server again.
This is why "propagation" is somewhat misleading. The change is not spreading outward like a wave. It is more like a cache expiration happening independently at each resolver worldwide, at different times depending on when they last queried.
The TTL strategy
If you know a DNS change is coming, reduce the TTL well in advance:
- 24-48 hours before the change: Lower TTL to 300 seconds (5 minutes)
- Wait for the old TTL to expire: If the old TTL was 86400 (24 hours), wait 24 hours for all caches to pick up the new low TTL
- Make the DNS change: Now resolvers will pick up the new record within 5 minutes
- After verification: Raise TTL back to a longer value (3600 or higher)
This strategy reduces the propagation window from hours (or days) to minutes. The critical step most people miss is step 2: you must wait for the old TTL to expire before the low TTL takes effect at all resolvers.
Why some resolvers ignore TTL
Some ISP resolvers enforce minimum TTLs regardless of what you set. Certain ISPs cache records for a minimum of 30 minutes or even longer. There is nothing you can do about this except wait.
Google Public DNS (8.8.8.8) and Cloudflare DNS (1.1.1.1) generally respect TTLs accurately. If your record is correct on these resolvers but wrong on your ISP's resolver, the ISP is caching aggressively.
Checking propagation status
To verify your DNS change has propagated, you need to query multiple resolvers across different networks and geographic locations:
# Query specific resolvers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @208.67.222.222 example.com A # OpenDNS
If all three return the new record, major public resolvers have updated. ISP resolvers may still be caching the old record.
Common DNS change scenarios
Migrating to a new host: Change the A record (or CNAME) to point to the new server's IP. During propagation, some users will reach the old server and some the new. Both servers should be operational during this window.
Adding a subdomain: Add an A or CNAME record. No propagation concern for caches because the record did not exist before. However, negative caching (NXDOMAIN caching) can cause delays if the subdomain was queried before the record was created.
Changing nameservers: This propagates through the registry (like Verisign for .com) and can take 24-48 hours. Nameserver changes are the slowest DNS change because they involve the TLD servers, which have their own cache behavior.
Email (MX records): MX record changes affect email delivery. During propagation, email may be delivered to either the old or new mail server. Ensure both servers can receive mail during the transition.
The checker tool
For monitoring DNS propagation across multiple global resolvers simultaneously, I built a DNS propagation checker that queries resolvers worldwide and shows which have updated and which are still serving cached records.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)