A junior admin migrates the helpdesk portal to a new server, updates the A record to the new IP, watches it resolve correctly from their own laptop, and closes the ticket. Forty minutes later the complaints start: half the office gets a connection timeout, the other half loads the page fine. Restarting the new server twice does nothing, because the new server was never the problem. The record itself was right. What was wrong was assuming that changing a DNS record changes what everyone sees at the same moment.
DNS resolution isn't one lookup, it's a chain, and every hop in that chain is allowed to remember the answer instead of asking again. Your laptop's stub resolver first checks its own tiny cache. If it doesn't have an answer, it asks a recursive resolver (your router, your ISP, or something like 1.1.1.1 or 8.8.8.8). That recursive resolver checks its own cache too, and only if it's empty does it do the expensive part: ask a root server which TLD server handles ".com", ask that TLD server which nameserver is authoritative for the domain, then ask the authoritative server directly for the record. Every one of those answers comes back with a TTL, a number of seconds saying how long whoever received it is allowed to keep reusing it before asking again.
That TTL is the actual explanation for the office split. The home users hitting a cold resolver got the new record fresh. The office users were behind a corporate DNS resolver that had queried the old record hours earlier, when TTL was still set to 86400 seconds (24 hours) from before anyone planned a migration. That resolver isn't broken and isn't slow, it's doing exactly what it was told: don't bother the authoritative server again for a full day. Every office device downstream of it keeps getting handed the old IP until that clock actually runs out, no matter how many times you refresh the new server.
The fix is a sequencing problem, not a DNS problem. Before a planned cutover, drop the TTL on the record you're about to change, ideally down to something like 300 seconds, and leave it there for at least as long as the OLD TTL was set to, so every resolver that already cached the old answer is forced to expire it before you flip anything. Only then do you change the record. Once you've confirmed the new IP is resolving everywhere you can check, you can raise the TTL back up for stability. Skipping the low-TTL waiting period is the single most common reason a "DNS change" looks like an outage that only affects some people: you migrated before the old answer had any reason to expire.
dig +trace example.com is worth knowing cold for exactly this kind of problem. It walks the actual resolution path hop by hop, root, TLD, authoritative, and shows you the record and its remaining TTL at each stage, instead of just handing you whatever your local resolver currently has cached. When "it works for me but not for them" shows up, that's the first command to reach for, because it tells you whether you're looking at a real record problem or a caching problem that will fix itself on a clock you can actually predict.
This is exactly the kind of foundational networking most people skip past because it "just works" until the one day it doesn't. The Network Engineer L1 book covers subnetting, VLANs, routing, DNS and DHCP with 12 labs and 30 real scenarios built to put you in this exact situation before it happens on a production system you're responsible for: https://resources.codelivly.com/product/network-engineer-l1/
Top comments (0)