Cloudflare flipped the switch on Internal DNS this week, turning a closed beta into a generally available service that lets organizations run the DNS for their private networks on the exact same global network and control plane they already use for public DNS, Zero Trust, and application delivery. Announced on July 20, 2026, the move targets one of the last pieces of enterprise infrastructure that most companies still run as a separate, isolated silo: the DNS that answers queries for intranet.corp, jira.internal, or db.cluster.local and is rarely managed by the same team or tooling as the public zone file. (Cloudflare’s announcement details the GA rollout)
For years the standard enterprise setup has been a small pile of disconnected systems: one product for public DNS, another for internal DNS, and then a cloud-native DNS service inside every cloud account, each with its own security policy bolted on afterward. None of them share a control plane, and the moment an organization needs split-horizon DNS — where app.corp resolves to an internal IP for employees but a public IP for the internet — it has to keep two environments in sync by hand. When those systems drift, resolution breaks and outages follow.
One control plane instead of three
The headline pitch for Cloudflare Internal DNS is consolidation. Public and private DNS live on a single platform with one API, one audit trail, and one place to set policy. The appliance refresh cycle and the scaling bottlenecks that came with legacy DNS appliances disappear, because the service runs on the same infrastructure behind 1.1.1.1 rather than on hardware a team has to rack and capacity it has to provision.
Split-horizon DNS, historically the part that forces parallel environments, becomes a configuration choice instead of a second product. Internal and external resolution are defined as separate views over shared zones, managed from one control plane. There are no parallel systems to keep in sync, so there is no drift to chase down at 2 a.m. when a record changed in one place and not the other.
What is actually in the box
Cloudflare Internal DNS is built from two distinct components, because authoritatively serving records and enforcing DNS security policy are genuinely different jobs.
The Gateway Resolver handles recursive resolution and policy evaluation. It originally launched back in 2020 as part of Cloudflare for Teams and is powered by 1.1.1.1 for public resolution; it carries a built-in policy engine that can filter DNS queries and redirect them to different upstream sources, all driven by flexible expressions, with logging and audits feeding a single pane of glass. (Cloudflare Gateway documentation)
Internal Authoritative DNS serves records for internal zones, built on the same authoritative platform Cloudflare has operated for over a decade for its public customers. Together they mean an organization can both answer “what is the IP for git.internal?” and decide “which users and devices are even allowed to ask?” without leaving the Cloudflare stack. (Cloudflare’s authoritative DNS overview)
Why this matters for Zero Trust
The more interesting angle is what it does to the gap in most Zero Trust deployments. Organizations happily gate web traffic, SSH, and SaaS access, then leave private name resolution as a blind spot — anyone on the network can resolve internal hostnames, and there is no per-user or per-device policy on who sees which answer.
With Internal DNS, resolver policies decide which users and devices resolve against which view, and those policies are enforced by the same Cloudflare Gateway that already governs the rest of outbound traffic. Private name resolution stops being the exception to an otherwise Zero Trust architecture. A contractor’s device can be pointed at a restricted view that hides sensitive hostnames, while full-time staff get the complete internal zone — all from one policy language.
The retirement plan for DNS appliances
Cloudflare is explicitly positioning this as a way to retire hardware appliances, legacy DNS servers, and cloud-locked resolvers. Because the service runs on Cloudflare’s global infrastructure rather than a customer’s data center, there is no hardware to maintain and no DNS capacity to provision ahead of peak. For teams whose primary DNS still runs on a pair of VMs that everyone is afraid to reboot, that is a meaningful operational simplification.
For Enterprise customers, Cloudflare says Internal DNS is included with Cloudflare Gateway at no additional charge, which removes the usual “new SKU, new budget line” friction that keeps legacy DNS alive.
The honest limits
This is not a universal replacement for every DNS deployment, and claiming otherwise would misread the launch. Internal DNS is an Enterprise-tier, Gateway-bound capability — smaller teams or shops that are not already Cloudflare Gateway customers are not the target, and adopting it means committing to Cloudflare as the DNS control plane for both public and private space. Organizations deeply invested in another vendor’s resolver or a heavily customized BIND/Active Directory integrated-DNS setup will face a real migration, not a flip of a switch, and split-horizon still requires deliberate view design — the tool removes the sync burden, not the thinking.
There is also a philosophical tradeoff: consolidating public and private DNS onto one vendor’s global network improves consistency and auditability, but it concentrates resolution (and a chunk of internal topology) inside Cloudflare’s infrastructure. That is a reasonable bet for many enterprises and a non-starter for some regulated or air-gapped environments that cannot let internal hostnames transit a third-party resolver at all.
The bottom line
Cloudflare Internal DNS going GA is less about a new feature and more about deleting a category of toil: the separate internal-DNS appliance, the hand-synced split-horizon environment, and the private-resolution blind spot in Zero Trust rollouts. If your organization already runs Cloudflare Gateway, the ability to manage private zones, enforce per-user resolution policies, and retire DNS hardware from one console is available today at no added cost — the practical question is no longer whether the tooling exists, but whether your internal zone design is clean enough to migrate.
