Split Horizon DNS: Why Your Internal and External DNS Differ

Split Horizon DNS is when one domain name returns different answers depending on who is asking. Someone on your office LAN querying intranet.example.com gets a private address like 10.0.4.20, while the same query from a coffee shop gets a public IP, a different host, or nothing at all. The DNS server decides which answer to hand back based on the source IP of the query, and that is the whole trick behind split DNS.

You will also see it called Split Brain DNS or DNS views. Same idea, different vocabulary depending on which vendor's documentation you are reading.

What is split DNS, in plain terms

Normal DNS is supposed to be universal. Ask any resolver on Earth for example.com and you should get the same A record. Split DNS deliberately breaks that assumption for one zone, on purpose, under your control.

Two zones exist with the same name:

• The internal zone, served by a DNS server that only your LAN, VPN, or VPC can reach. It contains private addresses and often extra hostnames that do not exist publicly (printer, nas, git-internal).
• The external zone, served by your public authoritative nameservers. It contains only what the internet needs to see: the web server, the mail exchangers, SPF and DKIM records.

A client never sees both. It sees whichever zone its resolver is authoritative for or forwards to.

Why anyone bothers running two answers

Split horizon DNS is not a hack someone invented for fun. It solves four concrete problems.

1. Internal traffic should not leave the building

If your file server sits on the same switch as the laptop asking for it, sending that traffic out to the public IP and back through the firewall is wasteful and slow. Internal DNS resolution hands back the private address so the packets stay on the LAN.

2. Your router might not support hairpinning

When a device inside the network tries to reach its own public IP, many consumer and some business routers simply drop the connection. That is the classic NAT loopback problem where you cannot access your own server by domain from home. Split DNS sidesteps it entirely: the internal answer points straight at the private IP, so the packet never needs to hairpin.

3. You do not want to publish your internal map

Every hostname in a public zone is reconnaissance material. Listing backup01, vcenter, jenkins, and sql-prod in public DNS tells an attacker exactly what to go after. Keeping those names in an internal-only view means an outside scan returns NXDOMAIN.

4. Cloud and hybrid setups need it

AWS Route 53 private hosted zones, Azure Private DNS, and Google Cloud private zones all exist precisely because workloads in a VPC should resolve a service name to a private endpoint address while the public internet resolves the same name to a load balancer. Same concept, managed for you.

How a DNS view decides which answer to send

The decision is almost always based on the source IP address of the DNS query. Not the user, not the hostname, not a cookie. Just where the packet came from.

1. A client sends a query to whatever resolver it was handed by DHCP or configured manually.
2. That resolver matches the client's source IP against an access control list, for example "anything in 10.0.0.0/8 or 192.168.0.0/16".
3. If it matches the internal ACL, the server answers from the internal zone file.
4. If it does not match, it answers from the external zone file, or refuses and lets public nameservers handle it.

Those private ranges in step 2 are defined by RFC 1918, and if you want the full breakdown of which blocks are reserved and why, our guide to private IP address ranges covers it.

The critical consequence: which answer you get depends entirely on which resolver you are talking to. Change your DNS server to 8.8.8.8 and you instantly land in the external view, even while sitting at your desk on the LAN. If you are not sure which resolver your machine is actually using, here is how to find your DNS server address.

How split horizon DNS is set up in real products

A minimal BIND view config looks like this:

acl internal-nets { 10.0.0.0/8; 192.168.0.0/16; localhost; };

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

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

Order matters. If the external view came first with match-clients { any; }, nobody would ever reach the internal view. Full syntax lives in the official BIND 9 documentation, and Microsoft documents the equivalent approach under DNS Policies in Windows Server.

How to tell if you are behind split DNS

The test is simple: ask two different resolvers the same question and compare.

# Ask your local/internal resolver
dig intranet.example.com A

# Ask a public resolver directly, bypassing the internal view
dig @1.1.1.1 intranet.example.com A

# Windows equivalent
nslookup intranet.example.com
nslookup intranet.example.com 1.1.1.1

Three possible outcomes:

• Same IP both times - no split horizon DNS for that name.
• Private IP locally, public IP from 1.1.1.1 - classic split DNS.
• An answer locally, NXDOMAIN from 1.1.1.1 - the name exists only in the internal zone.

To confirm what the rest of the world genuinely sees, run the name through a public DNS record lookup that queries external resolvers rather than your own.

The things that break with split brain DNS

The two zones drift apart

This is the number one failure mode. Someone adds a new web host to the public zone and forgets the internal copy. Now half the company cannot reach the new service, and the DNS server itself looks healthy. Every record that exists in both zones is a record that has to be updated twice.

DNS over HTTPS quietly bypasses your internal view

Firefox, Chrome, and Windows 11 can all send queries to a public DoH resolver instead of the one from DHCP. When that happens, a laptop sitting on the LAN suddenly gets the external answer and cannot reach internal-only hosts. Most enterprise setups disable browser DoH via policy or publish a canary domain to signal that DoH should be off.

VPN split tunnelling sends DNS the wrong way

With split tunnel VPNs, only some traffic goes through the tunnel. If DNS queries are not among them, remote staff resolve internal names against their home ISP resolver and get NXDOMAIN. The fix is usually a DNS suffix search list plus conditional forwarding for your internal domain.

TLS certificates get awkward

An internal-only hostname cannot pass an HTTP-based certificate challenge because no public server answers on that name. You either use a DNS-01 challenge against the public zone, or run an internal certificate authority and distribute the root cert to your devices.

Cached answers outlive the change

A client that queried the external view and cached a public IP keeps using it until the TTL expires, even after it moves back onto the LAN. Short TTLs on records that exist in both views (300 seconds is common) limit the damage. The mechanics are the same as normal DNS propagation and how long updates take.

Failures look like a broken resolver

When the internal DNS server is down or unreachable, clients often fall back to a public resolver and then fail on every internal name. Users report it as a general DNS outage. If you are chasing symptoms like this on Windows, the breakdown of what is actually happening when the DNS server is not responding walks through the resolver fallback chain.

Rules that keep split DNS sane

• Keep the internal zone as small as possible. Only override the records that genuinely need a private answer. Let everything else fall through to public DNS via forwarding.
• Never duplicate the whole zone by hand. Generate the internal zone from the public one plus a small delta file, or use conditional forwarding rather than a full second copy.
• Use a dedicated subdomain for internal-only hosts, such as corp.example.com. It makes the boundary obvious and stops name collisions.
• Do not use fake TLDs like .local or .corp. ICANN reserves some and has delegated others; .local also collides with mDNS. Use a subdomain of a domain you actually own.
• Make internal nameservers unreachable from the internet. An exposed internal view is exactly the map you were trying to hide.
• Document which records are split. A one-page list of every name that differs between views saves hours during an outage.

See exactly what the outside world resolves for your domain

When you are running Split Horizon DNS, the fastest way to spot a drifted record is to compare your internal answer against the public one. Our DNS Lookup tool queries A, AAAA, MX, NS, TXT, CNAME and SOA records through public resolvers and shows each value with its TTL.

Check your public DNS records →