Cloudflare Internal DNS Goes GA: What Site Owners and Admins Should Know
Cloudflare Internal DNS is now generally available for Enterprise customers using Cloudflare Gateway, combining public and private DNS management on a single control plane.
Cloudflare Internal DNS reached general availability on July 21, 2026, giving organizations a way to run authoritative and recursive name resolution for private networks on the same global network that already handles their public DNS, Zero Trust, and application services. For many businesses, internal name resolution has lived on a separate platform for years, complete with its own appliances, its own security rules, and its own audit logs. Cloudflare's new offering aims to fold those responsibilities into one management surface, removing the operational seams that split-horizon DNS usually creates.
The shift matters to anyone running multi-site hosting, mixed cloud environments, or branch networks that depend on private hostnames such as db.internal, erp.corp, or environment-specific service endpoints. Hosting customers who rely on Cloudflare for performance and security can now extend the same dashboard and API to their private name resolution. Readers who want a quick refresher on how DNS records are managed today can review how to manage the DNS zone in the control panel, while those onboarding a domain can follow the steps to how to add a website to Cloudflare.
Key Takeaways
- Cloudflare Internal DNS is included for Enterprise customers using Cloudflare Gateway, with no separate license fee.
- Two components power the service: the Gateway Resolver for recursive resolution and policy enforcement, and Internal Authoritative DNS for serving private zones.
- DNS Views group zones into resolution contexts, enabling split-horizon behavior without maintaining duplicate records.
- Resolver Policies inside Cloudflare Gateway decide which users, devices, or locations see which view.
- Record changes travel through a single API regardless of source, then propagate globally in seconds.
Why Cloudflare Built Internal DNS
Most enterprises carry three independent DNS footprints at once: a public-facing DNS service, an internal resolver pool for employees and offices, and cloud-native DNS inside each provider's environment. Each one carries its own permission model, its own logging pipeline, and its own way of representing the same hostname. When those systems disagree, users see inconsistent answers depending on where they connect from, and administrators spend time chasing the drift rather than improving the network.
Split-horizon DNS is the common workaround. The same record exists twice, with one answer for external clients and another for internal users. Keeping the two copies aligned is the hard part, and a missed synchronization almost always produces a support ticket. Cloudflare's pitch is straightforward: replace that fragmented stack with a single platform that owns both public and private name data, enforces policy once, and exposes everything through one audit trail. For a quick overview of related coverage, see the SiteCountry Cloudflare knowledge base tag.
The Two Building Blocks
Cloudflare Internal DNS separates two responsibilities that legacy products often combine. The Gateway Resolver handles recursive queries and decides what happens to each one. It launched in 2020, runs on the same infrastructure as the public 1.1.1.1 resolver, and includes a built-in policy engine that can filter lookups, redirect them to specific upstreams, and log every decision for auditing.
Internal Authoritative DNS is the second half. It serves records for private zones on the same authoritative platform Cloudflare has run for more than a decade, the platform already answering for more domains than any other provider. The separation matters because authoritative serving and policy enforcement are different jobs that benefit from different scaling characteristics.
Core Objects: Zones, Views, and Resolver Policies
Administrators work with three primary objects when configuring the service. Each one plays a specific role in how private names get answered.
| Object | Purpose | Where it lives |
|---|---|---|
| Internal Zone | Holds authoritative records for private resources such as internal apps, databases, and service endpoints. | Internal Authoritative DNS |
| DNS View | Groups zones into the resolution context a given population of users or devices should see. | Cloudflare dashboard and API |
| Resolver Policy | Matches incoming queries by user, device, or location and routes them to the right view. | Cloudflare Gateway |
| Zone Reference | Lets one shared zone appear in multiple views without duplicating records. | Internal Authoritative DNS |
Zone references are the practical difference between a clean configuration and a duplicated one. A shared name like intranet.local is defined once, then referenced from every view that needs it. Removing the copy step is what makes split-horizon DNS stop drifting.
How a Query Flows Through the System
When a client issues a lookup, the Gateway Resolver evaluates any matching resolver policies before any name resolution happens. From that point, three paths are possible. A policy can target an internal view, in which case the query is handed to Internal Authoritative DNS and answered from the matching view's zone data. A policy can also block the query outright, dropping it at the resolver for security or compliance reasons. When no internal policy applies, the lookup continues along the public path, where 1.1.1.1 works through the standard DNS hierarchy to return a public answer.
Views can be configured to fall back to public resolution when a name is missing from the internal store, so the same resolver serves both private and public hostnames without the client having to switch resolvers. That removes the conditional DNS forwarding configuration that legacy split-horizon setups usually require.
How a Record Change Propagates
Every record edit enters through the same DNS Records API, regardless of whether the change is made through the dashboard, a Terraform configuration, or a direct API call. That single ingress point is auditable in one place and behaves predictably for every team touching DNS. Once accepted, the change is written to durable storage in Cloudflare's core data centers and validated before replication begins.
From there, the update fans out across Cloudflare's global network. Cached entries along the way are invalidated as the new data arrives. In practice, edited records become visible within seconds rather than waiting for TTL expiry on every intermediate resolver. For hosting customers who manage large fleets of records, this removes one of the more stubborn pain points of running DNS on aging infrastructure.
Getting Started in the Dashboard
Internal DNS is available now to Enterprise customers who already use Cloudflare Gateway. The typical setup follows three short steps in the dashboard. First, create an internal zone and add your first private record. Second, build a DNS view and attach the zone to it. Third, write a Gateway resolver policy that determines which users and devices receive that view when they query.
The final step also involves creating a Gateway location and selecting Internal DNS View as the resolution method, then choosing the view the policy should target. Queries that match the new policy will resolve against the internal zones immediately. Teams already comfortable with the Cloudflare control panel can sign in through the login to control panel page to begin.
What This Means for Hosting Customers
Website owners who outsource their infrastructure rarely think about private DNS until a merger, a new branch office, or a hybrid cloud project forces the issue. Cloudflare Internal DNS lowers the activation cost for those scenarios because there is no appliance to rack, no capacity to size, and no separate vendor relationship to manage. Policy and logging happen inside the same Gateway console that already governs web traffic, so security teams gain a single source of truth instead of another silo.
For WordPress operators in particular, the unification matters whenever an internal staging site, a private admin panel, or a database host needs a friendly hostname. Centralizing those records under the same dashboard used for public DNS reduces the chance of an outage caused by inconsistent records between environments. Anyone reviewing broader protection strategies can also read about Cloudflare waf WordPress vulnerabilities for context on how Gateway, WAF, and DNS work together.
Frequently Asked Questions
Who can use Cloudflare Internal DNS today?
Internal DNS is available to Enterprise customers who already subscribe to Cloudflare Gateway. There is no separate charge for the internal DNS capability itself; it is bundled with the Gateway subscription for qualifying plans.
Do I need new hardware or a new resolver at each office?
No. The service runs entirely on Cloudflare's global network, which also powers the public 1.1.1.1 resolver. Offices point their local DNS configuration at the Gateway Resolver and let Cloudflare handle recursive lookups and policy decisions remotely.
How does split-horizon DNS work without keeping two copies of every record?
Internal Zones hold the authoritative records, and DNS Views define which population of users sees which set of zones. A shared zone can be referenced from multiple views, so the record exists once but is answered differently based on who is asking.
What happens to queries that do not match any resolver policy?
Queries that do not match a resolver policy fall through to normal public resolution. The Gateway Resolver hands them to the public DNS hierarchy, so existing public name lookups continue to behave exactly as they did before Internal DNS was enabled.
How quickly do record changes take effect across the network?
Edits are written through one API, persisted in core data centers, and replicated across Cloudflare's global network with cache invalidation along the way. In most cases, the updated record is answered within seconds rather than waiting for old TTL values to expire.
Action Checklist for Site Owners
- Confirm that your Cloudflare plan includes Gateway, since Internal DNS is gated behind Enterprise Gateway licensing.
- Inventory the private hostnames your team relies on today, including staging environments, internal admin panels, and database endpoints.
- Group those hostnames into internal zones and decide which users or devices should see each one.
- Create DNS views and reference zones across views to avoid duplicate record sets.
- Write Gateway resolver policies that match the right populations to the right views and log every decision for audit purposes.
- Test fallback behavior so that lookups not covered by an internal view still resolve through the public path without surprises.
- Review your broader security posture, including WAF rules, to make sure private DNS, public DNS, and application security share consistent policy.
Cloudflare Internal DNS is a quiet but consequential step toward unified network infrastructure. By collapsing private and public name resolution into a single platform with one API, one audit trail, and one policy engine, it removes the operational friction that has made split-horizon DNS fragile for years. Hosting customers and site owners should treat the general availability announcement as a good moment to revisit how their internal name resolution is structured and whether consolidating on Cloudflare Gateway makes sense for their environment.
