DNS migration without downtime: TTL done right

What TTL is and why it decides the migration

Every DNS record carries a TTL (time to live) in seconds. It tells resolvers such as those of Google, Cloudflare or your ISP how long they may cache the answer without asking the authoritative nameserver again. With a TTL of 86400, a resolver can keep serving your old A record for up to 24 hours after the change, and there is nothing you can do about it.

That is why a migration starts with the TTL, not with the change. Lower it to 300 seconds in time, and old caches expire at most five minutes after the switch. The catch: the lowering itself has to make it through the old TTL first. If you go from 86400 to 300 today, you have to wait 24 hours before all resolvers know the new value.

Two kinds of migration

A hosting migration changes only individual records, usually A, AAAA and maybe a CNAME for www. The zone stays with the same DNS provider. That is the easy case: lower the TTL, wait, change the record, done.

A nameserver change is different. The whole zone moves to another provider and the NS records at the registrar are switched. You cannot influence the TTL of the NS delegation at the registry, which is often a day or more. So the old and the new zone must be identical during the transition, because you never know which nameserver a resolver is asking right now.

Step by step: changing nameservers

The order is critical. Every step you skip comes back later as an outage.

1. 24 to 48 hours before: lower the TTL of all records in the old zone to 300.
2. Export or write down the complete old zone: A, AAAA, CNAME, MX, all TXT records (SPF, DKIM selectors, DMARC under _dmarc, verification records from Google, Microsoft and others), SRV, CAA, and every single subdomain.
3. Create everything at the new provider with the same values and a short TTL as well.
4. Verify the new zone directly against the new nameservers before switching anything (see below). The DNS checker compares both zones record by record.
5. If DNSSEC is enabled: remove the DS record at the registrar or update it to the new keys, otherwise you get SERVFAIL after the switch.
6. Point the NS records at the registrar to the new nameservers.
7. After the switch, test the website, inbound mail, outbound mail and every subdomain.
8. After one or two days, raise the TTL back to 3600 or higher.

The classic failures

Almost every outage during a DNS migration has one of these causes, and almost all of them would have shown up in a zone comparison before the switch.

• Forgotten MX: the website works, but no mail arrives. Senders get bounces or their mail sits in queues.
• Forgotten DKIM selectors: outbound mail keeps flowing, but every message fails DKIM and often DMARC as a result. Nobody notices until mail lands in spam.
• SPF copied but verification TXT records not: Google Workspace or Microsoft 365 eventually report the domain as no longer verified.
• DS record left at the registrar: the old DNSSEC keys are still published while the new zone is signed differently or not at all. Validating resolvers return SERVFAIL, and the domain is gone for a large share of users.
• Overlooked subdomains: shop., api., intranet., autodiscover. and wildcard records often only appear in the old provider's panel after scrolling.
• CAA forgotten or copied wrongly: the next certificate renewal fails.

Checking propagation the right way

If you check with nslookup or dig without naming a server after the switch, you are asking your own resolver, and it will return the old answer until the TTL expires. That says nothing about whether the new zone is correct. Ask the authoritative nameservers directly instead, old and new, and compare.

# Check the new zone directly at the new nameserver, before switching
dig @ns1.new-provider.example example.com MX +short
dig @ns1.new-provider.example example.com TXT +short
dig @ns1.new-provider.example selector1._domainkey.example.com TXT +short

# Which nameservers does the world see?
dig example.com NS +short

# Check the delegation at the registry (for .com)
dig @a.gtld-servers.net example.com NS

Only when the answers of both nameservers match for every record is the switch safe. After the switch, querying several public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) shows how far propagation has come.

After the migration

Keep the old zone running unchanged for at least a week. Resolvers with long caches, mail servers that still know yesterday's NS records and registry TTLs mean that part of the queries still arrive at the old nameservers days later. As long as the same data lives there, nobody notices.

Then raise the TTL again. 3600 seconds is a good default, 86400 for records that never change. Short TTLs increase query volume and make the domain more fragile when a nameserver is down. And take a snapshot of the finished zone so you know what it should look like next time.

Frequently asked questions

How long does propagation really take?

As long as the longest TTL involved. With lowered record TTLs and a pure hosting migration, a few minutes. With a nameserver change, the TTL of the registry delegation decides, usually between a few hours and two days. As long as old and new zone are identical, it does not matter.

Can I set the TTL to 60 seconds?

Technically yes, and for the hours around the switch that is fine. Some resolvers ignore very short TTLs and cache for a few minutes anyway. Permanently, 60 seconds is unnecessary and generates a lot of queries.

Do I have to disable DNSSEC for the migration?

The safest way is to remove the DS record at the registrar before the switch, wait until it has left the caches, and re-enable DNSSEC at the new provider afterwards. A migration with continuous signing is possible but requires both providers to coordinate keys.