You cannot put a real CNAME on the apex — use CNAME flattening
· dns · cname · apex · alias · aname
dnscnameapexaliasanameNo — 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/AAAArecords 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.
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