Technical
TTL
Also called Time to live.
TTL is the number of seconds a DNS answer may be reused from cache before the resolver must ask again. A shorter TTL means faster changes and more lookups.
How it is measured
`dig example.com A` prints the TTL in the second column. The authoritative server shows the full value, and a resolver with the record cached shows it counting down. Ask twice a few seconds apart: 299, then 291, means the resolver has it cached from a 300-second record.
Common values are 300 (5 minutes), 3600 (1 hour), and 86400 (1 day). The longest wait after a change is the old TTL, not the new one.
Worked example
A firm plans to switch hosts on Saturday at 02:00. Its A record carries 86,400. On Friday at 02:00 it lowers the TTL to 300. By Saturday every cache holds a 300-second copy. At 02:00 the IP changes, and by 02:06 nearly every resolver has the new address.
Without the Friday step, some visitors would have reached the old server until Sunday at 02:00. After the move the firm raises the TTL back to 3,600 to cut query volume.
How it differs
TTL is the cache lifetime on a DNS record. DNS is the system that does the lookups. TTL sets how long answers are remembered, while DNS is the whole mechanism. Some resolvers also clamp very low TTLs up to their own floor.
Common errors
Lowering the TTL after the change instead of before it. Leaving 300 forever and adding lookups. Setting 0. Forgetting that the old TTL controls the wait. Using different TTLs across one record set. Confusing it with an HTTP cache lifetime. Ignoring the NS TTL held at the TLD.
In practice
A day before any change, drop the TTL to 300, and after it settles return to an hour or more. Check the result with `dig` against a public resolver.