How to Monitor DNS Propagation After a Registrar Change

DNS migrations look simple on paper and produce real incidents in practice. The records are updated at the registrar, the TTLs expire, the world refreshes its DNS cache, and everything works. Or so the story goes. In reality, partial propagation happens regularly: some resolvers serve the new record, some serve the old one, and end-user behaviour splits along regional or ISP lines. This guide covers how to monitor a DNS migration, what to check, and how to catch the failures that silent DNS does not surface.

How DNS propagation actually works

When you change a DNS record at the registrar, the old record stays in resolver caches around the world until its TTL expires. Different resolvers refresh at different times; some respect TTL strictly and some round it up. The result is a window (usually one TTL plus a few minutes, but sometimes hours) during which different users see different records.

Your own resolver may be the last one to update, because operating systems and applications cache DNS aggressively above the OS-level resolver. The classic mistake is to ping the new endpoint from your laptop, see it work, declare propagation complete, and discover the next morning that EU customers are still hitting the old IP.

What to monitor during a migration

Four DNS record types cover the common migration cases. Each one needs its own monitor for the duration of the change.

• A and AAAA records for the hostname you are migrating. The headline check: is the new IP being served?
• CNAME records for any subdomain that uses one. CNAME chains can break silently if one link points at a non-existent host.
• MX records if email is involved. A bad MX migration produces silent email rejection without an obvious customer-facing symptom.
• NS records if you are switching DNS providers. The NS record is the foundation; if it is wrong, nothing else matters.

Multi-region checking

A DNS monitor that runs from a single resolver in a single region misses the whole point. The interesting question is whether the new record has propagated everywhere, not whether your monitor's local resolver has refreshed.

Tools like dnschecker.org let you spot-check propagation across multiple regions interactively. For automated monitoring, you want a tool that checks multiple resolvers and alerts on any disagreement. If your monitoring tool only checks from one location, run an additional manual check from a different region (your phone on cellular data is often enough) before declaring the migration complete.

Lowering TTLs before the migration

The single most useful piece of preparation is to lower the TTL of the affected records 24 to 48 hours before the change. The new TTL has to propagate first, which is why the lead time matters.

• Before migration: lower TTL from the default 3600 (1 hour) to 60 (1 minute). Wait for the TTL drop to propagate, which takes one cycle of the old TTL plus a buffer.
• During migration: update the record. Resolvers refresh within 60 seconds.
• After migration: monitor for 24 hours to catch any stuck caches. Restore the TTL to 3600 once you are confident propagation is complete.

Catching the silent partial-propagation failure

Partial propagation is the failure mode that hurts. Half of your customers see the new endpoint, half see the old one, and the half-broken state is invisible to your own monitoring if it only checks from one place.

Three signals catch it. A spike in support tickets that mentions the old behaviour or the old hostname. A divergence in user metrics between regions (US conversion drops while EU stays flat). A monitor that explicitly checks each region's resolver separately, alerts on disagreement. Run all three for at least 24 hours after a migration.

A pre-migration checklist

Two days before the migration, lower the TTL of all affected records to 60 seconds. The day before, add DNS monitors for the new record values, expected to fire because the records have not changed yet. On migration day, update the records. The monitors flip green. Watch for 24 hours, paying attention to multi-region disagreement and support ticket volume. Once both are clean for 24 hours, restore the TTLs and remove the temporary monitors. The migration is complete when the metrics are clean, not when the records are updated.