Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The rollout that started October 26 is expected to take seven days and covers zone DNS settings and account DNS defaults.
- Until an account reaches the rollout, Advanced Nameservers may still be returned as cloudflare.standard; that does not mean the account lost eligibility.
- Use nameservers.type=cloudflare.advanced for new writes. During the transition, foundation_dns remains a compatibility alias.
- If a PATCH includes both fields, their values must agree or the API rejects the request.
- Cloudflare plans to start removing foundation_dns on November 23, 2026, with an expected seven-day rollout. Migrate integrations ahead of that date.
What changed in the Cloudflare DNS API?
On October 26, 2026, Cloudflare began a gradual rollout that represents Advanced Nameservers with `nameservers.type: "cloudflare.advanced"`. Cloudflare expects this rollout to take seven days, so accounts may see different response values at the same time.
The change affects the zone settings endpoint `/zones/{zone_id}/dns_settings` and the account-default endpoint `/accounts/{account_id}/dns_settings`. If your SDK, control plane or automation reads or writes either setting, review its field mapping and type checks.
Why might Advanced Nameservers still return cloudflare.standard?
Before the rollout reaches an account, Cloudflare says the API may still return Advanced Nameservers as `nameservers.type: "cloudflare.standard"`. That indicates the new response representation has not reached the account; a client should not interpret it as a subscription or feature shutdown.
Cloudflare also says this API representation change does not alter a Foundation DNS subscription or whether Advanced Nameservers are enabled on a zone, and it does not require a zone migration. Keep rollout state separate from existing account eligibility and configuration so the temporary response does not trigger an incorrect write-back.
How should clients handle the new field?
Use `nameservers.type` for new writes. Eligible accounts can PATCH `cloudflare.advanced`; the account-level and zone-level endpoints use the same field concept. Response clients should also add `cloudflare.advanced` to accepted values, especially SDKs, validators and admin tools that use a closed enum.
During the transition, `foundation_dns` remains available for reads and writes as a deprecated compatibility alias. A compatibility layer can continue to recognize the old boolean, but new code should gradually make `nameservers.type` its primary field while retaining any needed legacy reads until the old field is removed.
What if a PATCH sends both fields?
During the transition, a request that includes both `nameservers.type` and `foundation_dns` must express the same state in both fields. Cloudflare rejects conflicting PATCH values. For Advanced Nameservers, do not send `cloudflare.advanced` alongside `foundation_dns: false`.
If an older client still sends the boolean, generate both representations from the same source of truth or gradually stop sending the old field. Avoid calculating each value in a separate settings path, which can produce conflicting requests during an upgrade.
What should integrations change before November 23?
Cloudflare lists November 23, 2026 as the end-of-life date for `foundation_dns` and says the API will begin gradually no longer returning or accepting it from that date. The rollout is expected to take seven days. Complete the client migration before then; do not treat November 23 as a grace period to start changing code.
First widen client enums so `cloudflare.advanced` does not fail parsing. Then update writes and retain legacy-boolean compatibility in reads during the transition. Review both account-default and zone-level API paths, ensure requests cannot send contradictory values, and log any unrecognized type for diagnosis.
Advanced Nameservers still require account eligibility. Acceptance of the new type in PATCH does not grant every plan or account access to Advanced Nameservers, and the field migration does not change entitlements.
Is this a DNS migration or subscription change?
No. This changes how the DNS settings API represents Advanced Nameservers and does not require a zone migration. Cloudflare explicitly says the change does not alter the Foundation DNS subscription or whether a zone has Advanced Nameservers enabled.
The work belongs in integrations that read or write these DNS settings endpoints. Check the account's existing entitlement, then migrate the field handling. Do not describe the API change as a new plan, automatic enablement or an actual DNS cutover.
Sources
Frequently Asked Questions
Should I disable Advanced Nameservers if I read cloudflare.standard during rollout?
Do not disable it based only on that response. Cloudflare says Advanced Nameservers may still be returned as cloudflare.standard before the rollout reaches an account. Evaluate that transitional response separately from the account's entitlement and existing configuration.
How long can I keep using foundation_dns?
The compatibility alias remains readable and writable during the transition. Cloudflare lists November 23, 2026 as its end-of-life date and plans to gradually stop returning or accepting it from that date. Migrate to nameservers.type before then.
Will changing the field enable Foundation DNS on my account?
No. The new type does not change subscriptions or zone entitlements. Advanced Nameservers still require eligibility, and Cloudflare says the API update does not require a zone migration.
Is updating the zone endpoint enough?
If your integration also manages account-level DNS defaults, update its handling for `/accounts/{account_id}/dns_settings` too. Cloudflare says the account-level and zone-level endpoints will adopt the new representation together.