DNS Propagation In Depth — TTL, Caching, and Why It Takes Time

“Wait 24-48 hours for DNS propagation” is the standard answer everyone gives, but it dodges the real questions: what’s actually happening during those hours? Why so long? And can you speed it up? This guide explains DNS propagation properly — including the TTL settings that control it, the resolvers that cache it, and how to verify a change has fully propagated.

What “propagation” actually is

DNS isn’t one global database. It’s a distributed system of caches:

• Authoritative nameservers hold the definitive records for your domain (e.g. ns1.iwebvault.com). When you change DNS, you change these.
• Recursive resolvers (your ISP’s DNS, Google’s 8.8.8.8, Cloudflare’s 1.1.1.1) cache DNS responses to avoid asking the authoritative server every time.
• Local caches on routers, operating systems, browsers — each layer caches too.

When you change a record at the authoritative level, the change is instant there. But every cached copy elsewhere keeps serving the OLD record until that cache expires. “Propagation” = the time it takes for all those caches to refresh.

TTL — Time To Live

Every DNS record has a TTL — how long resolvers should cache it. When you create or edit a record, you set its TTL (in seconds):

Trade-off: lower TTL = faster propagation when you change records, but more DNS lookups (slightly more load on authoritative servers, slightly slower visitor experience). Higher TTL = better caching efficiency, but slow to change.

The “lower TTL before changing” trick

Before any planned change (migration, DNS provider switch, IP change), lower the TTL on the record being changed:

1. Today: Set TTL on the record to 300 (5 min). Save.
2. Wait for the OLD TTL (typically 4 hours) to expire so caches everywhere learn the new 300-sec TTL.
3. Tomorrow: Make your real change. Caches refresh within 5 minutes.
4. A few hours after the change, raise TTL back to 14400 or 86400 for efficiency.

This compresses what would be a 24-48 hour propagation into about 5 minutes for the actual change. Used by every professional doing migrations.

Why nameserver changes take longer

Changing a record’s value is one thing. Changing your nameservers entirely is different. The TLD’s “glue records” (e.g. .com’s records for your nameservers) have their own TTLs — typically 48 hours — controlled by the TLD operator, not by you.

When you change nameservers at your registrar, the registrar tells the TLD to update. The TLD does update quickly, but resolvers that previously cached the old nameservers continue using them until their TTL expires. This is why nameserver changes are the slowest type of DNS change — typically 24-48 hours.

Checking propagation status

Method 1: whatsmydns.net

Enter your domain and record type. The site queries DNS servers from many global locations and shows what each sees. When all locations show the new value, propagation is complete.

Method 2: command line dig

From your terminal:

# Query default resolver (shows what you'd see)
dig yourdomain.com

# Query specific public resolvers
dig @8.8.8.8 yourdomain.com    # Google
dig @1.1.1.1 yourdomain.com    # Cloudflare
dig @9.9.9.9 yourdomain.com    # Quad9

# Query authoritative directly (bypasses all caches)
dig @ns1.iwebvault.com yourdomain.com

If authoritative shows the new value but resolvers show old, propagation in progress. If authoritative shows old too, your change didn’t apply.

Method 3: nslookup (Windows)

nslookup yourdomain.com 8.8.8.8

Same idea — query specific resolvers and compare.

Why YOUR computer sometimes lags

You changed DNS, whatsmydns.net shows it’s propagated globally, but YOUR browser still loads the old site. Causes in order of likelihood:

• Browser cache. Browsers cache DNS independently. Clear browser cache or open private/incognito.
• OS DNS cache. Flush it:
  • Windows: ipconfig /flushdns
  • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • Linux: sudo systemctl restart systemd-resolved (varies by distro)
• Router DNS cache. Restart your router.
• Hosts file override. Look at /etc/hosts (Linux/Mac) or C:WindowsSystem32driversetchosts for any line referencing your domain. Remove if present.
• Browser HSTS cache. Some browsers cache HTTPS settings — clearing browser data resets it.

Negative caching (the sneaky one)

If you query a non-existent record (say, you query foo.yourdomain.com before creating it), the resolver caches the “doesn’t exist” answer too — for a duration set by the SOA record’s “minimum TTL” (typically 1-3 hours).

Implication: if you check a record before creating it, then create it, then check again — you’ll still see “doesn’t exist” until that negative cache expires. Don’t pre-check records you haven’t created yet.

Common propagation issues

“Some users see the new site, some don’t.” Normal mid-propagation behavior. Users on resolvers that cached early still see old; users on resolvers that refreshed see new. Resolves itself within TTL.

“It’s been days and propagation isn’t complete.” Genuinely odd. Check that the change actually saved at the authoritative nameserver (dig @ns1.iwebvault.com yourdomain.com). If it doesn’t show there, your change didn’t apply — re-save it. If it does, but resolvers don’t see it, lower TTL and wait again.

“I changed an A record but my email broke.” If you accidentally changed the MX record’s destination or removed the mail A record, mail won’t deliver. Verify MX and mail.yourdomain.com A records are intact.

“My site is back to the old version after I just updated content.” Not a DNS issue — that’s HTTP caching (Cloudflare, browser, CDN). Purge cache at the appropriate layer.

“Site loads in incognito but not normal browser.” Browser cache for the site. Clear it for the domain.

What’s next

• Understanding the DNS records being propagated: DNS records explained.
• Migrating cleanly with minimal downtime: Migrating a domain.
• If your domain isn’t resolving at all: Troubleshooting guide.

Propagation isn’t magic — it’s just cache expiry on a planet-scale distributed system. Lower TTLs before changes, use dig to verify, flush local caches when in doubt. Most “propagation” frustration comes from not knowing where the cached data lives; once you do, the timeline becomes predictable.