);
})
diff --git a/src/content/changelogs/casb.yaml b/src/content/changelogs/casb.yaml
index defded828c08ab..e51707c9e3d9cf 100644
--- a/src/content/changelogs/casb.yaml
+++ b/src/content/changelogs/casb.yaml
@@ -12,7 +12,7 @@ entries:
- publish_date: "2024-06-03"
title: Atlassian Bitbucket integration
description: |-
- You can now scan their Bitbucket Cloud workspaces for a variety of contextualized security issues such as source code exposure, admin misconfigurations, and more.
+ You can now scan your Bitbucket Cloud workspaces for a variety of contextualized security issues such as source code exposure, admin misconfigurations, and more.
- publish_date: "2024-05-23"
title: Data-at-rest DLP for Box and Dropbox
description: |-
diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/configure-tunnels/origin-configuration.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/configure-tunnels/origin-configuration.mdx
index 4b5e4d62182211..48793581bb7512 100644
--- a/src/content/docs/cloudflare-one/connections/connect-networks/configure-tunnels/origin-configuration.mdx
+++ b/src/content/docs/cloudflare-one/connections/connect-networks/configure-tunnels/origin-configuration.mdx
@@ -180,6 +180,6 @@ access:
required: true
teamName:
audTag:
- - aud1
- - aud2
+ -
+ -
```
diff --git a/src/content/docs/cloudflare-one/policies/gateway/http-policies/file-sandboxing.mdx b/src/content/docs/cloudflare-one/policies/gateway/http-policies/file-sandboxing.mdx
index d5e257970d70f0..53d62923820cb2 100644
--- a/src/content/docs/cloudflare-one/policies/gateway/http-policies/file-sandboxing.mdx
+++ b/src/content/docs/cloudflare-one/policies/gateway/http-policies/file-sandboxing.mdx
@@ -55,6 +55,24 @@ To begin quarantining downloaded files, turn on file sandboxing:
You can now create [Quarantine HTTP policies](/cloudflare-one/policies/gateway/http-policies/#quarantine) to determine what files to scan in the sandbox.
+## Create test policy
+
+To test if file sandboxing is working, you can create a Quarantine policy that matches the [Cloudflare Sandbox Test](https://sandbox.cloudflaredemos.com/):
+
+1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Gateway** > **Firewall policies**, then select **HTTP**.
+2. Select **Add a policy**.
+3. Add the following expression:
+
+ | Selector | Operator | Value | Action |
+ | -------- | -------- | ----------------------------- | ---------- |
+ | Host | is | `sandbox.cloudflaredemos.com` | Quarantine |
+
+4. In **Sandbox file types**, select _ZIP Archive (zip)_.
+5. From a device [connected to your Zero Trust organization](/cloudflare-one/connections/connect-devices/), open a browser and go to the [Cloudflare Sandbox Test](https://sandbox.cloudflaredemos.com/).
+6. Select **Download Test File**.
+
+Gateway will quarantine and scan the file, display an interstitial status page in the browser, then release the file for download.
+
## Compatibility
### Supported file types
diff --git a/src/content/docs/data-localization/compatibility.mdx b/src/content/docs/data-localization/compatibility.mdx
index c238945185342e..9d1381ad9efb3c 100644
--- a/src/content/docs/data-localization/compatibility.mdx
+++ b/src/content/docs/data-localization/compatibility.mdx
@@ -42,14 +42,14 @@ The table below provides a summary of the Data Localization Suite product's beha
| ---------------------------- | --------------- | ----------------- | -------------------------- |
| Advanced Certificate Manager | ⚫️ | ⚫️ | ⚫️ |
| Advanced DDoS Protection | ✅ | ✅ | 🚧 [^3] |
-| API Shield | ✅ | ✅ | ✘ [^4] |
+| API Shield | ✅ | ✅ | 🚧 [^4] |
| Bot Management | ✅ | ✅ | 🚧 [^5] |
-| DNS Firewall | ⚫️ | ⚫️ | 🚧 [^1] |
+| DNS Firewall | ⚫️ | ⚫️ | 🚧 [^22] |
| Page Shield | ✅ | ✅ | ✅ |
-| Rate Limiting | ✅ | ✅ | 🚧 [^1] |
+| Rate Limiting | ✅ | ✅ | ✅ [^37] |
| SSL | ✅ | ✅ | ✅ |
| Cloudflare for SaaS | ✘ | ✅ | ✅ |
-| Turnstile | ⚫️ | ✘ | ✅ |
+| Turnstile | ⚫️ | ✘ | ✅ [^38] |
| WAF/L7 Firewall | ✅ | ✅ | ✅ |
| DMARC Management | ⚫️ | ⚫️ | ✅ |
@@ -60,17 +60,19 @@ The table below provides a summary of the Data Localization Suite product's beha
| Product | Geo Key Manager | Regional Services | Customer Metadata Boundary |
| ---------------------------- | --------------- | ----------------- | -------------------------- |
| Cloudflare Images | ⚫️ | ✅ [^36] | 🚧 [^35] |
-| Cloudflare Pages | ✘ | ✅ [^11] | 🚧 [^1] |
+| AI Gateway | ✘ | ✘ | 🚧 [^39] |
+| Cloudflare Pages | ✅ [^11] | ✅ [^11] | 🚧 [^1] |
+| Cloudflare D1 | ⚫️ | ⚫️ | 🚧 [^40] |
| Durable Objects | ⚫️ | ✅ [^7] | 🚧 [^1] |
| Email Routing | ⚫️ | ⚫️ | ✅ |
| R2 | ✅ [^27] | ✅ [^8] | ✅ [^28] |
| Smart Placement | ⚫️ | ✘ | ✘ |
| Stream | ⚫️ | ✘ | 🚧 [^1] |
-| Workers (deployed on a Zone) | ✅ | ✅ | 🚧 [^1] |
+| Workers (deployed on a Zone) | ✅ | ✅ | 🚧 [^41] |
| Workers AI | ⚫️ | ✘ | ✅ |
| Workers KV | ⚫️ | ✘ | ✅ [^34] |
| Workers.dev | ✘ | ✘ | ✘ |
-
+| Workers Analytics Engine (WAE) | ⚫️ | ⚫️ | 🚧 [^1] |
***
@@ -81,9 +83,10 @@ The table below provides a summary of the Data Localization Suite product's beha
| Argo Smart Routing | ✅ | ✘ [^9] | ✘ [^10] |
| Static IP/BYOIP | ⚫️ | ✅ [^26] | ⚫️ |
| Magic Firewall | ⚫️ | ⚫️ | ✅ |
+| Magic Network Monitoring | ⚫️ | ⚫️ | 🚧 [^1] |
| Magic Transit | ⚫️ | ⚫️ | 🚧 [^1] |
| Magic WAN | ⚫️ | ⚫️ | ✅ |
-| Spectrum | ✅ | ✅ | ✅ |
+| Spectrum | ✅ | ✅ [^42] | ✅ |
***
@@ -112,7 +115,7 @@ The table below provides a summary of the Data Localization Suite product's beha
[^1]: Logs / Analytics not available outside US region when using Customer Metadata Boundary.
[^2]: Regular and Custom Tiered Cache works; Smart Tiered Caching not available with Regional Services.
[^3]: Adaptive DDoS Protection is only supported for US CMB.
-[^4]: API shield will not yet work with Customer Metadata Boundary enabled outside of US region.
+[^4]: Features such as API Discovery and Volumetric Abuse Detection will not work with CMB set to EU only.
[^5]: Some advanced Enterprise features, including the [Anomaly Detection engine](/bots/concepts/bot-score/#anomaly-detection), are not available.
[^6]: Only when using a Custom Domain set to a region, either through Workers or [Transform Rules](/images/transform-images/serve-images-custom-paths/) within the same zone.
[^7]: [Jurisdiction restrictions for Durable Objects](/durable-objects/reference/data-location/#restrict-durable-objects-to-a-jurisdiction).
@@ -126,7 +129,7 @@ The table below provides a summary of the Data Localization Suite product's beha
[^15]: Can be localized to US FedRAMP region only. More regions coming in 2024.
[^16]: Customer Metadata Boundary can be used to limit data transfer outside region, but Access User Logs will not be available outside US region.
[^17]: Currently may only be used with US FedRAMP region.
-[^18]: Only US FedRAMP region.
+[^18]: The only connectivity option is [US FedRAMP region](/cloudflare-one/connections/connect-networks/configure-tunnels/tunnel-run-parameters/#region). Regional Services only applies when using [Public Hostnames](/cloudflare-one/connections/connect-networks/routing-to-tunnel/) set to a region.
[^19]: Uses Gateway HTTP and CASB.
[^20]: You can [bring your own certificate](https://blog.cloudflare.com/bring-your-certificates-cloudflare-gateway/) to Gateway but these cannot yet be restricted to a specific region.
[^21]: Gateway HTTP supports Regional Services. Gateway DNS does not yet support regionalization. ICMP proxy and WARP-to-WARP proxy are not available to Regional Services users.
@@ -142,3 +145,9 @@ The table below provides a summary of the Data Localization Suite product's beha
[^34]: Jurisdictional Restrictions (storage) for Workers KV pairs is not supported today.
[^35]: Logs / Analytics not available outside US region when using Customer Metadata Boundary. Jurisdictional Restrictions (storage) options are not supported today.
[^36]: Only when using a [Custom Domain](/images/manage-images/serve-images/serve-from-custom-domains/) set to a region.
+[^37]: Legacy Zone Analytics & Logs section not available outside US region when using CMB. Use [Security Analytics](/waf/analytics/security-analytics/) instead.
+[^38]: [Turnstile Analytics](/turnstile/turnstile-analytics/) are available. However, there are no regionalization guarantees for the Siteverify API yet.
+[^39]: Jurisdictional Restrictions (storage) options for [Logs](/ai-gateway/observability/logging/) are not supported today.
+[^40]: Jurisdictional Restrictions ([data location](/d1/configuration/data-location/) / storage) options are not supported today.
+[^41]: Logs / Analytics not available outside US region when using Customer Metadata Boundary. Use Logpush instead.
+[^42]: Only applies to HTTP/S Spectrum applications.
diff --git a/src/content/docs/data-localization/metadata-boundary/get-started.mdx b/src/content/docs/data-localization/metadata-boundary/get-started.mdx
index 38474b386df308..e002d916b16c98 100644
--- a/src/content/docs/data-localization/metadata-boundary/get-started.mdx
+++ b/src/content/docs/data-localization/metadata-boundary/get-started.mdx
@@ -22,7 +22,11 @@ To configure Customer Metadata Boundary in the dashboard:
## Configure Customer Metadata Boundary via API
-You can also configure Customer Metadata Boundary via API. These are some examples of API requests.
+You can also configure Customer Metadata Boundary via API.
+
+Currently, only SuperAdmins and Admin roles can edit DLS configurations. Use the **Account-level Logs:Read/Write** API permissions for the `/logs/control/cmb` endpoint to read/write Customer Metadata Boundary configurations.
+
+These are some examples of API requests.
diff --git a/src/content/docs/data-localization/regional-services/get-started.mdx b/src/content/docs/data-localization/regional-services/get-started.mdx
index 881492bab5edf1..d6706eb2c54f83 100644
--- a/src/content/docs/data-localization/regional-services/get-started.mdx
+++ b/src/content/docs/data-localization/regional-services/get-started.mdx
@@ -75,8 +75,11 @@ Refer to the table below for the complete list of available regions and their de
## Configure Regional Services via API
-You can also use Regional Services via API. These are some examples of API requests.
+You can also use Regional Services via API.
+Currently, only SuperAdmins and Admin roles can edit DLS configurations. Use the Zone-level **DNS: Read/Write** API permission for the `/addressing/` endpoint to read or write Regional Services configurations.
+
+These are some examples of API requests.
diff --git a/src/content/docs/dns/additional-options/dns-zone-defaults.mdx b/src/content/docs/dns/additional-options/dns-zone-defaults.mdx
new file mode 100644
index 00000000000000..ab41eb6128202a
--- /dev/null
+++ b/src/content/docs/dns/additional-options/dns-zone-defaults.mdx
@@ -0,0 +1,38 @@
+---
+pcx_content_type: how-to
+title: Zone defaults
+sidebar:
+ order: 3
+---
+
+# Configure DNS zone defaults
+
+While there are default values for DNS settings that Cloudflare applies to all new zones, Enterprise accounts have the option to configure their own DNS zone defaults according to their preference.
+
+:::caution
+DNS zone defaults are only applied at the moment a new zone is created and will not impact already existing zones. Any of the values specified as default can later be adjusted within each zone, on the respective [**DNS** > **Settings**](https://dash.cloudflare.com/?to=/:account/:zone/dns/settings) or [**DNS** > **Records**](https://dash.cloudflare.com/?to=/:account/:zone/dns/records) page.
+:::
+
+## Steps
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login) and select your account.
+2. Go to **Manage Account** > **Configurations** > **DNS Settings**.
+3. For **DNS zone defaults**, select **Configure defaults**.
+
+The values you select for the listed settings will be automatically applied to new zones as you add them to your Cloudflare account.
+
+## Available settings
+
+- [Nameserver assignment](/dns/nameservers/nameserver-options/#assignment-method): Select your preferred nameserver type or assignment method that you want Cloudflare to use for your new zones. This setting applies both to primary zones ([full setup](/dns/zone-setups/full-setup/)) and [secondary zones](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/).
+
+For primary zones:
+
+- [Multi-provider DNS](/dns/nameservers/nameserver-options/#multi-provider-dns): Control whether or not Cloudflare will consider `NS` records you add on the zone apex and if zones that contain external nameservers listed in the registrar will be activated.
+- [Nameserver TTL](/dns/nameservers/nameserver-options/#nameserver-ttl): Control how long, in seconds, your nameserver (`NS`) records are cached. The default time-to-live (TTL) is 24 hours. This setting applies both to Cloudflare nameservers and [custom nameservers](/dns/nameservers/custom-nameservers/).
+- [SOA record](/dns/manage-dns-records/reference/dns-record-types/#soa): Adjust values for the start of authority (SOA) record that Cloudflare creates for your zone.
+
+For secondary zones:
+
+- [Secondary DNS override](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/proxy-traffic/): Enable the options to use Cloudflare [proxy](/dns/manage-dns-records/reference/proxied-dns-records/) and add `CNAME` records at your zone apex.
+
+ Multi-provider DNS does not apply as a setting for secondary zones, as this is already a required behavior for this setup. `SOA` record and the `NS` record TTL are defined on your external DNS provider and only transferred into Cloudflare.
\ No newline at end of file
diff --git a/src/content/docs/dns/additional-options/reverse-zones.mdx b/src/content/docs/dns/additional-options/reverse-zones.mdx
index 29ee8f5cbf76fc..5a43c998a655a0 100644
--- a/src/content/docs/dns/additional-options/reverse-zones.mdx
+++ b/src/content/docs/dns/additional-options/reverse-zones.mdx
@@ -1,8 +1,8 @@
---
pcx_content_type: how-to
title: Reverse zones and PTR records
-weight: 0
-
+sidebar:
+ order: 5
---
import { Details, Example } from "~/components"
diff --git a/src/content/docs/dns/concepts.mdx b/src/content/docs/dns/concepts.mdx
index a29692a9c9c50f..1cf0ac7b4d079b 100644
--- a/src/content/docs/dns/concepts.mdx
+++ b/src/content/docs/dns/concepts.mdx
@@ -9,29 +9,49 @@ head:
---
-This page defines and articulates key concepts that are relevant to the Cloudflare DNS service and are used in this documentation. For more concepts and broader descriptions, check out the [Cloudflare Learning Center](https://www.cloudflare.com/learning/dns/what-is-dns/).
+This page defines and articulates key concepts that are relevant to the Cloudflare DNS service and are used in this documentation. For more concepts and broader descriptions, refer to the [Cloudflare Learning Center](https://www.cloudflare.com/learning/dns/what-is-dns/).
## Domain
-Also known as domain name, a domain is the string of text that identifies a specific website, such as `google.com` or `facebook.com`. Every time you access a website from your web browser, a DNS query takes place and the domain name is mapped to the actual IP address where the website is hosted.
+Also known as domain name, a domain is the string of text that identifies a specific website, such as `google.com` or `facebook.com`. Every time you access a website from your web browser, a DNS query takes place and the DNS service maps the domain to the actual IP address where the website is [hosted](/fundamentals/setup/manage-domains/).
## Registrar
-Before you can start using the Cloudflare DNS service, you must first have a domain. This is achieved by using a service called registrar. As explained in our [Learning Center](https://www.cloudflare.com/learning/dns/glossary/what-is-a-domain-name-registrar/), a registrar handles the reservation of domain names as well as the assignment of IP addresses for those domains.
+Before you can start using the Cloudflare DNS service, you must first have a domain. This is achieved by using a service called registrar. As explained in our [Learning Center](https://www.cloudflare.com/learning/dns/glossary/what-is-a-domain-name-registrar/), a registrar handles the reservation of domain names.
-Cloudflare offers at-cost domain registration through [Cloudflare Registrar](/registrar/).
+Very often the same company that offers domain registration also offers web hosting and DNS management.
-## Zone
+You can register a domain name at cost through [Cloudflare Registrar](/registrar/). Every domain acquired through Cloudflare Registrar must also use Cloudflare as their [primary authoritative DNS](#authoritative-dns).
+
+## Nameserver
-DNS zone is an administrative concept used for delegating control over DNS settings for different domains, subdomains or a set of both. You can read more about this in the [specific Learning Center article](https://www.cloudflare.com/learning/dns/glossary/dns-zone/).
+Although the resolution of a DNS query involves a number of different servers, in this documentation nameserver usually refers to the Cloudflare authoritative nameservers. As explained in the [article about DNS server types](https://www.cloudflare.com/learning/dns/dns-server-types/), the authoritative nameserver is the last stop in the resolution of a DNS query.
-For the purpose of this documentation, keep in mind that each site added to a Cloudflare account is listed in the account home page as a zone. The exact properties and behaviors of your zone depend on its [setup option](/dns/zone-setups/).
+Refer to [Nameservers](/dns/nameservers/) for details on the different nameserver offerings.
-## Nameserver
+## Authoritative DNS
+
+Authoritative DNS refers to the service whose nameservers provide the final information mapping a hostname (such as `example.com` or `blog.example.com`) to the IP address that hosts the corresponding content or resources.
+
+This is important because the performance of such authoritative DNS services determine how available, resilient, and performant your website or application is. Cloudflare DNS is an authoritative DNS service leveraging Cloudflare's global network. Refer to [How Cloudflare works](/fundamentals/concepts/how-cloudflare-works/) for details.
+
+## DNS setups
+
+It is also possible that one same company will use more than one DNS provider. Usually, this relates to making a domain more resilient - if one provider faces an outage, the nameservers operated by the other DNS provider will most likely still be available.
+
+In this context, you can have a primary DNS setup, when you use Cloudflare to manage your DNS records, or a [secondary DNS setup](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/), when your DNS records are managed on a different provider and Cloudflare simply receives zone transfers containing your DNS records.
+
+When you have a primary DNS setup, you can either use only Cloudflare (also known as [Full setup](/dns/zone-setups/full-setup/)), or you can use Cloudflare and another provider, where the other provider is the one to receive [outgoing zone transfers](/dns/zone-setups/zone-transfers/cloudflare-as-primary/) from Cloudflare.
+
+Finally, as Cloudflare also works as a [reverse proxy](/fundamentals/concepts/how-cloudflare-works/#how-cloudflare-works-as-a-reverse-proxy), [partial (CNAME) setups](/dns/zone-setups/partial-setup/) can be used when you do not want Cloudflare to be [authoritative](#authoritative-dns) for your domain but you still want to proxy individual subdomains through Cloudflare.
+
+## Zone
+
+DNS zone is an administrative concept used for delegating control over a given domain and its subdomains. Read more in the ["What is a DNS zone?" Learning Center article](https://www.cloudflare.com/learning/dns/glossary/dns-zone/).
-Although the resolution of a DNS query involves a number of different servers, in this documentation nameserver usually refers to the Cloudflare authoritative nameservers. As explained in the [article about DNS server types](https://www.cloudflare.com/learning/dns/dns-server-types/), the authoritative nameserver is the last stop in the query, the server that returns the IP address for the requested domain.
+For the purpose of this documentation, keep in mind that each domain added to a Cloudflare account is listed in the account home page as a zone. The exact properties and behaviors of your zone depend on its [DNS setup](/dns/zone-setups/).
-When you have a domain using a [full setup](/dns/zone-setups/full-setup/), Cloudflare provides the authoritative nameservers for your domain. Refer to [Nameservers](/dns/nameservers/) for details on the different nameserver offerings.
+Also, different Cloudflare products and features are configurable at the zone level. Refer to [Fundamentals](/fundamentals/setup/manage-domains/connect-your-domain/#domain-configurations) for details.
## DNS records
@@ -43,4 +63,4 @@ For more details about using DNS records within Cloudflare, refer to [Manage DNS
DNSSEC stands for DNS Security Extensions. It increases security by adding cryptographic signatures to DNS records. These signatures can then be checked to verify that a record came from the correct DNS server, preventing anyone else from issuing false DNS records on your behalf and redirecting traffic intended for your domain. You can read more about it in the [article about DNS security](https://www.cloudflare.com/learning/dns/dns-security/).
-For help setting up DNSSEC in Cloudflare, refer to [Enable DNSSEC](/dns/dnssec/).
+For help setting up DNSSEC in Cloudflare, refer to [Enable DNSSEC](/dns/dnssec/).
\ No newline at end of file
diff --git a/src/content/docs/dns/dnssec/multi-signer-dnssec/setup.mdx b/src/content/docs/dns/dnssec/multi-signer-dnssec/setup.mdx
index 5992a27ef72a30..77ab9187a4575b 100644
--- a/src/content/docs/dns/dnssec/multi-signer-dnssec/setup.mdx
+++ b/src/content/docs/dns/dnssec/multi-signer-dnssec/setup.mdx
@@ -1,14 +1,14 @@
---
pcx_content_type: how-to
-title: Setup
+title: Set up multi-signer DNSSEC
sidebar:
order: 5
-head:
- - tag: title
- content: Set up multi-signer DNSSEC
+ label: Setup
---
-This page explains how you can enable [multi-signer DNSSEC](/dns/dnssec/multi-signer-dnssec/) with Cloudflare, using the [model 2](/dns/dnssec/multi-signer-dnssec/about/) as described in [RFC 8901](https://www.rfc-editor.org/rfc/rfc8901.html).
+import { Tabs, TabItem } from "~/components";
+
+This page explains how you can enable [multi-signer DNSSEC](/dns/dnssec/multi-signer-dnssec/about/) with Cloudflare, using the [model 2](/dns/dnssec/multi-signer-dnssec/about/#model-2) as described in [RFC 8901](https://www.rfc-editor.org/rfc/rfc8901.html).
## Before you begin
@@ -20,12 +20,29 @@ Note that:
## 1. Set up Cloudflare zone
-:::note
+### Cloudflare as Primary (full setup)
+
+If you use Cloudflare as a primary DNS provider, meaning that you manage your DNS records in Cloudflare, do the following:
+
+
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login) and select your account and zone.
+2. Go to **DNS** > **Settings**.
+3. Select **Enable DNSSEC** and **Confirm**.
-The following steps also apply if you use [Cloudflare as a secondary DNS provider](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/), with the difference that, in such case, the records in steps 2 and 3 should be transferred from the primary, and step 4 is not necessary.
+:::note
+For the purpose of this tutorial, you will update your registrar with the DS record later, in [Step 3](/dns/dnssec/multi-signer-dnssec/setup/#3-set-up-registrar).
:::
-1. Use the [Edit DNSSEC Status endpoint](/api/operations/dnssec-edit-dnssec-status) to enable DNSSEC and activate multi-signer DNSSEC for your zone. This is done by setting `status` to `active` and `dnssec_multi_signer` to `true`, as in the following example.
+4. Also enable **Multi-signer DNSSEC** and **Multi-provider DNS**.
+5. Go to **DNS** > **Records** and create the following records at your zone apex (meaning you should use `@` in the record **Name** field):
+ - A [DNSKEY record](/dns/manage-dns-records/reference/dns-record-types/#ds-and-dnskey) with the zone signing key(s) (ZSKs) of your external provider(s).
+ - A [NS record](/dns/manage-dns-records/reference/dns-record-types/#ns) with your external provider nameservers.
+
+
+
+
+1. Use the [Edit DNSSEC Status endpoint](/api/operations/dnssec-edit-dnssec-status) to enable DNSSEC and activate multi-signer DNSSEC for your zone. Set `status` to `active` and `dnssec_multi_signer` to `true`, as in the following example.
```bash
curl --request PATCH \
@@ -74,27 +91,68 @@ curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
}'
```
-4. Enable the usage of the nameservers you added in the previous step by using the API request below. Alternatively, go to [**DNS** > **Settings**](https://dash.cloudflare.com/?to=/:account/:zone/dns/settings) and enable **Multi-provider DNS**.
+4. Enable the usage of the nameservers you added in the previous step by using the API request below.
:::caution
+This step is required. Without turning on this setting, Cloudflare will ignore any `NS` records created on the zone apex. This means that responses to DNS queries made to the zone apex and requesting `NS` records will only contain Cloudflare nameservers.
+:::
+
+```bash
+curl --request PATCH \
+"https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_settings" \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "multi_provider": true
+}'
+```
+
+
+
+
+### Cloudflare as Secondary
-This step is required if you are using Cloudflare as a primary DNS provider - without enabling this setting, Cloudflare will ignore any `NS` records created on the zone apex. This means that responses to DNS queries made to the zone apex and requesting `NS` records will only contain Cloudflare nameservers.
+If you use Cloudflare as a secondary DNS provider, do the following:
-If you are using [Cloudflare as a secondary DNS provider](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/), this step is not necessary.
+
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login) and select your account and zone.
+2. Go to **DNS** > **Settings**.
+3. For **DNSSEC with Secondary DNS** select **Live signing**.
+
+:::note
+For the purpose of this tutorial, you will update your registrar with the DS record later, in [Step 3](/dns/dnssec/multi-signer-dnssec/setup/#3-set-up-registrar).
:::
+4. Also enable **Multi-signer DNSSEC**.
+5. Add the zone signing key(s) (ZSKs) of your external provider(s) to a DNSKEY record at your primary DNS provider. This record should be transferred successfully to Cloudflare.
+6. Add your external provider(s) nameservers as NS records on your zone apex at your primary DNS provider. These records should be transferred successfully to Cloudflare.
+
+
+
+
+1. Use the [Edit DNSSEC Status endpoint](/api/operations/dnssec-edit-dnssec-status) to enable DNSSEC and activate multi-signer DNSSEC for your zone. Set `status` to `active` and `dnssec_multi_signer` to `true`, as in the following example.
+
```bash
-curl --request PATCH \
-"https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_settings" \
+$ curl --request PATCH 'https://api.cloudflare.com/client/v4/zones/{zone_id}/dnssec' \
--header "X-Auth-Email: " \
--header "X-Auth-Key: " \
--header "Content-Type: application/json" \
--data '{
- "multi_provider": true
+ "status": "active",
+ "dnssec_multi_signer": true
}'
```
+2. Add the ZSK(s) of your external provider(s) to a DNSKEY record at your primary DNS provider. This record should be transferred successfully to Cloudflare.
+
+3. Add your external provider(s) nameservers as NS records on your zone apex at your primary DNS provider. These records should be transferred successfully to Cloudflare.
+
+
+
+
## 2. Set up external provider
1. Get Cloudflare's ZSK using either the API or a query from one of the assigned Cloudflare nameservers.
@@ -110,7 +168,7 @@ curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/dnssec/zsk" \
Command line query example:
```sh
-dig dnskey @ +noall +answer | grep 256
+$ dig dnskey @ +noall +answer | grep 256
```
2. Add Cloudflare's ZSK that you fetched in the previous step to the DNSKEY record set of your external provider(s).
@@ -120,4 +178,4 @@ dig dnskey @ +noall +answer | grep 256
1. Add DS records to your registrar, one for each provider. You can see your Cloudflare DS record on the [dashboard](https://dash.cloudflare.com/?to=/:account/:zone/dns) by going to **DNS** > **Settings** > **DS Record**.
-2. Update the nameserver settings at your registrar to include the nameservers of all providers you will be using for your multi-signer DNSSEC setup.
+2. Update the nameserver settings at your registrar to include the nameservers of all providers you will be using for your multi-signer DNSSEC setup.
\ No newline at end of file
diff --git a/src/content/docs/dns/get-started.mdx b/src/content/docs/dns/get-started.mdx
index 38c650c99c9a56..edf693a0a0cabd 100644
--- a/src/content/docs/dns/get-started.mdx
+++ b/src/content/docs/dns/get-started.mdx
@@ -2,7 +2,7 @@
title: Get started
pcx_content_type: navigation
sidebar:
- order: 2
+ order: 1
head:
- tag: title
content: Get started with Cloudflare DNS
@@ -11,7 +11,7 @@ head:
import { GlossaryDefinition, Render } from "~/components";
-You can use Cloudflare DNS with a variety of [setups](/dns/zone-setups/).
+You can use Cloudflare DNS with a variety of [setups](/dns/zone-setups/). For an overview of what these setups are and if you are not yet familiar with specific DNS terminology, refer to [Concepts](/dns/concepts/).
In the most common setup (full), you [add your domain](/fundamentals/setup/manage-domains/add-site/), import your [DNS records](/dns/manage-dns-records/), and [update your nameservers](/dns/nameservers/update-nameservers/) to make Cloudflare your primary authoritative DNS provider. Once the setup is completed:
@@ -33,8 +33,6 @@ The following links introduce important concepts and will guide you through acti
- [How Cloudflare works](/fundamentals/concepts/how-cloudflare-works/): An overview of how Cloudflare works as a DNS provider and as a reverse proxy.
-- [DNS concepts](/dns/concepts/): Fundamental concepts to help you understand DNS terminology.
-
- [DNS analytics](/dns/additional-options/analytics/): An overview of the different data sources and insights you can get when using Cloudflare DNS.
- [Troubleshooting](/dns/troubleshooting/): A full resources list for when something is not working.
\ No newline at end of file
diff --git a/src/content/docs/dns/manage-dns-records/reference/dns-record-types.mdx b/src/content/docs/dns/manage-dns-records/reference/dns-record-types.mdx
index 64c86646c37ed2..18d9dca401a360 100644
--- a/src/content/docs/dns/manage-dns-records/reference/dns-record-types.mdx
+++ b/src/content/docs/dns/manage-dns-records/reference/dns-record-types.mdx
@@ -6,7 +6,7 @@ sidebar:
---
-import { Render } from "~/components"
+import { Details, Render } from "~/components"
This page provides information about some of the different types of DNS records that you can manage on Cloudflare. For guidance on how to add, edit, or delete DNS records, refer to [Manage DNS records](/dns/manage-dns-records/how-to/create-dns-records/).
@@ -318,20 +318,73 @@ Within Cloudflare, PTR records are used for reverse DNS lookups and should prefe
### SOA
-A [start of authority (SOA)](https://www.cloudflare.com/learning/dns/dns-records/dns-soa-record/) record stores information about your domain such as admin email address, when the domain was last updated, and more.
+A start of authority (SOA) record stores information about your domain such as admin email address, when the domain was last updated, and more. Refer to [What is a DNS SOA record](https://www.cloudflare.com/learning/dns/dns-records/dns-soa-record/) for an example.
If you are using Cloudflare for your [authoritative DNS](/dns/zone-setups/full-setup/), you do not need to create an SOA record. Cloudflare creates this record automatically when you start using Cloudflare's authoritative nameservers.
-
+If you have an Enterprise account, you also have the option to change the SOA record values that Cloudflare will use.
+You can do that for existing zones by going to **DNS** > **Records** > **DNS record options**, or you can configure your own [DNS zone defaults](/dns/additional-options/dns-zone-defaults/) and define the SOA record values that Cloudflare will use for all new zones added to your account.
+
+Refer to the following list for information about each SOA record field:
+
+
+
+* **`MNAME`**: The primary nameserver for the zone. Secondary nameservers receive zone updates from the nameserver specified in this field.
+* **`RNAME`**: The email address of the administrator responsible for the zone.
+
+ The `@` symbol is replaced by the first dot. If an email address contains a dot before `@`, this should be represented as `\.`.
+
+ | Email | `RNAME` |
+ |---------------------------|-------------------------|
+ |`john@example.com` | `john.example.com` |
+ |`john.doe@example.com` | `john\.doe.example.com` |
+
+* **`Serial`**: The serial number for the zone. Secondary nameservers initiate zone transfers if this number increases.
+* **`Refresh`**: Time (in seconds) after which a secondary nameserver should query the primary for the `SOA` record, to detect zone changes. Only relevant if DNS NOTIFY ([RFC 1996](https://www.rfc-editor.org/rfc/rfc1996.html)) is not configured.
+
+ | Default | Minimum | Maximum |
+ |--------------|------------|----------|
+ |`10000` | `600` | `86400` |
+
+* **`Retry`**: Time (in seconds) after which a secondary nameserver should retry getting the serial number from the primary nameserver after a failed attempt. Any specified values must not be greater than `Refresh`.
+
+ | Default | Minimum | Maximum |
+ |--------------|------------|----------|
+ |`2400` | `600` | `3600` |
+
+* **`Expire`**: Time (in seconds) after which a secondary nameserver should stop answering queries for a zone if the primary does not respond. Any specified values must not be smaller than `Refresh`.
+
+ | Default | Minimum | Maximum |
+ |--------------|------------|-----------|
+ |`604800` | `86400` | `2419200` |
+
+* **`Record TTL`**: The [time to live](/dns/manage-dns-records/reference/ttl/) of the SOA record.
+
+ | Default | Minimum | Maximum |
+ |--------------|------------|----------|
+ |`3600` | `1800` | `3600` |
+
+* **`Minimum TTL`**: The TTL for caching negative responses. Refer to [RFC 2308](https://www.rfc-editor.org/rfc/rfc2308.html#section-4) for details.
+
+ | Default | Minimum | Maximum |
+ |--------------|------------|----------|
+ |`1800` | `60` | `86400` |
+
+
+
### NS
A [nameserver (NS) record](https://www.cloudflare.com/learning/dns/dns-records/dns-ns-record/) indicates which server should be used for authoritative DNS.
-You only need to add NS records when you are [creating custom or vanity nameservers](/dns/nameservers/custom-nameservers/), using [subdomain setup](/dns/zone-setups/subdomain-setup/), or [delegating subdomains outside of Cloudflare](/dns/manage-dns-records/how-to/subdomains-outside-cloudflare/).
+You only need to add NS records to your DNS records table in Cloudflare when you are using [subdomain setup](/dns/zone-setups/subdomain-setup/) or [delegating subdomains outside of Cloudflare](/dns/manage-dns-records/how-to/subdomains-outside-cloudflare/).
+:::note
+Your assigned Cloudflare nameservers, custom nameservers, and their corresponding [nameserver TTLs](/dns/nameservers/nameserver-options/#nameserver-ttl) are controlled via dedicated sections in [**DNS** > **Records**](https://dash.cloudflare.com/?to=/:account/:zone/dns/records). For details, refer to [Nameservers](/dns/nameservers/).
+:::
+
### DS and DNSKEY
[DS and DNSKEY](https://www.cloudflare.com/learning/dns/dns-records/dnskey-ds-records/) records help implement DNSSEC, which cryptographically signs DNS records to prevent domain spoofing.
diff --git a/src/content/docs/dns/manage-dns-records/reference/ttl.mdx b/src/content/docs/dns/manage-dns-records/reference/ttl.mdx
index 9f2336e380d6bf..c964f025023f0c 100644
--- a/src/content/docs/dns/manage-dns-records/reference/ttl.mdx
+++ b/src/content/docs/dns/manage-dns-records/reference/ttl.mdx
@@ -27,3 +27,7 @@ It may take longer than 5 minutes for you to actually experience record changes,
## Unproxied records
For **DNS only** records, you can choose a TTL between **30 seconds** (Enterprise) or **60 seconds** (non-Enterprise) and **1 day**.
+
+## Nameserver TTL
+
+[Nameserver TTL](/dns/nameservers/nameserver-options/#nameserver-ttl) is a separate feature and only affects Cloudflare nameservers and custom nameservers. For other [NS records](/dns/manage-dns-records/reference/dns-record-types/#ns) on your DNS records table, TTL is controlled by their respective TTL fields.
\ No newline at end of file
diff --git a/src/content/docs/dns/nameservers/custom-nameservers/account-custom-nameservers.mdx b/src/content/docs/dns/nameservers/custom-nameservers/account-custom-nameservers.mdx
index 7f86c62d5932f7..3b5e989ac0bd28 100644
--- a/src/content/docs/dns/nameservers/custom-nameservers/account-custom-nameservers.mdx
+++ b/src/content/docs/dns/nameservers/custom-nameservers/account-custom-nameservers.mdx
@@ -10,10 +10,9 @@ head:
description: With account-level custom nameservers, you can use the same custom
nameservers for different zones in the account. The domain or domains that
provide the nameservers names do not have to exist as zones in Cloudflare.
-
---
-import { Example, Render } from "~/components"
+import { Example, Render, Tabs, TabItem } from "~/components"
@@ -25,15 +24,33 @@ For this configuration to be possible, a few conditions apply:
+* Choosing a set from `ns_set 1` through `ns_set 5` will influence how Cloudflare assigns nameservers to your new zones if you configure [DNS zone defaults](/dns/nameservers/nameserver-options/#dns-zone-defaults).
+
## Enable account custom nameservers
### 1. Set up ACNS names and sets
-1. Use the [Add account custom nameserver endpoint](/api/operations/account-level-custom-nameservers-add-account-custom-nameserver) to create account custom nameservers. Follow the [conditions](#configuration-conditions) for `ns_name` and `ns_set`.
+1. Create ACNS names and sets:
+
+
+
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
+2. Go to **Manage Account** > **Configurations** > **DNS Settings**.
+3. For **Account custom nameservers**, select **Configure custom nameservers**.
+4. Insert a fully qualified domain name for **Nameserver name** and choose a **Nameserver set**. Follow the [configuration conditions](#configuration-conditions).
+
+
+
+
+Use the [Add account custom nameserver endpoint](/api/operations/account-level-custom-nameservers-add-account-custom-nameserver) to create account custom nameservers. Follow the [conditions](#configuration-conditions) for `ns_name` and `ns_set`.
-Cloudflare will assign an IPv4 and an IPv6 address to each ACNS name.
+
+
+
+Cloudflare will assign an IPv4 and an IPv6 address to each ACNS name, and these nameservers will be listed as options that you can [use on existing zones](#2-use-acns-on-existing-zones) or [set up as default for new zones in the account](#3-optional-make-acns-default-for-new-zones).
2. Make sure `A/AAAA` records with the assigned IPv4 and IPv6 exist at the authoritative DNS of the domain that provides the ACNS names.
@@ -53,20 +70,53 @@ Cloudflare will assign an IPv4 and an IPv6 address to each ACNS name.
* If you are using Cloudflare Registrar for the domain that provides the ACNS names, [contact Cloudflare Support](/support/contacting-cloudflare-support/) to add the account custom nameservers and IP addresses as glue records to the domain.
- * If you are not using Cloudflare Registrar for the domain that provides the ACNS names, add the account custom nameservers and IP addresses to your domain's registrar as [glue records](https://www.rfc-editor.org/rfc/rfc1912.html#section-2.3). If you do not add these records, DNS lookups for your domain will fail.
+ * If you are not using Cloudflare Registrar for the domain that provides the ACNS names, add the account custom nameservers and IP addresses to your domain's registrar as glue records ([RFC 1912](https://www.rfc-editor.org/rfc/rfc1912.html)). If you do not add these records, DNS lookups for your domain will fail.
### 2. Use ACNS on existing zones
-1. Choose an ACNS set as custom nameservers for a zone. Use the [Set ACNS Related Zone Metadata endpoint](/api/operations/account-level-custom-nameservers-usage-for-a-zone-set-account-custom-nameserver-related-zone-metadata) for each zone.
+1. Choose an ACNS set as custom nameservers for a zone:
+
+
+
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account and zone.
+2. Go to **DNS** > **Records**.
+3. For **Custom nameservers**, select **Configure**.
+4. Select **Use your account custom nameservers** and choose a nameserver set from the list.
+5. Select **Save** to confirm.
+
+
+
+
+Use the endpoint [Update DNS Settings for a Zone](/api/operations/dns-settings-for-a-zone-update-dns-settings) and configure the `nameservers` object accordingly for each zone.
+
+
+
2. Make sure the nameservers are updated:
- * If your domain uses [Cloudflare Registrar](/registrar/), [contact Cloudflare Support](/support/contacting-cloudflare-support/) to update your nameservers.
- * If your domain uses a different registrar or if it has been delegated to a parent domain, manually update your nameservers. Refer to [Update nameservers](/dns/nameservers/update-nameservers/) for detailed guidance.
+ * If your domain uses [Cloudflare Registrar](/registrar/), [contact Cloudflare Support](/support/contacting-cloudflare-support/) to update your nameservers.
+ * If your domain uses a different registrar, update the nameservers at your registrar to use the account custom nameservers.
+ * If your zone is delegated to a parent zone, update the corresponding `NS` record at the parent zone.
### 3. (Optional) Make ACNS default for new zones
-To make these ACNS the default nameservers for all new zones added to your account from now on, use the endpoint [Update DNS Settings for an Account](/api/operations/dns-settings-for-an-account-update-dns-settings). Within the `zone_defaults` object, set the following:
+To make ACNS the default option for all new zones added to your account from now on:
+
+
+
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
+2. Go to **Manage Account** > **Configurations**.
+3. For **DNS zone defaults**, select **Configure defaults**.
+4. Change the **Nameserver assignment method** to **Account custom nameservers**.
+
+Refer to [DNS zone defaults](/dns/nameservers/nameserver-options/#dns-zone-defaults) for details.
+
+
+
+
+Use the endpoint [Update DNS Settings for an Account](/api/operations/dns-settings-for-an-account-update-dns-settings). Within the `zone_defaults` object, set the following:
```txt
"zone_defaults": {
@@ -76,21 +126,45 @@ To make these ACNS the default nameservers for all new zones added to your accou
}
```
+
+
+
## Disable account custom nameservers
### 1. Remove ACNS assignment from zones
To remove ACNS from a zone, first update your nameservers to stop using ACNS:
-* If you are using [Cloudflare Registrar](/registrar/), use the [Set ACNS Related Zone Metadata endpoint](/api/operations/account-level-custom-nameservers-usage-for-a-zone-set-account-custom-nameserver-related-zone-metadata) to change the `enabled` parameter to `false`, and then [contact Cloudflare Support](/support/contacting-cloudflare-support/) to set your nameservers back to the regular Cloudflare-branded nameservers.
-* If you are not using [Cloudflare Registrar](/registrar/), modify the domain's registrar to use your regular Cloudflare-branded nameservers and then use the [Set ACNS Related Zone Metadata endpoint](/api/operations/account-level-custom-nameservers-usage-for-a-zone-set-account-custom-nameserver-related-zone-metadata) to set the `enabled` parameter to `false`.
+
+
-### 2. Delete ACNS names or sets
+* If you are using [Cloudflare Registrar](/registrar/), [contact Cloudflare Support](/support/contacting-cloudflare-support/) to set your nameservers back to the regular Cloudflare branded nameservers.
+* If you are not using [Cloudflare Registrar](/registrar/), modify the domain's registrar to use your regular Cloudflare branded nameservers.
+
+
+
-:::caution
+* If you are using [Cloudflare Registrar](/registrar/), use the [Set ACNS Related Zone Metadata endpoint](/api/operations/account-level-custom-nameservers-usage-for-a-zone-set-account-custom-nameserver-related-zone-metadata) to change the `enabled` parameter to `false`, and then [contact Cloudflare Support](/support/contacting-cloudflare-support/) to set your nameservers back to the regular Cloudflare branded nameservers.
+* If you are not using [Cloudflare Registrar](/registrar/), modify the domain's registrar to use your regular Cloudflare branded nameservers and then use the [Set ACNS Related Zone Metadata endpoint](/api/operations/account-level-custom-nameservers-usage-for-a-zone-set-account-custom-nameserver-related-zone-metadata) to set the `enabled` parameter to `false`.
+
+
+
+
+### 2. Delete ACNS names or sets
Following the [configuration conditions](#configuration-conditions), each set must have between two and five different nameserver names. When you delete all names or leave a set with only one nameserver name, the set will no longer be listed as an option for the zones in your account.
-:::
+
+
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
+2. Go to **Manage Account** > **Configurations** > **DNS Settings**.
+3. For **Account custom nameservers**, select **Delete** next to the ACNS name.
+
+
+
Use the [Delete account custom nameserver endpoint](/api/operations/account-level-custom-nameservers-delete-account-custom-nameserver) to delete a specific ACNS.
+
+
+
\ No newline at end of file
diff --git a/src/content/docs/dns/nameservers/custom-nameservers/index.mdx b/src/content/docs/dns/nameservers/custom-nameservers/index.mdx
index b8e133ea7b4343..87f0369a140695 100644
--- a/src/content/docs/dns/nameservers/custom-nameservers/index.mdx
+++ b/src/content/docs/dns/nameservers/custom-nameservers/index.mdx
@@ -19,7 +19,7 @@ To use custom nameservers, a zone must be using Cloudflare as [Primary (Full set
## Availability
* Zone custom nameservers are available for zones on Business or Enterprise plans. Via API or on the dashboard.
-* Account custom nameservers are available for customers on Business (after [contacting Cloudflare Support](/support/contacting-cloudflare-support/)) or Enterprise plans. Once configured, account custom nameservers can be used by all zones in the account, regardless of the zone plan. Via API only.
+* Account custom nameservers are available for customers on Business (after [contacting Cloudflare Support](/support/contacting-cloudflare-support/)) or Enterprise plans. Once configured, account custom nameservers can be used by all zones in the account, regardless of the zone plan. Via API or on the dashboard.
* Tenant custom nameservers, if created by the tenant owner, will be available to all zones belonging to any account that is part of the tenant. Via API only.
## Restrictions
diff --git a/src/content/docs/dns/nameservers/custom-nameservers/tenant-custom-nameservers.mdx b/src/content/docs/dns/nameservers/custom-nameservers/tenant-custom-nameservers.mdx
index 97d7bca5688328..76f9a347e84592 100644
--- a/src/content/docs/dns/nameservers/custom-nameservers/tenant-custom-nameservers.mdx
+++ b/src/content/docs/dns/nameservers/custom-nameservers/tenant-custom-nameservers.mdx
@@ -91,7 +91,7 @@ curl https://api.cloudflare.com/client/v4/tenants/{tenant_id}/custom_ns \
-2. Add the account custom nameservers and IP addresses to your domain's registrar as [glue (A and AAAA) records](https://www.rfc-editor.org/rfc/rfc1912.html#section-2.3)
+2. Add the account custom nameservers and IP addresses to your domain's registrar as glue (A and AAAA) records ([RFC 1912](https://www.rfc-editor.org/rfc/rfc1912.html)).
3. If the domain or domains that are used for the tenant custom nameservers do not exist within the same account, you must create the `A/AAAA` records on the configured nameserver names (for example, `ns1.example.com`) at the authoritative DNS provider.
diff --git a/src/content/docs/dns/nameservers/custom-nameservers/zone-custom-nameservers.mdx b/src/content/docs/dns/nameservers/custom-nameservers/zone-custom-nameservers.mdx
index eac06f9b0c7241..107479c0057363 100644
--- a/src/content/docs/dns/nameservers/custom-nameservers/zone-custom-nameservers.mdx
+++ b/src/content/docs/dns/nameservers/custom-nameservers/zone-custom-nameservers.mdx
@@ -28,7 +28,9 @@ To create zone custom nameservers:
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account and zone.
2. Go to **DNS** > **Records**.
-3. On **Custom Nameservers**, click **Add Custom Nameservers** and enter the subdomains used for the ZCNS names (for example, `ns1`, `ns2`, `ns3`).
+3. On **Custom nameservers**, select **Configure**.
+4. Select **Create custom nameservers just for `your-domain.com`** and enter the subdomains used for the ZCNS names (for example, `ns1`, `ns2`, `ns3`).
+5. Select **Save** to confirm.
@@ -40,20 +42,19 @@ Use the [Edit zone endpoint](/api/operations/zones-0-patch) and specify the cust
-Cloudflare will assign an IPv4 and an IPv6 address to each ZCNS name and automatically create the associated `A` or `AAAA` records (visible after you refresh the page).
+Cloudflare will assign an IPv4 and an IPv6 address to each ZCNS name and automatically create the associated `A` or `AAAA` records.
The next step depends on whether you are using [Cloudflare Registrar](/registrar/) for your domain:
- If you are using Cloudflare Registrar for your domain, [contact Cloudflare Support](/support/contacting-cloudflare-support/) to add the custom nameservers and IP addresses as glue records to the domain.
-- If you are not using Cloudflare Registrar for your domain, add the zone custom nameservers at your registrar as your authoritative nameservers and as [glue (A and AAAA) records](https://www.rfc-editor.org/rfc/rfc1912.html#section-2.3). If you do not add these records, DNS lookups for your domain will fail.
-
+- If you are not using Cloudflare Registrar for your domain, add the zone custom nameservers at your registrar as your authoritative nameservers and as glue (A and AAAA) records ([RFC 1912](https://www.rfc-editor.org/rfc/rfc1912.html)). If you do not add these records, DNS lookups for your domain will fail.
### Secondary zones
If you are using [Cloudflare as a secondary DNS provider](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/), you can still set up zone custom nameservers. After following the [steps above](/dns/nameservers/custom-nameservers/zone-custom-nameservers/#primary-full-setup-zones) to create zone custom nameservers, do the following:
1. Get the ZCNS IPs. You can see them on the dashboard (**DNS** > **Records**) or you can use the [Zone details endpoint](/api/operations/zones-0-get) to get the `vanity_name_servers_ips`.
2. At your primary DNS provider, add [`NS` records](/dns/manage-dns-records/reference/dns-record-types/#ns) and, on the subdomains that you used as ZCNS names, add `A/AAAA` records.
-3. At your registrar, add the zone custom nameservers as your authoritative nameservers and as [glue (A and AAAA) records](https://www.rfc-editor.org/rfc/rfc1912.html#section-2.3).
+3. At your registrar, add the zone custom nameservers as your authoritative nameservers and as glue (A and AAAA) records ([RFC 1912](https://www.rfc-editor.org/rfc/rfc1912.html)).
## Remove zone custom nameservers
@@ -63,7 +64,7 @@ To remove zone custom nameservers (and their associated, read-only DNS records):
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account and zone.
2. Go to **DNS** > **Records**.
-3. On **Custom nameservers**, select **Remove custom nameservers**.
+3. On **Custom nameservers**, select **Disable**.
diff --git a/src/content/docs/dns/nameservers/index.mdx b/src/content/docs/dns/nameservers/index.mdx
index 80c791f2f0ff32..6d1adfb7dfb908 100644
--- a/src/content/docs/dns/nameservers/index.mdx
+++ b/src/content/docs/dns/nameservers/index.mdx
@@ -20,7 +20,7 @@ Regardless of the type you choose, for these nameservers to be authoritative for
### Standard nameservers
-When you add a domain on a [primary (full)](/dns/zone-setups/full-setup/) DNS setup, Cloudflare automatically assigns two standard nameservers for your zone.
+Unless your account has a specific [DNS zone defaults](/dns/additional-options/dns-zone-defaults/) configuration, when you add a domain on a [primary (full)](/dns/zone-setups/full-setup/) or [secondary](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/) DNS setup, Cloudflare automatically assigns two standard nameservers for your zone.
Standard nameservers are hosted on `ns.cloudflare.com` and follow the pattern `.ns.cloudflare.com`.
diff --git a/src/content/docs/dns/nameservers/nameserver-options.mdx b/src/content/docs/dns/nameservers/nameserver-options.mdx
index 303810d45d36b2..327d70e20e8ae6 100644
--- a/src/content/docs/dns/nameservers/nameserver-options.mdx
+++ b/src/content/docs/dns/nameservers/nameserver-options.mdx
@@ -10,9 +10,25 @@ import { Example } from "~/components"
Refer to the sections below to learn about different nameserver options.
+## Assignment method
+
+When you add a domain on a full or secondary setup, Cloudflare automatically assigns your nameservers.
+
+The [default assignment method](/dns/zone-setups/reference/nameserver-assignment/) is to use standard nameservers and favor consistent nameserver names across all zones within an account. Nonetheless, in case there are conflicts - for example, if someone else has already added the same zone to a different account - you may get different nameserver names.
+
+To have control over what nameservers are assigned for different zones within an account, you can use [account custom nameservers](/dns/nameservers/custom-nameservers/account-custom-nameservers/).
+
+### DNS zone defaults
+
+If you have an Enterprise account, you also have the option to [configure your own DNS zone defaults](/dns/additional-options/dns-zone-defaults/) and change how Cloudflare handles nameserver assignment when you add a new zone to your account:
+
+- **Standard nameservers randomized**: instead of attempting consistency, Cloudflare assigns random pairs of nameserver names every time you add a new domain to your account.
+- **Advanced nameservers**: Cloudflare uses the same method as the default - trying to keep nameserver names consistent for different zones within an account - but uses the specific [Foundation DNS nameservers](/dns/foundation-dns/advanced-nameservers/).
+- **Account custom nameservers**: Cloudflare automatically assigns a set of [account custom nameservers](/dns/nameservers/custom-nameservers/account-custom-nameservers/) that you have previously configured for your account. In this method, **Set 1** will be attempted first and, in case of any conflicts, Cloudflare will cycle through the other nameserver sets, in ascending order.
+
## Multi-provider DNS
-Multi-provider DNS is an optional setting for zones using [full setup](/dns/zone-setups/full-setup/) and is an enforced default behaviour for zones using [secondary setup](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/).
+Multi-provider DNS is an optional setting for zones using [full setup](/dns/zone-setups/full-setup/) and is an enforced default behavior for zones using [secondary setup](/dns/zone-setups/zone-transfers/cloudflare-as-secondary/).
When you enable multi-provider DNS on a primary (full setup) zone:
@@ -32,6 +48,14 @@ This means that responses to DNS queries made to the zone apex and requesting `N
:::caution
-If you choose this option, you should also make sure to set up [multi-signer DNSSEC](/dns/dnssec/multi-signer-dnssec/).
+If you choose this option and you also want to use DNSSEC on your zone, make sure to set up [multi-signer DNSSEC](/dns/dnssec/multi-signer-dnssec/).
+
+:::
+
+## Nameserver TTL
+
+For both Cloudflare nameservers (standard or advanced) and custom nameservers, the `NS` record time-to-live (TTL) is controlled by the specific setting in **DNS** > **Records** > **DNS record options**.
+
+The default TTL is 24 hours (or 86,400 seconds), but you have the option to lower this value depending on your needs. For example, shorter TTLs can be useful when you are changing nameservers or migrating a zone. Accepted values range from 30 to 86,400 seconds.
-:::
\ No newline at end of file
+This setting can also be configured as a [DNS zone default](/dns/additional-options/dns-zone-defaults/), meaning new zones created in your account will automatically start with the value you define.
\ No newline at end of file
diff --git a/src/content/docs/dns/zone-setups/index.mdx b/src/content/docs/dns/zone-setups/index.mdx
index a90b0892e3c284..d57f9fd1777ab7 100644
--- a/src/content/docs/dns/zone-setups/index.mdx
+++ b/src/content/docs/dns/zone-setups/index.mdx
@@ -1,9 +1,8 @@
---
pcx_content_type: concept
-title: Zone setups
+title: DNS setups
sidebar:
order: 3
-
---
import { Details } from "~/components"
@@ -40,7 +39,7 @@ If you are on a Free or Pro plan, [full setup](/dns/zone-setups/full-setup/) is
If you are on a Business or Enterprise plan, you can use [partial (CNAME) setup](/dns/zone-setups/partial-setup/) to keep your primary DNS provider and only proxy individual subdomains through Cloudflare.
-If you are on an Enterprise plan, you also have the option to use [zone transfers](/dns/zone-setups/zone-transfers/) to set up Cloudflare as either a primary or a secondary DNS provider.
+If you are on an Enterprise plan, you also have the option to use [zone transfers](/dns/zone-setups/zone-transfers/) to set up Cloudflare as either a primary or a secondary DNS provider.
diff --git a/src/content/docs/dns/zone-setups/reference/nameserver-assignment.mdx b/src/content/docs/dns/zone-setups/reference/nameserver-assignment.mdx
index ffd70aca7be951..f0cb516ee5fd75 100644
--- a/src/content/docs/dns/zone-setups/reference/nameserver-assignment.mdx
+++ b/src/content/docs/dns/zone-setups/reference/nameserver-assignment.mdx
@@ -8,16 +8,14 @@ When you add a domain on a [primary (full)](/dns/zone-setups/full-setup/) or [se
Each domain's assigned nameservers may be different than other domains, even if those domains are within the same account.
-These nameserver assignments cannot be changed unless you set up [custom or vanity nameservers](/dns/nameservers/custom-nameservers/).
+These nameserver assignments cannot be changed. However, depending on your subscription, you may have different options to [control the nameservers assignment method](/dns/nameservers/nameserver-options/#assignment-method) or to use your own [custom nameservers](/dns/nameservers/custom-nameservers/).
:::caution
-
To prevent domain hijacking, you can no longer preset Cloudflare nameservers at your registrar before creating the respective zone in Cloudflare. If you preset your nameservers and then add the domain, your domain will be assigned a new pair of nameservers.
To keep the same nameservers across your domains, use [Account custom nameservers](/dns/nameservers/custom-nameservers/account-custom-nameservers/).
-
:::
For more background on nameserver assignments, refer to [our blog](https://blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers/).
diff --git a/src/content/docs/dns/zone-setups/zone-transfers/cloudflare-as-primary/setup.mdx b/src/content/docs/dns/zone-setups/zone-transfers/cloudflare-as-primary/setup.mdx
index add064c80c8c37..0bd55c4b963726 100644
--- a/src/content/docs/dns/zone-setups/zone-transfers/cloudflare-as-primary/setup.mdx
+++ b/src/content/docs/dns/zone-setups/zone-transfers/cloudflare-as-primary/setup.mdx
@@ -116,7 +116,11 @@ It should also have updated [Access Control Lists (ACLs)](/dns/zone-setups/zone-
Using the information from your secondary DNS provider, [create `NS` records](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) on your zone apex listing your secondary nameservers.
-By default, Cloudflare ignores `NS` records that are added to the zone apex. To modify this behaviour, enable [multi-provider DNS](/dns/nameservers/nameserver-options/#multi-provider-dns):
+By default, Cloudflare ignores `NS` records added to the zone apex. To modify this behavior, enable [multi-provider DNS](/dns/nameservers/nameserver-options/#multi-provider-dns):
+
+:::note
+If your account [zone defaults](/dns/additional-options/dns-zone-defaults/) are already defined to have **Multi-provider DNS** enabled, this step may not be necessary.
+:::
@@ -127,6 +131,8 @@ By default, Cloudflare ignores `NS` records that are added to the zone apex. To
+Send the following `PATCH` request replacing the placeholders with your zone ID and authentication information:
+
```bash
curl --request PATCH \
"https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_settings" \
diff --git a/src/content/docs/email-routing/email-workers/send-email-workers.mdx b/src/content/docs/email-routing/email-workers/send-email-workers.mdx
index 97651902c2b798..df307bbf3ae848 100644
--- a/src/content/docs/email-routing/email-workers/send-email-workers.mdx
+++ b/src/content/docs/email-routing/email-workers/send-email-workers.mdx
@@ -16,7 +16,7 @@ import { WranglerConfig } from "~/components";
```toml
send_email = [
- {type = "send_email", name = "", destination_address = "@example.com"},
+ {name = "", destination_address = "@example.com"},
]
```
diff --git a/src/content/docs/hyperdrive/get-started.mdx b/src/content/docs/hyperdrive/get-started.mdx
index 8fbfb622cb295d..c172656857ce97 100644
--- a/src/content/docs/hyperdrive/get-started.mdx
+++ b/src/content/docs/hyperdrive/get-started.mdx
@@ -175,7 +175,7 @@ To connect to your database, you will need a database driver which allows you to
To install `postgres`, ensure you are in the `hyperdrive-tutorial` directory. Open your terminal and run the following command:
-
+
With the driver installed, you can now create a Worker script that queries your database.
@@ -190,7 +190,7 @@ The `index.ts` file is where you configure your Worker's interactions with Hyper
Populate your `index.ts` file with the following code:
```typescript
-// Postgres.js 3.4.4 or later is recommended
+// Postgres.js 3.4.5 or later is recommended
import postgres from "postgres";
export interface Env {
diff --git a/src/content/docs/magic-transit/get-started.mdx b/src/content/docs/magic-transit/get-started.mdx
index 226d4efd15cc62..ddaf2fc09ace4f 100644
--- a/src/content/docs/magic-transit/get-started.mdx
+++ b/src/content/docs/magic-transit/get-started.mdx
@@ -43,7 +43,7 @@ The LOA must be a PDF. Transit providers may reject the LOA if it is a JPG or PN
### Verify IRR entries
-Verify your Internet Routing Registry (IRR) entries match corresponding origin autonomous system numbers (ASNs) to ensure Magic Transit routes traffic to the correct autonomous systems (AS). For guidance, refer to [Verify IRR entries](/byoip/concepts/irr-entries/best-practices/#verify-an-irr-entry).
+Verify that your Internet Routing Registry (IRR) entries match your corresponding origin autonomous system numbers (ASNs) to ensure Magic Transit routes traffic to the correct autonomous systems (AS). For guidance, refer to [Verify IRR entries](/byoip/concepts/irr-entries/best-practices/#verify-an-irr-entry).
If you are using a Cloudflare IP, you do not need to verify your IRR entries.
diff --git a/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx b/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx
index 2146172f240606..663299c43dd66b 100644
--- a/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx
+++ b/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx
@@ -39,14 +39,17 @@ If you do not have an ASN or do not want to bring your ASN to Cloudflare, you ca
Current customers who are still using Cloudflare's AS209242 can continue using this same ASN. No further change is required.
:::
-## Add an IP prefix
+## Advertise your prefix
+
+:::note
+You can only advertise your prefix [after running pre-flight checks](/magic-transit/get-started/#5-run-pre-flight-checks) with Cloudflare. If your prefix status is greyed out and shows an _Withdrawn_ status, your prefix is locked. Contact your account team to close the pre-flight checks phase with you and unlock your prefixes.
+:::
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login), and select your account.
2. Go to **Magic Transit** > **Configuration**.
-3. From the **IP Prefixes** tab, select **Create**.
-4. Fill out the information for your prefix and select **Add IP Prefix**.
-
-After you add the prefix, you can edit its status.
+3. From the **IP Prefixes** tab select your prefix > **Edit**.
+4. Under **Status**, select _Advertise_ to advertise your prefix.
+5. Select **Edit Prefix** to save your changes.
## Edit the status of a prefix
@@ -55,9 +58,9 @@ After you add the prefix, you can edit its status.
3. _(Optional)_ Edit the description for your prefix.
4. Select **Edit IP Prefix** to save your changes.
-:::note[Note:]
To avoid latency and potentially dropped routes, enable prefix advertisement from Cloudflare before withdrawing the advertisement from your data center.
-:::
+
+You should also be aware that announcing or withdrawing a prefix should propagate across Cloudflare's global network almost instantly, with changes typically taking effect within a few minutes at most. However, Cloudflare has no control over how long ISPs take to refresh their routes. Keep this in mind when announcing or withdrawing a prefix from your account, and plan accordingly.
## Delete a prefix
@@ -66,10 +69,6 @@ You can only delete a prefix with an **Unapproved** status. To delete prefixes w
1. From the **IP Prefixes** tab, locate the prefix you want to modify and select **Delete**.
2. Confirm your choice from the modal by selecting **Delete**.
-:::note
-Withdrawing a prefix should propagate across Cloudflare's global network almost instantly, with changes typically taking effect within a few minutes at most. However, Cloudflare has no control over how long ISPs take to refresh their routes. Keep this in mind when announcing or withdrawing a prefix from your account, and plan accordingly.
-:::
-
## Border Gateway Protocol (BGP) control for advertisements
Use BGP to control the advertisement status of your prefix - advertised or withdrawn - from Cloudflare's global network for on-demand deployment scenarios. BGP Control works by establishing BGP sessions to Cloudflare's globally distributed Route Reflectors, which will initiate propagation of your prefix advertisement across Cloudflare's global network.
diff --git a/src/content/docs/r2/api/workers/workers-api-reference.mdx b/src/content/docs/r2/api/workers/workers-api-reference.mdx
index 104f2c27919019..ce0539010e6bd5 100644
--- a/src/content/docs/r2/api/workers/workers-api-reference.mdx
+++ b/src/content/docs/r2/api/workers/workers-api-reference.mdx
@@ -87,6 +87,7 @@ export default {
- Deletes the given values and metadata under the associated keys. Once the delete succeeds, returns void.
- R2 deletes are strongly consistent. Once the Promise resolves, all subsequent read operations will no longer see the provided key value pairs globally.
+ - Up to 1000 keys may be deleted per call.
- `list`
diff --git a/src/content/docs/reference-architecture/diagrams/network/optimizing-roaming-experience-with-geolocated-ips.mdx b/src/content/docs/reference-architecture/diagrams/network/optimizing-roaming-experience-with-geolocated-ips.mdx
new file mode 100644
index 00000000000000..25672dca3c858f
--- /dev/null
+++ b/src/content/docs/reference-architecture/diagrams/network/optimizing-roaming-experience-with-geolocated-ips.mdx
@@ -0,0 +1,68 @@
+---
+title: Optimizing device roaming experience with geolocated IPs
+pcx_content_type: reference-architecture-diagram
+products:
+ - Magic WAN
+ - Gateway
+sidebar:
+ order: 1
+ label: Device roaming with geolocated IPs
+updated: 2024-12-13
+---
+
+## Introduction
+
+A private [Access Point Name](https://en.wikipedia.org/wiki/Access_Point_Name) (APN) enables devices, like connected vehicles, connected containers, healthcare devices or drones, to be connected while roaming across different countries. The device connects with a SIM or eSIM card to a dedicated network, and as the device moves to a new country, it automatically selects the appropriate private APN for the local provider.
+
+APN traffic, typically managed by a third party provider such as a telecommunications company, is routed through specific regional Internet breakouts to get access to the Internet. This architecture can create challenges in regards to the localization of that traffic. For example, a device roaming in France might have traffic exit to the Internet from a UK-based Internet breakout. Therefore web sites and other Internet services will treat the device as if it is in the UK and deliver content in the wrong language or apply regional restrictions.
+
+In this document, we'll discuss how Cloudflare can be used to solve this problem and will use the example of a service provider using private mobile networks (APNs) to connect devices roaming across multiple countries through regional Internet breakouts. This use case is relevant to global enterprises with regional offices, transportation fleets with connected vehicles, or any organization needing to maintain consistent, secure, and region-specific connectivity for roaming devices.
+
+
+
+# Correctly locate and secure devices by connecting them to the Cloudflare global network
+
+Cloudflare addresses these challenges by routing device traffic from the Internet breakout to our global network, where traffic is processed at a Cloudflare data center close to the Internet breakout. This allows for two benefits:
+
+1. Cloudflare can analyse the traffic, determine the original country of origin, and then ensure that traffic egresses onto the Internet from an IP address that is geolocated to the same country of origin.
+2. Cloudflare can filter traffic based on [secure web gateway](/cloudflare-one/policies/gateway/) policies, allowing you to protect devices from accessing risky Internet hosts. It also allows you to lock down access for devices to specific Internet hosts, such as only allow devices to make requests to APIs that support their function.
+
+The architecture diagram below provides a visual representation of this solution, showing how traffic from various countries — routed via different mobile network APN — is directed through Internet breakouts. Cloudflare optimizes and secures the Internet connection by leveraging [geolocated public IPs](/cloudflare-one/policies/gateway/egress-policies/dedicated-egress-ips/), ensuring that the traffic is secure and regionally localized to the device location.
+
+This diagram is intended for network engineers, IT architects, and decision-makers looking to improve service relevance and performance for end-users. Key use cases include multinational corporations aiming to provide faster, region-specific Internet access and services in users' native languages, ensuring a superior user experience across diverse geographical locations.
+
+
+
+1. **Data collection and regional routing**.
+
+ Traffic from roaming devices is securely collected through the service provider's private APN and routed to third-party regional Internet breakouts. Each country in the network is assigned a specific RFC1918 IP subnet, simplifying traffic segmentation and management.
+
+2. **Traffic sorting**.
+
+ The Internet breakout will categorize the traffic into separate buckets to identify its country of origin \- in this example each country's APN is given a dedicated private IP subnet.
+
+3. **Connectivity options**.
+
+ Cloudflare supports multiple connection methods to integrate with the regional breakout architecture:
+
+ - [**GRE tunnels**](/magic-wan/reference/tunnels/) for ease of use.
+ - [**IPsec tunnels**](/magic-wan/reference/tunnels/) for encrypted communication.
+ - [**Cloudflare Network Interconnect (CNI)**](/magic-wan/network-interconnect/) for direct, high-performance connections.
+
+4. **Localized Internet breakout using [Magic WAN](/magic-wan/) and [Gateway](/cloudflare-one/policies/gateway/)**.
+
+ With Magic WAN and using [dedicated egress](/cloudflare-one/policies/gateway/egress-policies/dedicated-egress-ips/) with our [secure web gateway](/cloudflare-one/policies/gateway/), Cloudflare enables Internet traffic to exit with source IPs registered in the desired country. This ensures end-users benefit from geolocalized content and services, such as access to region-specific platforms, tailored to their location.
+
+5. **Advanced security and filtering options**.
+
+ Cloudflare enhances the security of Internet breakouts with advanced features, including:
+
+ - [**DNS filtering**](/cloudflare-one/policies/gateway/initial-setup/dns/) to manage and block access to unwanted, high risk domains.
+ - [**Network firewalling**](/cloudflare-one/policies/gateway/network-policies/) for enforcing detailed security policies. For example, you can restrict vehicles to only send data over the Internet to a designated set of cloud telemetry systems while blocking all other traffic.
+ - [**Full SSL inspection**](/cloudflare-one/policies/gateway/http-policies/tls-decryption/) to protect against sophisticated threats and provide traffic visibility on encrypted traffic. It enables additional protections such as antivirus scanning, malware prevention, and file sandboxing.
+
+# Related Resources
+
+- [Gateway](/cloudflare-one/policies/gateway/)
+- [Magic WAN](/magic-wan/)
+- [Cloudflare servers don't own IPs anymore](https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-anymore/)
diff --git a/src/content/docs/speed/optimization/content/speed-brain.mdx b/src/content/docs/speed/optimization/content/speed-brain.mdx
index 623b4de0fe4d46..c87ccf1a9107ae 100644
--- a/src/content/docs/speed/optimization/content/speed-brain.mdx
+++ b/src/content/docs/speed/optimization/content/speed-brain.mdx
@@ -99,7 +99,7 @@ To disable Speed Brain, set `value:` to `"off"`.
-You can also configure Speed Brain using Terraform. For more details, refer to the [`cloudflare_zone_settings_override` resource](https://registry.terraform.io/providers/cloudflare/cloudflare/4.43.0/docs/resources/cloudflare_zone_settings_override) in the Terraform documentation.
+You can also configure Speed Brain using Terraform. For more details, refer to the [`cloudflare_zone_settings_override`](https://registry.terraform.io/providers/cloudflare/cloudflare/4.48.0/docs/resources/zone_settings_override) resource in the Terraform documentation.
@@ -115,4 +115,4 @@ You can also configure Speed Brain using Terraform. For more details, refer to t
- Speed Brain will not work with restrictive [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) configurations using `strict-dynamic` or `nonce-{hash}` attributes.
-- Currently, Speed Brain is not compatible with websites that use or rely on `pages.dev`.
\ No newline at end of file
+- Currently, Speed Brain is not compatible with websites that use or rely on `pages.dev`.
diff --git a/src/content/docs/support/troubleshooting/http-status-codes/1xx-informational.mdx b/src/content/docs/support/troubleshooting/http-status-codes/1xx-informational.mdx
index 0d4e7db823ca64..ba9aae95f3f76d 100644
--- a/src/content/docs/support/troubleshooting/http-status-codes/1xx-informational.mdx
+++ b/src/content/docs/support/troubleshooting/http-status-codes/1xx-informational.mdx
@@ -5,26 +5,49 @@ title: 1xx Informational
---
-## Overview
+The 1xx Informational status codes serve as interim responses that provide connection status updates without completing the request-response cycle. These codes are not intended for final actions but rather to indicate that the request is being processed or additional steps are required.
-1xx codes are often interim responses for sharing connection status information. Not intended for final request or response action. Requirements from the server:
+The requirements the server must follow when sending 1xx Informational status codes in response to a client's request include:
-* Responses all terminated by the first empty line after status line
+- Responses must be terminated by the first empty line following the status line.
+- 1xx responses are not supported by HTTP/1.0; the origin server should never send a 1xx response to an HTTP/1.0 client.
-* Not used for HTTP 1.0. Origin server should never send 1xx response to HTTP 1.0 client
+Cloudflare forwards all 1xx responses from origin servers but does not generate them directly.
-Cloudflare will forward all of these responses and never generates this response.
+## 100 Continue ([RFC7231](https://tools.ietf.org/html/rfc7231))
-**100 Continue (**[**RFC7231**](https://tools.ietf.org/html/rfc7231)**)**
+The 100 Continue status indicates that the server has received the request headers and is ready for the client to send the request body.
-Confirmation of the initial request to send a response body. The origin server is willing to accept the request (based on the request headers). This is returned before the client typically sends the response body. This prevents clients from sending unnecessary or unusable data. Required from server: If the client sends `Expect: 100-continue` header, the server must respond immediately with either `100 Continue` and continue to read from the input stream or send another response code. Cloudflare uses Keep-Alive connections so this response should not be necessary
+### Common use cases
-**101 Switching Protocols (**[**RFC7231**](https://tools.ietf.org/html/rfc7231)**)**
+Allows clients to verify if the server will accept their request headers before sending a potentially large or unusable request body, optimizing data flow.
-Origin server accepts the client’s request to switch protocols. Client request either contained `Upgrade` in a header field or there was a change in the application protocol being used on this connection. If using Upgrade header field, the server has agreed to upgrade to a protocol that is higher on the client’s priority list than the current protocol being used. Origin server must also respond with a `Upgrade` header field to indicate the new protocol(s) to which the connection is being switched It is assumed that this switch will be advantageous to both the client and the server. Most common use case is with websockets. For information about Cloudflare’s Websockets, refer to [Cloudflare Now Supports Websockets](https://blog.cloudflare.com/cloudflare-now-supports-websockets/).
+When a client includes the `Expect: 100-continue` header, it is requesting a confirmation before sending the request body, prompting the server to respond immediately with either `100 Continue` to proceed or an appropriate status code (for example, `401 Unauthorized` or `413 Payload Too Large`) if the request is unacceptable.
-**102 Processing (**[**RFC2518**](https://tools.ietf.org/html/rfc2518)**)**
+### Cloudflare-specific information
-Server has received the client’s completed response, but is expecting to take more time to process ( e.g. > 20 seconds). The server must send a final response after the request has been completed. Used for only HTTP 1.1 and higher.
+Cloudflare uses Keep-Alive connections to maintain persistent communication between clients and servers, making the `100 Continue` response typically unnecessary, as Keep-Alive reduces overhead and eliminates the need for intermediate confirmations.
-If Cloudflare does not receive a response in 100 seconds or less after a 102, an [Error 522: Connection Timed Out](https://support.cloudflare.com/hc/articles/115003011431#522error) will be generated. 102 responses can be used to prevent [Error 524: A timeout error](https://support.cloudflare.com/hc/articles/115003011431#524error).
+## 101 Switching Protocols ([RFC7231](https://tools.ietf.org/html/rfc7231))
+
+The 101 Switching Protocols status code indicates that the origin server accepts the client's request to switch protocols.
+
+### Common use cases
+
+The 101 Switching Protocols status code indicates that the server has accepted the client's request to change protocols, either by including an `Upgrade` header or through a change in the application protocol on the connection. When the `Upgrade` header is used, the server agrees to switch to a protocol higher on the client's priority list and responds with an `Upgrade` header to specify the new protocol(s). This change is assumed to benefit both the client and the server, with WebSockets being the most common use case.
+
+### Cloudflare-specific information
+
+Cloudflare supports WebSocket connections, which often involve the 101 Switching Protocols status code. The protocol switch allows clients to establish a WebSocket connection for real-time, bidirectional communication. For information about Cloudflare's Websockets, refer to [Cloudflare Now Supports Websockets](https://blog.cloudflare.com/cloudflare-now-supports-websockets/).
+
+## 102 Processing ([RFC2518](https://tools.ietf.org/html/rfc2518))
+
+102 Processing status code indicates that the server has received the request and is currently processing it, but the final response is not yet ready. This status code is only applicable to HTTP/1.1 and higher.
+
+### Common use cases
+
+The 102 Processing status code is commonly used in scenarios requiring long-running operations, such as complex database transactions or large file processing. It helps maintain the connection during extended processing times, typically exceeding 20 seconds, ensuring efficient communication between the client and server throughout the operation.
+
+### Cloudflare-specific information
+
+If Cloudflare receives a 102 Processing response, it expects a final response within 100 seconds. Failure to receive this response results in an [Error 522: Connection Timed Out](https://support.cloudflare.com/hc/articles/115003011431#522error). However, sending interim 102 Processing responses can help prevent [Error 524: A timeout error](https://support.cloudflare.com/hc/articles/115003011431#524error), ensuring that the connection remains active while the server processes the request.
\ No newline at end of file
diff --git a/src/content/docs/workflows/build/call-workflows-from-pages.mdx b/src/content/docs/workflows/build/call-workflows-from-pages.mdx
new file mode 100644
index 00000000000000..ca21bbe57242cc
--- /dev/null
+++ b/src/content/docs/workflows/build/call-workflows-from-pages.mdx
@@ -0,0 +1,142 @@
+---
+title: Call Workflows from Pages
+pcx_content_type: concept
+sidebar:
+ order: 11
+---
+
+import { WranglerConfig, TypeScriptExample } from "~/components";
+
+You can bind and trigger Workflows from [Pages Functions](/pages/functions/) by deploying a Workers project with your Workflow definition and then invoking that Worker using [service bindings](/pages/functions/bindings/#service-bindings) or a standard `fetch()` call.
+
+:::note
+
+You will need to deploy your Workflow as a standalone Workers project first before your Pages Function can call it. If you have not yet deployed a Workflow, refer to the Workflows [get started guide](/workflows/get-started/guide/).
+
+:::
+
+### Use Service Bindings
+
+[Service Bindings](/workers/runtime-apis/bindings/service-bindings/) allow you to call a Worker from another Worker or a Pages Function without needing to expose it directly.
+
+To do this, you will need to:
+
+1. Deploy your Workflow in a Worker
+2. Create a Service Binding to that Worker in your Pages project
+3. Call the Worker remotely using the binding
+
+For example, if you have a Worker called `workflows-starter`, you would create a new Service Binding in your Pages project as follows, ensuring that the `service` name matches the name of the Worker your Workflow is defined in:
+
+
+```toml
+services = [
+ { binding = "WORKFLOW_SERVICE", service = "workflows-starter" }
+]
+```
+
+
+Your Worker can expose a specific method (or methods) that only other Workers or Pages Functions can call over the Service Binding.
+
+In the following example, we expose a specific `createInstance` method that accepts our `Payload` and returns the [`InstanceStatus`](/workflows/build/workers-api/#instancestatus) from the Workflows API:
+
+
+```ts
+import { WorkerEntrypoint } from "cloudflare:workers";
+
+interface Env {
+ MY_WORKFLOW: Workflow;
+}
+
+type Payload = {
+ hello: string;
+}
+
+export default class WorkflowsService extends WorkerEntrypoint {
+ // Currently, entrypoints without a named handler are not supported
+ async fetch() { return new Response(null, {status: 404}); }
+
+ async createInstance(payload: Payload) {
+ let instance = await this.env.MY_WORKFLOW.create({
+ params: payload
+ });
+
+ return Response.json({
+ id: instance.id,
+ details: await instance.status(),
+ });
+ }
+}
+```
+
+
+Your Pages Function would resemble the following:
+
+
+```ts
+interface Env {
+ WORKFLOW_SERVICE: Service;
+}
+
+export const onRequest: PagesFunction = async (context) => {
+ // This payload could be anything from within your app or from your frontend
+ let payload = {"hello": "world"}
+ return context.env.WORKFLOWS_SERVICE.createInstance(payload)
+};
+```
+
+
+To learn more about binding to resources from Pages Functions, including how to bind via the Cloudflare dashboard, refer to the [bindings documentation for Pages Functions](/pages/functions/bindings/#service-bindings).
+
+### Using fetch
+
+:::note "Service Bindings vs. fetch"
+
+We recommend using [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) when calling a Worker in your own account.
+
+Service Bindings don't require you to expose a public endpoint from your Worker, don't require you to configure authentication, and allow you to call methods on your Worker directly, avoiding the overhead of managing HTTP requests and responses.
+
+:::
+
+An alternative to setting up a Service Binding is to call the Worker over HTTP by using the Workflows [Workers API](/workflows/build/workers-api/#workflow) to `create` a new Workflow instance for each incoming HTTP call to the Worker:
+
+
+```ts
+// This is in the same file as your Workflow definition
+export default {
+ async fetch(req: Request, env: Env): Promise {
+ let instance = await env.MY_WORKFLOW.create({
+ params: payload
+ });
+ return Response.json({
+ id: instance.id,
+ details: await instance.status(),
+ });
+ },
+};
+```
+
+
+Your [Pages Function](/pages/functions/get-started/) can then make a regular `fetch` call to the Worker:
+
+
+```ts
+export const onRequest: PagesFunction = async (context) => {
+ // Other code
+ let payload = {"hello": "world"}
+ const instanceStatus = await fetch("https://YOUR_WORKER.workers.dev/", {
+ method: "POST",
+ body: JSON.stringify(payload) // Send a payload for our Worker to pass to the Workflow
+ })
+
+ return Response.json(instanceStatus);
+};
+```
+
+
+You can also choose to authenticate these requests by passing a shared secret in a header and validating that in your Worker.
+
+### Next steps
+
+* Learn more about how to programatically call and trigger Workflows from the [Workers API](/workflows/build/workers-api/)
+* Understand how to send [events and parameters](/workflows/build/events-and-parameters/) when triggering a Workflow
+* Review the [Rules of Workflows](/workflows/build/rules-of-workflows/) and best practices for writing Workflows
diff --git a/src/content/docs/workflows/build/events-and-parameters.mdx b/src/content/docs/workflows/build/events-and-parameters.mdx
index 3acc65a03aac53..13ffd623d773fa 100644
--- a/src/content/docs/workflows/build/events-and-parameters.mdx
+++ b/src/content/docs/workflows/build/events-and-parameters.mdx
@@ -6,7 +6,7 @@ sidebar:
---
-import { MetaInfo, Render, Type } from "~/components";
+import { MetaInfo, Render, Type, WranglerConfig, TypeScriptExample } from "~/components";
When a Workflow is triggered, it can receive an optional event. This event can include data that your Workflow can act on, including request details, user data fetched from your database (such as D1 or KV) or from a webhook, or messages from a Queue consumer.
diff --git a/src/content/docs/workflows/build/rules-of-workflows.mdx b/src/content/docs/workflows/build/rules-of-workflows.mdx
index b65d27586c0ad1..e4297f747556eb 100644
--- a/src/content/docs/workflows/build/rules-of-workflows.mdx
+++ b/src/content/docs/workflows/build/rules-of-workflows.mdx
@@ -5,6 +5,8 @@ sidebar:
order: 10
---
+import { WranglerConfig, TypeScriptExample } from "~/components";
+
A Workflow contains one or more steps. Each step is a self-contained, individually retriable component of a Workflow. Steps may emit (optional) state that allows a Workflow to persist and continue from that step, even if a Workflow fails due to a network or infrastructure issue.
This is a small guidebook on how to build more resilient and correct Workflows.
@@ -17,6 +19,7 @@ can be applied multiple times without changing the result beyond the initial app
As an example, let us assume you have a Workflow that charges your customers, and you really do not want to charge them twice by accident. Before charging them, you should
check if they were already charged:
+
```ts
export class MyWorkflow extends WorkflowEntrypoint {
async run(event: WorkflowEvent, step: WorkflowStep) {
@@ -52,6 +55,7 @@ export class MyWorkflow extends WorkflowEntrypoint {
}
}
```
+
:::note
@@ -67,6 +71,7 @@ You can also think of it as a transaction, or a unit of work.
- ✅ Minimize the number of API/binding calls per step (unless you need multiple calls to prove idempotency).
+
```ts
export class MyWorkflow extends WorkflowEntrypoint {
async run(event: WorkflowEvent, step: WorkflowStep) {
@@ -84,6 +89,7 @@ export class MyWorkflow extends WorkflowEntrypoint {
}
}
```
+
Otherwise, your entire Workflow might not be as durable as you might think, and you may encounter some undefined behaviour. You can avoid them by following the rules below:
@@ -92,6 +98,7 @@ Otherwise, your entire Workflow might not be as durable as you might think, and
- 🔴 Do not make too many service calls in the same step (unless you need it to prove idempotency).
- 🔴 Do not do too much CPU-intensive work inside a single step - sometimes the engine may have to restart, and it will start over from the beginning of that step.
+
```ts
export class MyWorkflow extends WorkflowEntrypoint {
async run(event: WorkflowEvent, step: WorkflowStep) {
@@ -105,6 +112,7 @@ export class MyWorkflow extends WorkflowEntrypoint {
}
}
```
+
### Do not rely on state outside of a step
@@ -112,6 +120,7 @@ Workflows may hibernate and lose all in-memory state. This will happen when engi
This means that you should not store state outside of a step:
+
```ts
function getRandomInt(min, max) {
const minCeiled = Math.ceil(min);
@@ -152,9 +161,11 @@ export class MyWorkflow extends WorkflowEntrypoint {
}
}
```
+
Instead, you should build top-level state exclusively comprised of `step.do` returns:
+
```ts
function getRandomInt(min, max) {
const minCeiled = Math.ceil(min);
@@ -192,11 +203,13 @@ export class MyWorkflow extends WorkflowEntrypoint {
}
}
```
+
### Do not mutate your incoming events
The `event` passed to your Workflow's `run` method is immutable: changes you make to the event are not persisted across steps and/or Workflow restarts.
+
```ts
interface MyEvent {
user: string;
@@ -219,17 +232,20 @@ export class MyWorkflow extends WorkflowEntrypoint {
return await env.KV.get(event.user)
})
- let someOtherData await step.do("following step that uses that state", async () => {
+ let someOtherData = await step.do("following step that uses that state", async () => {
// Access to userData here
// Will always be the same if this step is retried
})
+ }
+}
```
+
### Name steps deterministically
Steps should be named deterministically (even if dynamic). This ensures that their state is cached, and prevents the step from being rerun unnecessarily. Step names act as the "cache key" in your Workflow.
-
+
```ts
export class MyWorkflow extends WorkflowEntrypoint {
async run(event: WorkflowEvent, step: WorkflowStep) {
@@ -255,9 +271,53 @@ export class MyWorkflow extends WorkflowEntrypoint {
let catList = await step.do("get cat list from KV", async () => {
return await env.KV.get("cat-list")
})
+
for(const cat of catList) {
await step.do(`get cat: ${cat}`, async () => {
return await env.KV.get(cat)
})
}
+ }
+}
+```
+
+
+### Instance IDs are unique
+
+Workflow [instance IDs](/workflows/build/workers-api/#workflowinstance) are unique per Workflow. The ID is the unique identifier that associates logs, metrics, state and status of a run to a specific an instance, even after completion. Allowing ID re-use would make it hard to understand if a Workflow instance ID referred to an instance that run yesterday, last week or today.
+
+It would also present a problem if you wanted to run multiple different Workflow instances with different [input parameters](/workflows/build/events-and-parameters/) for the same user ID, as you would immediately need to determine a new ID mapping.
+
+If you need to associate multiple instances with a specific user, merchant or other "customer" ID in your system, consider using a composite ID or using randomly generated IDs and storing the mapping in a database like [D1](/d1/).
+
+
+```ts
+// This is in the same file as your Workflow definition
+export default {
+ async fetch(req: Request, env: Env): Promise {
+ // 🔴 Bad: Use an ID that isn't unique across future Workflow invocations
+ let userId = getUserId(req) // Returns the userId
+ let badInstance = await env.MY_WORKFLOW.create({
+ id: userId,
+ params: payload
+ });
+
+ // ✅ Good: use a composite ID or an
+ let instanceId = getTransactionId() // e.g. assuming transaction IDs are unique
+ // or: compose a composite ID and store it in your database
+ // so that you can track all instances associated with a specific user or merchant.
+ instanceId = `${getUserId(request)}-${await crypto.randomUUID().slice(0, 6)}`
+ let { result } = await addNewInstanceToDB(userId, instanceId)
+ let goodInstance = await env.MY_WORKFLOW.create({
+ id: userId,
+ params: payload
+ });
+
+ return Response.json({
+ id: badInstance.id,
+ details: await badInstance.status(),
+ });
+ },
+};
```
+
diff --git a/src/content/docs/workflows/build/workers-api.mdx b/src/content/docs/workflows/build/workers-api.mdx
index 5ef8fe53f1c8ba..045222838e913c 100644
--- a/src/content/docs/workflows/build/workers-api.mdx
+++ b/src/content/docs/workflows/build/workers-api.mdx
@@ -125,17 +125,20 @@ binding = "MY_WORKFLOW"
# this is class that extends the Workflow class in src/index.ts
class_name = "MyWorkflow"
```
-
+### Bind from Pages
+
+You can bind and trigger Workflows from [Pages Functions](/pages/functions/) by deploying a Workers project with your Workflow definition and then invoking that Worker using [service bindings](/pages/functions/bindings/#service-bindings) or a standard `fetch()` call.
+
+Visit the documentation on [calling Workflows from Pages](/workflows/build/call-workflows-from-pages/) for examples.
+
### Cross-script calls
You can also bind to a Workflow that is defined in a different Worker script from the script your Workflow definition is in. To do this, provide the `script_name` key with the name of the script to the `[[workflows]]` binding definition in your `wrangler.toml` configuration.
For example, if your Workflow is defined in a Worker script named `billing-worker`, but you are calling it from your `web-api-worker` script, your `wrangler.toml` would resemble the following:
-
-
```toml title="wrangler.toml"
@@ -228,7 +231,7 @@ export default {
// params expects the type User
params: user
})
-
+
return Response.json({
id: instance.id,
details: await instance.status(),
diff --git a/src/content/partials/dns/acns-tcns-intro.mdx b/src/content/partials/dns/acns-tcns-intro.mdx
index 53d0b616fc2937..d75bd29c06d903 100644
--- a/src/content/partials/dns/acns-tcns-intro.mdx
+++ b/src/content/partials/dns/acns-tcns-intro.mdx
@@ -9,4 +9,4 @@ import { Markdown } from "~/components"
{props.two}CNS are organized in different sets (`ns_set`) and {props.two}CNS names can be provided by any domain, even if the domain does not exist as a zone in Cloudflare.
-For instance, if the {props.two}CNS are `ns1.example.com` and `ns2.vanity.org`, the domains `example.com` and `vanity.org` are not required to be zones in Cloudflare.
+For instance, if the {props.two}CNS are `ns1.example.com` and `ns2.vanity.test`, the domains `example.com` and `vanity.test` are not required to be zones in Cloudflare.
diff --git a/src/content/workers-ai-models/bge-base-en-v1.5.json b/src/content/workers-ai-models/bge-base-en-v1.5.json
index e390b71f8ebc60..42ce039ff64a0d 100644
--- a/src/content/workers-ai-models/bge-base-en-v1.5.json
+++ b/src/content/workers-ai-models/bge-base-en-v1.5.json
@@ -2,7 +2,7 @@
"id": "429b9e8b-d99e-44de-91ad-706cf8183658",
"source": 1,
"name": "@cf/baai/bge-base-en-v1.5",
- "description": "BAAI general embedding (bge) models transform any given text into a compact vector",
+ "description": "BAAI general embedding (Base) model that transforms any given text into a 768-dimensional vector",
"task": {
"id": "0137cdcf-162a-4108-94f2-1ca59e8c65ee",
"name": "Text Embeddings",
diff --git a/src/content/workers-ai-models/bge-large-en-v1.5.json b/src/content/workers-ai-models/bge-large-en-v1.5.json
index 48d3765f20c2e9..4e1526ed7b8d0b 100644
--- a/src/content/workers-ai-models/bge-large-en-v1.5.json
+++ b/src/content/workers-ai-models/bge-large-en-v1.5.json
@@ -2,7 +2,7 @@
"id": "01bc2fb0-4bca-4598-b985-d2584a3f46c0",
"source": 1,
"name": "@cf/baai/bge-large-en-v1.5",
- "description": "BAAI general embedding (bge) models transform any given text into a compact vector",
+ "description": "BAAI general embedding (Large) model that transforms any given text into a 1024-dimensional vector",
"task": {
"id": "0137cdcf-162a-4108-94f2-1ca59e8c65ee",
"name": "Text Embeddings",
diff --git a/src/content/workers-ai-models/bge-small-en-v1.5.json b/src/content/workers-ai-models/bge-small-en-v1.5.json
index 62288bb2cefb9c..61bd453e94c13d 100644
--- a/src/content/workers-ai-models/bge-small-en-v1.5.json
+++ b/src/content/workers-ai-models/bge-small-en-v1.5.json
@@ -2,7 +2,7 @@
"id": "57fbd08a-a4c4-411c-910d-b9459ff36c20",
"source": 1,
"name": "@cf/baai/bge-small-en-v1.5",
- "description": "BAAI general embedding (bge) models transform any given text into a compact vector",
+ "description": "BAAI general embedding (Small) model that transforms any given text into a 384-dimensional vector",
"task": {
"id": "0137cdcf-162a-4108-94f2-1ca59e8c65ee",
"name": "Text Embeddings",