Split-Horizon DNS: When the Same Domain Resolves Differently Depending on Who's Asking

Every article on this blog so far has assumed a domain has one answer for a given record, the same answer no matter who's asking or where they're asking from. Split-horizon DNS is the deliberate exception: the same hostname resolves differently depending on whether the query came from inside a particular network or from the public internet.

What split-horizon DNS actually is

A split-horizon (also called split-view or split-brain) setup maintains two versions of the same zone. An external view, the one the rest of the internet queries, answers with public-facing records. An internal view, only reachable from inside a specific network, answers the exact same hostnames with different records entirely, often private IP addresses that aren't routable from outside that network at all.

Public resolver queries app.example.com  ->  203.0.113.50 (public load balancer)
Internal resolver queries app.example.com ->  10.20.30.40 (private internal address)

Both are legitimate, current answers. Which one a client gets depends entirely on which resolver they asked, not on anything being stale or wrong.

How it's actually implemented

There isn't one standard mechanism. Some setups run genuinely separate authoritative nameservers, an internal one reachable only from inside the corporate network or VPN, and an external one that's the domain's real, publicly delegated authority. Others use a single nameserver product with a built-in views feature, matching the query's source network or the resolver that sent it and serving a different, pre-configured zone file depending on the match. Either approach produces the same effect from a client's perspective: ask from inside, get one answer; ask from outside, get another.

Why domains actually do this

Internal-only tools with a friendly name. A company might run wiki.example.com or grafana.example.com for internal use, reachable only from the office network or VPN, without wanting to expose that hostname's real internal address to the public internet, or in some cases without wanting the hostname to resolve to anything at all for an outside query.

Avoiding disclosure of internal topology. A public DNS zone is queryable by anyone, and every record in it is effectively public information. A company that doesn't want its internal server naming conventions, subnet ranges, or the sheer number of internal services it runs visible to an outside party has a real reason to keep that data out of the public zone entirely, rather than publishing it and relying on a firewall alone to keep it inaccessible.

Giving internal clients a shorter path. An internal resolver can point a hostname directly at a private, same-network address instead of routing internal traffic out to a public IP and back in through a load balancer or NAT, which is faster and doesn't depend on internet connectivity working at all for two machines on the same network to reach each other.

The operational cost

Split-horizon setups mean keeping two zones in sync deliberately, or accepting that they'll diverge for the records that are genuinely meant to differ. A record that's supposed to be identical on both sides but gets updated on only one is a specific, easy-to-miss failure mode: everything looks correct from whichever side you happen to check, and the discrepancy only surfaces when someone compares the two directly or when a client on one side reports something a client on the other side can't reproduce.

What this means for external monitoring

This is the important scoping note. A monitoring tool that queries public, authoritative nameservers, which is how DNS monitoring generally works, only ever sees the external view of a split-horizon domain. It has no way to see, and no way to check, whatever the internal view is serving, since that internal view is by design unreachable from outside the network it's scoped to. External monitoring is the right tool for the external half of a split-horizon setup, and structurally can't be the tool for the internal half, no matter how it's configured.

Checking which view you're getting

dig A app.example.com @8.8.8.8

Querying a public resolver like this always gets the external view, since a public resolver has no path to whatever internal nameserver serves the private answer. Getting the internal view requires querying from inside the network in question, against whichever resolver that network actually uses. OneDollarDNS's DNS resolver comparison tool is useful for confirming the external view is consistent across public resolvers, though it can't see the internal one for the same reason.

How DNS monitoring fits in

OneDollarDNS monitors what your domain's public, authoritative nameservers serve, the external view of a split-horizon setup. That's the half of the picture visible to the outside world, the half that affects public-facing traffic, certificate issuance, and email delivery. The internal view, by design, sits outside what any external monitoring tool can observe at all, and needs its own internal tooling if it needs monitoring too.