Reference guide · dns-ssl · Published 2026-08-16 · 4 min read
What CNAME flattening is and how to use it
What CNAME flattening is, why apex CNAME records fail normally, and when to point your root domain at a hosting service.
- ·The DNS rule
- ·How flattening works
- ·When to use it
The DNS rule that makes this hard
A CNAME record says "this name is an alias for that other name". RFC 1034 also says that once a node has a CNAME, no other record type may coexist with it. The DNS zone apex, the root of your domain, must carry the SOA and NS records, so by the spec there is no legal room for a CNAME at the apex. Most authoritative DNS servers refuse one outright.
The practical consequence is the problem every cloud service met: if your service only exposes a hostname and does not give you a stable IP, there was no standards way to point the bare domain at it. The CNAME vs A record article covers the base comparison, and the record types reference has the full taxonomy.
How flattening works
CNAME flattening is a provider-side workaround. When you create a CNAME at the apex (or any name your provider chooses to flatten), the provider does not return the CNAME. Instead its DNS servers act as a resolver: they look up the target's A and AAAA records themselves, cache the result, and answer your apex query with those IPs as if you had configured an A record.
So the resolution path is:
- A resolver asks for
example.com. - The authoritative server (your provider) sees the CNAME and resolves its target internally.
- It returns the target's IP addresses as the A/AAAA answer, respecting the target TTL.
To the client it looks completely standard, an A record, and the DNS response remains valid alongside the mandatory SOA and NS records. The trick is invisible and RFC-compatible from the resolver's point of view, which is exactly what the providers advertise.
When to use it
Use a flattened CNAME when you want the apex to point at a service that only gives you a hostname, such as a load balancer, a CDN, a site builder, or a cloud hosting origin that rotates IPs.
| Hosting model | Apex solution |
|---|---|
| Service gives a stable IP | Plain A record, no flattening needed |
| Service gives a hostname (hosted platform) | CNAME at apex, flattened by the DNS provider |
| You need low DNS resolution latency | Target an IP or a provider with a known, stable reply |
The trade-off is timing and control. The flattened answer is only as current as the provider's cached resolution of the target, so when the target's IPs change, the apex answer lags by the target's TTL. For most websites served through a CDN that is a non-event, but for a service you move between hosts on the same day the lag can be noticed. If the provider supports it, an ALIAS-like record at the apex is the same idea, and DNS solutions like Route 53 call the equivalent an alias record.
CNAME flattening and CDNs
The CDN static assets article mentions the same handshake from the performance side. When the CNAME target is a CDN, the flattening and the proxy can compose: your DNS provider resolves the CDN's anycast IPs and your traffic lands on the nearest CDN edge, whether or not a proxy is involved. Using a flattened CNAME to a CDN is the standard reason people enable it, because a CDN almost never publishes a stable IP to point an A record at.
Prevention
Only use CNAME flattening when the target truly has no stable IP, keep the zone's host records accurate, and check with a dig that the apex returns an A record to clients (the provider synthesizes it) so you never present a broken CNAME to a resolver that rejects it.