Introduction

When a cutover looks correct from the public internet but internal users still reach the old server, split-horizon DNS is usually the reason. The public DNS zone may already point to the new destination, while the internal DNS view, private zone, or corporate resolver is still handing out the old private IP. That creates a confusing situation where external checks look healthy but office users, VPN clients, or internal systems keep connecting to the retired environment.

Treat this as an internal DNS view problem, not a general propagation problem. The goal is to identify which internal resolver path is still serving the old address and update or clear that path cleanly.

Symptoms

  • External users reach the new site or service, but internal users still hit the old server
  • Office networks, VPN clients, or internal applications behave differently from public checks
  • Public DNS lookups show the new record, but internal lookups return an old private IP
  • Only users on certain networks still see the old environment after cutover
  • The issue appears after migration, load balancer changes, or service relocation
  • Internal monitoring and external monitoring disagree about the active endpoint

Common Causes

  • The internal DNS view or private zone was not updated during cutover
  • A split-horizon resolver is serving a stale record for the old private IP
  • Internal DNS forwarders or conditional forwarders still point at an outdated zone source
  • Resolver or operating system caches preserved the pre-cutover answer longer than expected
  • Different sites or VPN paths are querying different internal resolvers
  • The old internal record was updated in one place but not in all authoritative private zones

Step-by-Step Fix

  1. Prove the difference between public and internal resolution with direct lookups from both contexts, because you need to confirm this is truly a split-horizon issue and not a general DNS propagation delay.
  2. Identify which internal resolver the affected users or systems are actually querying, because large environments often have multiple DNS paths and only one of them may still serve the old private IP.
  3. Check the relevant internal DNS zone or private view for the affected hostname and confirm whether it still contains the old address, because the wrong record is often still present in the internal authoritative source.
  4. Review any internal forwarders, conditional forwarders, or DNS appliances in the path, because they may continue sending requests to an outdated zone source even after the main private DNS record was corrected.
  5. Compare results across office networks, VPN clients, servers, and internal containers if behavior differs, because different network segments may be using different resolver chains.
  6. Clear resolver cache at the authoritative internal DNS layer and then at downstream caching resolvers where appropriate, because an updated private zone does not help if intermediate internal caches still serve the old answer.
  7. Flush local client or operating system DNS cache on a test machine and retry the lookup, because endpoint caching can make the internal DNS fix look incomplete even after the server-side record was corrected.
  8. Confirm that the new internal target is actually reachable and intended for internal users, because some cutovers change both DNS and internal routing and you need the replacement private IP to be valid before broad cache clearing.
  9. Document the internal DNS source of truth, the resolver chain, and the final corrected private record after the cutover, because split-horizon incidents often recur when teams update public DNS but forget the internal view.