Most teams do not have a DNS problem they talk about in meetings. They have three of them: a public zone file, a private one on an appliance nobody wants to reboot, and a cloud-native resolver inside every account — none sharing a control plane, none sharing policy. Cloudflare Internal DNS, now generally available, collapses that mess onto the same global network and Zero Trust plane you already use for public DNS (Cloudflare’s GA announcement). If your organization already runs Cloudflare Gateway, you can stand up private resolution without buying another appliance or racking hardware.
This is the setup workflow as it actually maps to Cloudflare’s model: an Internal Authoritative DNS service that serves your private zones, plus the Gateway Resolver that answers recursive queries and enforces policy. The two are managed from one console, which is the entire point.
Before you start
Internal DNS is an Enterprise-tier capability bundled with Cloudflare Gateway at no added charge, so the practical prerequisites are straightforward:
- An active Cloudflare Zero Trust / Gateway account on an Enterprise plan.
- A registered domain (or sub-domain) you control, used to namespace your internal zones — for example
corp.internalorsvc.example.com. - A way to point devices at Cloudflare’s resolver. For managed fleets that means the WARP client or a Gateway DNS Forwarding Profile; for networks, it means pointing your DHCP or router DNS at the Gateway resolver addresses.
If you are not already a Gateway customer, this product is not aimed at you — it assumes Cloudflare is already your outbound-traffic control plane.
Step 1 — Create the internal zone
In the Cloudflare Zero Trust dashboard, open the Internal DNS area and create a new internal authoritative zone (for example corp.internal). This is the namespace your private records will live in. Unlike a public zone, it is not served to the internet; only clients routed through the Gateway Resolver can see it, and only under whatever policy you attach.
Give the zone a clear name and confirm it. You now have an empty private zone sitting on the same authoritative platform Cloudflare has run for public customers for over a decade (Cloudflare’s DNS basics).
Step 2 — Add your records
Populate the zone the way you would any other: A/AAAA records for git.corp.internal, jira.corp.internal, db.cluster.local, CNAMEs for aliases, and so on. The editor behaves like the standard Cloudflare DNS editor, so bulk import, TTLs, and record comments all work.
A useful habit here is to mirror the intent of your old internal zone rather than copying it record-for-record. Internal DNS is a good moment to drop the zombie entries that accumulated on the legacy appliance.
Step 3 — Design split-horizon views
Split-horizon DNS — where app.corp resolves to an internal IP for employees but a public IP for the internet — is the classic reason teams keep two environments in sync by hand. In Internal DNS, split-horizon becomes a view over your zones rather than a second product.
Define at least two views: a full internal view (everything) and a restricted view (a subset of hostnames). You then decide, per policy, which clients resolve against which view. This is where the “no more hand-syncing” promise becomes real: there is one zone, multiple answers, and the resolver chooses based on who is asking.
Step 4 — Point devices at the Gateway Resolver
Private records are worthless if clients never ask the right resolver. Route your fleet to the Gateway Resolver:
- Managed devices: deploy or configure the WARP client, or push a Gateway DNS Forwarding Profile, so DNS queries egress through Gateway.
- Networks: set DHCP or router DNS to the Gateway resolver addresses so laptops and servers on the LAN resolve through Cloudflare.
- Individuals: for contractors or BYOD, the WARP client is the cleanest path because policy follows the device identity rather than the network.
Because the Gateway Resolver is built on 1.1.1.1‘s recursive engine (Cloudflare Gateway documentation), public resolution keeps working for normal internet names while private names resolve from your internal zones.
Step 5 — Apply per-user and per-device resolver policies
This is the step that turns “internal DNS” into “Zero Trust internal DNS.” In Gateway, create DNS resolver policies (the same policy language Gateway uses for the rest of outbound traffic) that control which views a given identity or device group can see.
Concretely: full-time staff get the complete internal view; a contractor’s device gets the restricted view that hides sensitive hostnames; a specific service account might be allowed only db.cluster.local. Policies are evaluated per query, logged in the same audit trail as everything else, and can filter or redirect based on flexible expressions. Private name resolution stops being the blind spot most Zero Trust rollouts leave open.
Step 6 — Verify, then watch the logs
Before you cut over, test from a client routed through Gateway: dig git.corp.internal (or nslookup) should return the internal record, while an unauthenticated query from outside Gateway should not. Then open Gateway Logs and confirm the resolution events appear with the expected policy outcome.
The single pane of glass is the quiet win here — one audit stream for public and private resolution, instead of scraping appliance logs and cloud console exports separately.
Where teams trip up
A few realities are worth naming so the migration does not surprise you:
- It is a migration, not a flip. If you run a heavily customized BIND or Active Directory–integrated DNS, moving zones into Cloudflare is real work. The tool removes the sync burden; it does not remove the thinking about view design.
- You are consolidating onto one vendor. Public and private resolution both transit Cloudflare’s global network. That is a fine bet for most enterprises and a non-starter for regulated or air-gapped environments that cannot let internal hostnames leave their perimeter.
- Scope it to Gateway customers. Because it is bundled with Gateway, the value compounds only if Cloudflare already governs your outbound traffic. Adopting it standalone means adopting Gateway too.
The bottom line
Setting up Cloudflare Internal DNS is less about learning a new product and more about deleting three old ones: the internal-DNS appliance, the hand-synced split-horizon environment, and the private-resolution gap in your Zero Trust story. If you already run Cloudflare Gateway, the workflow is zone, records, views, resolver routing, and policy — and it 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 without bringing the legacy clutter along.
