Split-horizon DNS without running your own BIND

The office runs an internal app at app.example.com. From home it should reach the public load balancer; from the office it should go straight to 10.0.20.50 without leaving the building. One name, two answers. Every network team meets this sooner or later, and most solve it by running a DNS server they never really wanted to own.

1 When you need split-horizon DNS

Split-horizon (also called split-view or split-brain DNS) is worth it when the same name must resolve differently inside and outside:

• Internal shortcuts. Office or VPN users reach a service on its private address instead of going out to the internet and back in.
• Internal-only names. git.example.com or grafana.example.com exist only for the internal side; outside they return nothing.
• Avoiding hairpin NAT. Many routers handle "connect to my own public IP from inside" badly or not at all.
• Different targets per site. Branch offices get the nearest internal mirror, everyone else the public one.

It is not an access control. A split hides a name from the internet's view of your zone, but anyone who can query from the internal side sees it, and hostnames often leak anyway through certificate transparency logs. Authentication still belongs in the application.

2 The usual ways to do it, and what they cost

2.1 BIND views on your own servers

The textbook answer. BIND chooses a view by the client's address and serves a different copy of the zone from each:

acl office { 203.0.113.0/24; };

view "internal" {
    match-clients { office; };
    zone "example.com" { type primary; file "internal/example.com.zone"; };
};

view "external" {
    match-clients { any; };
    zone "example.com" { type primary; file "external/example.com.zone"; };
};

It works well and it is yours to run: at least two servers, patching, monitoring, DDoS exposure on the public side, and two zone files to keep consistent by hand. Secondaries need their own per-view arrangement for zone transfers, usually a separate TSIG key per view. For many teams this is the only reason they still operate authoritative DNS at all.

2.2 A second internal DNS server

The common shortcut: Active Directory DNS, Pi-hole, dnsmasq or the firewall's resolver holds a local copy of example.com with the internal addresses. The trap is that once the internal server considers itself authoritative for example.com, it answers every name in that zone from its own copy. Any public record you add later (a new MX, a verification TXT, a new subdomain) does not exist for internal users until someone copies it over. The usual symptom is "it works from home but not from the office".

2.3 Hairpin NAT instead of DNS

Skip the split and let the router send traffic for its own public IP back inside. It needs no DNS work, but it depends on the router, sends internal traffic through the firewall's NAT path, and hides the client's real address from the server. It solves reachability, not internal-only names.

2.4 Cloud private zones

The large clouds offer private zones, scoped to their own networks (checked 2 October 2026):

Both are good if everything already lives in that cloud. For an office, a branch network or a mix of on-premises and cloud, you end up building plumbing around them.

3 How source-based split-horizon works

An authoritative nameserver never sees your laptop. It sees the recursive resolver that asks on the laptop's behalf. So a split on the authoritative side is decided by the resolver's address:

Three practical consequences:

• The internal side needs its own resolver with a stable public address: the firewall, an Unbound or BIND resolver, AD DNS forwarding out, or the VPN concentrator. If laptops talk to 8.8.8.8 or 1.1.1.1 directly, the query arrives from Google's or Cloudflare's addresses and gets the public answer.
• Never put a public resolver's range in a view. Those addresses serve millions of people, and all of them would get your internal answers.
• Remote staff get the internal answer only through the VPN, when the VPN hands out the office resolver (or a resolver whose egress address is in the view).

4 Test both sides of the split

First find the public address your resolver uses when it talks to authoritative servers. Google's nameservers answer this TXT query with the address they see:

dig +short TXT o-o.myaddr.l.google.com @ns1.google.com     # your own egress address
dig +short TXT o-o.myaddr.l.google.com                     # the egress of the resolver you use

Then compare the answers through the normal resolver, straight at the authoritative server from inside, and from somewhere outside (a phone hotspot or a VPS):

dig +short app.example.com A                       # inside, through the office resolver
dig +short app.example.com A @ns1.primedns.net     # inside, straight at the authoritative server
dig +short app.example.com A @ns1.primedns.net     # same command from outside the office

If the inside answer is still public, the query is not arriving from the address you put in the view. Check the egress address again, and check that clients are not bypassing the office resolver (browsers with DNS over HTTPS turned on are a common culprit).

5 Private reverse DNS without a server

The same mechanism solves an old annoyance: PTR records for private ranges. Logs, traceroutes and monitoring are easier to read when 10.0.20.50 resolves to app.office.example.com, but reverse zones for RFC 1918 space cannot be delegated on the public internet. Resolvers answer them locally as empty by default (RFC 6303), so you tell your resolver to ask your DNS provider instead. With Unbound:

server:
    local-zone: "10.in-addr.arpa." nodefault
    domain-insecure: "10.in-addr.arpa."

stub-zone:
    name: "20.0.10.in-addr.arpa."
    stub-host: ns1.primedns.net
    stub-host: ns2.primedns.net

The provider answers those queries from the view that matches your resolver, so two customers can both use 10.0.20.0/24 without seeing each other's names.

6 How PrimeDNS handles this

Split-horizon is built into PrimeDNS, not a separate product or an add-on to domain registration. It runs on our own implementation of DNS views in the nameserver itself.

• No servers to run. No BIND, no second internal copy of the zone, no zone transfers between views.
• Works for offices and on-premises networks, not only inside one cloud's VPCs, and it is not Enterprise-only.
• A view is a named list of networks. Add the public address of your office or VPN resolver (for example 203.0.113.5/32). A network belongs to exactly one view, so answers are never ambiguous.
• Attach a view to a zone and PrimeDNS creates a variant of the zone, seeded with a copy of the current records. Edit the variant like any other zone, in the panel or through the API.
• Keep the variant in sync on your terms. A sync panel shows what changed in the public zone and lets you pull selected changes, without overwriting records you made different on purpose. This is the "internal copy nobody updates" problem, solved.
• Private reverse zones for RFC 1918, RFC 6598 (carrier-grade NAT) and RFC 4193 (IPv6 ULA) space get their view created automatically.
• Every change is in the Audit Log, including changes to variant zones, and team members can be limited to the zones they look after.

Split-horizon for regular domains is part of the Business plan; private reverse zones are available from the Professional plan. Setup steps with screenshots are in the Split-Horizon Views guide.

Information about other providers is based on their public documentation as of 2 October 2026. Product names and trademarks belong to their owners. Spotted something out of date? Write to This email address is being protected from spambots. You need JavaScript enabled to view it..