Cloudflare Internal DNS is now generally available, giving enterprise customers a single platform to run both public and private DNS resolution on the same global network already used for Zero Trust, networking, and application services.
Private DNS has historically lived apart from the rest of an organization's network stack. Most enterprises run one platform for public DNS, a separate one for internal name resolution, and often a third set of cloud-native DNS services inside each cloud environment, each with its own security policy layered on top. Split-horizon setups, where internal and external users need different answers for the same hostname, add another layer of complexity, since keeping multiple DNS environments synchronized becomes its own operational burden. When those systems drift apart, outages tend to follow.
Internal DNS folds private zones into the same control plane as everything else Cloudflare already manages, giving administrators one API, one audit trail, and one place to set policy across both public and private resolution. Enterprise customers using Cloudflare Gateway get the feature at no additional cost.
The system is built from two components. Internal Authoritative DNS serves records for private zones on the same authoritative platform Cloudflare has run for its public DNS for more than a decade. The Gateway Resolver handles recursive resolution and policy evaluation, and because it's powered by the same infrastructure behind 1.1.1.1, it comes with a built-in policy engine that can filter or redirect queries based on configurable rules, with logging feeding into a single audit view.
Split-horizon resolution is handled through views, which group zones into the resolution context a specific set of users or devices should see. Rather than duplicating records across environments, administrators can define a shared zone once and reference it from multiple views, avoiding the copy-and-drift problem that split-horizon configurations traditionally force onto network teams.
When a query reaches the Gateway Resolver, one of three things happens: if a resolver policy points to an internal view, the query resolves against that view's private zones; if policy blocks it, the query is dropped; otherwise it resolves publicly through 1.1.1.1. Views can also fall back to public resolution automatically when a name isn't found internally, so a single resolver can serve both private and public names without a client needing to know the difference in advance.
Every change to a DNS record, whether made through the dashboard, Terraform, or a direct API call, passes through the same DNS Records API, giving teams one write path to audit regardless of how a change originated. Changes are persisted and validated centrally before propagating across Cloudflare's network, with cached entries invalidated as updates land, so edits take effect in seconds rather than waiting on TTL expiry.
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 connectivity method that routes DNS traffic 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 extend internal name resolution to every connected device without installing a client on each one.
Cloudflare has framed Internal DNS as a first step rather than a finished product, with tighter integration planned across 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 a single platform rather than several disconnected ones. Enterprise customers can access the feature today through the Networking section of the Cloudflare dashboard.