Blog

A visitor’s resolver asks CloudFloorDNS for www.example.com. We answer with a CNAME to www.example.com.cdn.cloudflare.net.

That name resolves to Cloudflare’s anycast network, where the request meets the cache, the WAF and Cloudflare’s DDoS protection.

Anything Cloudflare can’t serve from cache is fetched from your origin, at the address you give Cloudflare in Step 4.

The bare domain, mail and every other hostname are answered by CloudFloorDNS as usual and go direct. Cloudflare never sees them.

It needs Cloudflare Business or Enterprise.

The CNAME setup isn’t offered on Free or Pro — the conversion option simply doesn’t appear. Cloudflare lists Business at $200/month billed annually or $250/month billed monthly (current plans).

The bare domain can’t be a CNAME.

DNS doesn’t allow a CNAME at the zone apex, so example.com can’t point at Cloudflare the way www does. You’ll send it to www instead; Step 8 covers the options.

Only what you point at Cloudflare is proxied.

Cloudflare handles exactly the hostnames you CNAME to it. That includes DNS itself: Cloudflare’s DNS-layer DDoS protection only applies when it runs your nameservers, so here your DNS stays on CloudFloorDNS’s DDoS-protected network.

Your origin address moves into Cloudflare.

After the switch, the www record in Cloudflare’s dashboard decides where traffic goes. When you move servers, update it there, not at CloudFloorDNS.

Some records are permanent.

Cloudflare’s cloudflare-verify TXT record has to stay in your zone for as long as you use the setup, and so does the _acme-challenge CNAME if you choose delegated certificate validation in Step 5.

Cloudflare Registrar domains are excluded.

Domains registered at Cloudflare can’t use a CNAME setup. Registered with us or with any other registrar? You’re fine.

Note your current www record and lower its TTL

Open the zone for example.com in the CloudFloorDNS control panel and find the www record. Write down its value: that’s your origin, and it’s also your way back. Then lower its TTL to 600 seconds (10 minutes) and wait at least as long as the old TTL before you continue, so the change in Step 7 takes effect quickly.

If www is already a CNAME to a hosting provider (something like yoursite.hostingco.net), note that hostname instead. You’ll use it as the origin in Step 4.

Add the domain and convert it to a CNAME setup

Add example.com to your Cloudflare account and choose the Business (or Enterprise) plan. Cloudflare scans your existing records and then tells you to change your nameservers. Ignore the nameserver instructions.

On the domain’s Overview page, select Convert to CNAME DNS Setup and confirm with Convert. Cloudflare then shows a Verification TXT Record. Copy it; if you lose it, it’s also listed on the DNS Records page.

Prove you own the domain

Add the verification record to your zone:

Type just cloudflare-verify in the name column; the panel adds your domain for you. Cloudflare checks for the record and emails you when the zone is active, which can take up to a few hours. To confirm the record is being served:

dig +short TXT cloudflare-verify.example.com

Leave this record in place permanently. Cloudflare uses it to keep confirming you control the zone.

Create the proxied www record

Go to DNS → Records and make sure there’s a record for www pointing at your origin, with the proxy turned on (orange cloud, Proxied):

If your host gives you a hostname rather than an IP address, create a proxied CNAME for www pointing at that hostname instead. Don’t point it at anything that resolves back through Cloudflare, such as your bare domain.

Then delete everything else the scan imported. Cloudflare isn’t answering DNS for your domain in this setup, so those copies do nothing for visitors, and if a proxied CNAME ever points at one of them, Cloudflare uses its own stale copy instead of asking CloudFloorDNS. Keep this zone to the hostnames you proxy.

Get the edge certificate issued before you switch

Cloudflare includes a free Universal SSL certificate, but on a CNAME setup it can’t validate the certificate automatically until traffic is already flowing through Cloudflare — unless you add validation records at your DNS provider first. Switch DNS before the certificate is active and HTTPS visitors can see certificate errors until it completes; Cloudflare’s own documentation says HTTP validation is only for sites that can tolerate a few minutes of downtime. For a live site, validate through DNS first. There are two ways:

CF_API_TOKEN="your-api-token"
ZONE_ID="your-zone-id"
API="https://api.cloudflare.com/client/v4/zones/$ZONE_ID"

# 1. Find the Universal certificate pack that covers www
curl -s "$API/ssl/certificate_packs?status=all" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq '.result[] | {id, type, hosts, status}'

# 2. Switch that pack to TXT validation
CERT_PACK_ID="id-from-step-1"
curl -s -X PATCH "$API/ssl/verification/$CERT_PACK_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"validation_method":"txt"}'

Use Full (strict) and test before you switch

Under SSL/TLS → Overview, make sure the encryption mode is Full (strict), so Cloudflare connects to your server over HTTPS and checks its certificate. If the zone uses Automatic SSL/TLS, it picks the most secure mode your origin supports; choose Custom to set it yourself. Avoid Flexible: it leaves the Cloudflare-to-server leg unencrypted and causes redirect loops on sites that already force HTTPS.

You can now send a request through Cloudflare without touching DNS:

# Pin www.example.com to a Cloudflare edge address for this one request
CF_IP=$(dig +short www.example.com.cdn.cloudflare.net | head -n1)
curl -sI --resolve www.example.com:443:$CF_IP https://www.example.com \
  | grep -iE '^(HTTP|server|cf-ray)'

You’re looking for a normal status code, server: cloudflare and a cf-ray header. A TLS error means the edge certificate isn’t active yet (on the quiet-hour route from Step 5, add -k to test everything else). A 5xx error means Cloudflare can’t reach your server, so check the address from Step 4 and your firewall.

Point www at Cloudflare

Change the www record from its A/AAAA value into a CNAME:

Keep the trailing dot: the target is outside your zone, so it’s entered as a full name ending in a dot. A CNAME can’t share its name with other records, so remove anything else at www too, such as an AAAA record or an old TXT verification record.

Within roughly the TTL you set in Step 1, visitors to www are flowing through Cloudflare.

Send the bare domain to www

Because example.com can’t be a CNAME, decide what happens when someone types it. In order of preference:

• Redirect it at CloudFloorDNS. Add an REDIRECT:// record with the name left blank and https://www.example.com as the data. Our forwarding servers answer for the bare domain and send visitors to www, so your server’s IP doesn’t appear on the bare domain at all. An aux value of 10 keeps the path (example.com/pricing → www.example.com/pricing); once you’ve tested it, 12 makes it a permanent 301. For visitors who type https:// in front of the bare domain, the forwarder also needs a certificate for it: our Secure Branding and Forwarding plans include automatic Let’s Encrypt certificates, or ask support what your plan covers.
• Proxy it through Cloudflare too. Cloudflare can proxy the apex in a CNAME setup when your DNS provider can flatten it, which is what an ALIAS record does. Add an ALIAS record with the name left blank pointing to example.com.cdn.cloudflare.net., add a proxied example.com record in Cloudflare, and create a Redirect Rule there that sends it to www. Make sure your edge certificate covers example.com as well.
• Redirect on your own server. Keep the apex A record pointing at your server and redirect to www there. It’s the simplest option, but it publishes your server’s IP, sends bare-domain visitors around Cloudflare, and stops working if you lock your server down to Cloudflare’s addresses in Step 10.

Verify everything

# Ask your authoritative nameservers directly
NS=$(dig +short NS example.com | head -n1)
dig +short www.example.com CNAME @$NS   # expect www.example.com.cdn.cloudflare.net.
dig +short MX example.com @$NS          # unchanged

# Requests to www should come back from Cloudflare
curl -sI https://www.example.com | grep -iE '^(server|cf-ray)'

# The bare domain should redirect to www
curl -sI https://example.com | grep -i '^location'

Then check mail flow and any other hostnames you care about. They should behave exactly as before, because nothing about them changed.

Lock down the origin and log real visitor IPs

Cloudflare only protects traffic that goes through it. Anyone who learns your server’s address can still reach it directly, so finish with three checks:

• Accept web traffic only from Cloudflare. Restrict ports 80 and 443 to Cloudflare’s published IP ranges, or turn on Authenticated Origin Pulls so your server only accepts connections that present Cloudflare’s client certificate.
• Look for records that give the address away. Hostnames such as ftp, cpanel or direct that point at the same server publish its IP. Move those services or accept the exposure knowingly.
• Restore visitor IPs in your logs. Your server now sees Cloudflare’s addresses. Cloudflare passes the original visitor IP in the CF-Connecting-IP header; configure mod_remoteip (Apache) or the real_ip module (nginx) to trust that header from Cloudflare’s ranges only.