Understanding Split-Horizon DNS

Split-horizon DNS (also called split-view or split-brain DNS) is the practice of returning different DNS answers for the same name depending on who's asking. It's widely used by organisations that run a mix of internal and external services, operate hybrid cloud, or have multiple sites and remote users. Done well, it improves routing, reduces edge load, and keeps internal names private, without relying on obscurity for security.

What problem does it solve?

Using a single, public DNS view for everything causes friction:

• Hairpin/NAT loopback: Internal clients resolve a public IP and bounce out to the edge to reach a service that actually lives next door.
• Inefficient routing: Internal traffic rides the internet path when a local/private path is available.
• Name exposure: Internal service names (build servers, back-office apps) appear in public DNS.
• Operational coupling: Marketing/CDN changes unintentionally affect how internal users reach services.

Split-horizon separates these concerns. Public users get public endpoints; internal clients get the shortest, most appropriate path.

How it works (conceptually)

You expose two (or more) "view" of DNS for the same domain or subdomain:

• External view: Only public-facing records (A/AAAA, CNAME, MX, TXT, etc.) that the internet should see.
• Internal view: Records that include private addresses (RFC1918/ULA), internal service names, and anything meant for corporate or trusted networks.

A resolver decides which view to use based on request attributes (typically source IP/subnet, but also interface, VPN state, or resolver policy). Most enterprise DNS servers (BIND, Unbound, Microsoft DNS, Infoblox, PowerDNS, etc.) support this pattern via views or policies. Many managed DNS platforms let you split by zone (e.g., corp.example.com internal, example.com external) even if they don't offer true policy-based split.

When you should use it

• Hybrid cloud: Same application, different endpoints (private link/VPC peering internally; public load balancer externally).
• Multi-site WAN: Return site-local service IPs to reduce cross-site traffic.
• Zero trust/VPN access: Present private addresses only to authenticated clients, public addresses otherwise.
• Service optimisation: Internal users bypass WAF/CDN for low-latency private paths while the public stays on the hardened edge.

When you should not use it

• Public/marketing domains: Keep example.com globally consistent for SEO, analytics, and cache behaviour.
• Email delivery domains: MX/SPF/DKIM/DMARC must be the same everywhere; do not split these.
• If you lack change control, two DNS views doubles the places drift can occur. If you can't keep them in sync where they should be, avoid.

Split-horizon is not a security control by itself. It can limit exposure of names and reduce attack surface mapping, but it must sit behind real controls: network segmentation, least privilege, hardened edge, identity-aware access. Treat it as an operational tool with privacy side benefits.

Design principles

• Prefer subdomain separation: Keep example.com public; host internal services under corp.example.com or internal.example.net. It clarifies intent and avoids accidental splits on mail/marketing records.
• Minimise record overlap: Only duplicate records across views when necessary (like the same hostname with different IPs). Everything else should exist in exactly one view.
• Plan for mobility: Laptops and mobiles roam between networks. Use sensible TTLs (e.g., 300–900 seconds) to reduce stale caches when moving from external to internal paths and back.
• Document the decision tree: Who sees which view and why. Include ACLs, resolver order, and fallbacks.
• Automate: Use infrastructure-as-code for both views to prevent configuration drift.

Operational gotchas

• Caching & roams: Clients can cache a public answer and keep using it internally. Shorter TTLs help; some platforms support split-DNS aware resolvers on endpoints.
• Certificates: If internal and external hostnames differ, you’ll manage multiple certs. If they’re the same, ensure the cert covers both paths and issuance is compliant (no private names in public certs).
• Monitoring & telemetry: Probe both views. External uptime checks won’t reveal an internal misroute, and vice versa.
• DNSSEC: It’s compatible, but be deliberate. Sign zones appropriately and ensure validators won’t flag differences as tampering.
• Incident response: A change that fixes the external path might break the internal one. Bake dual-view checks into change control.

Tool-agnostic example patterns

1) Split by view (same hostname, different IPs)

• app.example.com = Public view: 203.0.113.10 (WAF/LB)
• app.example.com = Internal view: 10.10.20.15 (service VIP)

2) Split by subdomain (clean separation)

• Public: www.example.com, api.example.com
• Internal: api.corp.example.com, db.corp.example.com (private IPs only)

3) Site-aware answers

• Internal view, Site A: print.office.example.com = 10.0.1.40
• Internal view, Site B: print.office.example.com = 10.0.2.40

Implementation checklist

1. Choose the boundary: Zone split (corp.example.com) or true view-based split for the same names.
2. Define access: Source subnets, VPN ranges, device posture—how a request qualifies for each view.
3. Map records: Which names exist where, and which overlap intentionally.
4. Set TTL strategy: Shorter for roaming-sensitive records; longer for stable ones.
5. Automate & validate: Lint configs, run zone/view tests, include pre-/post-change checks.
6. Monitor both planes: External RUM/Synthetic + internal probes per site/VPN.
7. Document & train: Support teams need a simple “which view am I hitting?” playbook.

Quick litmus test

If a name is used by customers, search engines, or email, don’t split it.
If a name is used by employees/services and benefits from a private, faster, or site-local path, consider split-horizon with automation, clear ownership, and guardrails.