Cloudflare Internal DNS consolidates public DNS and private DNS onto one control plane, one API, and one audit trail. There’s a single policy engine for every DNS query, whether it is for a public website or an internal application.
Enterprises typically operate separate systems for internal and external DNS because the two serve different audiences. Public DNS resolves names for services meant to be reached from the internet. Private DNS resolves internal resources, such as databases and internal applications, that should never be visible outside the corporate network.
While public DNS is usually a single system, private DNS is often scattered across on-premises appliances, cloud-native resolvers, and split-horizon setups, where the same hostname resolves to a different answer depending on whether the query comes from inside or outside the network. Coordinating those deployments across headquarters, branch offices, and multiple clouds means ongoing manual synchronization work for network teams.
Private DNS itself is not a new concept. It is already available from hyperscalers and established enterprise DNS vendors, but it typically runs apart from public DNS, with its own console, control plane and policy engine.
Cloudflare’s answer is a product it calls Internal DNS.
“Many organizations already use Cloudflare for their public DNS,” Enrique Somoza, product, performance and infrastructure at Cloudflare, told Network World. “Internal DNS extends that same platform to private DNS, so public and private are managed from the same global network and control plane.”
How it works
Query handling starts at the resolver, not at the zone. That consolidation extends to daily operations as well.
“Instead of operating two separate DNS systems, customers use one API, one audit trail, one dashboard, and one policy engine for every DNS query—whether it is for a public website or an internal application,” Somoza said.
Policy first. The resolver sits ahead of every lookup, not behind it. “Architecturally, Cloudflare Gateway becomes the resolver that customers connect to, and can use WARP, DNS over HTTPS, DNS over TLS, or traditional DNS,” Somoza said. “Gateway evaluates zero -trust policies first, then routes the query to the appropriate DNS view based on context, such as source IP, device posture, or network location.”
No public path in. Internal zones sit outside the public DNS hierarchy entirely. “Internal zones are never assigned public nameservers—they are only reachable through Gateway, so every query is evaluated before it is resolved,” Somoza said.
One hostname, multiple answers. Branch offices, data centers and cloud environments no longer each need their own resolver stack. “Operationally, this simplifies environments that span branch offices, data centers, and multiple clouds,” Somoza said. “The same internal hostname can return different answers depending on where the request originated without maintaining separate resolver infrastructure, conditional forwarders, or duplicate zone files.”
Somoza described the underlying objective in direct terms: “The goal is to make internal DNS behave like a single service instead of a collection of independent deployments,” he said.
View selection. The same hostname can resolve to different IP addresses depending on where the request comes from. Gateway makes that call using several client signals.
“View selection is policy driven,” Somoza said. “Gateway resolver policies evaluate the context of each DNS query, including attributes like source IP, device identity, or network location and determine which DNS view should answer the request.”
A view is a container, not a separate infrastructure stack. Somoza explained that a view is simply a logical grouping of internal zones. For example, a company could have separate views for Europe and North America, or for corporate users and operational technology networks.
Latency and resilience. Internal DNS inherits its performance characteristics from Cloudflare’s existing public network. “Internal DNS runs on Cloudflare’s global network, so queries are answered by the nearest available Gateway location, helping keep latency low for connected users,” Somoza said. “Because Internal DNS runs on the same global infrastructure as Cloudflare’s public DNS, it benefits from the same anycast architecture, geographic distribution, and resilient network design.”
How this differs from split-horizon DNS
Internal DNS replaces the duplicate-zone model traditional split-horizon setups depend on.
“Before migrating, many organizations maintain multiple versions of the same internal DNS zones across headquarters, branch offices, and cloud environments,” Somoza explained. “Conditional forwarders determine which resolver answers each query, and keeping those environments synchronized becomes an ongoing operational task.”
Internal DNS collapses those duplicate zones into a single authoritative copy split across views instead. “With Internal DNS, that configuration becomes much simpler,” Somoza said. “A customer might create a single corp.internal zone in Cloudflare and define multiple DNS views.”
For example, users in headquarters could receive one internal IP address for wiki.corp.internal, while branch offices receive a different address. Somoza emphasized that the zone itself only exists once. “Instead of maintaining multiple copies of the same configuration, administrators manage a single source of truth,” he said.
Early use cases and migration challenges
Not surprisingly, Somoza noted that the first use case Cloudflare sees for Internal DNS is for split-horizon DNS consolidation. There is also interest from organizations that operate across multiple cloud providers that want one consistent internal DNS service instead of managing separate DNS platforms in each environment.
Another common use case is extending zero-trust policies to internal name resolution. “Customers already use Gateway to control access to internet traffic, and Internal DNS lets them apply similar policy decisions before internal names are resolved,” Somoza said.
When it comes to migration, the friction customers report during migration is procedural rather than architectural.
“Customers need to think through API permissions, connectivity, and how existing local DNS forwarding rules interact with Gateway,” Somoza said. “Those are all well understood migration steps and customers often run both environments in parallel before completing the transition.”
