Merge branch 'cloudflare:production' into for-pnpm

Author: millette

.github/CODEOWNERS

@@ -204,6 +204,7 @@
 # Support
 
 /src/content/docs/support/ @shanecloudflare @zeinjaber @TracyCloudflare @ngayerie @cloudflare/pcx-technical-writing @cloudflare/customer-support
+/src/assets/images/support/ @shanecloudflare @zeinjaber @TracyCloudflare @ngayerie @cloudflare/pcx-technical-writing @cloudflare/customer-support
 
 # Turnstile
 

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/remove-custom-hostnames.mdx

@@ -26,7 +26,7 @@ If the custom hostname is in a **Moved** state for seven days, it will transitio
 
 If your customer's domain is not using Cloudflare, you must remove a customer's custom hostname from your zone if they decide to churn.
 
-This is especially important if your end customers are using Cloudflare because if the custom hostname changes the DNS target to point away from your SaaS zone, the custom hostname will continue to route to your service. This is a result of the [custom hostname priority logic](/ssl/reference/certificate-and-hostname-priority/#hostname-priority-cloudflare-for-saas).
+This is especially important if your end customers are using Cloudflare because if the custom hostname changes the DNS target to point away from your SaaS zone, the custom hostname will continue to route to your service. This is a result of the [custom hostname priority logic](/ssl/reference/certificate-and-hostname-priority/#hostname-priority).
 
 <Tabs syncKey="dashPlusAPI"> <TabItem label="Dashboard">
 

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/reference/troubleshooting.mdx

@@ -33,7 +33,7 @@ There are three main causes of error 1016:
 
 1. Custom Hostname ownership validation is not complete. To check validation status, run an API call to [search for a certificate by hostname](/cloudflare-for-platforms/cloudflare-for-saas/start/common-api-calls/) and check the verification error field: `"verification_errors": ["custom hostname does not CNAME to this zone."]`.
 2. Fallback Origin is not [correctly set](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#1-create-fallback-origin). Confirm that you have created a DNS record for the fallback origin and also set the fallback origin.
-3. A Wildcard Custom Hostname has been created, but the requested hostname is associated with a domain that exists in Cloudflare as a standalone zone. In this case, the [hostname priority](/ssl/reference/certificate-and-hostname-priority/#hostname-priority-cloudflare-for-saas) for the standalone zone will take precedence over the wildcard custom hostname. This behavior applies even if there is no DNS record for this standalone zone hostname.
+3. A Wildcard Custom Hostname has been created, but the requested hostname is associated with a domain that exists in Cloudflare as a standalone zone. In this case, the [hostname priority](/ssl/reference/certificate-and-hostname-priority/#hostname-priority) for the standalone zone will take precedence over the wildcard custom hostname. This behavior applies even if there is no DNS record for this standalone zone hostname.
 
 In this scenario each hostname that needs to be served by the Cloudflare for SaaS parent zone needs to be added as an individual Custom Hostname.
 

src/content/docs/dns/manage-dns-records/index.mdx

@@ -6,11 +6,40 @@ sidebar:
 
 ---
 
-import { DirectoryListing, FeatureTable, GlossaryTooltip } from "~/components"
+import { DirectoryListing, FeatureTable, GlossaryTooltip, Details, Example } from "~/components"
 
 DNS records contain information about your domain and are used to make your website or application available to visitors and other web services.
 
-For background about different types of DNS records, refer to the [Learning Center](https://www.cloudflare.com/learning/dns/dns-records/).
+Depending on the providers you used to [get your domain name](/fundamentals/setup/manage-domains/#get-a-domain-name) and [host your website or application](/fundamentals/setup/manage-domains/#host-your-domain), it is expected that DNS records were automatically created on your behalf. According to your [setup](/dns/get-started/), you can use Cloudflare to manage your DNS records.
+
+## DNS records table
+
+DNS records have different types and each type serves a different purpose. For background about the different types of DNS records, refer to the [Learning Center](https://www.cloudflare.com/learning/dns/dns-records/). To quickly find reference information about a specific type refer to [DNS record types](/dns/manage-dns-records/reference/dns-record-types/).
+
+When managing your records at Cloudflare, besides the common record fields described below, you may also find an option for [Proxy status](/dns/manage-dns-records/reference/proxied-dns-records/) and [CNAME flattening](/dns/cname-flattening/). These are specific features offered by Cloudflare.
+
+<Details header="Record fields">
+- **Type**: Defines the purpose of a record. Different types of record require different information in their corresponding `Content` field.
+- **Name**: Identifies the resource that the record resolves to. Depending on the purpose of the record, the value you want to add to this field will also change.
+- **Content**: Contains the core value of a record, depending on the record type.
+- **TTL**: Controls how long each record is cached by DNS resolvers.
+</Details>
+
+<Details header="Example">
+
+<Example>
+DNS management for **example.com**:
+
+| Type | Name    | Content      | Proxy status | TTL    |
+| ---- | ------- | ------------ | ------------ | ------ |
+| A    | `blog`  | `192.0.2.1`  | Proxied      | Auto   |
+
+In this example, an IP address resolution record of type `A` is indicating that the resources that correspond to the subdomain `blog.example.com` can be reached on the IPv4 address `192.0.2.1`.
+
+Also, as this record is <GlossaryTooltip term="proxy status" link="/dns/manage-dns-records/reference/proxied-dns-records/">proxied</GlossaryTooltip>, Cloudflare automatically defines for how long this information should be cached by DNS resolvers.
+</Example>
+
+</Details>
 
 ## DNS records quota
 

src/content/docs/pages/framework-guides/nextjs/ssr/get-started.mdx

@@ -79,7 +79,7 @@ const nextConfig = {};
 export default nextConfig;
 ```
 
-These changes allows you to access [bindings](/pages/framework-guides/nextjs/ssr/bindings/) in local development.
+These changes allow you to access [bindings](/pages/framework-guides/nextjs/ssr/bindings/) in local development.
 
 ### 4. Ensure all server-rendered routes use the Edge Runtime
 

src/content/docs/rules/url-forwarding/bulk-redirects/how-it-works.mdx

@@ -6,6 +6,8 @@ sidebar:
   label: How it works
 ---
 
+import { MetaInfo } from "~/components";
+
 For each incoming request, Cloudflare evaluates all URL redirects of each Bulk Redirect List that is enabled by a Bulk Redirect Rule.
 
 If there is a match for a URL redirect according to the URL matching algorithm, the redirect action is performed immediately, according to the URL redirect configuration parameters. Cloudflare performs no further processing once a redirect action has been executed.
@@ -14,27 +16,25 @@ If there is a match for a URL redirect according to the URL matching algorithm,
 
 The following URL redirect parameters control the matching behavior between the request URL and source URLs of the configured (and enabled) URL redirects:
 
-- **Subpath matching** (default: false)
-
-  - If true, the URL redirect will apply to all paths under the given source path. For example, consider the following source and target URLs of a URL redirect:
+- **Subpath matching** <MetaInfo text="(default: false)"/>
 
-    — Source URL: `https://example.com/foo/`
+  - If `true`, the URL redirect will apply to all paths under the given source path. For example, consider the following source and target URLs of a URL redirect:
 
-    — Target URL: `https://example.com/qux/`
+    - Source URL: `https://example.com/foo/`
+    - Target URL: `https://example.com/qux/`
 
   - With this configuration and **Subpath matching** enabled, an incoming request to `example.com/foo/bar` will be redirected to `https://example.com/qux/bar`.
 
   :::note
   URL redirects with **Subpath matching** enabled cannot contain more than 16 `/` (slash) characters in the source URL path.
   :::
 
-- **Include subdomains** (default: false)
-
-  - If true, the source URL hostname of the URL redirect will also apply to all its subdomains. For example, consider the following source and target URLs of a URL redirect:
+- **Include subdomains** <MetaInfo text="(default: false)"/>
 
-    — Source URL: `https://example.com/about`
+  - If `true`, the source URL hostname of the URL redirect will also apply to all its subdomains. For example, consider the following source and target URLs of a URL redirect:
 
-    — Target URL: `https://example.com/newpage`
+    - Source URL: `https://example.com/about`
+    - Target URL: `https://example.com/newpage`
 
   - With this configuration and **Includes subdomains** enabled, incoming requests to `http://a.example.com/about` and `http://a.b.example.com/about` would also match, in addition to the specified domain with no subdomain (`https://example.com/about`).
 
@@ -44,29 +44,27 @@ For detailed information on these parameters, refer to [URL redirect parameters]
 
 The following parameters configure how Cloudflare determines the path and query string of the final target URL:
 
-- **Preserve query string** (default: false)
+- **Preserve query string** <MetaInfo text="(default: false)"/>
 
-  - If true, the final target URL will keep the query string of the original request. For example, consider the following source and target URLs of a URL redirect:
+  - If `true`, the final target URL will keep the query string of the original request. For example, consider the following source and target URLs of a URL redirect:
 
-    — Source URL: `https://example.com/about`
-
-    — Target URL: `https://example.com/newpage`
+    - Source URL: `https://example.com/about`
+    - Target URL: `https://example.com/newpage`
 
   - With this configuration and **Preserve query string** enabled, an incoming request to `http://example.com/about?q=term` would be redirected to `https://example.com/newpage?q=term`. If **Preserve query string** is disabled, the same incoming request would be redirected to `https://example.com/newpage`.
 
-- **Preserve path suffix** (default: true)
+- **Preserve path suffix** <MetaInfo text="(default: true)"/>
 
   - Defines if the final target URL will include the parts of the request path that did not match the URL redirect's source URL.
 
   - When **Subpath matching** is enabled, the path that was not matched is copied over to the final target URL. For example, consider the following source and target URLs of a URL redirect:
 
-    — Source URL: `https://example.com/a/`
-
-    — Target URL: `https://example.com/b/`
+    - Source URL: `https://example.com/a/`
+    - Target URL: `https://example.com/b/`
 
   - An incoming request to `https://example.com/a/foo` will be redirected to `https://example.com/b/foo`.
 
-  - If you set **Preserve path suffix** to false, the same request will still match the redirect, but it will be redirected to `https://example.com/b/`.
+  - If you set **Preserve path suffix** to `false`, the same request will still match the redirect, but it will be redirected to `https://example.com/b/`.
 
 For detailed information on these parameters, refer to [URL redirect parameters](/rules/url-forwarding/bulk-redirects/reference/parameters/).