Split-Horizon DNS Guide: Views, Leaks and Safe Design

Split-horizon DNS gives internal and external clients different answers for the same name, and most of its security failures come from those two views drifting apart or leaking into each other. Almost every organisation runs some form of it: an internal Active Directory zone, a cloud private hosted zone that shadows the public domain, or a VPN that sends only corporate names to the corporate resolver. Done well, it keeps internal addresses and hostnames off the internet. Done badly, it publishes internal names in the public view, breaks DNSSEC validation, or silently sends internal lookups to a public resolver. This guide covers how split-horizon DNS works on the main platforms, where it leaks, how encrypted DNS changes the picture, and a safe design and rollout. It is for network, DNS and cloud platform teams.

Key takeaways

Split-horizon is a configuration pattern, not a standard. RFC 9499 (DNS Terminology, BCP 219) notes that "split DNS" and "split-horizon DNS" have long been used without formal definition, and that views are not a standardised part of the DNS even though they are widely implemented.
Treat it as an exposure-reduction control, not access control. Hiding a name does not protect the service behind it; anything reachable must still be authenticated and filtered.
Most leaks are human. Internal records copied into the public zone, public certificates for internal names and clients that bypass the internal resolver expose more than any protocol weakness.
Cloud private zones do not fall back. Amazon Route 53 returns NXDOMAIN for a name missing from a matching private hosted zone rather than asking the public zone, so every needed record must exist in the private view.
Encrypted DNS now has a split-horizon answer. RFC 9704 (Standards Track, January 2025) lets a domain owner authorise a local encrypted resolver for internal subdomains, so clients can trust split answers without sending everything to one resolver.

What split-horizon DNS is and why organisations use it

A DNS server or set of servers answers the same query differently depending on who is asking. RFC 9499 describes a view as a server configuration that provides different responses depending on attributes of the query, such as the source address. The terms split DNS, split-horizon and split-brain DNS are used interchangeably in practice.

Pattern	How it works	Typical use	Main risk
Same zone name, two views	One name (for example example.com) is served from an internal copy to internal clients and a public copy to everyone else	Internal clients reach a service on a private address, the internet reaches the public address	The two copies drift; internal records end up in the public copy
Separate internal subdomain	Internal names live under a child zone such as corp.example.com that exists only on internal resolvers	Active Directory, internal applications	Clients using a public resolver cannot resolve it and fail open to public lookups
Private-use top-level name	Names under a TLD that will never be delegated, such as .internal	Lab, home and isolated networks	Names cannot get publicly trusted certificates; collisions if an undelegated-looking name is later delegated
Cloud private zone shadowing a public zone	A private hosted zone with the same name as the public zone, attached to specific virtual networks	Private endpoints for cloud services and internal load balancers	Missing records return NXDOMAIN; forwarding rules can override the private zone
Client-side split (VPN or ZTNA)	The client sends queries for listed domains to the corporate resolver and everything else elsewhere	Remote workers on split-tunnel VPN or ZTNA	Domains missing from the list leak to the local or public resolver

On naming, RFC 6761 (Special-Use Domain Names) reserves .test, .example, .invalid and .localhost and tells caching servers how to treat them, and on 29 July 2024 the ICANN Board resolved to reserve .INTERNAL from delegation in the DNS root zone permanently to support private use. Avoid invented suffixes such as .corp or .lan, which have no such reservation, and avoid .local, which Microsoft's Azure Private DNS documentation advises against because not all operating systems support it. For many organisations a subdomain of a registered domain is the better choice because it can carry publicly trusted certificates and RFC 9704 authorisation.

How the main platforms implement split views

BIND views

Selection: each view block uses match-clients (source address or TSIG key) and match-destinations (the server address the query arrived on). ISC's knowledge base article on views describes these as the multiplexer in front of the views. Views are evaluated in the order they appear and the first match wins, so put the narrow internal view first.
Independence: ISC notes that each view holds its own copy of zone data and, by default, its own cache. Zones shared between views need the in-view option (BIND 9.10.0 and later).
Transfers between views: ISC recommends a TSIG key per view so that a secondary's internal view transfers from the primary's internal view, using the key in also-notify, masters and allow-transfer, and notify explicit so unsigned NOTIFY messages do not reach the wrong view.

See the BIND DNS Server Hardening for the wider BIND configuration.

Windows Server DNS policies

Zone scopes: from Windows Server 2016, one server can hold both versions of a zone. The default zone scope serves external clients; Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal" creates the internal copy, and records are added to it with Add-DnsServerResourceRecord ... -ZoneScope "internal".
Policies: Add-DnsServerQueryResolutionPolicy maps criteria such as -ServerInterface (the interface that received the query) or client subnet to the internal zone scope.
Selective recursion: Microsoft's split-brain article shows disabling recursion on the default recursion scope (Set-DnsServerRecursionScope -Name . -EnableRecursion $False) and creating a recursion scope for internal clients only, so a server that is authoritative for the internet does not become an open resolver.

See the Windows Server DNS and DHCP Security Guide.

Cloud private zones

Amazon Route 53: a public and a private hosted zone can share a name; the private zone answers queries from associated VPCs. If the private zone matches the name but has no record of the requested name and type, the VPC Resolver returns NXDOMAIN and does not forward to a public resolver. The most specific matching zone wins, and if a Resolver forwarding rule and a private zone for the same name are associated with the same VPC, the Resolver rule takes precedence. The VPC needs enableDnsHostnames and enableDnsSupport set to true.
Azure Private DNS: private and public zones can share a name for a split-horizon view. A virtual network must be linked to a private zone to resolve it, and linked networks have full access to all records in that zone. Auto-registration adds A records for virtual machines in a linked network; one virtual network can link to only one zone with auto-registration enabled.

Cross-network resolution between cloud and on-premises sites is covered in the Cloud Private Connectivity Guide.

Leak paths: how internal information escapes

Leak path	What is exposed	How to prevent or find it
Internal records added to the public view by mistake	Private addresses, internal hostnames, naming conventions that help reconnaissance	Separate change approval per view; automated diff of the public zone against an allowlist of public names
Public certificates for internal names	Every name on a publicly trusted certificate appears in Certificate Transparency logs	Use an internal CA for internal-only names, or accept and review that the name will be public
Zone transfer from the wrong view	The full internal zone	Restrict `allow-transfer` per view to TSIG-authenticated secondaries; test AXFR from outside
Clients using a public resolver (browser DoH, hard-coded resolvers, personal settings)	Internal query names sent to a third party; internal services fail or resolve to public addresses	Managed DoH policy, block known public resolvers, monitor port 53 and 853 egress
Split-tunnel VPN or ZTNA domain lists that miss a domain	Internal names queried on hotel or home networks; possible spoofed answers	Keep the client domain list generated from the internal zone list, not hand maintained
Suffix search lists and short names	Queries for single-label names appended to public suffixes or resolved by LLMNR and NBT-NS	Use fully qualified names, keep search lists short, disable LLMNR and NBT-NS
Forwarders and resolver logs held by third parties	Every internal query name	Do not forward internal zones to external resolvers; review provider logging terms

Attackers collect DNS information as reconnaissance (MITRE ATT&CK T1590.002, Gather Victim Network Information: DNS), so internal names that leak into public view or passive DNS datasets have lasting value to them. See the Passive DNS and DNS History Guide for how historical DNS data persists, and the LLMNR and NBT-NS Poisoning guide for the fallback name resolution risk.

DNSSEC and split-horizon

Validation failures: if the public zone is signed and the internal view of the same zone serves unsigned or differently signed records, validating resolvers inside the network will reject internal answers as bogus. Either sign the internal view as well, keep internal names in a separate child zone that is not delegated publicly, or configure the internal validating resolver with the internal zone as a local authority.
Delegation across the boundary: RFC 9704 includes a way for a local resolver to sign internal zones without holding keys valid for the parent zone, using DNSSEC delegation across split-DNS boundaries.
Do not turn validation off to make split DNS work. Fix the zone design instead; validation protects internal clients against cache poisoning too.

See the DNSSEC Deployment Guide.

Encrypted DNS and RFC 9704

Split-horizon only works if internal clients ask the internal resolver. Browser and operating system DNS over HTTPS can send queries to a public resolver that has never heard of the internal names. The Encrypted DNS Enterprise Guide covers the policy settings that keep managed clients on the enterprise resolver.

RFC 9704, Establishing Local DNS Authority in Validated Split-Horizon Environments (Standards Track, January 2025), adds a standard way for a client to trust a local resolver for specific internal names:

The network advertises claims. It offers encrypted resolvers through DNR or DDR and sends authorisation claims through DHCP or a Provisioning Domain (PvD) splitDnsClaims entry, naming the resolver, the parent zone and the claimed subdomains.
The domain owner approves. The parent zone operator publishes a verification token in a TXT record under _splitdns-challenge.
The client validates. The client checks the token through a trusted external encrypted resolver or local DNSSEC validation, and only then treats the local resolver as authoritative for those subdomains.

The RFC's security considerations note that resolver names appear in public verification records, so they should not reveal sensitive information; that salts must be random and regenerated when a claim changes; that the mechanism covers only a domain owner's own split views and does not enable filtering by others; and that special-use names such as home.arpa. and local. must not be validated with it. It also suggests placing internal names under a child zone so that other names can still use an external resolver. Client support is still emerging, so check your operating systems before relying on it.

Choosing a design

Situation	Recommended approach	Why
Small organisation, few internal services	Internal child zone (corp.example.com) on the internal resolver, public zone untouched	One source of truth per zone; no duplicated records to drift
Same service reachable inside and outside on different addresses	Same-name split with a documented list of names that exist in both views	Users keep one URL; the duplicated list is small enough to diff
Large cloud estate with private endpoints	Cloud private zones per service domain, central resolver endpoints, conditional forwarding from on-premises	Matches how cloud private endpoints resolve; avoids NXDOMAIN surprises
Remote workforce on ZTNA or split-tunnel VPN	Client domain list generated from the zone inventory, plus managed DoH to the enterprise resolver	Prevents leaks for names missing from hand-made lists
Isolated lab or OT network	.internal or a dedicated child zone with no public delegation	No dependence on the public DNS; reserved name avoids collisions

Hiding names is not a substitute for network controls. Services that should be internal must also be unreachable or authenticated from outside, as the ZTNA Guide describes. If a public record points to a decommissioned internal-to-public resource, the Subdomain Takeover and Dangling DNS Guide applies.

How to implement or clean up split-horizon DNS

Inventory every view. List each zone, which servers or cloud zones serve it, which clients see which copy, and which forwarding rules apply. Include cloud private zones and VPN client domain lists.
Classify names. Mark each record as public, internal or both. Names marked both need an owner and a reason.
Diff the views. Export the public zone and confirm it contains no private addresses (RFC 1918 ranges, unique local IPv6) and no names on the internal-only list. Run this diff in the change pipeline, not once.
Lock down transfers and recursion. Restrict zone transfers per view to TSIG-authenticated secondaries and make sure the externally facing server does not recurse for internet clients.
Pilot client changes. Change VPN, ZTNA or DoH policies for a pilot ring first, watch resolution failures and helpdesk tickets for a week, then widen. Keep the previous client profile ready to redeploy as the rollback.
Fix DNSSEC interactions. Before signing a public zone that has an internal view, test validation from internal resolvers against the internal copy.
Automate record sync. Generate both views from one source (infrastructure as code or IPAM) so a name that exists in both is changed in both.
Retire unused internal-public duplicates. Each removal reduces drift. Remove from the public view first, confirm no external dependency, then remove internally.

Detection and measurement

Public zone content checks: alert on any public record that resolves to a private address range or matches the internal-only name list.
Egress DNS monitoring: log and alert on internal clients sending DNS to anything other than the enterprise resolvers on TCP and UDP 53, TCP 853 and known DoH endpoints. See the DNS Logging and Detection Guide.
Internal-name queries at the edge: queries for internal suffixes arriving at the public authoritative servers mean clients are resolving internal names through public paths.
Transfer attempts: log refused AXFR and IXFR requests per view.
Certificate Transparency: monitor CT logs for certificates naming internal-only hosts.

Metrics that show the design is working:

Number of public records pointing to private addresses (target zero).
Percentage of managed endpoints whose DNS traffic goes only to enterprise resolvers.
Count of internal-suffix queries seen at public authoritative servers per week (falling trend).
Number of names maintained in both views, and percentage generated from a single source.
Time between an internal zone change and the VPN or ZTNA domain list update.

Common failure patterns

Copying the internal zone file to the public server during a migration or outage, publishing the full internal namespace.
Hand-maintained VPN domain lists that lag the zone inventory, so new internal services are resolved through the user's home or hotel resolver.
Assuming cloud private zones fall back to public DNS. A private hosted zone that shadows the public domain but lacks a record breaks access to that public name for every attached VPC.
Forwarding rules that silently override private zones, so cloud workloads resolve on-premises answers instead of private endpoint addresses.
Turning off DNSSEC validation internally to make a split view of a signed zone work, removing protection against cache poisoning.
Using invented suffixes such as .corp, which cannot get public certificates and leak to the public root when clients use outside resolvers.

Framework mapping

Framework	Reference	How split-horizon DNS relates
NIST SP 800-53 Rev. 5	SC-20, SC-21, SC-22	Secure authoritative and recursive name resolution, and the architecture and provisioning of name services, including separation of internal and external roles
NIST SP 800-53 Rev. 5	SC-7, CM-6, SI-4	Boundary protection for resolver traffic, configuration settings for views and policies, monitoring of DNS egress
NIST CSF 2.0	PR.PS-01, DE.CM-01	Configuration management of views and policies; monitoring of networks and network services, including DNS
CIS Controls v8.1	Control 4 and Control 12	Secure configuration of network infrastructure and managed network services
ISO/IEC 27001:2022 Annex A	A.8.20, A.8.21, A.8.22	Network security, security of network services and segregation of networks
MITRE ATT&CK	T1590.002, T1071.004	DNS reconnaissance against leaked names; DNS used as a command-and-control channel, which egress controls also limit

For the full NIST DNS deployment guidance see the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.

Practitioner checklist

NHI Mgmt Group recommends the following checks.

Document every split view, cloud private zone, forwarding rule and client domain list in one inventory.
Classify each record as public, internal or both, with an owner for every name in both views.
Run an automated check that the public view contains no private addresses or internal-only names.
Restrict zone transfers per view to TSIG-authenticated secondaries and test AXFR from outside.
Stop externally facing authoritative servers from recursing for internet clients.
Generate VPN and ZTNA split DNS lists from the zone inventory.
Set managed DoH policy so clients use the enterprise resolver, and monitor DNS egress.
Test DNSSEC validation from internal resolvers before signing a zone that has an internal view.
Prefer a registered subdomain or .internal for internal names over invented suffixes.
Track RFC 9704 client support and plan internal names under a child zone to use it.

Split-Horizon DNS Guide: Internal and External Views, Leak Paths and Safe Design