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 and whyHow I use it inArchitectureLessons learned and gotchasImpactFurther reading

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

Split-horizon DNS architecture: One name, two resolution paths The same hostname follows an internal resolver and ingress path from inside the network, or public DNS and the edge from outside, before both routes reach the service. ARCHITECTURE FLOW ONE NAME, TWO RESOLUTION PATHS Same hostname: One name for both locations SAME HOSTNAME One name for both locations Inside query: A client asks from the lab INSIDE QUERY A client asks from the lab Outside query: A client asks from the internet OUTSIDE QUERY A client asks from the internet Internal resolver: Return the internal ingress path INTERNAL RESOLVER Return the internal ingress path Public DNS: Return the public edge path PUBLIC DNS Return the public edge path Service: Both paths reach the intended app SERVICE Both paths reach the intended app Cyan. Automated step or path. Green. Recorded or healthy outcome. Rounded box. Actor or process. Arrow. Direction of work or data.
The same name resolves through an internal path from inside and a public edge path from outside. Domains, resolver addresses, and hostnames are omitted.

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 because DNS answers drive routing decisions. If the wrong side answers, traffic goes somewhere expensive or gets stopped by a gate meant for someone else.

Further reading

Split-horizon DNS