Home / Articles / Free Subdomains and CNAME: Point a DNSHE Hostnam…

Free Subdomains and CNAME: Point a DNSHE Hostname at Cloudflare Pages Without Changing NS

· ~11 min · dns

Free subdomain providers are attractive for pilots: zero cash cost, quick hostnames, enough HTTPS once pointed at a real host. They also come with a hard operational rule on some platforms: do not move nameservers to Cloudflare or another DNS host, or you may lose the free domain. This guide explains how to keep nameservers on providers such as DNSHE while still serving a site from Cloudflare Pages via CNAME.

On this page
  1. Why NS changes are dangerous on free domains
  2. The CNAME model
  3. Steps on Cloudflare Pages
  4. Steps on DNSHE (generic)
  5. SSL and verification timing
  6. Implications for AdSense
  7. Checklist

Why NS changes are dangerous on free domains

Paid domains you register can usually move NS freely. Free subdomains are often a privilege tied to the provider’s DNS. If the control panel warns that custom NS are unsupported—or community lore says moving NS deletes the domain—treat that as a hard constraint. Cloudflare’s “add site / change nameservers” onboarding is the wrong tool here. You want DNS records only at the free provider, and Pages’ custom domain feature on Cloudflare’s side.

The CNAME model

A CNAME says: this hostname is an alias of another hostname. For Pages, you typically CNAME wei-huang.ccwu.cc to negency-lab-pilot.pages.dev (or the exact target Cloudflare displays). Visitors resolve your free hostname; Cloudflare terminates TLS and serves your static files. Apex domains sometimes need ALIAS/ANAME; many free subdomains are already nested hostnames, so CNAME fits naturally.

Do not create conflicting A records pointing at random IPs. Remove obsolete records that fight the CNAME. TTL can start low (300–600 seconds) while testing, then raise later.

Steps on Cloudflare Pages

  1. Deploy the site so https://<project>.pages.dev already works.
  2. Open Workers & Pages → your project → Custom domains → Set up a custom domain.
  3. Enter the free hostname (example: wei-huang.ccwu.cc).
  4. Cloudflare shows the DNS record it expects—usually a CNAME to your pages.dev hostname.
  5. Because DNS is not on Cloudflare, you will add that record at DNSHE (or your provider), then wait for Pages to validate.

If validation fails, re-check spelling, proxy status (for free providers there is no orange-cloud—just a normal CNAME), and whether you accidentally added the record on the wrong parent zone.

Steps on DNSHE (generic)

UI labels vary, but the workflow is:

  1. Log in to the DNSHE control panel with the account that owns the subdomain.
  2. Open DNS management for ccwu.cc / your subdomain entry.
  3. Add CNAME: host/name wei-huang (or full name depending on UI) → target negency-lab-pilot.pages.dev (trailing dots may be required—follow the panel’s example).
  4. Save. Do not change NS1/NS2 away from DNSHE values.
  5. Verify with dig CNAME wei-huang.ccwu.cc +short from any machine until the target appears.

If the panel offers “parked page” or “URL forward” instead of DNS records, prefer a real CNAME for Pages SSL. HTTP redirects alone often break certificate issuance.

SSL and verification timing

Cloudflare issues a certificate after it sees the correct CNAME. Propagation can take minutes to a few hours. During that window, pages.dev remains your reliable URL. Do not delete the pages.dev deployment. Once the custom hostname shows Active / SSL Active, test HTTPS with a mobile browser and check for mixed content (all assets on HTTPS paths).

Implications for AdSense

You can apply to AdSense using the pages.dev URL first, then add the custom domain later—or wait until the custom hostname is live. Consistency helps: whichever URL you submit should serve the same substantial content, privacy policy, and contact path. Free parent domains may share reputation with other subdomains; keep content original and policy-safe. Never buy fake traffic to “look active.”

Checklist

Follow the checklist in order. Skipping “pages.dev already works” is the most common cause of confusing half-configured domains.

How to verify with dig and browsers

After saving the CNAME, query from more than one resolver:

dig CNAME wei-huang.ccwu.cc +short
dig CNAME wei-huang.ccwu.cc @1.1.1.1 +short
curl -I https://wei-huang.ccwu.cc

If dig shows the correct target but HTTPS fails, focus on Cloudflare’s certificate state rather than rewriting DNS again. If dig shows nothing or an old target, wait for TTL or flush local caches; avoid “fixing” by adding A records that conflict.

Browser diagnostics: check the certificate subject matches your custom hostname, confirm HSTS is not pinning you to a broken prior experiment, and load the privacy page over the custom host. Bookmark both URLs during cutover.

Rollback plan

If the custom domain misbehaves, keep pages.dev as the canonical publish target. Remove or disable the custom domain in Pages if you need a clean slate, but you can also leave DNS in place while fixing content. Communicate the primary URL in AdSense and Search Console deliberately—switching submitted URLs mid-review without content parity creates avoidable confusion.