DNS CNAME Flattening Explained: How to Use Apex Domains with CDNs and Cloud Services

The Apex Domain Problem (and Why You Should Care)

If you've ever tried to connect your website to a CDN or cloud platform, you've likely hit the same wall: the service asks you to create a CNAME record. But your domain's root — the apex, or bare domain like example.com — was never meant to use CNAME records. The DNS specification (RFC 1034) states that a CNAME cannot coexist with other record types at the same name. Since every domain requires SOA and NS records at its root, CNAMEs are off-limits there. Subdomains like www work fine, but the apex has historically been stuck with static A records.

This creates a serious limitation. CDNs and cloud platforms (think Cloudflare, AWS, Netlify, Vercel, Shopify) need to route your traffic dynamically across many servers, which requires DNS control via CNAME aliasing. Without a workaround, you'd be forced to redirect all users from example.com to www.example.com — not ideal for brand consistency, link equity, or email authentication.

Enter CNAME flattening.

What Is CNAME Flattening?

CNAME flattening is a DNS technique that lets your authoritative DNS provider answer queries for your apex domain as if it were a CNAME. The trick: instead of returning a CNAME response to the client, the provider resolves the chain on its own edge and returns a final A or AAAA record. The end user's resolver never sees the CNAME; it just gets a normal IP address. This neatly bypasses the RFC restriction while keeping the apex fully functional.

The relevant language in RFC 1034 calls this behavior "implementation-specific" at the root — modern providers like Cloudflare, Amazon Route 53, and DNSimple took that permission and made it production-ready.

How CNAME Flattening Works

Here's the simplified flow, step by step:

• A user asks for example.com.
• The query reaches your authoritative DNS provider (e.g., Cloudflare).
• The provider sees a CNAME record for example.com pointing to a target like my-site.netlify.app.
• Instead of telling the resolver "go ask netlify.app," the provider resolves that target itself.
• The provider returns the resulting IP address as a standard A record response.

The browser, the client, and even intermediate resolvers never need to know a CNAME exists. Everything looks like a normal DNS query, and your apex behaves exactly like a CNAME-backed subdomain.

Why CDNs and Cloud Services Depend on It

CDNs route your traffic through global anycast networks. To do that effectively, they need the ability to change origin IPs, load-balance across regions, and fail over to backup servers at a moment's notice. If your apex were hardwired to a single A record, the CDN couldn