The Problem Split-Horizon DNS Solves
Imagine a company that hosts a web application at app.example.com. Externally, the domain resolves to a public IP address — say 203.0.113.1 — which is the external interface of the company's firewall. Behind that firewall, the actual application server sits at the private IP 10.0.0.5.
When an employee in the office opens app.example.com, their browser gets the public IP 203.0.113.1 from DNS and sends a request to it. That request hits the firewall from the inside — and many firewalls and routers cannot handle traffic that exits to a public IP and must be reflected back into the internal network. This is called NAT hairpinning or NAT loopback, and it frequently fails on consumer-grade equipment. Even when it works, the traffic takes a needless detour through the firewall instead of going directly to the internal server.
Split-horizon DNS fixes this by maintaining two separate sets of DNS answers: internal clients receive 10.0.0.5 for app.example.com, while external clients receive 203.0.113.1. Internal traffic goes directly to the application server; external traffic goes through the public IP and firewall as intended. The same domain name works correctly from both locations.
How Split-Horizon DNS Is Implemented
The core mechanism is a DNS server that inspects the source IP address of incoming queries and selects a different zone file or response set based on which network the query arrived from. Internal source addresses (typically RFC 1918 ranges like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) receive internal answers. All other source addresses receive public answers.
This can be implemented at several levels: a dedicated internal DNS server that overrides specific records, a full split-zone configuration on an authoritative server, or source-address-based routing in a sophisticated resolver. The key requirement is that internal clients must use the internal DNS server — typically enforced by DHCP delivering the internal resolver's IP as the DNS server address for all devices on the corporate network.
DNS Views in BIND
BIND (Berkeley Internet Name Domain) — the most widely deployed DNS server software — implements split-horizon through a feature called views. In named.conf, you define named view blocks that each contain their own zone definitions and apply only to queries matching a specified access control list.
A typical split-horizon BIND configuration defines an internal view matching the corporate IP ranges with a zone file that contains private IP addresses, and an external view matching any (all other sources) with a zone file containing public IP addresses. BIND evaluates views in order and serves the first matching view. Both views are authoritative for the same domain name (example.com) but contain different A records for the same hostnames.
The zone files must be maintained separately. A record in the external zone file does not automatically appear in the internal zone file. This is the central operational challenge of split-horizon DNS.
Split-Horizon DNS on Windows Server
Microsoft Windows Server DNS supports split-horizon through DNS policies, introduced in Windows Server 2016. A DNS policy can match queries based on client subnet, time of day, transport protocol, or query type, and return different responses for each match. This is more granular than BIND views and integrates with Active Directory for enterprise deployments.
For smaller Windows-based networks, the simpler approach is to run an internal DNS server that hosts a stub zone or conditional forwarder for internal domains, while external queries are forwarded to a public resolver. This does not require duplicate zone maintenance — internal records are served from the internal server, and everything else is forwarded upstream.
Split-Horizon DNS vs NAT Hairpinning vs VPN
There are three common approaches to the problem of internal clients needing to reach internal resources by public hostname. Each has different trade-offs.
NAT hairpinning (NAT loopback) configures the router to reflect packets back into the internal network when they are destined for the router's own public IP from an internal source. This requires no DNS changes but is not supported by all routers and adds latency by routing traffic through the firewall unnecessarily.
Split-horizon DNS solves the problem at the DNS layer cleanly and efficiently. Traffic goes directly between internal devices without touching the firewall. It requires maintaining separate DNS records and ensuring all internal devices use the internal resolver.
VPN with split DNS is used for remote workers. The VPN client pushes an internal DNS server address to the remote device, so internal domain queries resolve to internal IPs reachable through the VPN tunnel, while public queries go to the normal internet resolver.
Cloud Use Cases: AWS Route 53 Private Hosted Zones
Cloud providers implement split-horizon DNS as a first-class feature. AWS Route 53 Private Hosted Zones allow you to create DNS records that are only visible to EC2 instances within specified VPCs. You can have a public hosted zone for example.com with public-facing A records, and simultaneously a private hosted zone for the same domain with internal IP addresses visible only to resources inside your VPC. Route 53 automatically serves the private zone answers to queries originating from within the associated VPCs and the public zone answers to external queries.
Azure Private DNS Zones and GCP Cloud DNS private zones offer equivalent functionality. This makes split-horizon DNS standard practice in cloud architectures where applications need consistent internal addressing without exposing private endpoints to the public internet.
Zone Drift: The Key Risk
The most serious operational risk in split-horizon DNS is zone drift — the internal and external zone files diverging over time as changes are applied inconsistently. An engineer who adds a new service record to the external DNS but forgets to add it to the internal DNS leaves internal users unable to resolve the new hostname. An engineer who updates an IP in the external zone but not the internal zone sends internal traffic to the wrong server.
Mitigating zone drift requires process discipline or tooling. DNS management platforms that treat split-horizon as a single policy with internal and external views of the same record set prevent drift by design. Automated deployment pipelines that update both zones simultaneously are another common solution. Manual management of two separate zone files is error-prone and should be avoided for any zone with frequent changes.
Split-Horizon DNS vs Alternatives
| Approach | How It Works | Complexity | Client Requirements | Best For |
|---|---|---|---|---|
| Split-horizon DNS | Internal resolver returns private IPs; external resolver returns public IPs | Medium — requires separate zone maintenance | Must use internal DNS server | Office networks; cloud VPCs |
| NAT hairpinning | Router reflects internal-to-public traffic back inward | Low — router config only | None — transparent | Small networks with capable routers |
| VPN DNS push | VPN pushes internal resolver to remote clients | Low — part of VPN config | VPN client must be connected | Remote workers accessing internal resources |
Frequently Asked Questions
What problem does split-horizon DNS solve?
Split-horizon DNS primarily solves the NAT hairpinning problem. When internal devices try to reach a service using its public domain name, the request is routed to the public IP at the edge of the network. Many routers and firewalls cannot handle a packet that arrives from the internal network destined for their own external IP, causing the connection to fail. Split-horizon DNS sidesteps this by returning the internal IP address directly to internal clients, so traffic never has to leave the local network to reach internal resources.
What is NAT hairpinning and why does split DNS fix it?
NAT hairpinning (also called NAT loopback) is when a device on an internal network tries to reach an internal server using its public IP address or public domain name. The traffic goes from the internal device to the router, which must then "hairpin" it back into the internal network to reach the destination. Many consumer routers do not support this correctly, dropping the connection. Split-horizon DNS fixes it by returning the internal IP for internal clients, so the traffic never needs to leave the local network.
How do I configure split-horizon DNS on my router?
Most consumer routers do not support split-horizon DNS natively. The common approach is to run a local DNS resolver such as dnsmasq or Pi-hole on your network and configure DHCP to point all internal devices at it. In dnsmasq, you add an address directive — for example, address=/app.example.com/192.168.1.10 — to override the public DNS answer for internal clients. For enterprise environments, BIND named.conf view clauses or Windows Server DNS policies provide full split-horizon support.
What is a DNS view in BIND?
A DNS view in BIND (Berkeley Internet Name Domain) is a named configuration block in named.conf that defines a separate zone file and applies it only to queries matching specific criteria — typically source IP address ranges. You define an "internal" view matching your RFC 1918 address ranges with a zone file pointing to internal IPs, and an "external" view matching all other sources with a zone file pointing to public IPs. BIND evaluates views in order and serves the first matching view to each query.
Does split-horizon DNS work with VPNs?
Yes, and VPNs rely on a form of split-horizon DNS to function correctly for remote workers. When a VPN client connects, the VPN server pushes an internal DNS resolver address to the client. Queries for internal domains go to the internal resolver (returning internal IPs), while queries for public domains go to the normal resolver. This is called split DNS or split tunneling at the DNS layer. Without it, remote workers connected via VPN could not resolve internal hostnames like intranet.company.com.
What is the risk of split-brain DNS misconfiguration?
The primary risk of split-horizon DNS is zone drift — the internal and external zone files diverging over time as changes are made to one but not the other. A record added to the external zone but not the internal zone means internal users cannot reach the resource by hostname. A record updated in the external zone but not the internal zone means internal users connect to the wrong server. Automated synchronization processes or DNS management platforms that maintain both views simultaneously are essential to avoid these consistency problems.