When to lower TTL — and when not to

You lower TTL before a planned move so caches can expire the old answer in time. You do not lower it during an outage that is already cached, and you do not leave it at 30 forever. After the cutover finishes, raise the TTL again so resolvers stop querying your nameservers more than they need to.

When lowering TTL helps

Lower the TTL a day before you change an A, AAAA, MX, or CDN target. Use something in the 300–3600 range for records you expect to edit soon. Wait out the previous TTL so most public caches have already dropped the old value. Then make the change. After traffic looks correct, raise the TTL back to a steadier number. Values around 86400 work well for names you rarely move.

Keep the change narrow when you can. Edit the record you are about to move, not every record in the zone. SOA refresh is a separate setting and does not replace a sensible A-record TTL. Leaving TTL at 30 on the apex and on MX “for agility” only increases query load, and mail receivers still retry on their own schedule.

When lowering TTL does not help

If the cutover already happened and some visitors still hit the old IP, dropping TTL to 30 now will not clear caches that already hold the old answer. Those resolvers keep serving what they have until their remaining TTL runs out. Lowering the authoritative TTL only helps resolvers that miss or expire. Everyone else is still on the clock they already received.

Ask a public cache what it still holds:

dig example.com A +ttlunits @1.1.1.1

The remaining TTL is your wait. Work with that number, confirm ns1 and ns2 publish the correct answer, and avoid flapping the A record every few minutes. Repeated changes multiply stale answers in the wild. If the authoritative nameservers already show the new IP and caches disagree, you wait out the remaining TTL. That is the practical first hour of a move that went live too early.

Wrong record type is not a TTL problem

DNAME and CNAME at the apex are not fixed by waiting on TTL. If dig shows a CNAME where you expected an address record, the published type is wrong and lowering TTL will not repair it. See DNAME vs CNAME when the answer shape itself is the issue.

In short, lower TTL on purpose before a planned change, wait out the old value, cut over once, then raise TTL again. Do not treat a low TTL as the fix for an outage that is already sitting in cache.