One Platform for Public and Private DNS
Cloudflare Internal DNS is now generally available, giving Enterprise customers a single system to manage both public and private DNS records instead of running separate infrastructure for each. The service is included at no additional cost for existing Enterprise Cloudflare Gateway customers.
Solving a Problem Most Companies Just Live With
Many organizations still run one platform for public DNS, a separate legacy system for internal DNS, and yet another set of cloud-native resolvers inside each cloud environment, each with its own security policy layered on top. When those systems drift out of sync, the result is often an outage. Split-horizon DNS, where internal and external users need different answers for the same hostname, makes the problem worse by requiring multiple environments to stay perfectly synchronized.
How the Architecture Works
Internal DNS is built from two pieces working together: a Gateway Resolver that handles recursive resolution and policy evaluation, and an Internal Authoritative DNS layer built on the same platform that already powers Cloudflare's public DNS. When a query comes in, the Gateway Resolver checks policy first. If a rule points to an internal view, the query is answered from that view's zones. If policy blocks it, the query is dropped. Otherwise it resolves normally against the public DNS hierarchy, and views can even fall back to public resolution automatically when an internal name isn't found.
A key design choice is that internal and external views are separate lenses over shared zones rather than duplicated copies of data. A zone like intranet.local can be defined once and referenced across as many views as needed, which avoids the drift-prone duplication that split-horizon setups usually force on network teams.
A Single Write Path for Every Change
Every DNS change, whether made through the dashboard, Terraform, or a direct API call, passes through the same DNS Records API. That means there's exactly one path to audit regardless of how a change originated, and once persisted, updates replicate across Cloudflare's global network with cached entries invalidated as they arrive, so edits take effect in seconds instead of waiting on TTL expiry.
Getting Started
Setup involves three steps: creating a zone, creating a view, and defining a resolver policy that determines which users or devices resolve against that view. The feature works with any Cloudflare connectivity method that routes DNS through the Gateway Resolver, including the Cloudflare One Client, DNS over HTTPS, DNS over TLS, standard port 53 DNS, PAC file deployments, and Cloudflare WAN, meaning organizations running Cloudflare WAN can resolve internal hostnames across an entire connected network without installing a client on every device.
Cloudflare frames this as the first step rather than the destination, with tighter integration planned between DNS, networking, and Zero Trust policy so that resolving a hostname, reaching the service behind it, and enforcing who's allowed to access it become decisions made through one platform instead of several disconnected ones.