# Exercise 2: Diagnose a "Works for Me, Not for Them" DNS Report

## Scenario

Your team migrated `checkout.northwind.dev` from an old server (`198.51.100.5`) to a new one (`198.51.100.9`) three hours ago. The change was made correctly at the authoritative nameserver, and `dig` run directly against the authoritative nameserver confirms the new IP is live and correct.

Two support tickets came in since:

- **Ticket A**, filed 2 hours ago: a customer on a home ISP connection says checkout is "completely broken" — their browser is timing out trying to reach the *old* IP, `198.51.100.5`, which has since been decommissioned. Checking the record's history, its `TTL` had been set to `86400` (24 hours) for the past year, and was never lowered before the migration.
- **Ticket B**, filed 10 minutes ago: a *different* customer, on a different ISP, says a brand-new subdomain your team also created during this migration, `returns.northwind.dev`, "doesn't exist" — their browser shows a DNS error, even though `dig` against the authoritative nameserver shows the record exists and is correct. Checking further, this same customer had, out of curiosity, tried loading `returns.northwind.dev` two days ago — *before* the record was created — and gotten the same "doesn't exist" error then too. The zone's `SOA` minimum field is set to `3600` (1 hour).

## Deliverables

Produce all of the following, in this file, below this line:

1. **A diagnosis for Ticket A** — explain, using theory section 5, precisely which cache is most likely still serving the stale IP to this customer, why `dig` against the authoritative server looking correct doesn't contradict this, and give a concrete estimate of when this customer's issue should self-resolve given the TTL that was in effect.
2. **A diagnosis for Ticket B** — explain, using theory section 8, why this is a *different* mechanism than Ticket A even though both look like "stale DNS," identify exactly which cached record type is causing it, and give a concrete estimate of when this customer's issue should self-resolve.
3. **A process fix** — propose one concrete change to how your team handles *future* DNS migrations that would have prevented Ticket A specifically from happening (referencing the TTL-lowering pitfall in theory's Common Pitfalls), and state clearly why it would not have prevented Ticket B (since Ticket B's cause is unrelated to the migration's own TTL).
4. **One clarifying question** you would need answered to be fully certain about Ticket B's root cause, and what answer would confirm vs. rule it out.

## Constraints

- Do not propose "just wait" as a complete diagnosis for either ticket — each answer must name the specific cache/mechanism responsible and give a time estimate grounded in the numbers given in the scenario.
- Treat the two tickets as having genuinely different root causes, even though both present as "DNS seems stale to this one customer."