Stale DNS record: traffic still goes to the old server

The scenario

The app used to run on Old-Server (10.0.2.99). It now runs on New-Server (10.0.2.20). Old-Server's web service has been shut down, but the machine is still on and still holds its address. Nobody updated DNS: DNS-Server (10.0.1.53) still answers app.example.com with 10.0.2.99. The Client asks DNS-Server, gets the old address, and connects to a machine that no longer runs the app. Because Old-Server still holds the address, it rejects the connection at once instead of leaving the Client waiting. There is no caching in this lab: what you see is simply an outdated record, which is also exactly what a client with a stale cached answer experiences.

What you will work out

Recognise an outdated DNS answer, fix the record, and understand how TTL and caching stretch the same problem out in real networks.

Why this matters

Server moves, re-addressing and cloud migrations all change where a name should point. Forgetting a record, or changing it without allowing for cached copies, produces the confusing outage where some users reach the new server and others still reach the old one. Checking what a name resolves to, and whether that is the address you expect, is the first step.

Running it

Stale DNS Record: The Server Moved opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.