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. Split-horizon DNS configurations serve different answers based on the source of the query, typically providing private IPs for internal users and public IPs for external users.

This issue commonly appears after infrastructure migrations, IP address changes, or service relocations where the public DNS was updated but the internal/private DNS views were overlooked. Organizations with split-horizon DNS typically have separate authoritative zones or DNS views for internal networks, and these internal views are managed separately from public DNS, making them easy to miss during migration planning.

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 (specific offices, VPN segments) 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
  • External status pages show healthy but internal users report issues
  • Different office locations experience different results for the same hostname
  • VPN-connected users see different behavior than office-connected users
  • Internal applications fail while external-facing services work correctly

Common Causes

  • The internal DNS view or private zone was not updated during cutover, leaving old records in place
  • A split-horizon resolver is serving a stale record for the old private IP due to caching
  • 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 with different configurations
  • The old internal record was updated in one place but not in all authoritative private zones
  • Internal DNS changes require separate approval or change management that was not completed
  • Private zone transfers from primary to secondary internal DNS servers failed
  • VPN DNS settings use different resolvers than office network DNS

Step-by-Step Fix

  1. 1.Prove the difference between public and internal resolution with direct lookups from both contexts (dig @public-dns hostname vs dig @internal-dns hostname), because you need to confirm this is truly a split-horizon issue and not a general DNS propagation delay.
  2. 2.Identify which internal resolver the affected users or systems are actually querying by checking DNS client configuration on affected machines, because large environments often have multiple DNS paths and only one of them may still serve the old private IP.
  3. 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 (check BIND zone files, Windows DNS, or internal DNS management console).
  4. 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. 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 with different configurations.
  6. 6.Clear resolver cache at the authoritative internal DNS layer (rndc flush for BIND, Clear-Cache for Windows DNS) 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. 7.Flush local client or operating system DNS cache on a test machine (ipconfig /flushdns on Windows, sudo systemd-resolve --flush-caches on Linux) and retry the lookup, because endpoint caching can make the internal DNS fix look incomplete even after the server-side record was corrected.
  8. 8.Confirm that the new internal target is actually reachable and intended for internal users by testing connectivity to the new private IP, because some cutovers change both DNS and internal routing and you need the replacement private IP to be valid before broad cache clearing.
  9. 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.

Verification

Confirm the fix is complete:

  1. 1.Query internal DNS from multiple internal locations and verify the new IP is returned
  2. 2.Test from VPN connections and different office networks to ensure consistent resolution
  3. 3.Verify internal users can access the service using the new private IP
  4. 4.Confirm internal monitoring shows the correct endpoint
  5. 5.Check that no internal users report reaching the old environment

Prevention

To avoid this issue in future migrations:

  • Include internal/private DNS views in migration checklists alongside public DNS
  • Document all internal DNS views and zones that serve the hostname
  • Coordinate internal DNS updates with the same rigor as public DNS changes
  • Test from both internal and external perspectives during migration validation
  • Include split-horizon DNS in change management and approval workflows
  • Set up monitoring that checks both internal and external DNS resolution
  • Document the relationship between internal and external DNS records for each service
  • [Fix DNS Caa Record Blocking Letsencrypt Certificate Issuance Issue in DNS](dns-caa-record-blocking-letsencrypt-certificate-issuance)
  • [DNS CAA Record Blocking Let's Encrypt Renewal in a Multi-Provider Zone](dns-caa-record-blocking-letsencrypt-renewal-multi-provider-zone)
  • [Fix Dns Cdn Apex Domain Cname Restriction Alias Aname Record Issue in Dns](dns-cdn-apex-domain-cname-restriction-alias-aname-record)
  • [Fix DNS Cname Apex Not Supported Rfc Violation Registrar Issue in DNS](dns-cname-apex-not-supported-rfc-violation-registrar)
  • [Fix DNS Dnssec Validation Failure Chain Of Trust Broken Issue in DNS](dns-dnssec-validation-failure-chain-of-trust-broken)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix Split-Horizon DNS Still Resolving Old Internal IP After Cutover", "description": "Resolve split-horizon DNS still serving an old internal IP after cutover by checking internal zones, forwarders, resolver cache, and private DNS views.", "url": "https://www.fixwikihub.com/fix-split-horizon-dns-still-resolving-old-internal-ip-after-cutover", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T05:57:34.589Z", "dateModified": "2025-10-31T05:57:34.589Z" } </script>