Cloudflare nameserver sets beta: Enterprise setup and delegation

Separate Enterprise beta access from the extra Advanced requirement

The October 14 announcement introduces account-level nameserver sets. The beta is available to Enterprise customers through the API only, and a zone must belong to the same account as its set. Standard and Advanced Custom sets are separate types. The Advanced type additionally requires a Foundation DNS subscription; Enterprise status alone does not remove that requirement.

Sets are separate from legacy zone, account and tenant custom nameserver configurations. Existing configurations cannot be converted into sets, and a zone can use only one configuration at a time. Legacy custom_ns remains supported and both approaches can coexist within an account. The new reusable objects are no longer limited to the legacy five numbered sets.

A set can be assigned repeatedly, but it cannot be edited after creation: it can only be created or deleted. Changing names therefore requires preparing another set and explicitly assigning zones. Adding or removing names does not silently change zones already using a set. Sets also cannot yet be the DNS default for new zones.

Plan names, address counts and ip_set to avoid conflicts

Each set needs two to five unique lowercase names; internationalized names must use Punycode. A nameserver name can belong to any domain, including one that is not itself a Cloudflare zone. The same name can appear in more than one set within an account.

ip_count selects how many IPv4 addresses and how many IPv6 addresses are assigned to each name. It ranges from one to three and defaults to one. Standard sets may use different counts for different names; every name in an Advanced set must use the same count. A maximum of three does not mean three are mandatory.

ip_set defaults to 1. Sets with the same ip_set and advanced value may reuse addresses; changing either uses a separate address group. Standard 1 and Advanced 1 are separate groups too. A zone cannot share nameserver IPs with its parent, a subdomain zone or a same-named zone in another account. Use a set with a different ip_set for that conflict.

For Advanced sets, ipv4_groups and ipv6_groups map to their address arrays by index. Groups a and b use non-overlapping sets of data centers; group c covers all Cloudflare data centers, including both a and b. These are not three disjoint networks, and the redundancy design is not a promise of zero outages.

Create the set and retain its ID and per-name addresses

Create a set with POST /accounts/{account_id}/dns_settings/nameserver_sets. List each name and required ip_count in nameservers, and provide the planned ip_set. Omit advanced or set it to false for a standard set. Set it to true for an Advanced set, while meeting the Foundation DNS and equal-count requirements.

The response supplies the set ID and separate ipv4 and ipv6 arrays for each name. Advanced responses also include the corresponding group arrays. Preserve that per-name mapping for record creation and inspection; a single combined pool of addresses is not enough.

An account cannot contain two sets with exactly the same names and addresses. The documentation also describes listing and retrieving sets. The create endpoint’s specific token permissions were not separately established in the pages reviewed here; the zone-write permissions below should not be treated as a complete authorization guide for creating account-level sets.

Publish A/AAAA records and distinguish when glue is needed

Cloudflare does not create or update DNS records for a nameserver set, even when the names belong to a domain using Cloudflare DNS. At each name’s authoritative DNS provider, create A and AAAA records containing all addresses assigned to that particular name.

If a name is inside the zone that will use the set—for example, example.com using ns1.example.com—it is in-bailiwick and needs usable glue at the parent. For a domain using Cloudflare Registrar, the official instructions say to contact Cloudflare Support to add glue.

An out-of-bailiwick name does not inherently need parent glue simply because it is selected as a nameserver. Glue and the name’s authoritative A/AAAA records are distinct; the latter must still be correct. Cloudflare not separately validating parent glue does not mean recursive resolution can work without required glue.

Assign the set, then update registrar or parent-zone delegation

Use PATCH /zones/{zone_id}/dns_settings with nameservers.type set to custom and nameserver_set_id set to the returned ID. Assignment requires at least one of the Zone DNS Settings Write or DNS Write token permissions. Both standard and Advanced Custom sets use type: custom.

Assignment replaces the zone’s existing Cloudflare-branded standard or Advanced nameservers, or its existing nameserver set. It fails if the set’s addresses conflict with a parent, subdomain zone or same-named zone in another account; use a set with a different ip_set.

At the zone’s registrar, set authoritative nameservers to all names in the set. If the zone is delegated through a parent zone, update its NS delegation there. The zone API configuration and the delegation returned by the parent are separate things to inspect; completing one does not establish that the other is updated or fully propagated.

Check activation against each name, not a pooled address list

Without multi-provider DNS, three things must match exactly for activation and continued active status: the parent’s NS name set must equal the selected set; each name’s live A answers must equal its assigned IPv4 addresses; and each name’s live AAAA answers must equal its assigned IPv6 addresses.

Addresses are validated separately for each name. Publishing ns1’s addresses under ns2 cannot satisfy ns1’s requirements, even if the records across the set collectively contain every address. Cloudflare does not separately check parent glue, but in-bailiwick names still need usable glue for recursive resolution.

With multi-provider DNS, the parent’s NS answers must include every expected name, and each name must return all IPv4 and IPv6 addresses assigned to it. Additional names and addresses are allowed. Do not apply that more permissive rule to a zone without multi-provider DNS.

Handle delegation and record propagation before deleting a set

A set cannot be deleted while any zone uses it. The official exit example first changes the zone’s nameserver type back to cloudflare.standard or cloudflare.advanced and updates nameservers at the registrar. A delegation through a parent zone must also be accounted for.

After the delegation or nameserver change propagates, remove obsolete A, AAAA and parent glue records, then wait for those removals to propagate. Only when no zone uses the old set and cleanup has propagated should it be deleted with DELETE /accounts/{account_id}/dns_settings/nameserver_sets/{id}.

Cloudflare does not reserve a deleted set’s name-to-address assignments. A new set may receive different addresses, so deleting first and assuming the same mapping can be recreated is unsafe.

These three pages do not provide DNSSEC DS/key migration instructions, a fixed propagation deadline or specific fees. A signed zone still needs an applicable migration plan checked separately. This explanation is not a complete migration recipe with guaranteed continuity, and it supplies no universal instruction to disable or re-enable DNSSEC.