Exercise 2: Still Loading From the Old Server 20 Minutes After the DNS Change — Possible Solution
====================================================================

Most likely cause:

Per the chapter, "every DNS record carries a TTL (time to live) --
how long a resolver is allowed to cache the answer before it has to
ask again... cached copies at resolvers scattered around the world
keep serving the old answer until their own individual TTL expires.
This is the concrete mechanism behind a genuinely common source of
confusion: 'I changed my DNS and nothing happened.'" The site owner's
own experience matches this exactly -- the A record was genuinely
updated at the authoritative server, but visitors (or the site owner's
own machine) are very likely still being served a cached answer from
BEFORE the change, by a recursive resolver that hasn't yet re-queried
the authoritative server because its own cached copy of the old
answer hasn't expired yet.

Why 20 minutes isn't necessarily long enough:

The chapter doesn't specify what the old record's own TTL value was
set to before the change -- but TTL values are commonly set to
significantly longer than 20 minutes (an hour, several hours, or even
a full day is common for a record that isn't specifically being
prepared for a migration). If the old A record's TTL was, for example,
3600 seconds (one hour), then a resolver that cached the old answer
just before the change was made could legitimately continue serving
that cached, outdated answer for up to a full hour afterward -- 20
minutes into that window is not remotely surprising or unusual, it's
exactly the expected behavior of caching working as designed.

What this is not:

This is not necessarily evidence that the DNS change itself failed or
was configured incorrectly -- per the chapter's own explanation, this
delay is a normal, expected consequence of how DNS caching works, not
a sign of a bug. The correct response is not to assume the change
didn't take effect, but to wait out the old TTL, or to directly query
the authoritative nameserver itself (bypassing any intermediate cache)
to confirm the new record is actually correct and already being
served from the source, even while other cached copies elsewhere
haven't caught up yet.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies caching/TTL as the specific mechanism at play, using
the chapter's own explicit "I changed my DNS and nothing happened"
framing, and explains why the delay is expected rather than a sign of
misconfiguration, rather than jumping to "something is broken."