How to Set Up Cloudflare Enterprise DNS on Google Cloud DNS
Updated October 19, 2026 · 6 min read
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, Namecheap, or Cloudflare without an xCloud integration.
Prerequisites
- You have bought Cloudflare Enterprise for the domain. See How to Activate the Cloudflare Enterprise Addon or 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 listns-cloud-*.googledomains.comservers. - 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:
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 IPExpected 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
dig +short A example.com # Cloudflare edge addresses
curl -sI https://example.com | grep -iE 'server|cf-ray' # server: cloudflare + a cf-ray headerserver: 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:
- Delete the root ALIAS and add
A example.com. → <origin IP>again. - Keep the
_cf-custom-hostnameTXT and_acme-challengeCNAME exactly as they are. - Wait until
dig @1.1.1.1 +short A example.comreturns your origin IP. - Select Verify Records. The status changes to Active.
- 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.