What is split-horizon DNS, and what problems appear when authoritative servers give internal and external clients different views of the same names?

## What split-horizon means **Split-horizon DNS** (also called **split DNS**) is an authoritative setup where the same names get different answers depending on who asks. RFC 9499 describes it as authoritative servers that "provide partly or completely different answers in those domains depending on the source of the query", with the consequence that "a domain name that is notionally globally unique has different meanings for different network users". The usual mechanism is a **view**: a server configuration that selects which version of a zone to answer from. RFC 9499 says views typically differ by the source address of the query, but can also key on the destination address, the query type (for example, `AXFR`) or whether the query is recursive, and adds that views "are not a standardized part of the DNS, but they are widely implemented in server software". Nothing on the wire tells a client which view it got. Typical reasons to split: - internal clients should reach private addresses while outsiders reach public ones; - some names should exist only inside the network; - the organisation prefers not to publish its internal inventory. ## Who the server actually sees The central trap: an authoritative server almost never sees the end user. It sees the **recursive resolver** that forwards the user's question. The view is chosen by that resolver's address. | Client situation | Resolver it uses | View it gets | |---|---|---| | office desktop | internal resolver | internal | | laptop at home, no VPN | home or ISP resolver | external | | laptop on VPN that kept its home resolver | home or ISP resolver | external, although the user is "inside" | | internal resolver forwarding to an outside service | the outside service | external | So "inside" in a split-horizon design means "using a resolver whose address the internal view trusts", which is not the same as being on the network. Extensions that carry part of the client's address to the authoritative server exist, but they are optional and belong to answer-steering material, not to split-horizon's basic mechanism. ## The operational costs 1. **Two versions to keep consistent.** A record that must be identical in both views is now edited twice. Each view is effectively its own zone with its own serial; drift shows up as "works inside, broken outside". 2. **Replication per view.** Secondaries must receive the right version of each view. Since views can key on the query type or on the requester, transfers need to be scoped so a secondary serving the external view never receives the internal one. 3. **Mixed caches.** A resolver that serves both populations, or forwards on their behalf, caches whichever view answered first and hands it to everyone until it expires. 4. **Leaks.** An internal name accidentally added to the external view is published to the world; an externally reachable resolver that is allowed to query the internal view hands internal answers to anyone. 5. **Debugging confusion.** The same query from two places returns two correct-looking answers. Every investigation starts with "which resolver, and which view?". 6. **Signing complications.** If the zone is DNSSEC-signed, each view's data must be signed consistently; the signing itself is DNSSEC material. ## Security expectations Split-horizon hides names from casual lookup; it is not an access control. Anyone who can use an internal resolver sees the internal view, and names leak through logs, certificates and configuration files. Services that must be private need network or application-level controls regardless of what DNS returns. ## Alternatives and when to prefer them - **An internal-only subdomain.** Put internal names under, say, `corp.example.com`, served only by internal authoritative servers, and do not delegate it from the public `example.com` zone. Outsiders get a nonexistent name; insiders' resolvers are configured to reach the internal servers. No name has two meanings. - **The same answer everywhere.** Publish public addresses for public services and rely on routing for internal clients, accepting a hairpin path. - **Split only where necessary.** Keep most of the zone identical in both views and diverge on a documented, small set of names. Split-horizon is sometimes the pragmatic choice, for example when a service must be reached by one name from both sides at different addresses. The judgement is to keep the divergent set small, to own the resolver configuration that decides who is "inside", and to document which view each population gets.