Cloudflare changes Advanced Nameservers in its DNS API: update strict validators

A representation change can break automation

Cloudflare began changing how its DNS settings API represents Advanced Nameservers on October 26, 2026, according to its official changelog. Website operators using these endpoints for inventory or configuration should review strict response validators. A valid new provider response can otherwise be rejected by an internal client.

The rollout is expected to take seven days. This October 27 report concerns an API representation change, not a reported DNS outage, zone migration or subscription change. It is not a reason to change registrar delegation.

Understand both representations

The earlier representation used foundation_dns: true. The new representation sets nameservers.type to cloudflare.advanced. Before rollout reaches an account, Advanced Nameservers can still be represented as cloudflare.standard; that response alone does not mean the feature was disabled.

Both zone-level and account-level DNS settings endpoints change. Updating one response parser while leaving the other unchanged can therefore leave an integration incomplete. A zone represents a managed domain scope; the account contains broader account settings.

The foundation_dns field remains a deprecated read/write compatibility alias. New writes should use nameservers.type. Requests supplying both must agree or will be rejected. The expected seven-day rollout is not an announced removal deadline for the old field.

Prioritize strict, multi-site clients

Agencies with multi-site scripts, infrastructure-as-code workflows and typed DNS inventories should check first. For example, a validator accepting only standard and custom values might reject advanced while DNS continues working. This is Friday Works’ example of a client failure mode, not a reported customer incident.

Advanced Nameservers are part of Foundation DNS and use anycast network groups and distinct assignment behavior. The October 26 change describes that existing configuration through the API. It does not grant Foundation DNS access to accounts lacking the entitlement.

For manually configured sites that do not use these endpoints, start by consulting the operator. Content, canonicals and sitemaps do not need changes merely because an API value changes. The announcement provides no basis for promising higher search rankings.

Test reads separately from writes

Friday Works recommends retaining a redacted response from infrastructure you manage, then testing parsers against both documented representations. Accepting a new schema value must not become permission to change arbitrary configuration.

Readers must tolerate rollout differences; writers should choose one primary representation and avoid inconsistent dual fields. Validate error handling too: a rejected request must not become a success notification or trigger unnecessary zone recreation.

Cloudflare says entitled accounts can PATCH cloudflare.advanced throughout rollout. Restrict write tests to an owned test zone with a rollback plan. Changing customer-facing delegation is unnecessary for checking this representation.

Monitor the client and the website independently

After updating clients, inspect account and zone GET responses and verify automation finishes correctly. Review deployment and backup scripts as well; they may use separate validators. Preserve relevant error results with secrets removed.

Monitor website reachability separately from JSON decoding. DNS makes the destination reachable to browsers and crawlers, so operational failures can affect crawling, but this announcement does not establish such an outage. The practical benefit is preparing client software without creating one.