Documentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/dns/llms.txt
Use this file to discover all available pages before exploring further.
STOP! If you are an AI agent or LLM, read this before continuing. This is the HTML version of a Cloudflare documentation page. Always request the Markdown version instead — HTML wastes context. Get this page as Markdown: https://developers.cloudflare.com/dns/internal-dns/get-started/index.md (append index.md) or send Accept: text/markdown to https://developers.cloudflare.com/dns/internal-dns/get-started/. For this product's page index use https://developers.cloudflare.com/dns/llms.txt. For all Cloudflare products use https://developers.cloudflare.com/llms.txt.
If you will be using an API token for authentication, make sure you have the following permissions:
API token configuration
Permissions
Account - DNS Views - Edit
Zone - DNS - Edit
Account - Account Settings - Edit
Zone - DNS Settings - Edit
Zone - Zone - Edit
Account Resources
Include - (Your account)
Zone Resources
Include - Specific zones
When creating a token for Internal DNS, we recommend scoping it to specific internal zones rather than using "All zones". This follows the principle of least privilege. If you create new internal zones later, you will need to update the token scope to include them. Support for automatic zone-type scoping (for example, "all internal zones") is planned for a future release.
Internal zones can contain the same DNS record types that Cloudflare supports for public zones.
An internal zone can have the same name as a public zone in the same account.
Each internal zone can be linked to multiple views.1
There can be several internal zones with the same name in one account. However, two internal zones with the same name cannot be linked to the same view.
Internal zones are not subject to any top-level domain (TLD) restrictions. This means that an internal zone can be created if its TLD is not registered publicly (for example, xyz.local), if it is created on the TLD itself (local), or even if on the root (.).
1 Logical groupings of internal DNS zones that are referenced by Gateway resolver policies to define how a specific query should be resolved.
Add DNS records to your internal zone using your preferred option:
Select Add a record and choose Create under the record type you want to add. Refer to DNS record types for details.
Repeat this process for each internal zone you wish to add.
Use the Create Zone endpoint to create an internal zone. Specify your account ID and set the type to internal.
Internal zone configuration conditions
Internal zones can contain the same DNS record types that Cloudflare supports for public zones.
An internal zone can have the same name as a public zone in the same account.
Each internal zone can be linked to multiple views.1
There can be several internal zones with the same name in one account. However, two internal zones with the same name cannot be linked to the same view.
Internal zones are not subject to any top-level domain (TLD) restrictions. This means that an internal zone can be created if its TLD is not registered publicly (for example, xyz.local), if it is created on the TLD itself (local), or even if on the root (.).
1 Logical groupings of internal DNS zones that are referenced by Gateway resolver policies to define how a specific query should be resolved.
Use other API endpoints, such as /batch, to manage DNS records. Refer to Batch record changes for details.
Repeat this process for each internal zone you wish to add.
(Optional) Reference a zone from another zone
During an internal DNS query resolution, if no internal record is found within a matching internal zone, Cloudflare will check if the matching internal zone is referencing another internal zone. Successive references can be followed with a maximum of five references in a chain.
Find the zone you want to use as reference and choose Select in the respective row.
Use the Update DNS settings endpoint to add a reference from an internal zone to another internal zone. In --json, specify the internal_dns object with the parameter reference_zone_id.
In the following example, internal zone A (ID 8a904aeb565c42cfa207d98f6edea2f3) is referencing internal zone B (ID 8e64c6fb4b514f3faf64de81efc11e51).
In Cloudflare One ↗, go to Traffic policies > Firewall policies > Resolver policies.
Select Add a policy and enter a name and description.
Create an expression for the traffic you wish to route. For guidance about selectors, operators, and values, refer to Gateway resolver policies.
Select Use Internal DNS. Choose the view that queries matching the expression should be sent to.
(Optional) Adjust the option to Fallback through public DNS according to your use case.
Off: Gateway DNS resolver returns the response as-is to the client.
On: In case the response from the internal zone is REFUSED, NXDOMAIN, or a response with a CNAME type, Gateway DNS resolver sends the query to Cloudflare 1.1.1.1 public resolver and tries to resolve the query via public DNS.
Select Create policy to confirm.
Use the API endpoints under Zero Trust > Gateway > Rules to set up resolver policies. For guidance about selectors, operators, and values, refer to Gateway.
Use the rule settings object to define resolve_dns_internally, specifying view_id and fallback option. The fallback options behave as follows:
none: Gateway DNS resolver returns the response as-is to the client.
public_dns: In case the response from the internal zone is REFUSED, NXDOMAIN, or a response with a CNAME type, Gateway DNS resolver sends the query to Cloudflare 1.1.1.1 public resolver and tries to resolve the query via public DNS.
Once you add the Gateway resolver policy, it will be listed in the respective internal view under Resolver policies referencing this view.
Manage with Terraform
You can also manage Internal DNS resources with the Cloudflare Terraform provider ↗. The patterns are identical to public DNS zones — the only difference is setting type = "internal" on the cloudflare_zone resource.
Use a zone-scoped API token for day-to-day management and an account-level token for creating new zones. If your token is scoped to specific zones, remember to update it when you add new internal zones. For a complete working example, refer to the Terraform provider documentation ↗.