A developer calls from home: "API responds in 20 ms at the office, 800 ms outside." You run dig api.example.com on the laptop: public load balancer IP. On VPN, they get an internal pod IP not routed from the Internet. The ticket escalates when prod deploys a cert valid only on the internal name.
Split-horizon serves two legitimate DNS truths by query origin. Wired wrong, it becomes confusion: private IP leaks, inconsistent TLS certs, lying resolver caches.
Principle: one question, several answers
Split-horizon (split DNS) returns different records by source network: office/VPN vs Internet. db.example.com may point to 10.0.1.50 for admins and 203.0.113.10 for the public.
That is normal and often desirable to cut internal latency and avoid exposing admin services. It is not malicious DNS lying: it is a visibility policy.
Where production breaks
| Symptom | Frequent cause |
|---|---|
| Public site unreachable internally | Missing hairpin NAT, bad split |
| RFC1918 IP in VirusTotal | Internal zone served publicly by mistake |
| Missing SAN cert | Internal name used on public front |
| Slow resolution | Internal/external forwarder loop |
Worst case: internal record synced to public DNS by an unreviewed cron script.
Deployment models
Two zones: corp.internal (undelegated) + example.com (public). Clear for teams.
BIND views / Unbound policies: one engine, subnet ACLs. Requires config discipline.
Cloud DNS + Private Link: Route 53 Resolver, Azure Private DNS — boundary becomes network + IAM.
Choose based on who operates DNS and how many sites you run.
Sync and governance
Shared records (MX, SPF TXT, DKIM) must stay identical on both sides unless documented. Automate replication of common parts; isolate internal overrides in dedicated files or labels.
Every change must answer: "Who sees what?" and "Which resolver is used when VPN drops?"
Tests before every change
From Internet: dig +trace, DNSSEC if active, compare with a public resolver.
From VPN: same queries, verify IP and TTL.
From guest network: ensure no internal forwarder is reachable.
Log zone diffs like application code.
Living documentation
Table: FQDN | internal view | external view | owner | last verified.
Review on each internal service onboarding.
Quarterly same laptop test VPN off + on.
Split horizon and TLS
Internal names need internal CA or public cert SAN covering internal DNS — cert mismatch breaks tools even if DNS resolves.
Certificate renewal automation must update both views if names differ.
Document which hostnames appear in browser bar for staff vs customers — confusion drives misconfigured fixes.
Split DNS during hybrid cloud: on-prem AD DNS conditional forwarders to cloud private zone — loop if misconfigured.
Document resolver order on laptops: corporate VPN DNS first, public fallback second — split brain laptop debugging classic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.
Split-horizon documentation
FQDN internal/external/owner/verified table. Quarterly laptop VPN test. Internal TLS renewal covers both views.
Public cloud leak
Automate diff internal vs public zone in CI — internal IP in public zone fails pipeline.
Decide and move forward without blind spots
- List every FQDN with internal answer, external answer, business owner, and last verified date.
- Separate zones — BIND views, Route 53 split policies, or dedicated internal DNS; avoid one zone file that is « almost the same ».
- Test from a laptop — VPN on and off against the same critical URLs (API, git, monitoring).
- Restrict AXFR transfers — alert on SOA serial drift between views or if a public secondary leaks an internal IP.
- Document onboarding runbook — every new internal service adds a table row before production.
To size internal vs managed DNS hosting, browse our directory, comparison tool, and network guides.
Frequently asked questions
Can split-horizon mix with public DNS?
Yes, but only external views should be publicly delegated. Internal names must never appear in Internet-served zones without filtering.
Two separate zones or one server with views?
Separate zones (internal.example / example.com) simplify governance. BIND views work if ACL policy is strict and audited.
What when VPN fails?
Plan a backup resolver, temporary external failover records, and a runbook that does not require internal access to restore public service.
How to stop laptops off VPN resolving internally?
Do not expose internal forwarders on untrusted networks; use non-delegated internal suffixes and explicit split-tunnel policies.
Before adding an internal view, write: "An engineer without VPN must be able to…" — if the ending is "…nothing", you have a single point of failure.