Split-Horizon DNS

Internal vs external DNS views for the same domain, use in VPCs and split-tunnel VPNs, and private hosted zones.

Overview

Overview Split-horizon DNS (also called split-brain DNS or split-view DNS) is a configuration where the same domain name returns different DNS responses depending on the source of the query. External clients resolving api.example.com receive the public IP of a load balancer; internal clients within the VPC receive the private IP of the same service, bypassing the load balancer and NAT gateway entirely.

This pattern is fundamental to cloud networking. In AWS, Route 53 private hosted zones implement split-horizon DNS natively — you create a private hosted zone for example.com, associate it with specific VPCs, and records in that private zone shadow the public hosted zone for queries originating inside those VPCs. The resolver inside the VPC (169.254.169.253, the VPC's built-in resolver at the second IP of the VPC CIDR) checks private hosted zones first, then falls through to public DNS.

Split-horizon DNS solves the hairpinning problem. Without it, an application inside a VPC that calls api.example.com would resolve to the public ELB IP, send traffic out through the internet gateway, have it NATted back in, traverse the ELB, and reach the target — adding latency and NAT gateway cost. With a private hosted zone pointing api.example.com to the internal ALB or directly to service IPs, traffic stays on the AWS private network.

The same pattern applies to split-tunnel VPNs. Employees connected to a corporate VPN with split tunneling receive internal DNS responses for company domains (routing those queries through the VPN tunnel to an internal resolver) while public internet traffic bypasses the VPN. The VPN client is configured with DNS search domains that determine which queries go to the internal resolver.

Split-horizon DNS introduces operational complexity. When internal and external views diverge, debugging connectivity issues requires knowing which view a client is using. Certificate management must account for both views — internal services may use private CAs or self-signed certificates that external clients should not trust.

Key concepts

Private Hosted Zone (Route 53)
A Route 53 hosted zone associated with one or more VPCs. Queries from within an associated VPC resolve using the private zone records first; if no record exists in the private zone, the query falls through to public DNS. Private hosted zones are not visible outside the associated VPCs. They can override public records (e.g., a private zone for example.com with an api record pointing to a private IP shadows the public api.example.com record for VPC clients).
VPC Resolver (AmazonProvidedDNS)
Each AWS VPC has a built-in DNS resolver at the base of the VPC CIDR + 2 (e.g., 10.0.0.2 for a 10.0.0.0/16 VPC), also accessible via the link-local address 169.254.169.253. This resolver checks Route 53 private hosted zones associated with the VPC, then resolves public DNS. Route 53 Resolver endpoints extend this to on-premises networks via inbound and outbound resolver rules.
DNS Search Domain
A list of domain suffixes appended to unqualified hostnames for resolution. In split-tunnel VPN setups, the VPN client pushes internal search domains (e.g., corp.example.com) to the client's resolver. Queries for internal services (api.corp.example.com) are sent to the internal resolver through the tunnel; everything else uses the public resolver. This avoids routing all DNS traffic through the VPN while still resolving internal names correctly.
Hairpinning
When traffic exits a private network to a public address and immediately re-enters the same network. A VM calling an ELB by its public DNS name sends packets out through the internet gateway, the packets are NATted to the ELB's public IP, the ELB routes them to targets inside the same VPC, and responses travel back the same path. Split-horizon DNS eliminates hairpinning by resolving the service to its private IP, keeping traffic on the internal network.
Route 53 Resolver Rules
Rules that forward DNS queries matching specified domain names to specific IP addresses (resolver endpoints). Used to extend split-horizon DNS to hybrid cloud environments. Outbound rules forward internal domain queries from the VPC to on-premises resolvers. Inbound rules allow on-premises servers to resolve Route 53 private hosted zone names by querying the inbound endpoint IPs. This creates bidirectional split-horizon DNS across VPN or Direct Connect.

When to use it

  • Preventing VPC traffic from hairpinning through the internet gateway when calling internal services by their public domain name.
  • Providing internal services with human-readable names without exposing those names or IPs publicly.
  • Configuring split-tunnel VPNs so corporate DNS queries resolve internally while public traffic bypasses the tunnel.
  • Overriding public DNS records inside a VPC to point to a different backend (e.g., pointing an external SaaS vendor domain to an internal mock during testing).

Interview questions

  • How does split-horizon DNS work in AWS, and how would you implement it for a service that has both internal and external clients?
  • How does DNS resolution work over VPC peering, and what do you need to enable for split-horizon DNS to work across peered VPCs?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio