The apex domain (also called the root, naked, or zone apex — for example example.com rather than www.example.com) carries a structural limitation in DNS: it cannot host a CNAME record. This shapes how teams point root domains at SaaS providers, load balancers, and CDNs.
Why apex CNAMEs are forbidden
The DNS specification (RFC 1034 / RFC 2181) requires that the zone apex hold both a Start of Authority (SOA) record and Name Server (NS) records. A CNAME, by definition, says “this name is an alias for another name and has no other records.” Allowing a CNAME at the apex would conflict with the mandatory SOA and NS records that must live there.
Resolvers strictly enforce this. If you attempt to add example.com CNAME app.saas-provider.net, an authoritative DNS server should reject the configuration.
Why people want apex CNAMEs anyway
Pointing the bare root domain at a hostname (rather than a fixed IP) is desirable because:
-
SaaS providers, CDNs, and managed load balancers expose hostnames, not stable IPs. Their backing IPs rotate without notice.
-
Hard-coding an A record means re-pointing DNS whenever the provider rotates capacity.
-
Marketing teams want users to type
brand.comand land somewhere, without thewww.prefix.
This tension between “users want apex” and “DNS forbids apex aliases” produces the workarounds below.
Workaround 1: apex-to-WWW redirect
Keep an A record (or AAAA) at the apex pointing at a small redirect service. Users hitting example.com receive an HTTP 301 (or 308) to www.example.com, which is itself a CNAME pointing at the SaaS host.
- Pros: works with any DNS provider, requires no proprietary record types, simplest mental model.
- Cons: extra HTTP round-trip on first visit, breaks if the redirect host goes down, leaks bare-domain traffic to a separate path.
- The redirect service can be a CDN page rule, a tiny VM, or an S3 bucket configured for website redirection.
Workaround 2: CNAME flattening
The DNS provider resolves the CNAME chain server-side at query time and returns A/AAAA answers to the client. From the resolver’s perspective, the apex holds a normal A record. Behind the scenes the DNS provider re-queries the target hostname on each cache miss.
Compatible providers include:
- Cloudflare — free CNAME flattening on every plan, automatic when you create a CNAME at the apex. See also Cloudflare Plans.
- Route 53 — alias records, but only for AWS resources (CloudFront, ELB, S3 website, API Gateway, another Route 53 record).
- DNSimple — branded as ALIAS.
- DNS Made Easy — branded as ANAME.
- NS1 — ALIAS.
Server-side flattening does what the protocol forbids on the client side, while keeping the wire response standards-compliant.
Workaround 3: ALIAS / ANAME records
Some providers expose a virtual record type (ALIAS, ANAME) that the user configures as if it were a CNAME, but which the provider serves as A records to clients. This is functionally the same as flattening — the difference is mostly in branding and configuration UX.
- ALIAS / ANAME is not a standard DNS record type. It only exists at the management plane of the provider that supports it.
- Migrating between providers may require reconfiguring these records.
Tradeoffs
| Approach | Portability | Latency | Operational cost |
|---|---|---|---|
| Apex-to-WWW redirect | High | One extra round-trip | Low, but redirect host must be HA |
| CNAME flattening | Medium (locks you to compatible providers) | None | None |
| ALIAS / ANAME | Low (provider-specific) | None | None |
A common pragmatic answer: use a DNS provider that supports flattening, and additionally keep a redirect from www to apex (or vice versa) for users who type the alternate form.
Cloudflare specifics
Cloudflare’s free CNAME flattening applies whenever the domain uses Cloudflare nameservers. This is a separate concept from Cloudflare for SaaS apex proxying, which is an Enterprise-tier paid addon used by SaaS vendors to onboard their customers’ apex domains onto the SaaS platform. The two solve different problems:
- CNAME flattening: I own
example.com, want it to alias an external host. - Cloudflare for SaaS apex proxying: I run a SaaS, my customer wants
customer.com(their apex) to resolve into my platform, and I want to handle TLS and routing for them.
TLS interaction
A separate concern: certificates for the apex must include the apex name in the SAN list. A wildcard like *.example.com does not cover example.com itself. See TLS Certificate Authorities and TLS.
Key takeaways
- Apex CNAMEs violate RFC 1034 because of the mandatory SOA/NS records.
- Three workarounds exist: HTTP redirect, server-side flattening, ALIAS/ANAME records.
- Flattening is usually the cleanest if your DNS provider supports it.
- Apex coverage in TLS certificates needs explicit SANs — wildcards do not include the apex.
See also
References
- RFC 1034 — Domain Names: Concepts and Facilities
- RFC 2181 — Clarifications to the DNS Specification
- Cloudflare Learning Center: CNAME flattening
- AWS Route 53 documentation: alias records