Starting today, Cloudflare Internal DNS is generally available. Cloudflare Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane customers already use for public DNS, Zero Trust, networking, and application services. Internal DNS — sometimes also referred to as private DNS — is one of the last pieces of enterprise infrastructure still managed separately from the rest of the network.
Many organizations operate one platform for public DNS, another for internal DNS, and use cloud-native DNS services inside each cloud environment with separate security policies layered on top. None of these systems share a common control plane. Split-horizon DNS adds another layer of complexity, often requiring multiple DNS environments to remain synchronized so internal and external users receive different answers for the same hostname.
When those systems drift, outages follow. With Cloudflare Internal DNS, you get a single platform to manage public and private DNS resources, enforcing DNS policies and gaining visibility across your entire DNS stack. For Enterprise customers, this is included with Cloudflare Gateway without any additional charge.
Why customers are adopting Internal DNS Consolidate DNS operations . Public and private DNS run on one 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 go away.
Simplify split-horizon DNS . Internal and external resolution are defined as separate views over shared zones, managed from a single control plane. There are no parallel systems to keep in sync, so there's no drift to chase down.
Extend Zero Trust to DNS . Resolver policies decide which users and devices resolve against which view, enforced by the same Cloudflare Gateway that already governs the rest of your traffic. Private name resolution stops being the gap in an otherwise Zero Trust architecture.
Modernize legacy infrastructure . Retire hardware appliances, legacy DNS servers, and cloud-locked resolvers. Cloudflare Internal DNS runs on the infrastructure behind 1.
- 1, with no hardware to rack and no capacity to provision.
What we built Cloudflare Internal DNS consists of two components: Gateway Resolver and Internal Authoritative DNS . Authoritatively managing zones is a different job from enforcing DNS security and routing policies. The Gateway Resolver handles recursive resolution and policy evaluation.
Launched in 2020 and powered by 1. 1. 1.
1 for public resolution, it comes with a built-in policy engine that can filter DNS queries and redirect queries to different upstream sources — all based on flexible expressions , with comprehensive logging and audits feeding a single pane of glass. Internal Authoritative DNS serves records for internal zones built on the same authoritative platform Cloudflare has operated for over a decade and that serves more domains than any other provider.
There are three primary objects customers work with: Internal Zones hold the authoritative records for private resources: environment-specific apps, service endpoints, databases. DNS Views group zones into the resolution context a given set of users or devices should see. This is what makes split-horizon work without parallel systems.
Resolver Policies sit in Gateway and route matching queries to a specific view. Zone references let administrators reuse a shared zone across multiple views rather than copying its records into each one. A common zone like intranet.
local is defined once and referenced everywhere it's needed, which is the difference between a Don't-Repeat-Yourself configuration and the duplicated, drift-prone setup that split-horizon usually forces. How a query resolves A DNS query from a client first hits the Gateway Resolver, where policy is evaluated. From there, one of three things happens.
If a resolver policy matches and points at an internal view, the query is routed to Internal Authoritative DNS and answered from the matching view's zones. If policy blocks the query, it is dropped at the resolver. Otherwise, the query follows the public path, with 1.
- 1 resolving it against the public DNS hierarchy.
Views can also fall back to public resolution when a name isn't found internally, so a single resolver can serve both private and public names without the client needing to know which is which. How a change propagates Record changes follow a predictable, high-speed path from input to edge. Every change enters through the same DNS Records API, whether it originates in the dashboard, in Terraform, or in a direct API call.
That unified ingress means there is exactly one write path to reason about and audit, regardless of how the change was made. The change is persisted in Cloudflare's core data centers for durability and validated before it propagates. From there, changes replicate across Cloudflare's global network and affected cached entries are invalidated as the updates arrive, so edited records take effect in seconds rather than waiting on TTL expiry.
Getting started If you're an Enterprise customer using Cloudflare Gateway, you have access to Internal DNS today. Open the Cloudflare dashboard, navigate to Networking, then Internal DNS . Setting up Internal DNS typically takes three steps: create a zone, create a view, and define a resolver policy that determines which users and devices should resolve against that view.
Create an internal zone and your first internal record: Then create a DNS view and link your zone to it: Finally, create a Gateway resolver policy in the Zero Trust dashboard that routes matching traffic to your view. Create a Gateway location , set your conditions, select Internal DNS View as the resolution method, and choose your view. That's it.
Queries matching your policy now resolve against your internal zones.
Originally published at blog.cloudflare.com
