Split-Horizon DNS: Same Name, Different Answer Inside and Out

Split-horizon DNS, also called split-view DNS, is a security and operational pattern where the same fully qualified domain name (FQDN) returns different DNS records depending on whether the query originates from inside or outside your network. This technique separates internal infrastructure from public-facing services, protecting sensitive systems while maintaining usable DNS names across both contexts.

Why Split-Horizon DNS Matters

In many organizations, internal servers and services share names with public endpoints. For example, mail.example.com might resolve to a public-facing mail gateway when queried from the internet, but to an internal Exchange server when queried from inside the corporate network. Without split-horizon DNS, you would either expose internal IP addresses to the public internet or force internal users to use different hostnames than external clients—both poor practices.

Split-horizon DNS solves this by using DNS views or zones that respond based on the source of the query. This approach reduces attack surface, simplifies naming conventions, and allows internal and external services to coexist under the same domain.

How Split-Horizon DNS Works

Most DNS servers that support split-horizon functionality use Access Control Lists (ACLs) or views to determine which zone data to return. When a query arrives, the server checks the source IP address against defined ACLs. If the query comes from a trusted internal network, the server responds with the internal view. If it comes from an external source, the server responds with the public view.

BIND (Berkeley Internet Name Domain), Microsoft DNS Server, and other enterprise-grade DNS platforms all support this pattern. The implementation varies slightly, but the principle remains consistent: one name, multiple answers.

Practical Configuration Example

Here is a simplified example using BIND DNS syntax:

acl "internal" {
  10.0.0.0/8;
  172.16.0.0/12;
  192.168.0.0/16;
};

view "internal" {
  match-clients { internal; };
  zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.internal";
  };
};

view "external" {
  match-clients { any; };
  zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.external";
  };
};

In this configuration, queries from addresses in the internal ACL match the internal view and receive records from example.com.internal. All other queries match the external view and receive records from example.com.external. The two zone files can contain completely different records for the same names.

Common Use Cases

• →Mail servers: external MX records point to a gateway; internal records point to the actual mail server
• →Web services: external A records resolve to a load balancer or CDN; internal records resolve to internal application servers
• →VPN and remote access: internal users reach services via private IPs; external users reach them via public endpoints
• →Database servers: internal records expose database hostnames to application servers; external view does not list them at all
• →API endpoints: internal API endpoints on private subnets are invisible to external queries

Best Practices

• →Define ACLs carefully and test them thoroughly before deployment
• →Keep internal and external zone files synchronized for common records to avoid confusion
• →Document which records differ between views and why
• →Monitor split-horizon DNS logs for unexpected query patterns
• →Use conditional forwarding in addition to split views for hybrid environments
• →Ensure internal DNS servers are not directly accessible from the internet

Split-horizon DNS is not a replacement for firewalls or network segmentation, but it is a valuable layer of defense and operational hygiene. It reduces the risk of accidental exposure of internal infrastructure and makes network administration more intuitive for users and administrators alike.