Split-horizon Dns

Expanded Definition

Split-horizon DNS, sometimes called split-view DNS or split-brain DNS in operational discussions, is a naming pattern where the same hostname resolves differently based on the requester’s network context. In NHI and IAM environments, that usually means internal service endpoints, private IPs, or internal control planes are exposed only to trusted zones, while external users receive public records. The design supports segmentation and reduces unnecessary exposure, but definitions vary across vendors on whether the boundary is enforced by resolver location, source network, or policy layer.

The important distinction is that split-horizon DNS is not an access-control mechanism by itself. It is a routing and name-resolution control that must be paired with identity-aware enforcement, certificate management, and consistent service registration. The operational risk grows when internal and external records diverge without ownership, because the two views can imply different trust assumptions for the same service name. For a broader NHI governance lens, see Ultimate Guide to NHIs and the identity visibility principles in NIST Cybersecurity Framework 2.0.

The most common misapplication is treating split-horizon DNS as a substitute for authorization, which occurs when teams assume internal dns visibility alone proves a service should be trusted.

Examples and Use Cases

Implementing split-horizon DNS rigorously often introduces record-management overhead, requiring organisations to weigh cleaner exposure boundaries against the cost of keeping multiple authoritative views synchronized.

• An internal API for service accounts resolves to a private load balancer inside the corporate network, while the same name resolves to a public front door for partners or internet-facing clients.
• A CI/CD system uses a private DNS view to reach deployment endpoints that should never be reachable from the public internet, reducing lateral exposure of build automation identities.
• A production database hostname returns a private address for application pods, while administrators outside the VPC receive no usable route, preventing accidental access from unmanaged networks.
• An organisation separates internal certificate enrollment endpoints from external marketing or customer portals, keeping non-human identity workflows on private infrastructure while preserving public service continuity.
• Split views are documented alongside asset ownership and rotation procedures in the Ultimate Guide to NHIs, because record drift can break token exchange, mTLS, and service discovery.

Where standards guidance matters, DNS naming and resolution behavior should be checked against NIST Cybersecurity Framework 2.0 governance expectations, especially for asset control and access boundaries.

Why It Matters in NHI Security

Split-horizon DNS matters because NHI workloads often depend on machine-to-machine discovery, and a naming mismatch can break authentication flows, redirect traffic to the wrong trust zone, or expose internal services through an unintended resolver path. When the internal and external views drift, service accounts may request tokens for one endpoint while connecting to another, creating confusing failures that resemble credential issues but are actually topology issues. That confusion can delay incident response, mask misconfigured secrets, and weaken Zero Trust enforcement.

The risk is not theoretical. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 5.7% of organisations have full visibility into their service accounts, which makes DNS inconsistency even harder to detect in practice. Split-horizon DNS should therefore be governed as part of the broader identity perimeter, not as a standalone networking convenience. For NHI controls and lifecycle context, see Ultimate Guide to NHIs and align the exposure model with NIST Cybersecurity Framework 2.0.

Organisations typically encounter split-horizon DNS as a root cause only after an outage, token failure, or unexpected exposure, at which point the concept becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams split identity governance from implementation work?
• How should organisations split responsibilities between IGA and PAM?
• What breaks when privileged access is split across multiple tools and platforms?
• What breaks when identity governance is split across vaults, IGA, and PAM tools?