You point your domain at a new server, and some visitors still reach the old one for hours. That’s “DNS propagation”. The name suggests updates spreading slowly across the internet, but what’s really happening is caching: resolvers keep old answers until they expire. Once you understand TTLs, you can make DNS changes take effect within minutes, and migrate servers without downtime.

How DNS lookups are cached

When a visitor opens example.com:

  1. Their device asks a recursive resolver: their ISP’s, or a public one like 1.1.1.1 or 8.8.8.8.
  2. If the resolver has a cached answer that’s still valid, it returns that immediately.
  3. Otherwise it asks the authoritative nameservers for your domain, gets the current record, and caches it for the record’s TTL (time to live).

Every resolver caches independently, so after a change some users get the new answer right away and others get the old one until their resolver’s cached copy expires. Browsers and operating systems add small caches of their own.

TTL: the number that controls it

dig example.com A +noall +answer
# example.com.   3600   IN   A   203.0.113.10
#                ^^^^ TTL in seconds (1 hour)

After you change a record, the worst case for resolvers that cached the old one is roughly one TTL. With a TTL of 86400 (24 hours), “propagation” can take a day. With 300, it takes about 5 minutes.

Record changes vs nameserver changes

Changing a record (A, AAAA, CNAME, MX, TXT) at your current DNS provider: the delay is bounded by that record’s TTL.

Changing nameservers (moving DNS to another provider, such as Cloudflare): this is slower, because the delegation (NS records) is cached at the TLD level (.com, .net), often with TTLs of 24–48 hours, and registrars can take time to publish the update. That’s where the “up to 48 hours” advice comes from.

Check propagation

Query authoritative and public resolvers directly:

dig +short example.com A @ns1.your-dns-provider.com     # the authoritative answer (the truth)
dig +short example.com A @1.1.1.1                        # Cloudflare resolver
dig +short example.com A @8.8.8.8                        # Google resolver
dig +short example.com A @9.9.9.9                        # Quad9
dig example.com NS +trace                                # follow delegation from the root

If the authoritative answer is correct and public resolvers still show the old one, you’re just waiting out the TTL. Online “DNS propagation checker” sites query resolvers worldwide for the same purpose. See dig and nslookup.

Flush local caches when testing:

resolvectl flush-caches                    # Linux with systemd-resolved
ipconfig /flushdns                         # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS

Chrome has its own cache: chrome://net-internals/#dns → Clear host cache.

Zero-downtime server migration with DNS

  1. Lower the TTL in advance. At least one old-TTL period before the move (e.g. 24 hours earlier if the TTL is 86400), set the TTL to 300.
  2. Prepare the new server completely: data synced, SSL certificates ready. Test it with a hosts-file entry pointing the domain at the new IP:
# /etc/hosts or C:\Windows\System32\drivers\etc\hosts
203.0.113.20   example.com www.example.com
  1. Final sync of databases and files (short write freeze, or replication).
  2. Change the A/AAAA records to the new IP.
  3. Keep the old server running for at least a few TTLs. Users with cached answers still reach it. Ideally make it proxy to the new server, or keep it read-only.
  4. Raise the TTL again (3600 or more) once everything is stable.

Certificates: Let’s Encrypt HTTP validation works only once DNS points to the new server. Use DNS validation or copy the existing certificates for the first hours. See wildcard certificates with DNS validation.

Email (MX) changes

Mail servers cache MX records too, and keep retrying deliveries for days. When moving mail:

  • lower the MX TTL in advance;
  • keep the old mail server accepting mail during the transition, and fetch any messages that land there;
  • update SPF records to include the new server’s IP before switching. See DNS records explained.

Negative caching

If someone queried a record before it existed (an NXDOMAIN answer), resolvers cache the “doesn’t exist” answer for the SOA’s negative TTL (the minimum field, often 300–3600 seconds). Create records before announcing new subdomains.

Quick reference

Situation Typical delay
Record change, TTL 300 ~5 minutes
Record change, TTL 3600 Up to ~1 hour
Record change, TTL 86400 Up to ~1 day
Nameserver change Hours, up to 48 h
New record previously queried Negative TTL from SOA

Related: change DNS servers on Linux and choosing a VPS location.

  • DNS
  • Networking
  • Migration