Split-horizon DNS returns different answers for the same domain depending on where the query originates — commonly used to serve internal, private IPs to internal clients while external clients receive the public IP.
What Problem This Solves
If you have internal services that should use a private IP when accessed from within your own network (faster, more secure, avoiding unnecessary traversal out to the public internet and back), but the same domain also needs a public IP for external access, split-horizon DNS serves the appropriate answer based on query source.
Common Use Case Example
Internal clients querying app.yourdomain.com → 10.0.0.5 (private IP)
External clients querying app.yourdomain.com → 203.0.113.10 (public IP)Prerequisites
- Self-hosted DNS server (BIND is commonly used for this specific feature)
- Distinguishable internal vs external network segments
Step 1 — Define Two Views in BIND
view "internal" {
match-clients { 10.0.0.0/8; 192.168.0.0/16; };
zone "yourdomain.com" {
type master;
file "/etc/bind/zones/internal.yourdomain.com.zone";
};
};
view "external" {
match-clients { any; };
zone "yourdomain.com" {
type master;
file "/etc/bind/zones/external.yourdomain.com.zone";
};
};Views are evaluated in order — the internal view (matching specific private IP ranges) must come before the catch-all external view.
Step 2 — Create the Internal Zone File
app IN A 10.0.0.5Step 3 — Create the External Zone File
app IN A 203.0.113.10Step 4 — Restart BIND
sudo systemctl restart bind9Step 5 — Test from Both Perspectives
# From an internal client
dig app.yourdomain.com
# From an external client
dig app.yourdomain.comVerify each returns the appropriate IP for its network location.
Alternative Approach: Separate Internal DNS Server
Rather than split-horizon views on one server, some organizations simply run a completely separate internal-only DNS server (used only by internal clients via their network configuration) alongside standard public DNS — simpler in some ways, though requires managing two entirely separate DNS infrastructures.
When Split-Horizon DNS Is Worth the Complexity
- You have genuinely sensitive internal services that shouldn't be reachable via their internal address from outside
- You want internal traffic to stay on your private network rather than routing out and back through the public internet
- You're running a reasonably sophisticated internal infrastructure already
Common Errors
Internal clients get the external (public) IP instead of internal — verify the match-clients ACL correctly matches your actual internal network's IP range, and that the internal view is defined before the external catch-all view.
Continue Reading
- How to Set Up a Secondary/Slave DNS Server
- Understanding NAT and How It Affects Your VPS
- How to Set Up a Private Network Between Multiple VPS Instances
Browse more articles in Networking & DNS.
