[DNS] Improve 'DNS setup' and monospace usage (#19168)

* Audit and replace 'zone setup' by 'DNS setup' as applicable

* Audit and remove excessive monospacing

* Apply suggestion from code review

Co-authored-by: Pedro Sousa <[email protected]>

* Address remaining monospace in dnssec.mdx

---------

Co-authored-by: Pedro Sousa <[email protected]>

Author: RebeccaTamachiro

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/provider-guides/salesforce-commerce-cloud.mdx

@@ -32,9 +32,9 @@ To enable O2O requires the following:
 1. Your SFCC environment must be configured as an "SFCC Proxy Zone". If you currently have an "SFCC Legacy Zone", you cannot enable O2O. More details on the different types of SFCC configurations can be found in the [Salesforce FAQ on SFCC Proxy Zones](https://help.salesforce.com/s/articleView?id=cc.b2c_ecdn_proxy_zone_faq.htm&type=5).
 2. Your own Cloudflare zone on an Enterprise plan.
 
-If you meet the above requirements, O2O can then be enabled per hostname. To enable O2O for a specific hostname within your Cloudflare zone, [create](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) a Proxied `CNAME` DNS record with a target of the `CNAME` provided by SFCC Business Manager, which is the dashboard used by SFCC customers to configure their storefront environment.
+If you meet the above requirements, O2O can then be enabled per hostname. To enable O2O for a specific hostname within your Cloudflare zone, [create](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) a Proxied CNAME DNS record with a target of the CNAME provided by SFCC Business Manager, which is the dashboard used by SFCC customers to configure their storefront environment.
 
-The `CNAME` provided by SFCC Business Manager will resemble `commcloud.prod-abcd-example-com.cc-ecdn.net` and contains 3 distinct parts. For each hostname routing traffic to SFCC, be sure to update each part of the example `CNAME` to match your SFCC environment:
+The CNAME provided by SFCC Business Manager will resemble `commcloud.prod-abcd-example-com.cc-ecdn.net` and contains 3 distinct parts. For each hostname routing traffic to SFCC, be sure to update each part of the example CNAME to match your SFCC environment:
 
 1. **Environment**: `prod` should be changed to `prod` or `dev` or `stg`.
 2. **Realm**: `abcd` should be changed to the Realm ID assigned to you by SFCC.

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/troubleshooting.mdx

@@ -19,24 +19,24 @@ If a domain is flagged by the CA, you need to contact Support before validation
 
 ## Certificate Authority Authorization (CAA) records
 
-`CAA` is a DNS resource record type defined in [RFC 6844](https://datatracker.ietf.org/doc/html/rfc6844) that allows a domain owner to indicate which CAs are allowed to issue certificates for them.
+CAA is a DNS resource record type defined in [RFC 6844](https://datatracker.ietf.org/doc/html/rfc6844) that allows a domain owner to indicate which CAs are allowed to issue certificates for them.
 
 ### For SaaS providers
 
-If your customer has `CAA` records set on their domain, they will either need to add the following or remove `CAA` entirely:
+If your customer has CAA records set on their domain, they will either need to add the following or remove CAA entirely:
 
 ```txt
 example.com. IN CAA 0 issue "letsencrypt.org"
 example.com. IN CAA 0 issue "pki.goog"
 ```
 
-While it is possible for `CAA` records to be set on the subdomain your customer wishes to use with your service, it will usually be set on the domain apex. If they have `CAA` records on the subdomain, those will also have to be removed.
+While it is possible for CAA records to be set on the subdomain your customer wishes to use with your service, it will usually be set on the domain apex. If they have CAA records on the subdomain, those will also have to be removed.
 
 ### For SaaS customers
 
-In some cases, the validation may be prevented because your hostname points to a `CNAME` target where `CAA` records are defined.
+In some cases, the validation may be prevented because your hostname points to a CNAME target where CAA records are defined.
 
-In this case you would need to either select a Certificate Authority whose `CAA` records are present at the target, or review the configuration with the service provider that owns the target.
+In this case you would need to either select a Certificate Authority whose CAA records are present at the target, or review the configuration with the service provider that owns the target.
 
 ***
 

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/setup.mdx

@@ -49,35 +49,35 @@ These IP addresses are different than those associated with your Cloudflare zone
 
 ### 3. Have customer create DNS record
 
-To finish the custom hostname setup, your customer can set up either an `A` or `CNAME` record at their authoritative DNS provider.
+To finish the custom hostname setup, your customer can set up either an A or CNAME record at their authoritative DNS provider.
 
 :::note
 
 
-If you want your customers to be able to use `CNAME` records, you will need to complete the [normal setup process](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/) as well.
+If you want your customers to be able to use CNAME records, you will need to complete the [normal setup process](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/) as well.
 
 
 :::
 
-#### `A` record
+#### A record
 
-If your customer uses an `A` record at their authoritative DNS provider, they need to point their hostname to the IP prefixed allocated for your account.
+If your customer uses an A record at their authoritative DNS provider, they need to point their hostname to the IP prefixed allocated for your account.
 
 <Render file="get-started-check-statuses" />
 
-Your customer's `A` record might look like the following:
+Your customer's A record might look like the following:
 
 ```txt
 example.com.  60  IN  A   192.0.2.1
 ```
 
-#### `CNAME` record
+#### CNAME record
 
-If your customer uses a `CNAME` record at their authoritative DNS, they need to point their hostname to your [`CNAME` target](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#2-optional-create-cname-target) [^1].
+If your customer uses a CNAME record at their authoritative DNS, they need to point their hostname to your [CNAME target](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#2-optional-create-cname-target) [^1].
 
 <Render file="get-started-check-statuses" />
 
-Your customer's `CNAME` record might look like the following:
+Your customer's CNAME record might look like the following:
 
 ```txt
 mystore.com CNAME customers.saasprovider.com

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started.mdx

@@ -26,9 +26,9 @@ import { Example, Render } from "~/components"
 
 ### 2. (Optional) Create CNAME target
 
-The `CNAME` target — optional, but highly encouraged — provides a friendly and more flexible place for customers to [route their traffic](#3-have-customer-create-cname-record). You may want to use a subdomain such as `customers.<SAAS_PROVIDER>.com`.
+The CNAME target — optional, but highly encouraged — provides a friendly and more flexible place for customers to [route their traffic](#3-have-customer-create-cname-record). You may want to use a subdomain such as `customers.<SAAS_PROVIDER>.com`.
 
-[Create](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) a proxied `CNAME` that points your `CNAME` target to your fallback origin (can be a wildcard such as `*.customers.saasprovider.com`).
+[Create](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) a proxied CNAME that points your CNAME target to your fallback origin (can be a wildcard such as `*.customers.saasprovider.com`).
 
 <Example>
 
@@ -46,11 +46,11 @@ The `CNAME` target — optional, but highly encouraged — provides a friendly a
 
 ### 3. Have customer create CNAME record
 
-To finish the custom hostname setup, your customer needs to set up a `CNAME` record at their authoritative DNS that points to your [`CNAME` target](#2-optional-create-cname-target) [^1].
+To finish the custom hostname setup, your customer needs to set up a CNAME record at their authoritative DNS that points to your [CNAME target](#2-optional-create-cname-target) [^1].
 
 <Render file="get-started-check-statuses" />
 
-Your customer's `CNAME` record might look like the following:
+Your customer's CNAME record might look like the following:
 
 ```txt
 mystore.example.com CNAME customers.saasprovider.com
@@ -67,7 +67,7 @@ B --> C[<code>proxy-fallback.saasprovider.com</code>]
 
 <br/>
 
-Requests to `mystore.example.com` would go to your `CNAME` target (`customers.saasprovider.com`), which would then route to your fallback origin (`proxy-fallback.saasprovider.com`).
+Requests to `mystore.example.com` would go to your CNAME target (`customers.saasprovider.com`), which would then route to your fallback origin (`proxy-fallback.saasprovider.com`).
 
 [^1]: <Render file="regional-services" />
 

src/content/docs/dns/cname-flattening/cname-flattening-diagram.mdx

@@ -12,20 +12,20 @@ description: Consider an example use case and the main steps involved in CNAME f
 
 import { Example } from "~/components"
 
-With `CNAME` flattening, Cloudflare returns an IP address instead of the target hostname that a `CNAME` record points to.
+With CNAME flattening, Cloudflare returns an IP address instead of the target hostname that a CNAME record points to.
 This process supports a few features and delivers better performance and flexibility, as mentioned in the [CNAME flattening concept page](/dns/cname-flattening/).
 
-Consider the diagram below to have an overview of the steps that may be involved in `CNAME` flattening.
+Consider the diagram below to have an overview of the steps that may be involved in CNAME flattening.
 
 :::note
 
-Note that this is a simpler scenario. Cases where `CNAME` flattening is optional and/or the target hostname is not external to Cloudflare work differently. 
+Note that this is a simpler scenario. Cases where CNAME flattening is optional and/or the target hostname is not external to Cloudflare work differently.
 
 :::
 
 ## Example use case
 
-* `domain.test` is a zone on Cloudflare and has the following `CNAME` record:
+* `domain.test` is a zone on Cloudflare and has the following CNAME record:
 
 <Example>
 
@@ -83,5 +83,5 @@ accDescr: Diagram of CNAME flattening process when there is a request for a doma
 
 ## Aspects to consider
 
-* If the `CNAME` record is proxied in Cloudflare, the answer is made up of multiple [Cloudflare IPs](https://www.cloudflare.com/ips/) and its Time to Live (TTL) is set to `300`.
-* If the `CNAME` record in Cloudflare is not proxied, the flattened answer consists of the IP address from the external DNS provider and its TTL corresponds to the lower value between the external record and the Cloudflare `CNAME` record.
+* If the CNAME record is proxied in Cloudflare, the answer is made up of multiple [Cloudflare IPs](https://www.cloudflare.com/ips/) and its Time to Live (TTL) is set to `300`.
+* If the CNAME record in Cloudflare is not proxied, the flattened answer consists of the IP address from the external DNS provider and its TTL corresponds to the lower value between the external record and the Cloudflare CNAME record.

src/content/docs/dns/cname-flattening/index.mdx

@@ -8,7 +8,7 @@ sidebar:
 
 import { Render } from "~/components"
 
-`CNAME` flattening speeds up `CNAME` resolution and allows you to use a `CNAME` record at your root/apex domain (`example.com`).
+CNAME flattening speeds up CNAME resolution and allows you to use a CNAME record at your root/apex domain (`example.com`).
 
 :::note
 
@@ -20,11 +20,11 @@ This functionality is also what allows you to use a [root custom domain](/pages/
 
 ## How it works
 
-With `CNAME` flattening, Cloudflare finds the IP address that a `CNAME` points to. This process could involve a single lookup or multiple (if your `CNAME` points to another `CNAME`). Cloudflare then returns the final IP address instead of a `CNAME` record, helping DNS queries resolve up to 30% faster.
+With CNAME flattening, Cloudflare finds the IP address that a CNAME points to. This process could involve a single lookup or multiple (if your CNAME points to another CNAME). Cloudflare then returns the final IP address instead of a CNAME record, helping DNS queries resolve up to 30% faster.
 
-For more details on the steps involved in `CNAME` flattening, review the [CNAME flattening diagram](/dns/cname-flattening/cname-flattening-diagram/) and refer to the [Cloudflare blog post](https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/).
+For more details on the steps involved in CNAME flattening, review the [CNAME flattening diagram](/dns/cname-flattening/cname-flattening-diagram/) and refer to the [Cloudflare blog post](https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/).
 
 ## Aspects to keep in mind
 
-* `CNAME` flattening happens by default in some cases. Refer to [Setup](/dns/cname-flattening/set-up-cname-flattening/) for details.
+* CNAME flattening happens by default in some cases. Refer to [Setup](/dns/cname-flattening/set-up-cname-flattening/) for details.
 * <Render file="cname-flattening-callout" />

src/content/docs/dns/cname-flattening/set-up-cname-flattening.mdx

@@ -14,18 +14,18 @@ import { Render, TabItem, Tabs, GlossaryTooltip } from "~/components"
 :::note
 
 
-If the `CNAME` target is on the same zone as the `CNAME` record, Cloudflare proceeds with `CNAME` flattening and ignores the **CNAME Flattening** setting.
+If the CNAME target is on the same zone as the CNAME record, Cloudflare proceeds with CNAME flattening and ignores the **CNAME Flattening** setting.
 
 
 :::
 
 ## For your zone apex
 
-`CNAME` flattening occurs by default for all plans when your domain uses a `CNAME` record for its zone apex (`example.com`, meaning the record **Name** is set to `@`).
+CNAME flattening occurs by default for all plans when your domain uses a CNAME record for its zone apex (`example.com`, meaning the record **Name** is set to `@`).
 
 ## For all CNAME records
 
-For zones on paid plans, you can choose to flatten all `CNAME` records. This option is useful for <GlossaryTooltip term="proxy status">DNS-only (unproxied)</GlossaryTooltip> `CNAME` records. [Proxied records](/dns/manage-dns-records/reference/proxied-dns-records/#proxied-records) are flattened by default as they return Cloudflare anycast IPs.
+For zones on paid plans, you can choose to flatten all CNAME records. This option is useful for <GlossaryTooltip term="proxy status">DNS-only (unproxied)</GlossaryTooltip> CNAME records. [Proxied records](/dns/manage-dns-records/reference/proxied-dns-records/#proxied-records) are flattened by default as they return Cloudflare anycast IPs.
 
 <Tabs syncKey="dashPlusAPI"> <TabItem label="Dashboard">
 
@@ -45,15 +45,15 @@ Make a `PATCH` request to the [Update DNS Settings](/api/resources/dns/subresour
 
 ## Per record
 
-Paid zones also have the option of flattening specific `CNAME` records.
+Paid zones also have the option of flattening specific CNAME records.
 
-If you use this option, a special [tag](/dns/manage-dns-records/reference/record-attributes/) `cf-flatten-cname` will be added to the respective flattened `CNAME` records in your zone file, allowing you to [export and import records](/dns/manage-dns-records/how-to/import-and-export/) without losing this configuration.
+If you use this option, a special [tag](/dns/manage-dns-records/reference/record-attributes/) `cf-flatten-cname` will be added to the respective flattened CNAME records in your zone file, allowing you to [export and import records](/dns/manage-dns-records/how-to/import-and-export/) without losing this configuration.
 
 <Tabs syncKey="dashPlusAPI"> <TabItem label="Dashboard">
 
 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login) and select your account and domain.
 2. In **DNS** > **Settings**, make sure that **CNAME flattening for all CNAME records** is turned off.
-3. Go to **DNS** > **Records** and find the `CNAME` record you would like to flatten.
+3. Go to **DNS** > **Records** and find the CNAME record you would like to flatten.
 4. Select **Edit** and turn on the **Flatten** option.
 5. Select **Save** to confirm.
 
@@ -66,7 +66,7 @@ For the following cases, **Flatten** will not be available:
 
 </TabItem> <TabItem label="API">
 
-With the available [API endpoints](/api/resources/dns/subresources/records/methods/create/), specify the following for each `CNAME` record in the request body:
+With the available [API endpoints](/api/resources/dns/subresources/records/methods/create/), specify the following for each CNAME record in the request body:
 
 ```txt
 "settings": {

src/content/docs/dns/dns-firewall/index.mdx

@@ -10,7 +10,7 @@ import { Description, Plan } from "~/components"
 
 <Description>
 
-Speed up and protect entire authoritative nameservers 
+Speed up and protect entire authoritative nameservers
 </Description>
 
 <Plan type="ent-add-on" />
@@ -19,7 +19,7 @@ Cloudflare DNS Firewall proxies all DNS queries to your nameservers through Clou
 
 ![Diagram showing protection provided by DNS Firewall. For more details, read further.](~/assets/images/dns/dns-firewall-overview.png)
 
-DNS Firewall is for customers who need to speed up and protect entire authoritative nameservers. If you need to speed up and protect individual zones, see Cloudflare DNS [Zone Setups](/dns/zone-setups).
+DNS Firewall is for customers who need to speed up and protect entire authoritative nameservers. If you need to speed up and protect individual zones, refer to Cloudflare DNS [Setups](/dns/zone-setups/).
 
 ***
 

src/content/docs/dns/dnssec/dnssec-states.mdx

@@ -18,13 +18,13 @@ This page describes different DNSSEC states and how they relate to the responses
 
 :::caution
 
-Once you have enabled DNSSEC on a zone for the first time, you cannot transition directly from an `active` state to a `deleted` state. You can only [delete DNSSEC records](/api/resources/dns/subresources/dnssec/methods/delete/) once your zone DNSSEC is in a `disabled` state. Cloudflare prevents you from deleting DNSSEC records before removing the DS record from the registrar to avoid DNS resolution issues. 
+Once you have enabled DNSSEC on a zone for the first time, you cannot transition directly from an `active` state to a `deleted` state. You can only [delete DNSSEC records](/api/resources/dns/subresources/dnssec/methods/delete/) once your zone DNSSEC is in a `disabled` state. Cloudflare prevents you from deleting DNSSEC records before removing the DS record from the registrar to avoid DNS resolution issues.
 :::
 
-In both `pending` and `active` states, Cloudflare signs the zone and responds with `RRSIG`, `NSEC`, `DNSKEY`, `CDS`, and `CDNSKEY` record types.
+In both `pending` and `active` states, Cloudflare signs the zone and responds with RRSIG, NSEC, DNSKEY, CDS, and CDNSKEY record types.
 
-In `pending-disabled` and `disabled` states, Cloudflare still signs the zone and serves `RRSIG`, `NSEC`, and `DNSKEY` record types, but the `CDS` and `CDNSKEY` records are set to zero ([RFC 8078](https://www.rfc-editor.org/rfc/rfc8078.html#section-4)), signaling to the registrar that DNSSEC should be disabled.
+In `pending-disabled` and `disabled` states, Cloudflare still signs the zone and serves RRSIG, NSEC, and DNSKEY record types, but the CDS and CDNSKEY records are set to zero ([RFC 8078](https://www.rfc-editor.org/rfc/rfc8078.html#section-4)), signaling to the registrar that DNSSEC should be disabled.
 
-In `deleted` state, Cloudflare does **not** sign the zone and does **not** respond with `RRSIG`, `NSEC`, `DNSKEY`, `CDS`, and `CDNSKEY` record types.
+In `deleted` state, Cloudflare does **not** sign the zone and does **not** respond with RRSIG, NSEC, DNSKEY, CDS, and CDNSKEY record types.
 
 Refer to [How DNSSEC works](https://www.cloudflare.com/dns/dnssec/how-dnssec-works/) to learn more about the authentication process and records involved.