Lowering DNS TTLs before a server migration

• How TTL affects a migration
• A practical timeline
• Test before switching
• Keep the old server running
• Do not forget other records
• Certificates

When you move an app to a new server, the slowest part is often waiting for DNS. Resolvers around the world cache the old IP for as long as the record’s TTL allows. If the TTL is a day, some users hit the old server for up to a day. Plan ahead and the cutover takes minutes.

§How TTL affects a migration

The TTL tells resolvers how many seconds they may cache a record. Lowering it only helps after the old TTL has expired everywhere. If the record has a TTL of 86400 seconds, lowering it to 300 today takes effect fully tomorrow.

§A practical timeline

Two days before: check current TTLs:

dig +noall +answer app.example.com

The number in the second column is the remaining TTL from your resolver. Check the authoritative value in your DNS provider.

At least one old TTL before the move: lower the TTL on the records you will change to 300 seconds, or 60 if your provider allows.

Migration day: bring up the new server, test it using a hosts file entry or curl --resolve, then change the record. Most traffic moves within five minutes.

After a few days: raise the TTL back to an hour or more once you are confident you will not roll back.

§Test before switching

curl --resolve app.example.com:443:203.0.113.10 https://app.example.com/health

This sends a real HTTPS request to the new IP with the right hostname, so you can verify TLS and the app before any user sees it.

§Keep the old server running

Some resolvers ignore low TTLs and some clients cache aggressively. Keep the old server serving, or proxying to the new one, for at least a day. For apps with a database, make the old instance read-only or proxy writes so data does not split.

§Do not forget other records

• www and the apex record
• API subdomains and webhooks registered with third parties
• Mail records, only if mail is moving too

§Certificates

The new server needs a valid certificate before cutover. With HTTP challenges, it cannot get one until DNS points to it, so either use a DNS challenge or accept a minute of certificate issuance right after the switch.

The mechanics behind caching, resolvers and why changes seem slow are explained in this piece on how DNS propagation works.

Disclosure: I help build Peon.