Keep seeing the term "split-horizon DNS" thrown around whenever discussions turn to accessing self-hosted services both locally and remotely under the same domain.
From an architectural perspective, how does the resolution split actually work under the hood without causing cache poisoning or routing loops? Does the local resolver simply intercept specific records before forwarding upstream, or is there a cleaner implementation pattern?
Trying to get a clear conceptual grasp before mapping out our internal infra. How do you guys conceptually explain this flow?
What is Split-Horizon DNS and how does it actually route traffic?
👁️ 51 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
Think of split‑horizon DNS as two separate authoritative zones for the same domain – one served by an internal DNS server (returning private IPs) and one by the public server (returning public IPs). Your internal resolvers are simply configured to query the internal server first (or via a view‑based DNS like BIND/PowerDNS), so they get the “local” records, while external resolvers only see the public zone; each server only answers for its own view, so there’s no cache poisoning or routing loop. It works much like a split‑tunnel VPN, but the decision happens at name‑resolution time instead of packet‑routing time.