Split-Horizon DNS (Internal vs. External)

The same question—"Where is mail.company.com?"—gets a different truthful answer depending on who's asking. An employee on the corporate network receives an internal IP address. A customer across the Internet receives a public IP address. Both answers are correct. The name means two things at once.

This is split-horizon DNS. It recognizes a fundamental truth about networks: inside and outside are different worlds, and the same hostname legitimately points to different places depending on which world you're standing in.

The Problem It Solves

Imagine you host your company website on an internal server. External visitors reach it through your public IP address—their requests traverse the Internet, hit your firewall, pass through load balancers, and finally arrive at the server.

Now imagine an employee in the office visits the same website. If they use the same public IP address, something absurd happens: their traffic leaves the internal network, travels to your firewall's external interface, gets inspected and permitted, then hairpins back inside to reach a server that was twenty feet away the entire time. The packet took a tour of your security infrastructure to visit its neighbor.

Split-horizon DNS eliminates this absurdity. Internal users resolve the hostname to the server's internal address and connect directly. External users resolve to the public address and traverse the appropriate path. Same hostname, different answers, each correct for its context.

Two Views of the Same World

A split-horizon DNS server maintains two separate views of your domain—internal and external. When a query arrives, the server examines where it came from and consults the appropriate view.

The internal view might contain thousands of records: database servers, internal APIs, development environments, management interfaces, backup systems. These hostnames exist only for internal users. External queries receive no answer for them—not "access denied," just silence. The names don't exist in that view of reality.

The external view is sparse by comparison: your public website, mail servers, maybe a partner API. Only what the outside world needs to reach.

This separation does more than optimize routing. It reduces your attack surface. An attacker performing DNS reconnaissance against your domain sees only your public-facing services. The internal database servers, the admin portals, the development environments—none of these appear. They exist in a view the attacker cannot access.

The Same Name, Different Services

Sometimes internal and external users need the same hostname to reach genuinely different services.

Consider api.company.com. External partners hit this endpoint for your public API—rate-limited, carefully scoped, production-hardened. Internal developers need the same hostname to reach an internal API with expanded permissions, detailed debugging output, and access to pre-release features.

Without split-horizon DNS, you'd need different hostnames: api.company.com for external, api-internal.company.com for internal. Developers must remember which to use. Documentation diverges. Someone inevitably hardcodes the wrong one.

With split-horizon DNS, both groups use api.company.com. The DNS infrastructure handles the routing based on who's asking. Simplicity preserved, separation maintained.

Implementation Approaches

BIND, the most widely deployed DNS server, implements this through named views. You define an internal view matching your private IP ranges and an external view matching everything else. Each view contains its own zone files with different records for the same domain names.

view "internal" {
    match-clients { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
    zone "company.com" { file "company.com.internal"; };
};

view "external" {
    match-clients { any; };
    zone "company.com" { file "company.com.external"; };
};

Cloud DNS providers offer similar functionality through private zones that respond only to queries from configured networks, while public zones handle Internet queries.

Some organizations run entirely separate DNS infrastructures: internal DNS servers that only answer internal queries, external DNS servers (often hosted by a provider) that handle the public Internet. More infrastructure to maintain, but stronger isolation.

Where It Goes Wrong

The most common failure: query source misclassification. Your internal network routes DNS queries through a NAT gateway or proxy. The DNS server sees the gateway's IP address, not the original client's. If that gateway IP isn't in your internal view's match list, internal users receive external answers.

The fix is ensuring your view definitions account for all the IP addresses your DNS server actually sees as query sources—including gateways, proxies, and infrastructure addresses.

Another frequent problem: internal users configured to use external DNS resolvers. If an employee's laptop uses 8.8.8.8 instead of your internal DNS servers, they'll receive external answers even while sitting in the office. Split-horizon only works when queries reach your split-horizon DNS infrastructure.

VPN users create a special case. When employees connect remotely, their DNS queries should receive internal answers—but only if the VPN properly pushes internal DNS servers to connected clients and routes DNS traffic through the tunnel. Misconfigured VPNs that let DNS queries leak to local resolvers break the split-horizon model.

What It Doesn't Do

Split-horizon DNS is information hiding, not access control. The fact that an attacker can't discover your internal hostnames through DNS doesn't prevent them from accessing those systems if they gain network access through other means. An attacker inside your network can query your internal DNS view just like any other internal user.

Proper security still requires network segmentation, firewalls, authentication, and authorization. Split-horizon DNS complements these controls by reducing reconnaissance opportunities, but it doesn't replace them.

DNS rebinding attacks also bypass split-horizon protections. An attacker's malicious website can initially resolve to an external IP (passing browser security checks), then quickly change to resolve to an internal IP address. The attack exploits browser behavior, not DNS infrastructure. Defense requires browser protections and internal firewall rules, not DNS configuration.

The Deeper Pattern

Split-horizon DNS reflects something true about how organizations work: inside and outside really are different. Different trust levels, different access patterns, different needs. The same resource—whether it's a website, an API, or a mail server—legitimately presents different faces to different audiences.

Rather than forcing this reality into a single flat namespace where everything is either internal or external, split-horizon DNS embraces it. The same name can mean different things to different people, and both meanings are correct.

This isn't a hack or a workaround. It's an acknowledgment that context matters—even at the level of DNS resolution.