Exercise 3: Lowering the TTL the Same Day as the Migration — Possible Solution
====================================================================

The flaw:

Per the chapter's own warn-box, "the TTL change itself is subject to
the OLD TTL that was in effect before it. Lowering the TTL at the same
time as making the actual change is too late; it needs to happen well
in advance, giving the old, longer TTL time to fully expire everywhere
before the real change goes out." The team's plan lowers the TTL and
performs the actual server migration on the same day -- but lowering
the TTL is itself a DNS record change, and per the chapter's own
caching mechanism, any change to a DNS record only actually takes
effect for resolvers everywhere once THEIR cached copy of the
PREVIOUS record expires according to ITS OWN TTL.

If the domain's TTL was, say, one hour before the team made their
change, then resolvers around the world that had already cached the
record (with the old, one-hour TTL) will continue serving that cached
answer -- with the OLD TTL value still in effect for their own caching
purposes -- for up to an hour after the team's "lower the TTL to 60
seconds" change was made at the authoritative server. The new, short
60-second TTL only becomes the effective value for a given resolver
AFTER that resolver's own pre-existing cache entry (governed by the
old, longer TTL) finally expires and it re-queries the authoritative
server, at which point it picks up both the new record's data AND the
new, short TTL together.

The consequence for their migration:

Since the team performed the actual server migration on the SAME day
they lowered the TTL, resolvers still working off the old, longer TTL
would continue directing traffic to the OLD server for however long
that old TTL had left to run when the change was made -- potentially a
full hour or more, depending on what the original TTL value was --
completely defeating the purpose of lowering the TTL to 60 seconds in
the first place, since that fast propagation only applies going
forward, to resolvers that have already picked up the new short TTL.

The correct approach:

Per the chapter's own guidance, the TTL should be lowered well in
advance of the actual migration -- long enough before it that the
OLD, longer TTL has had a full opportunity to expire everywhere first.
Only once resolvers have already picked up the new, short TTL should
the actual server migration itself be performed, at which point the
short TTL genuinely delivers the fast propagation the team was hoping
for.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains specifically why a TTL change is bound by the PREVIOUS
TTL rather than taking effect immediately, using the chapter's own
warn-box, and traces through the concrete consequence for the team's
same-day plan rather than just restating the rule.