ipTTL describes a cache lifetime
DNS answers can be cached. TTL indicates how long a record may be reused from cache. Resolvers obtain records at different times, so a change may not appear everywhere simultaneously. Often called propagation, this is not a single central update pushed to every device.
Plan before changing records
Lowering TTL ahead of a server move can help the transition. Lowering it at the moment of the move does not retroactively shorten answers cached under the old value. Keeping the old server available during the transition reduces the risk of interrupted access.
Is clearing a cache enough?
Clearing your device’s cache can help a local retest, but it does not clear your ISP’s or another resolver’s cache. Compare authoritative answers with those from your normal resolver. If the authoritative record is wrong, waiting or restarting a browser will not correct it.
A TTL timeline
A resolver that receives a record at 10:00 with a 3600-second TTL may retain it until about 11:00 despite a change at 10:05. Setting TTL to 60 later does not retroactively alter that cached copy. This explains lowering it in advance. Real refresh and failure behavior can vary; compare authoritative and cached answers separately.
Further reading
DNS concepts — RFC 1034 ↗Put it into practice
Inspect one public IP, or compare a list of addresses with the bulk lookup tool. Location results are approximate.
Single lookup ↗ Bulk lookup ↗