DNS Propagation

What DNS propagation is

DNS propagation is the delay between changing a DNS record — pointing your domain at a new host or IP — and every resolver worldwide actually seeing the change, because resolvers cache the old answer for as long as its TTL (time to live) allows. During that window some visitors and crawlers hit the new server while others still land on the old one, which is exactly the kind of split-brain you don't want in the middle of a migration.

Propagation is the plumbing under a host or domain move. It doesn't touch your redirect map or content, but if you fumble the TTL you'll muddy the very signals your post-migration monitoring depends on.

The one thing to do beforehand: lower the TTL

TTL is measured in seconds. A record with TTL 86400 can sit cached for a full day, so if you change the IP, some resolvers keep sending traffic to the old server for up to 24 hours. The fix is to lower the TTL before the move so caches expire fast, cut over, then raise it back once things are stable.

Drop it to 300 seconds (5 minutes) at least 24–48 hours ahead — long enough for the old high TTL to age out first. Then the actual switch propagates in minutes, not a day.

Example: lower TTL, then cut over

; BEFORE the migration (record still on old IP, but low TTL)
; do this 24-48h ahead so the OLD 86400 TTL expires first
www    IN  A   203.0.113.10    ; TTL 300  (was 86400)

; AT cutover: flip to the new host's IP, TTL still low
www    IN  A   198.51.100.20   ; TTL 300

; AFTER it's stable (a few days): raise TTL back for efficiency
www    IN  A   198.51.100.20   ; TTL 3600

Example: check what a resolver currently returns

$ dig www.example.com +noall +answer
www.example.com.    287    IN    A    198.51.100.20

That 287 is the seconds left on the cached record — it counts down from your TTL. Query a few public resolvers to see whether the change has reached them yet:

$ dig @8.8.8.8 www.example.com +short      # Google
198.51.100.20
$ dig @1.1.1.1 www.example.com +short      # Cloudflare
203.0.113.10                               # still the OLD IP - not fully propagated

Common DNS records and their propagation impact

How to check it on your own site

1. Read the current TTL. Run dig www.yourdomain.com +noall +answer. The number before IN A is seconds remaining on the cache. If it's 3600+ you want to lower it before any move.
2. Lower TTL 24–48h ahead. Set the record to 300 in your DNS panel. Wait for the old, higher TTL to expire so resolvers actually pick up the shorter one.
3. Cut over, then query multiple resolvers. After flipping the IP, run dig @8.8.8.8, @1.1.1.1, and your ISP's resolver. Mixed answers mean it's still propagating; consistent new IP everywhere means you're through.
4. Check globally. Use a "DNS checker" that queries dozens of locations, or query resolvers in other regions, to confirm the change reached beyond your own network.
5. Confirm the site serves correctly on the new IP. curl -I --resolve www.yourdomain.com:443:198.51.100.20 https://www.yourdomain.com/ forces the new server and checks it returns 200 with a valid cert before the world arrives.
6. Raise the TTL back to 3600+ once you've watched it hold stable for a few days.

Common mistakes & how to fix them

• Forgetting to lower TTL first. You cut over and half your traffic sticks to the old server for a day. Fix: drop TTL to 300 at least 24–48h before the move so caches are already short when you flip.
• Decommissioning the old server too fast. Resolvers still caching the old IP hit a dead host and users see downtime. Fix: keep the old server answering (or 301-ing) until dig against several resolvers all show the new IP.
• Only checking your own machine. Your resolver updating doesn't mean the world's has. Fix: query 8.8.8.8, 1.1.1.1, and a global DNS checker before calling it done.
• Ignoring MX and TXT. Move the site and quietly break email or your GSC verification. Fix: audit every record type before cutover, not just the A record.
• Confusing DNS delay with an SEO problem. A ranking wobble during propagation is usually the split-serving, not Google penalizing the move. Fix: confirm propagation is complete before diagnosing anything as an SEO issue in your monitoring.

Frequently asked questions

How long does DNS propagation actually take?

For A/CNAME records it's governed by TTL — minutes if you pre-lowered it, up to 24–48 hours if you left a high TTL in place. Nameserver (NS) changes are the slow case and can take a day or two regardless.

Does DNS propagation hurt SEO?

Not directly, if you handle it cleanly. The risk is indirect: if the old server goes dark before propagation finishes, crawlers and users hit errors, and that downtime can dent rankings. Keep both servers live through the window and you're fine.

Why do different tools show different IPs?

Because each resolver caches independently and expires on its own TTL clock. Seeing old and new IPs across resolvers is normal mid-propagation — it's done when they all agree on the new one.

Can I force propagation to go faster?

You can't force other resolvers to dump their cache early — that's why lowering TTL beforehand is the only real lever. You can flush your own local cache, but that doesn't change what the rest of the internet has cached.

Where does DNS fit in the migration sequence?

It's the switch that makes a host or domain move live, after your pre-migration audit and redirect prep. For the performance angle, see DNS configuration impact on SEO performance.