Changing an address record is easy; predicting when every resolver stops using the old answer is not. The time-to-live value travels with a DNS response and controls how long a cache may reuse it. Lowering the TTL at the moment of a migration does not rewrite answers that were cached earlier.

Lower the TTL before the event

If an existing record has a one-day TTL, lower it at least one old TTL before the planned switch. That gives caches time to fetch the shorter value while the old endpoint is still authoritative. The exact interval belongs in the change plan rather than in an improvised command during the migration.

Record the answer from the authoritative server and from at least one recursive resolver:

dig +noall +answer www.example.test A
dig @1.1.1.1 +noall +answer www.example.test A

The remaining TTL shown by a recursive resolver is evidence of its current cache state. Different resolvers can legitimately show different remaining values.

Keep both sides valid

During the switch, keep the old and new endpoints capable of serving the intended hostname. TLS names, redirects, and application configuration must agree on both sides. Removing the old endpoint immediately after the authoritative record changes creates an avoidable outage for clients that still hold the prior answer.

Negative answers are cached too. Creating a name that recently returned NXDOMAIN can take time to become visible because the negative response may remain in recursive caches according to the zone’s authority data.

Raise the TTL after observation

Once authoritative and representative recursive answers point to the new endpoint and the old cache window has elapsed, restore the normal TTL. Keep the change record with the old value, new value, authoritative answer, and rollback condition.

Sources