If you have ever tried to point your bare domain, for example example.com with no www, at a CDN or a SaaS platform that only gives you a hostname, you have probably run into a wall: your DNS provider refuses to let you put a CNAME on the apex. That is not a bug or a limitation of one vendor. It is a rule of the DNS protocol itself. ALIAS records, ANAME records, and CNAME flattening are the three ways providers work around it so your root domain can behave like it has a CNAME.
Why a CNAME cannot live at the apex
A CNAME record means "this name is just an alias for another name, so go look there for everything." The DNS standards are strict about one thing: if a name has a CNAME, it can have no other record of any other type. That exclusivity is the whole definition of a canonical name.
The problem is that your apex is not allowed to be empty of other records. By definition it must carry an SOA record and a set of NS records, and it almost always carries MX records for email too. Those cannot coexist with a CNAME. So the moment you try to alias the apex with a real CNAME, you would be breaking the one name that your entire zone depends on.
# This is illegal and will be rejected:
example.com. 3600 IN CNAME d1234.cloudfront.net.
example.com. 3600 IN SOA ns1.example.com. ... # conflict!
example.com. 3600 IN NS ns1.example.com. # conflict!Subdomains have no such constraint, which is why www.example.com CNAME example.com or shop.example.com CNAME myshop.myhost.net work perfectly. The restriction is specific to the apex because of what must live there.
The three workarounds
All three solve the same problem, which is "I need my apex to follow a hostname whose IP I do not control and which may change." They differ in where the resolution happens.
| Approach | What it is | What the world sees at the apex |
|---|---|---|
| ALIAS | A provider-specific record type | Normal A / AAAA records |
| ANAME | A provider-specific record type (same idea, different name) | Normal A / AAAA records |
| CNAME flattening | You enter a CNAME at the apex; the provider resolves and replaces it | Normal A / AAAA records |
The key insight is in the right-hand column: in every case, external resolvers receive ordinary A and AAAA records. The special handling is entirely server-side, inside your DNS provider. Nothing non-standard ever leaves the authoritative nameserver, so the rest of the internet, and DNSSEC, stays happy.
ALIAS and ANAME records
With ALIAS or ANAME, you configure a new record type that your provider understands. You tell it "the apex should follow d1234.cloudfront.net." Behind the scenes, when a query for your apex arrives, the provider looks up that target hostname, gets its current A and AAAA records, and returns those addresses as if they were ordinary A and AAAA records on your apex.
# Provider control panel (ALIAS/ANAME):
example.com. ALIAS myapp.herokudns.com.
# What a client actually receives:
$ dig example.com A +short
52.20.14.33
52.72.18.9CNAME flattening
CNAME flattening, popularized by Cloudflare, takes a different user experience. You literally enter a CNAME at the apex in the dashboard, and the provider accepts it because it knows it will not actually serve a CNAME. At query time it resolves the chain all the way to the final addresses and returns those A and AAAA records instead. The CNAME never goes out on the wire. Some providers let you flatten at the apex only, and some let you flatten any CNAME in the zone.
How the follow actually works
All three are dynamic. The provider periodically re-resolves the target hostname, so if your CDN or SaaS platform rotates its IP addresses, your apex quietly tracks the change. This is exactly the benefit a CNAME would give you if it were legal at the apex, and it is why you should never hardcode the target's current IPs into plain A records: the target can change them without notice and your site would go dark.
- A resolver asks your authoritative server for the apex A record.
- Your provider resolves the configured target hostname to its current addresses.
- It returns those addresses as A/AAAA records for your apex, with a TTL it controls.
- The resolver caches ordinary A records and never knows a hostname was involved.
Trade-offs to know before you rely on it
- It is not portable. ALIAS and ANAME are provider-specific. If you migrate DNS hosts, the record type may not exist at the new provider and you will need to reconfigure using whatever they offer.
- TTL is the provider's call. Because the provider resolves on your behalf, the TTL clients see is set by the provider, not by the target. If the target uses a very short TTL for fast failover, your flattened record may not react as quickly.
- Geolocation can be lost. Many CDNs return different IPs based on where the request comes from. If your provider resolves the target from one location, every visitor may get the same regional IPs rather than their own nearest edge. Some providers mitigate this; many do not.
- Health of the target matters. If the target hostname fails to resolve during a refresh, behavior varies by provider, from serving stale addresses to returning nothing.
- Certificate validation. HTTP-based ACME challenges on the apex generally work fine because the apex resolves to real addresses, but keep this in mind if you automate issuance.
The simplest alternative
If your platform publishes stable IP addresses specifically for apex use, you can skip all of this and set plain A and AAAA records. Several providers now hand out dedicated static anycast IPs for exactly this reason. The catch is you must keep those records in sync if the provider ever changes them, so the flattening or ALIAS approach remains safer whenever the target is a hostname that can move.
A quick decision guide
- Does your platform give you static apex IPs? Use plain A/AAAA records.
- Does it only give you a hostname? Use ALIAS, ANAME, or CNAME flattening, whichever your DNS provider supports.
- Is the target geo-aware (a global CDN)? Confirm your provider preserves geolocation, or accept that visitors may hit a single region.
- Planning to change DNS hosts later? Document which apex workaround you used so you can recreate it.
Check what resolvers really get
Because the magic happens inside your provider, the only way to be sure is to query your apex from the outside and confirm it returns healthy A and AAAA records that match your platform. After you set an ALIAS, ANAME, or flattened CNAME, verify the addresses are resolving everywhere with the Valla DNS propagation checker, and if you want to understand the apex records that make a CNAME impossible there in the first place, the Valla DNS /learn/ guides on the SOA record and wildcard records are a useful pairing.