DNS TTL
The number of seconds DNS resolvers may keep an answer before asking again. It sets how long old records can linger after a change.
See it
What it is
A DNS TTL is the number of seconds a recursive resolver may reuse an answer before asking the authoritative nameserver again. With a TTL of 3600, someone who looked up your site just before an IP change can keep the old answer for up to an hour.
Lower it before a planned host migration or failover so old answers expire quickly during the cutover. Make the reduction at least one old TTL in advance; changing 86400 to 300 five minutes before the move does not shorten the day-long copies resolvers already hold.
Gotcha: a shorter TTL means more DNS queries and is not a promise that every local cache refreshes on time. Some ISP resolvers clamp or ignore very low TTLs, and a browser or JVM holding its own DNS cache will not care what your zone says. Failed lookups get cached too, under the SOA record's negative-caching rules (RFC 2308), which is why a typo can outlive its fix. After the migration settles, raise the record TTL again instead of leaving emergency settings forever.
Ask AI for it
Prepare an Amazon Route 53 DNS cutover. At least one current TTL before the move, use the ChangeResourceRecordSets API to set TTL to 300 on the affected A, AAAA, and CNAME records. At cutover, change only their values and verify the authoritative servers, 1.1.1.1, and 8.8.8.8 with 'dig +noall +answer'. Keep the old origin healthy until its previous TTL has elapsed, then restore TTL to 3600 and print the final record set.