After changing the DNS record, not everyone may see the same result at the same time. TTL and cache layers are essential parts of planning migration.
Basic approach
TTL specifies the amount of time a DNS response can be cached. The update you make on the authoritative server does not retroactively shorten the remaining life of a previously acquired record. The client, browser, and recursive resolver may have different caching layers.
Application steps
- Record the TTL value before the change and the planned switching time.
- Compare the response of the authoritative server with the response of the resolver used by the client.
- Plan to ensure that the old and new target can be served during the transition; Don't rely on clearing the local cache alone.
Practical example
If the IP is changed at 14:00 when the TTL is one hour, a resolver that receives the old response at 13:59 can use it for the remaining time. Lowering the TTL just before the switch does not instantly refresh old caches.
Interpret the result correctly
Not all delay is DNS propagation. Incorrect delegation, missing record, or application cache can also create the same image. Noting the time, the queried server, and the returned value together shows which layer is left behind.
Source and follow-up reading
Protocol or command details: RFC 1034. The steps and example scenario are IPScans editorial narrative.