You cannot put a real CNAME on the apex — use CNAME flattening

No — you cannot put a real CNAME on your root (apex) domain like example.com. RFC 1034 states that a CNAME cannot coexist with any other record at the same name, but the apex is required to carry SOA and NS records, so a literal apex CNAME is invalid and most authoritative DNS hosts will reject it. The standard workaround is CNAME flattening (also marketed as ALIAS or ANAME): the authoritative server resolves the target's address at query time and returns A/AAAA records, so clients see ordinary address records at the apex while you still get the convenience of pointing at a hostname.

Why the apex blocks a CNAME

A CNAME is an exclusive alias: it says "this name is just another name for that one, look there for everything." The DNS specification forbids any other record type sitting alongside it. The apex of a zone, however, must always publish:

example.com.   IN   SOA   ns1.example.com. hostmaster.example.com. ...
example.com.   IN   NS    ns1.example.com.
example.com.   IN   NS    ns2.example.com.

Because SOA and NS are mandatory there, a CNAME at the apex would violate the no-coexistence rule. (A CNAME on a subdomain like www.example.com is perfectly fine — there are no mandatory records competing with it.) This is why www "just works" as a CNAME but the bare domain does not.

How flattening / ALIAS / ANAME fix it

These are all the same trick under different vendor names. You configure what looks like a CNAME at the apex pointing to, say, target.cdn.net. Internally the authoritative nameserver does not store a CNAME; instead, when a resolver asks for the apex, the server itself looks up the target's A/AAAA records and synthesizes the answer:

example.com.   IN   A      203.0.113.42
example.com.   IN   AAAA   2001:db8::42

The client receives valid address records at the apex, fully RFC-compliant, with no CNAME ever leaving the server. Cloudflare calls this CNAME flattening; Route 53 calls it an alias record; other providers call it ANAME or ALIAS.

Caveats worth knowing

Flattening is convenient but not identical to a true alias:

• The provider does the lookup, not the client. If the target serves geo-aware or CDN-routed answers, those answers reflect the DNS provider's location and resolver, not your end user's. A user in another region may be pointed at a sub-optimal edge.
• TTL handling varies. Some providers honor the target's TTL; others impose their own. Check how long flattened answers are cached so a backend IP change actually reaches clients on schedule.
• Support is not universal. Not every DNS host offers flattening. If yours does not, you either move DNS to one that does, or point the apex at static A/AAAA records and accept that you must update them manually when the target changes.

When in doubt, query the apex and confirm you are getting A/AAAA records back rather than a rejected or missing answer.

Look up your DNS records →

Further reading

• DNS propagation is really TTL expiry — here is how long it takes
• No MX record found: what it means and how to fix it
• CAA records explained: limiting who can issue your certificates
• RFC 1034 — Domain Names: Concepts and Facilities (the CNAME coexistence rule)
• RFC 2181 — Clarifications to the DNS Specification