Sooner or later everyone hits the same wall: you want your bare domain, example.com, to point at a hostname your hosting provider gave you — something like my-app.herokudns.com or a CDN endpoint — and DNS refuses to let you. A CNAME would be the obvious tool, but you cannot put a CNAME at the apex of a domain. Every DNS provider has invented a way around this, and they are subtly different. Understanding the restriction, and the three main workarounds, tells you what to expect from each platform.
The apex restriction, and why it exists
The apex — also called the root or the zone apex — is the bare domain itself, example.com with no subdomain in front. The DNS standards say a CNAME record cannot coexist with any other record for the same name. But the apex is obliged to carry other records: it must hold the zone's SOA record and its NS records, and it very often holds MX and TXT records too. Because a CNAME cannot sit alongside those, a CNAME at the apex is simply illegal DNS. This is why www.example.com can be a CNAME — it has no such obligations — while example.com cannot. The restriction is not a provider limitation; it is baked into how DNS works, which is exactly why providers had to build synthetic answers to route around it.
The shared idea: resolve at the server, answer with addresses
All three workarounds — flattening, ALIAS and ANAME — do the same conceptual thing. You configure a record at the apex that names a target hostname, just like a CNAME would. But instead of returning a CNAME to the client, the authoritative DNS server resolves that target itself, fetches its current A and AAAA addresses, and answers the apex query with those addresses directly. To the outside world the apex looks like a normal address record; behind the scenes the provider is chasing the target for you and keeping the answer fresh. The differences between the three are mostly about naming, standardisation and operational detail.
Cloudflare: CNAME flattening
Cloudflare calls its approach CNAME flattening. You literally create a CNAME record at the apex in the dashboard, and Cloudflare accepts it but does not serve it as a CNAME. Instead its resolvers follow the target, resolve it to addresses, and return those A/AAAA records in response to apex queries — "flattening" the alias into addresses. Because Cloudflare is also acting as a proxy for most of its customers, this fits naturally into how it already answers. The upside is that it just works and needs no special record type to learn. The trade-off is that the flattening happens inside Cloudflare's infrastructure, so the freshness of the answer depends on Cloudflare re-resolving the target, and the behaviour is specific to their platform rather than a portable standard.
Amazon Route 53: ALIAS records
Route 53 uses a proprietary ALIAS record. Rather than pointing at an arbitrary external hostname, an ALIAS is designed primarily to point the apex at AWS resources — a CloudFront distribution, an S3 static-site endpoint, an Elastic Load Balancer, or another Route 53 record in the same hosted zone. Route 53 resolves the alias internally and answers apex queries with the target's addresses. Two things make it distinctive. First, because it is tightly integrated with AWS, Route 53 knows the current addresses of those AWS resources natively and keeps up with them as they change. Second, ALIAS queries to AWS resources are not billed the way standard queries are, which matters at scale. The trade-off is lock-in: ALIAS is most powerful when the target is an AWS service, and it is a Route 53 feature you cannot take with you to another provider.
NS1 and others: ANAME records
ANAME is the name used by NS1 and several other providers (DNS Made Easy and others have their own equivalents) for a more general-purpose apex alias to any external hostname. Conceptually it is the same trick — resolve the target server-side, answer with addresses — but it is positioned as a vendor-neutral-ish record type rather than tied to one cloud's resources. There has been an effort to standardise ANAME behaviour so it works predictably across providers, though it remains provider-specific in practice. ANAME's strength is flexibility: it happily points an apex at a third-party CDN or SaaS hostname outside the provider's own ecosystem. Its trade-off is operational subtlety around how often the target is re-resolved and how the provider handles a target that returns different addresses to different regions.
Trade-offs to weigh
Three themes recur across all of them. Freshness: because the provider caches the resolved addresses, there is always a small lag between the target changing its addresses and the apex reflecting it — usually seconds to minutes, but worth knowing if your target uses very short TTLs. Geolocation: if the target hostname returns different addresses depending on where the query comes from (as most CDNs do), the provider's resolver location can influence which addresses your apex hands out, occasionally sending users to a less-than-optimal edge. And portability: none of these are true DNS records on the wire, so a zone that relies on flattening, ALIAS or ANAME does not transfer cleanly to a provider that lacks the equivalent feature. Plan your migrations with that in mind.
Choosing, and verifying
In practice the choice is usually made for you by the provider you already use: Cloudflare users flatten, Route 53 users use ALIAS, NS1 and similar users use ANAME. The important thing is to understand that all three are solving the illegal-apex-CNAME problem the same way, so once you know the mechanism you can reason about any of them. Whichever you use, verify the result by resolving the apex and confirming it returns real A/AAAA addresses rather than an errant CNAME — this site's resolver follows the chain and shows you exactly what the apex answers with. For the wider picture of records across your zone, our sibling DNS Studio helps you audit them, and DNSSEC Studio covers signing the zone, which interacts with synthesised apex answers in ways worth checking if you deploy DNSSEC alongside flattening or ALIAS.