# How to Set Up Cloudflare Enterprise DNS on Google Cloud DNS

> Activate a Cloudflare Enterprise domain whose DNS is in Google Cloud DNS: add the proof records first, wait for Active, then point the root at the edge with an ALIAS record.

Use this guide when your domain's DNS is hosted in **Google Cloud DNS** and you are activating it on the xCloud Cloudflare Enterprise add-on. Google Cloud DNS offers ALIAS records at the root, so the root never needs the two Cloudflare A records. The one rule is the order: **prove ownership while the root still points at your server, and add the ALIAS only after the domain shows Active.**

If your DNS is somewhere else, use the matching guide: [AWS Route 53](/docs/cloudflare-enterprise-dns-setup-aws-route-53/), [Namecheap](/docs/cloudflare-enterprise-dns-setup-namecheap/), or [Cloudflare without an xCloud integration](/docs/cloudflare-enterprise-dns-setup-cloudflare-without-integration/).

## Prerequisites

-   You have bought Cloudflare Enterprise for the domain. See [How to Activate the Cloudflare Enterprise Addon](/docs/how-to-activate-the-cloudflare-enterprise-addon/) or [How to Use Cloudflare Enterprise for External Domains](/docs/how-to-use-cloudflare-enterprise-for-external-domains/).
-   The domain's nameservers are Google Cloud DNS. Check with `dig +short NS example.com`; the answer should list `ns-cloud-*.googledomains.com` servers.
-   The website already loads from its origin, and the root currently resolves to your server IP.
-   You can edit the domain's Cloud DNS zone in the Google Cloud console.

## Why the order matters

Cloudflare refuses to verify a hostname whose DNS already resolves to Cloudflare. An ALIAS record answers with the Cloudflare edge addresses, so adding it before verification creates a deadlock: the root points at Cloudflare, Cloudflare will not verify it, the domain never activates, and visitors get Cloudflare error 1001.

The xCloud panel shows this warning for Google Cloud DNS: "Your DNS provider cannot hold a CNAME at the root, so use an ALIAS (or ANAME) record pointing at the target below. Add it only after the domain shows Active."

## Find your records

Open the domain's Cloudflare Enterprise page in xCloud. For a site, open the site's **Cloudflare Enterprise** page. For an external domain, go to **Addons → Cloudflare Enterprise Addons**, open the row's actions menu, and select **Manage**.

The **Ownership Verification** panel lists the exact records for your domain. The values below are shapes, not values: the ownership token and the certificate target are unique to each domain. Always copy them from the panel.

| Purpose | Record | Moves live traffic? |
| --- | --- | --- |
| Ownership proof | TXT at `_cf-custom-hostname.example.com.` | No |
| Certificate proof | CNAME at `_acme-challenge.example.com.` ending in `.dcv.cloudflare.com` | No |
| Routing | ALIAS at the root and CNAME at `www` | **Yes** |

Google Cloud DNS uses fully qualified names. Enter the complete name shown in the panel, with a trailing dot, rather than only the host part.

## Activate the domain

### 1. Add the two proof records

In the Google Cloud console, open **Network services → Cloud DNS**, select the zone, and add:

| Type | DNS name | TTL | Value |
| --- | --- | --- | --- |
| TXT | `_cf-custom-hostname.example.com.` | 300 | The ownership token from the panel |
| CNAME | `_acme-challenge.example.com.` | 300 | The certificate target from the panel |

**Leave the root A record pointing at your origin.** Do not add any Cloudflare addresses yet, and do not delete anything.

**Expected result:** Both records are saved in the zone, and the website still loads from your server.

### 2. Confirm Cloudflare can see the records

Cloudflare checks against its own resolver, so query `1.1.1.1` after the TTL has passed:

```bash
dig @1.1.1.1 +short TXT _cf-custom-hostname.example.com    # the ownership token
dig @1.1.1.1 +short CNAME _acme-challenge.example.com      # ...dcv.cloudflare.com.
dig @1.1.1.1 +short A example.com                          # still your ORIGIN IP
```

**Expected result:** The first two commands return the values from the panel, and the root still returns your server IP.

### 3. Verify and wait for Active

Select **Verify Records** in the **Ownership Verification** panel. If your team has a Cloudflare integration connected, the same button reads **Verify & Add Records**. To refresh the status, use **Refresh Status** in the page header for an external domain, or open the domain row's actions menu and select **Refresh status** for a site.

**Expected result:** The domain status changes to **Active**. If it stays at **Pending Verification**, wait out the TTL and verify again. Do not delete and re-add the domain.

### 4. Point the root and www at the edge

Only after the domain shows **Active**, change the routing records in one Cloud DNS transaction:

| Action | Type | DNS name | Value |
| --- | --- | --- | --- |
| Delete | A | `example.com.` | Your origin IP |
| Add | ALIAS | `example.com.` | The root CNAME target shown in the panel |
| Add or replace | CNAME | `www.example.com.` | The www target shown in the panel |

Keep both proof records. The `_acme-challenge` CNAME lets Cloudflare renew the certificate, so removing it breaks renewal later.

**Expected result:** The routing rows in the panel change to **Verified**, and the site starts serving through Cloudflare Enterprise.

## Verify it worked

```bash
dig +short A example.com                                   # Cloudflare edge addresses
curl -sI https://example.com | grep -iE 'server|cf-ray'    # server: cloudflare + a cf-ray header
```

`server: cloudflare` with a `cf-ray` header means the edge is serving the site. Also check `https://www.example.com` and the site's critical paths, such as login, forms, and checkout.

If `openssl s_client` or a browser shows a **Cloudflare Origin Certificate**, you reached the origin directly. That is almost always a stale local DNS cache, not a failed setup.

## Already stuck at Pending Verification

If you added the ALIAS before the domain was active, the panel shows: "Cloudflare cannot verify this root domain while it already points at Cloudflare. Point the root back at your server until the domain shows Active, then add the records below." To recover:

1.  Delete the root ALIAS and add `A example.com. → <origin IP>` again.
2.  Keep the `_cf-custom-hostname` TXT and `_acme-challenge` CNAME exactly as they are.
3.  Wait until `dig @1.1.1.1 +short A example.com` returns your origin IP.
4.  Select **Verify Records**. The status changes to **Active**.
5.  Replace the root A record with the ALIAS again.

Verification survives the change. Once the domain is active, it stays active.

## Troubleshooting

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Cloud DNS rejects the root CNAME | A zone apex cannot hold a CNAME. | Use an ALIAS record at the root instead. |
| A proof record shows **Pending** in the panel | The record is in a different zone, or the name is missing the domain part. | Check that `dig +short NS example.com` matches the zone's nameservers, and use the full name with a trailing dot. |
| `1.1.1.1` still shows an old value | The previous answer is cached until its TTL expires. | Wait for the TTL, then verify again. |
| SSL stays pending after the domain is active | The certificate proof is missing or still propagating. | Confirm the `_acme-challenge` CNAME answers, then refresh the domain status. |
| Resolvers return old records after a nameserver move | The previous DNS host still answers for some resolvers. | Compare `dig +short NS example.com` with `dig @ns-cloud-a1.googledomains.com +short example.com A`. |

## FAQ

### Why can't I add the root CNAME that the panel lists?

Google Cloud DNS does not allow a CNAME at the zone apex. Use an ALIAS record at the root pointing at the same target instead.

### Why does the domain stay at Pending Verification after I added the ALIAS record?

An ALIAS answers with Cloudflare's own addresses, and Cloudflare will not verify a hostname that already points at it. Point the root back at your origin until the domain shows **Active**, then add the ALIAS again.

### Should I delete the domain in xCloud and add it again?

No. Each new purchase generates a new ownership token, so you would have to update the TXT record again without fixing the cause.

### Does the root domain purchase cover www?

Yes. A root domain is registered with wildcard coverage, so the panel lists a routing record for both the root and `www`. Add both.