Private DNS Moves onto the Cloudflare Platform

Cloudflare has announced the general availability of Internal DNS, a service that brings both authoritative and recursive DNS for private networks onto the same global infrastructure and control plane used for its public DNS, Zero Trust, networking, and application offerings. The service is available to Enterprise customers with Cloudflare Gateway at no additional cost.

Internal DNS addresses a long-standing operational friction point: private DNS is often the last piece of enterprise infrastructure run on separate, disconnected systems. Many organizations manage public DNS on one platform, internal DNS on another, and cloud-native DNS inside each cloud environment—each with its own security policies. Split-horizon DNS adds further complexity by requiring multiple environments to stay synchronized so internal and external users get different answers for the same hostname. When these systems drift, outages can follow. Cloudflare's approach consolidates public and private DNS resource management onto a single platform with one API, one audit trail, and unified policy enforcement.

The core benefits for adopters include:

  • Consolidated DNS operations: Public and private DNS share one platform, API, and policy store, eliminating the appliance refresh cycle and scaling constraints of legacy DNS servers.
  • Simplified split-horizon DNS: Internal and external resolution are defined as separate views over shared zones from a single control plane, removing the need for parallel systems that can drift out of sync.
  • Extended Zero Trust coverage: Resolver policies decide which users and devices resolve against which view, enforced by the same Cloudflare Gateway that governs other traffic, closing the gap in Zero Trust architectures where private name resolution was previously unmanaged.
  • Legacy infrastructure retirement: Hardware appliances, legacy DNS servers, and cloud-locked resolvers can be replaced by the infrastructure behind 1.1.1.1, with no hardware to rack or capacity to provision.

Internal DNS addresses these issues without requiring changes to how users connect: it works with the Cloudflare One Client (formerly WARP), DNS over HTTPS (DoH), DNS over TLS (DoT), standard DNS on port 53, PAC file deployments, and Cloudflare WAN. For organizations running the latter, every device on the connected network can resolve internal hostnames through Cloudflare without per-device client installation, creating a consistent DNS experience across remote users, branch offices, data centers, and cloud environments.

Architecture and Core Components

Cloudflare Internal DNS is built from two distinct components that handle different jobs. The Gateway Resolver, launched in 2020 for recursive resolution and powered by 1.1.1.1, includes a policy engine that can filter queries and redirect them to different upstream sources using flexible expressions, with extensive logging and audits. Internal Authoritative DNS serves records for internal zones on the same authoritative platform Cloudflare has operated for over a decade, which serves more domains than any other provider.

Administrators work with three primary objects:

  • Internal Zones store the authoritative records for private resources: environment-specific apps, service endpoints, and databases.
  • DNS Views group zones into resolution contexts for specific sets of users or devices, enabling split-horizon behavior without parallel systems.
  • Resolver Policies live in Gateway and route matching queries to the appropriate view.

A key design element is zone references, which let administrators reuse a shared zone across multiple views without duplicating its records. A common zone such as intranet.local is defined once and referenced wherever required, avoiding the duplication and drift that typically accompanies split-horizon setups.

How Queries and Changes Flow

Query Resolution Path

When a client sends a DNS query, it first reaches the Gateway Resolver, where policy evaluation happens. One of three outcomes follows: if a resolver policy matches and points at an internal view, the query is routed to Internal Authoritative DNS and answered from that view's zones; if policy blocks the query, it is dropped at the resolver; otherwise, the query proceeds along the public path, with 1.1.1.1 resolving against the public DNS hierarchy. Views can also fall back to public resolution when an internal name isn't found, allowing a single resolver to serve both private and public names without client-side awareness of the distinction.

Change Propagation

Record changes follow a uniform path from input to edge. Every change enters through the same DNS Records API, regardless of whether it was made via the dashboard, Terraform, or a direct API call. This unified ingress ensures a single write path to reason about and audit. The change is persisted in Cloudflare's core data centers for durability and validated before propagation. From there, changes replicate across Cloudflare's global network, with affected cached entries invalidated as updates arrive—so edited records take effect in seconds rather than waiting on TTL expiry.

Getting Started

Enterprise customers with Cloudflare Gateway already have access. Setup involves three steps: create a zone, create a view, and define a resolver policy determining which users and devices resolve against that view. The process starts in the Cloudflare dashboard under Networking, then Internal DNS, where a zone and first internal record can be created:

POST https://api.cloudflare.com/client/v4/accounts/zones
{
  "account": {
    "id": "{account_id}"
  },
  "name": "corp.internal",
  "type": "internal"
}

POST https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "db.corp.internal",
  "content": "10.0.1.50",
  "ttl": 300
}

A DNS view is then created and linked to the zone:

POST https://api.cloudflare.com/client/v4/accounts/{account_id}/internal_dns/views
{
  "name": "production-view",
  "zones": ["{zone_id}"]
}

Finally, a Gateway resolver policy is created in the Zero Trust dashboard. After creating a Gateway location and setting conditions, the resolution method is set to Internal DNS View with the desired view selected. Queries matching the policy then resolve against internal zones.

Terraform support is included, with changes writing through the same DNS Records API as other methods—meaning infrastructure-as-code changes follow the identical ingestion and propagation path. Full documentation and end-to-end configuration examples are available in the developer documentation.

Part of a Larger Platform

Internal DNS extends the Connectivity Cloud platform many organizations already use for Zero Trust security, network connections via Cloudflare WAN, application acceleration, and protection of Internet-facing services. The introduction of private DNS onto this shared network represents a starting point rather than an endpoint; upcoming integration work aims to make internal hostname resolution, service access, and access enforcement decisions possible through one platform instead of multiple disconnected systems.