How Cloudflare Lets You Point Your Root Domain at a CDN
If you’ve ever tried to point yourdomain.example.com (not www.yourdomain.example.com) at Vercel, Netlify, Cloudflare Pages, or any platform that gives you a hostname instead of an IP address, you’ve run into one of DNS’s oldest and most annoying limitations.
The short version: you can’t use a CNAME record at your root domain. And since those platforms don’t give you a static IP to use in an A record, you’re stuck, unless your DNS provider supports something called CNAME flattening.
Cloudflare does, and it’s on by default, even on the free plan.
The Root Cause
DNS was designed in 1987, and one of its rules has quietly caused headaches ever since: a CNAME record cannot coexist with any other record type at the same hostname. This is a hard restriction from RFC 1034.
The problem is that your root domain, example.com, the zone apex, must have NS records (nameservers) and an SOA record, and typically MX records for email. That makes a CNAME at the apex technically illegal under the spec. Resolvers are supposed to ignore it or reject it entirely.
This was fine in 1987. It became a real problem once CDNs and cloud platforms stopped handing out static IP addresses and started giving you hostnames like your-site.vercel.app or d1234abcd.cloudfront.net instead. Subdomains could use CNAMEs just fine. Root domains couldn’t.
What CNAME Flattening Does
Cloudflare’s CNAME flattening solves this by handling the resolution internally before it ever reaches the outside world.
When you add a CNAME record at your root domain in Cloudflare’s dashboard, Cloudflare doesn’t actually serve that CNAME to DNS resolvers. Instead, it follows the CNAME chain on its own infrastructure, chasing through however many hops there are, until it reaches a final A or AAAA record (an actual IP address). It then returns that IP as if your root domain had a plain A record all along.
From the outside world’s perspective, example.com has a normal A record. No RFC violations. No broken resolvers. The CNAME is invisible.
As a side benefit, because Cloudflare does this resolution on its own internal network rather than across the public internet, it’s also faster. When Cloudflare introduced this feature, they measured roughly a 30% improvement in DNS resolution time for flattened records.
ANAME, ALIAS, CNAME Flattening, Are These the Same Thing?
Yes, they’re all solving the same problem. Different DNS providers just use different names:
| Term | Provider |
|---|---|
| CNAME Flattening | Cloudflare |
| ALIAS | DNSimple, NS1 |
| Alias records | AWS Route 53 |
| ANAME | DNS Made Easy |
None of these are defined in any DNS RFC, they’re all proprietary implementations of the same workaround. In every case, the provider resolves the hostname to an IP server-side and returns a plain A record to the public. No CNAME ever appears in the actual DNS response.
So if you see a tutorial that says “add an ANAME record” and you’re using Cloudflare, just add a CNAME, flattening takes care of the rest.
How to Set It Up
- Log in to Cloudflare and navigate to your domain’s DNS settings.
- Click Add record.
- Set the type to CNAME.
- Set the name to
@(this represents the root domain). - Set the target to whatever hostname your platform gave you (e.g.,
your-project.vercel.app). - Save. That’s it.
Cloudflare will flatten it automatically. No extra configuration, no plan upgrade needed.
A Few Things Worth Knowing
Domain verification can break with “flatten all” enabled. Some services verify domain ownership by checking that a CNAME record resolves to their expected target. If you’re on a paid Cloudflare plan and have enabled the “flatten all CNAMEs” option zone-wide, those checks will see an IP address instead of a CNAME and fail. The fix is to leave that option off unless you specifically need it, apex flattening is automatic and unaffected.
Cross-account CNAMEs are blocked. If your CNAME points to a hostname on a different Cloudflare account, you’ll get Error 1014. This trips people up when, for example, a Cloudflare Pages project lives under a different account than the domain.
You don’t fully control refresh timing. Cloudflare caches the resolved IP based on the TTL of the records in the chain. If the final A record at your platform has a long TTL, IP changes won’t propagate as quickly as you might expect. For most CDN use cases this doesn’t matter, but it’s worth knowing.
If you have a static IP, use an A record. CNAME flattening exists to solve a problem, if you don’t have that problem (because you have a dedicated IP), a plain A record is simpler and more predictable.
The Bottom Line
Cloudflare’s CNAME flattening is one of those features that quietly makes modern web infrastructure easier. You point your root domain at a CDN hostname the same way you’d point any subdomain, Cloudflare handles the DNS spec compliance behind the scenes. It works on every plan, requires no setup, and is the same thing you’ll see called ALIAS or ANAME at other providers.
If you’re deploying to Vercel, Netlify, Cloudflare Pages, or any similar platform and want yourdomain.example.com (not just www) to work, this is the answer.
Thanks for reading!