Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CF4SaaS] Clarify O2O intro adding a DNS record example #19098

Merged
merged 5 commits into from
Jan 10, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -9,52 +9,66 @@ head:

---

Orange-to-Orange (O2O) is a specific traffic routing configuration where traffic routes through two Cloudflare zones: the first Cloudflare zone is owned by customer 1 and the second Cloudflare zone is owned by customer 2, who is considered a SaaS Provider.
import { Example } from "~/components";

If one or more hostnames are onboarded to a SaaS Provider that uses Cloudflare products as part of their platform, specifically the [Cloudflare for SaaS product](/cloudflare-for-platforms/cloudflare-for-saas/), those hostnames will be created as Custom Hostnames in the SaaS Provider's zone. The Custom Hostnames must be activated to give the SaaS Provider permission to route traffic for the hostname through their zone.
Orange-to-Orange (O2O) is a specific traffic routing configuration where traffic routes through two Cloudflare zones: the first Cloudflare zone is owned by customer 1 and the second Cloudflare zone is owned by customer 2, who is considered a SaaS provider.

## Without O2O
If one or more hostnames are onboarded to a SaaS Provider that uses Cloudflare products as part of their platform - specifically the [Cloudflare for SaaS product](/cloudflare-for-platforms/cloudflare-for-saas/) - those hostnames will be created as [custom hostnames](/cloudflare-for-platforms/cloudflare-for-saas/domain-support/) in the SaaS Provider's zone.

If you do not have your own Cloudflare zone and have only onboarded one or more of your hostnames to a SaaS Provider, then O2O will not be enabled.
To give the SaaS provider permission to route traffic through their zone, any custom hostname must be activated by you (the SaaS customer) by placing a [CNAME record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#3-have-customer-create-cname-record) on your authoritative DNS. If your authoritative DNS is Cloudflare, you have the option to [proxy](/fundamentals/concepts/how-cloudflare-works/#application-services) your CNAME record, achieving an Orange-to-Orange setup.

Without O2O enabled, the settings configured in the SaaS Provider's zone will be applied to the traffic.

## With O2O

If you have your own Cloudflare zone (`example.com`) and your zone contains a [proxied DNS record](/dns/manage-dns-records/reference/proxied-dns-records/) matching the custom hostname (`mystore.example.com`) with a **CNAME** target defined by the SaaS Provider, then O2O will be enabled.

<Example>

DNS management for **example.com**

| **Type** | **Name** | **Target** | **Proxy status** |
| -------- | ------------ | --------------------------------- | ---------------- |
| `CNAME` | `mystore` | `customers.saasprovider.com` | Proxied |

</Example>

With O2O enabled, the settings configured in your Cloudflare zone will be applied to the traffic first, and then the settings configured in the SaaS provider's zone will be applied to the traffic second.

```mermaid
flowchart TD
accTitle: Your zone using a SaaS provider, but without O2O
accTitle: O2O-enabled traffic flow diagram

A[Website visitor]

subgraph Cloudflare
B[SaaS Provider-owned zone]
B[Customer-owned zone]
C[SaaS Provider-owned zone]
end

C[SaaS Provider Origin]
D[SaaS Provider Origin]

A --> B
B --> C
C --> D
```
## Without O2O

## With O2O

If you have your own Cloudflare zone and your zone contains a **Proxied** DNS record matching the Custom Hostname with a **CNAME** target provided by the SaaS Provider, then O2O will be enabled.
If you do not have your own Cloudflare zone and have only onboarded one or more of your hostnames to a SaaS Provider, then O2O will not be enabled.

With O2O enabled, the settings configured in your Cloudflare zone will be applied to the traffic first, and then the settings configured in the SaaS Provider's zone will be applied to the traffic second.
Without O2O enabled, the settings configured in the SaaS Provider's zone will be applied to the traffic.

```mermaid
flowchart TD
accTitle: O2O-enabled traffic flow diagram
accTitle: Your zone using a SaaS provider, but without O2O

A[Website visitor]

subgraph Cloudflare
B[Customer-owned zone]
C[SaaS Provider-owned zone]
B[SaaS Provider-owned zone]
end

D[SaaS Provider Origin]
C[SaaS Provider Origin]

A --> B
B --> C
C --> D
```
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ import { DirectoryListing } from "~/components"

Cloudflare partners with many [SaaS providers](/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/provider-guides/) to extend our performance and security benefits to your website.

Cloudflare customers can take this process a step further by managing their own zone on Cloudflare. This setup - known as **Orange-to-Orange (O2O)** - allows them to benefit from their provider's setup but still customize how Cloudflare treats incoming traffic to their zone.
If you are a SaaS customer, you can take this process a step further by managing your own zone on Cloudflare. This setup - known as **Orange-to-Orange (O2O)** - allows you to benefit from your provider's setup but still customize how Cloudflare treats incoming traffic to your zone.

## Related resources

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ The `CNAME` target — optional, but highly encouraged — provides a friendly a

<Example>

| **Type** | **Name** | **IPv4 address** | **Proxy status** |
| **Type** | **Name** | **Target** | **Proxy status** |
| -------- | ------------ | --------------------------------- | ---------------- |
| `CNAME` | `.customers` | `proxy-fallback.saasprovider.com` | Proxied |

Expand All @@ -53,21 +53,21 @@ To finish the custom hostname setup, your customer needs to set up a `CNAME` rec
Your customer's `CNAME` record might look like the following:

```txt
www.mystore.com CNAME customers.saasprovider.com
mystore.example.com CNAME customers.saasprovider.com
```

This record would route traffic in the following way:

```mermaid
flowchart TD
accTitle: How traffic routing works with a CNAME target
A[Request to <code>www.mystore.com</code>] --> B[<code>customers.saasprovider.com</code>]
A[Request to <code>mystore.example.com</code>] --> B[<code>customers.saasprovider.com</code>]
B --> C[<code>proxy-fallback.saasprovider.com</code>]
```

<br/>

Requests to `www.mystore.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" />

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ import { Render, TabItem, Tabs } from "~/components"

You need to perform the following steps for each custom hostname.

### Step 1 — Plan for validation
### 1. Plan for validation

Before you create a hostname, you need to plan for:

Expand All @@ -24,7 +24,7 @@ Depending on which method you select for each of these options, additional steps

:::

### Step 2 — Create custom hostname
### 2. Create custom hostname

After planning for certification and hostname validation, you can create the custom hostname.

Expand Down
Loading