Webmaster & Network·4 min read

Checking DNS Records During a Site Migration

A site migration isn't finished when the files land on the new server. It's finished when the world's resolvers agree about where your domain lives, and the only way to know is by checking dns records at each step of the cutover. Done right, verification turns a nervous DNS switch into a sequence of small confirmations: the new record is published, the old one has aged out, mail still routes. This guide walks through that sequence, TTL strategy included, using a live lookup instead of guesswork.

Open the tool All insights

Checking DNS records at each phase of a cutover

Verification beats hope.

Migrations produce a specific anxiety: you've changed a record at the registrar, and now you're refreshing the site wondering whether the change did anything. The fix is to verify the records themselves rather than the symptom. Run the DNS Lookup tool before touching anything to capture the current state, again right after saving changes to confirm the authoritative servers publish the new values, and once more later to check that caches have moved on.

Because the tool queries all nine common types in one pass, you also catch collateral damage early. Plenty of migrations break email because someone rebuilt the zone on the new provider and forgot the MX and TXT entries that made SPF pass.

One DNS record watched through a migration

A worked example.

Suppose www.example.com currently has one A record pointing at 203.0.113.10 with a TTL of 3600. The night before the move, you lower the TTL to 300. A lookup at that point still shows 203.0.113.10, which is correct, only the TTL changed.

At cutover you edit the record to 198.51.100.7. Now the checks tell the story: a query against the authoritative servers returns 198.51.100.7 within seconds, while your ISP's resolver may serve 203.0.113.10 for up to five more minutes until its cached copy expires. When repeated lookups from a couple of networks all return 198.51.100.7, the cutover is done, and you can raise the TTL back to something sane like 3600.

TTL values decide how fast DNS changes land

The throttle on every change.

Every record carries a time-to-live, the number of seconds a resolver may reuse the answer without asking again. High ttl values mean fewer queries and more caching, which is great for stability and terrible for cutovers. A record cached with 86400 can keep sending visitors to the old server a full day after you changed it.

The standard play is to drop the TTL well before the migration, at least one old-TTL-length in advance. If the record sat at 86400, lower it to 300 a day or more ahead, because resolvers holding the old answer won't notice your new TTL until their existing cache expires.

DNS propagation delays explained honestly

It's caching, not broadcasting.

You'll read that DNS changes take 24 to 48 hours to propagate, and the phrasing suggests your update slowly ripples across the planet. That's not how it works. Nothing is pushed anywhere. Each resolver simply keeps its cached answer until the TTL runs out, then fetches the new one on the next query.

So propagation time is really just the old TTL plus a little jitter. If lookups still show stale data long past that window, stop waiting and start debugging: the usual culprits are editing the zone at the wrong provider, a typo in the record name, or old nameservers still listed at the registrar.

DNS verification mistakes that stretch a migration

A few habits reliably turn a two-hour cutover into a two-day incident:

Testing with the browser instead of the resolver. Browser and OS caches lie for minutes after DNS has already updated, so you conclude the change failed when it didn't.
Forgetting the TTL drop beforehand, then discovering the old 86400 value has locked yesterday's address into caches worldwide.
Rebuilding only A records on the new DNS provider and losing the TXT records that carried SPF, DKIM, and site verification.
Editing the zone file at a provider the domain no longer uses. Always confirm the NS records first, they name the servers the internet actually consults.

Two habits that make DNS checks trustworthy

Export a baseline before you change anything. Run the full lookup, copy each record group out with the copy buttons, and paste the lot into your migration ticket. When something misbehaves at 1 a.m., that snapshot is the difference between restoring a value and reconstructing it from memory.

And verify the boring types, not just the A record you changed. Confirming NS, MX, and TXT after any zone work takes thirty seconds and catches the silent breakage that otherwise surfaces as bounced email three days later.

DNS Lookup, DNS Record Types, and Domain to IP

Pick the right tool per question.

This article is about running lookups and verifying changes. If you're staring at a SOA or CAA entry wondering what the fields even mean, the DNS Record Types reference explains each type and its syntax, a good companion to keep open while you work.

When your question shrinks to which address answers for this name right now, Domain to IP gives the tighter answer, just IPv4 and IPv6 results without the other record noise. And for registration-level questions, nameserver ownership and expiry, that's WHOIS Lookup territory.