FUNDAMENTALS · MECHANISM WALKTHROUGH

Split DNS
Why Internal and External Resolution Diverge

"mail.company.local works fine, mail.company.com fails externally" — a working internal record proves nothing about the public zone, because they're two completely separate resolution processes on two completely separate authoritative servers.

INTERNAL QUERY→ INTERNAL AD DNS (AUTH FOR .LOCAL)→ RESOLVES FINE→ EXTERNAL QUERY→ PUBLIC HIERARCHY (AUTH FOR .COM)→ MISCONFIGURED / MISSING RECORD→ FAILS

01 The Full Sequence — Worked Example

The Setup — Two Genuinely Separate Namespaces

The company runs an internal Active Directory domain, company.local — a private DNS namespace never delegated anywhere on the public internet, served entirely by internal AD-integrated DNS servers. Separately, the company owns the public domain company.com, delegated by its registrar to a public DNS provider (e.g. Cloudflare, Route 53).

Setup

Internal Query for mail.company.local

An internal client's resolver — pointed at the internal AD DNS server via DHCP — sends the query directly to that server, which is authoritative for the entire company.local zone. It owns the A record for the Exchange server (10.20.5.10) directly and answers immediately and correctly. No part of this touches the public internet's DNS hierarchy at all.

Internal

Checkpoint — This Success Proves Nothing About the Public Domain

company.local and company.com are two entirely separate zones, hosted on two entirely separate pieces of authoritative infrastructure, sharing nothing but part of a company name. A correctly working record in one zone carries zero implication about the health, existence, or correctness of any record in the other. This is the single fact the whole question is testing.

Checkpoint

External Query for mail.company.com

An external user's resolver has no knowledge of, or path to, the internal AD DNS server at all — it's not reachable from the internet, by design. Instead, this query follows the normal public hierarchy: root servers → .com TLD servers → company.com's actual public authoritative name servers.

External

The Failure Point — Somewhere in the Public Zone

The public authoritative server for company.com either has no record for the "mail" host, has a stale one, or has a record pointing to an IP/NAT mapping that isn't actually reachable (e.g. the firewall's VIP/DNAT for mail was reconfigured or never published). Resolution fails one of a few distinct ways — and which one matters for troubleshooting.

Failure

Two Fundamentally Different Failure Classes

NXDOMAIN/SERVFAIL — the name genuinely doesn't exist or the authoritative server errored — is a pure DNS/zone configuration problem, fixed by editing the zone. "Resolves fine but unreachable" — the record returns a valid IP, but nothing answers there — is usually a firewall, NAT, or server-availability problem, fixed by a completely different team. Conflating these two during triage sends the ticket to the wrong owner.

Diagnosis

The More Common Modern Pattern — Split-Horizon DNS

Many well-run environments avoid this two-namespace design entirely and instead use the same name, mail.company.com, both internally and externally — via split-horizon (split-brain) DNS. The internal DNS server hosts its own authoritative copy of just that record, returning the internal IP directly to internal clients, while the real public authoritative servers return the public-facing NAT'd IP to everyone else. Same name, two different truthful answers depending on who's asking.

Split-Horizon

Why Split-Horizon Exists at All

Without it, internal clients resolving the public name would get the public NAT'd IP and have to hairpin out through the firewall and back in just to reach a server sitting on their own LAN — wasted WAN bandwidth and added latency for zero benefit. Split-horizon lets internal traffic take the direct, efficient path while external traffic still goes through the proper public-facing NAT/firewall path.

Rationale

If This Environment Used Split-Horizon Instead

The exact same "works internally, fails externally" symptom could still occur under a split-horizon design — but the fix would be different: you'd check the public view of that specific record on the internal DNS server (or the actual public authoritative servers), not treat the two zones as unrelated the way the .local/.com scenario requires.

Contrast

The Actual Diagnostic Move

Query the domain's real public authoritative name servers directly — bypassing every local cache and resolver — with something like dig mail.company.com @ns1.provider.com. This shows exactly what the internet actually sees, independent of what any internal server, cache, or resolver believes, and is the fastest way to confirm whether the problem is genuinely in the public zone.

Verify

02 How to Explain This in an Interview

Say "these are two separate zones on two separate authoritative servers" first. That one sentence is the actual answer; everything else is supporting detail about why that matters practically.
Volunteer split-horizon DNS even though the question names two different domains. It shows you know the more common real-world pattern and can reason about the same underlying "who's asking determines the answer" idea in a different, more typical configuration.
Distinguish NXDOMAIN/SERVFAIL from "resolves but unreachable" explicitly. This is the detail that turns a DNS answer into an actual triage skill — knowing which team to hand the ticket to.
Name the actual diagnostic command. Being able to say "I'd dig the record directly against the authoritative nameservers, bypassing local cache" is concrete, hands-on, and exactly what a working engineer would actually do.
If pushed on design, mention .local is generally discouraged today. It shows awareness that this exact two-namespace pattern is often considered legacy practice, not a deliberate best-practice choice.

03 Follow-Up / Gotcha Questions

Q What's split-horizon (split-brain) DNS, and why do many organizations prefer it?

A It's a design where the same domain name resolves to different answers depending on whether the query originates internally or externally — internal clients get a direct internal IP, external clients get the public-facing NAT'd address. It avoids maintaining a second, separate internal-only namespace and avoids internal traffic unnecessarily hairpinning out through the firewall and back just to reach a server on the same LAN.

Q What's the practical difference between NXDOMAIN and a record that resolves but isn't reachable?

A NXDOMAIN means the name simply doesn't exist in the zone — a DNS configuration issue, fixed by adding or correcting a record. A record that resolves to a real IP but gets no response means DNS did its job correctly; the problem is downstream — firewall, NAT, or the server itself — and belongs to a different team than whoever manages the DNS zone.

Q Why can't an external user's DNS query ever reach the internal AD DNS server?

A The internal DNS server was never delegated any authority on the public internet and typically isn't even reachable from outside the corporate network at all — by design, it only serves clients on the internal network, so external resolvers have no path to it and no reason to ever query it.

Q How would you check exactly what the public internet sees for a domain, bypassing any local caching?

A Query the domain's actual authoritative name servers directly with a tool like dig or nslookup, specifying that server explicitly rather than using the system's default resolver — this returns the zone's true current state, with no local cache, ISP resolver cache, or split-horizon internal view able to mask what's actually published.

Q Why might using .local for an internal AD domain be discouraged today?

A .local specifically collides with mDNS (multicast DNS, RFC 6762) used by Bonjour/Avahi-style zero-configuration networking on many consumer and IoT devices, which can cause confusing, hard-to-diagnose resolution conflicts. Modern guidance generally favors using a subdomain of a domain you actually own (e.g. corp.company.com) for internal AD namespaces instead.

Q If internal DNS confirms the internal record is correct, does that tell you anything useful about the public zone's health?

A No — and saying so explicitly during troubleshooting is valuable, because it stops the investigation from wasting time re-verifying the internal side. The two zones are independent; confirming one is healthy only narrows the problem down to "must be somewhere in the other one," it doesn't diagnose it.

04 Quick-Fire Glossary

Term	Meaning
Authoritative Zone	The specific DNS zone a given server holds the definitive, source-of-truth records for
Split-Horizon / Split-Brain DNS	Serving different answers for the same name depending on whether the query is internal or external
AD-Integrated DNS	DNS zones stored and replicated within Active Directory, serving an internal domain namespace
NXDOMAIN	A DNS response indicating the queried name genuinely does not exist in the zone
SERVFAIL	A DNS response indicating the authoritative or resolving server encountered an internal error
Delegation	A parent zone (e.g. .com) pointing to the specific name servers authoritative for a subdomain
Public DNS Provider	A third-party service (Cloudflare, Route 53, etc.) hosting a domain's public-facing authoritative zone
dig / nslookup Direct Query	Querying a specific authoritative server directly, bypassing local/cached resolution
.local (mDNS Conflict)	A reserved namespace also used by multicast DNS, causing conflicts if reused for internal AD domains
Zone Drift	Configuration divergence between separately managed DNS zones over time