Support Library
Split-Brain DNS / Split Horizon
Split-horizon DNS answers differently inside and outside your network. How it is built, what goes wrong, and how to compare the views.
The short answer
Split-horizon DNS (often called split-brain) gives different answers for the same name depending on who asks. Clients on the internal network get internal addresses or internal-only names; everyone else gets the public view. It is common for intranets, VPNs and Active Directory domains that share a name with the public website. It works well when it is deliberate and documented, and causes confusing failures when the two views drift apart or a client ends up asking the wrong one.
How it is built
| Method | How it works |
|---|---|
| Views on one server | BIND views, Windows DNS policies or similar match the client's source address and serve a different copy of the zone |
| Separate internal servers | Internal resolvers host their own copy of the zone; public authoritative servers host the public one |
| Local overrides on the resolver | Unbound local-data, RPZ or a forwarder rule answers a few internal names and passes everything else through |
| Cloud private zones | A private hosted zone attached to a VPC answers names inside that network only |
| VPN split DNS | The VPN client sends queries for chosen domains to internal resolvers and the rest to the normal resolver |
What goes wrong
- The views drift. A record added publicly is missing internally, so a new service works from home and fails in the office, or the reverse.
- A full internal copy shadows the public zone. If the internal server hosts the whole zone, every public record must be duplicated there.
- The wrong resolver answers. Devices using DoH in the browser, a hard-coded public resolver, or a VPN that is disconnected get the public view.
- Caches mix views. A forwarder or laptop cache that saw the internal answer keeps it after the user leaves the network.
- DNSSEC. If the public zone is signed, internal answers for the same names are not signed with the public keys. Validating internal resolvers must be configured to treat the internal zone as authoritative, or validation fails.
- Leaks. Internal names or private addresses published in the public view reveal your network layout. See NAT and private IP ranges.
Comparing the views
| Command | View |
|---|---|
| dig @10.0.0.53 app.example.com A | Internal resolver |
| dig @1.1.1.1 app.example.com A | Public resolver |
| dig +norecurse @ns1.example.net app.example.com A | Public authoritative server |
| Resolve-DnsName app.example.com | What a Windows application actually gets, including NRPT and VPN rules |
Many organisations avoid the problem entirely by using a separate internal subdomain, such as corp.example.com, delegated only internally, or a reserved name under .internal, which ICANN set aside for private use in 2024.
How DNS Panopticon helps
Domain Visualizer sees only the public view, through a public resolver, so it is a quick way to check what outsiders get. Its record list shows the A and AAAA addresses it found, so an internal record that leaked into the public zone, such as one pointing at a 10.x or 192.168.x address, is easy to spot. It refuses names under internal-use TLDs such as .internal and .local.