Split-horizon DNS means that a fully qualified domain name can resolve differently depending on where and how the query is resolved. For example, api.example.com might resolve to an internet-facing load balancer for public users and an internal load balancer for workloads on a private network. The application uses the same hostname in both locations, while DNS directs clients toward an appropriate endpoint. An internal view can also contain names that do not exist in the public view.
The deciding factor is the DNS resolution path, not simply whether a device has a private IP address. An internal client using an external recursive resolver might receive the public answer. A remote employee connected through a VPN receives the internal answer only if the device's DNS configuration sends the relevant queries to a resolver that can access the internal view. Browser-managed encrypted DNS and local resolver overrides can bypass the intended configuration.
In a cloud environment, a common implementation uses public and private authoritative zones with the same domain name. The public zone is delegated through the public DNS hierarchy. The private zone is made available to selected virtual networks through zone associations, network links, or resolver policies. Records in these zones are managed separately; creating or changing a public record does not automatically update its private counterpart.
On AWS, an Amazon Route 53 public hosted zone and private hosted zone can both use example.com. Associate the private hosted zone with the VPCs that need its records and enable the required VPC DNS settings, including enableDnsSupport and enableDnsHostnames. Workloads querying the VPC Resolver then receive matching private-zone records, while internet clients use the public zone. A crucial operational detail is that a matching private zone does not merge with the public zone. If the requested name or record type is missing from that private zone, resolution does not automatically fall back to the public record.
Hybrid networks require an explicit forwarding design. On-premises DNS servers can conditionally forward the cloud namespace to Route 53 Resolver inbound endpoint addresses over private connectivity. For queries originating in a VPC that must reach on-premises DNS, Resolver outbound endpoints and forwarding rules provide the opposite direction. Allow both UDP and TCP port 53 where required, provide resilient endpoint connectivity, and avoid forwarding loops. On AWS, a matching Resolver forwarding rule takes precedence over a private hosted zone for the same domain, so overlapping rules deserve particular attention.
The main trade-offs are duplicated record management, more complicated troubleshooting, and inconsistent answers during changes. Positive and negative caching can preserve old results until their cache lifetimes expire. Test from each intended client network using its actual resolver, compare the returned records and response codes, and verify private-zone associations and forwarding rules before changing application settings.
Split-horizon DNS is not a security boundary or a routing mechanism. Returning a private address does not create network connectivity, and hiding a record does not authorize access. Routes, firewalls, security groups, application authentication, and TLS certificates still need to be correct. It is also distinct from geographic or weighted DNS routing: those policies select answers for traffic distribution, whereas split-horizon DNS separates namespace views for different resolution contexts.
Amazon Route 53