Bill Gernert
Networking & Edge

Split-horizon DNS

One name, two answers - the same hostname resolves to the internal service on the inside and to the public edge on the outside, so traffic takes the right path from wherever it starts.

What it is & why I use it

Split-horizon (or split-view) DNS means a single hostname resolves differently depending on where the query comes from. Inside the network, a service name points at its internal address; from the public internet, the same name points at the edge. Both are correct - they just serve different callers.

I use it so the lab can present one clean set of names to users and automation, without forcing internal traffic to detour out to the internet and back just to reach a box sitting one subnet away. The name stays stable; the path adapts to the caller.

How I use it in the lab

  • Layered resolvers. Internal clients resolve through the network's own DNS, which is authoritative for the internal view of the lab's names and points them at internal addresses.
  • Internal names for internal services. Where a service is only meant to be reached from inside, the internal view resolves it to the internal ingress - it never has to leave the network.
  • Public view for outside callers. From the internet, the same names resolve to the public edge, which applies its own identity and routing before anything reaches an origin.
  • Consistent naming everywhere. Configuration, dashboards, and automation use one hostname regardless of side, so nothing has to know whether it is currently inside or outside.

Architecture

Diagram coming Same name, two horizons: internal query -> internal resolver -> internal ingress; external query -> public DNS -> edge. Scrubbed of domains, resolver addresses, and hostnames.

In action

Screenshot coming The same hostname resolving to an internal address from inside and to the edge from outside. Captured per the publishing checklist - domains, addresses, and resolver detail redacted.

Lessons learned & gotchas

Gotcha - an internal client on the public answer hairpins out The failure mode that split-horizon exists to prevent: if an internal client resolves the public answer for a service, its traffic leaves the network, reaches the edge, and comes back in - a hairpin. Best case it is slow and pointless; worst case it now has to satisfy the edge's SSO gate that was never meant for machine-to-machine internal calls, so a call that should just work starts failing on an auth challenge. The whole point is that inside traffic gets the internal answer and reaches the service directly. When an internal caller mysteriously hits a login page or a latency cliff, "which horizon did it actually resolve?" is the first thing to check.
  • Resolution order is a design decision. Which resolver a client asks first decides which horizon it lands in. Get the precedence wrong and internal machines quietly take the external path - so the ordering has to be deliberate, not whatever the OS defaulted to.
  • Two horizons means two things to keep in sync. A name that exists on one side but not the other is a confusing outage. When a service is added or renamed, both views have to move together.
  • Test from both sides. "It resolves" from your workstation proves one horizon. The only way to trust split DNS is to check resolution from inside and outside, because each side can be right while the other is broken.

Impact

1 name
two correct answers
Direct
internal path, no hairpin
Stable
naming inside and out

Split-horizon DNS is what lets the lab use one tidy naming scheme without paying a routing tax for it. The hairpin lesson is the one that sticks: a name is not just a label, it is a routing decision, and if the wrong side answers, traffic goes somewhere expensive or gets stopped by a gate meant for someone else.

Code & further reading

DNS config (link coming) Split-horizon DNS

Published DNS config is scrubbed of domains, resolver addresses, hostnames, and internal records before it goes public.