Exercise 3: Two Non-Buggy Reasons "Fixed" Doesn't Look Fixed Yet — Possible Solution
====================================================================

EXPLANATION 1 — TTL / CACHE PROPAGATION DELAY
------------------------------
Per this chapter's warn-box, "a DNS record has a TTL - a length of
time other resolvers are allowed to keep serving their own cached copy
of it before checking again. Updating a record doesn't retroactively
update every cache that already has the old answer; those caches keep
serving the stale value until their own TTL expires." A genuinely
correct fix can be invisible to some users until their own resolver's
cached copy naturally expires - this is the TTL system working
exactly as designed, not a failure of the fix.

EXPLANATION 2 — SPLIT-HORIZON DNS
------------------------------
Per this chapter's tip-box, some organizations "deliberately configure
DNS to return different answers depending on where the query comes
from - an internal IP for requests from inside the corporate network,
a public IP for everyone else." A user in a different location or on a
different network could correctly receive a different, equally valid
answer than the one that was "fixed" - meaning nothing is actually
broken for them, they're simply seeing the other, intentionally
different side of the split.

WHY BOTH ARE "NOT A BUG"
------------------------------
Neither explanation involves the original fix being wrong or
incomplete. TTL-driven staleness is a caching mechanism functioning as
intended; split-horizon DNS is a deliberate configuration returning two
different correct answers by design. Both can make "I fixed it" and
"the user still sees the old/different result" simultaneously true
without contradiction.

WHY THIS WORKS AS AN ANSWER
------------------------------
It names two genuinely distinct, chapter-sourced explanations (TTL
caching delay and split-horizon DNS) rather than one explanation
repeated twice, and explains why each one means the original fix
wasn't actually wrong.