CNAME Flattening, ALIAS, or a Plain A Record for Your Root Domain?

You set up a CDN or a cloud load balancer, the provider tells you to point your domain at a hostname like something.cdn.example.net, and the DNS panel refuses to save a CNAME on the bare domain. Or it saves it, and a day later email stops arriving. Both come from the same DNS rule. The way out is one of three options for the root domain: CNAME flattening, an ALIAS-style record, or a plain A record. Which one fits depends on a few questions you can answer before you touch the zone.

Why the root domain can't just be a CNAME

The bare domain, example.com with nothing in front of it, is called the zone apex. Every zone needs an SOA record (start of authority, which holds the zone's serial number and timing values) and NS records (which list the authoritative nameservers) at the apex. Most domains also keep MX records for mail and TXT records for SPF and site verification there. A CNAME says 'this name is really that other name, go ask over there'. The DNS standards (RFC 1034, clarified in RFC 2181) don't allow a name that has a CNAME to hold any other records. At the apex, SOA and NS are always there, so a CNAME conflicts by definition. Some DNS software rejects the record outright. Some panels let it through, and that is the worse outcome. When a mail server looks up the MX for your domain and finds a CNAME, it follows the alias and asks the CDN's hostname for MX records instead. That hostname has none, or has someone else's, so your mail goes nowhere. TXT lookups for SPF can follow the same path. In support, this tends to show up as two unrelated-looking tickets, 'site moved fine' and 'email stopped', on the same day. The two workarounds solve this in different places:

CNAME flattening and ALIAS (some providers call it ANAME) are done by your authoritative DNS server. You enter the target hostname, the server looks up its A and AAAA records itself, and answers queries for the apex with plain IP addresses. To the outside world the apex holds ordinary A records, so SOA, NS, MX, and TXT keep working. These are provider features, not one standard, so the details differ.
A plain A record means you copy the target's IP addresses into the zone yourself. Nothing is resolved dynamically. If the IPs change, you have to notice and update them.

The checklist, in the order worth doing it

Inventory what lives at the apex today. Before changing anything, write down the SOA, NS, MX, and TXT records, plus any existing A and AAAA. These are what you must not lose, and the list also tells you whether a misplaced CNAME is already hiding something. Query the authoritative nameserver directly so you see the zone as published, not a cached copy.

BASH

# Read-only checks. Replace example.com and the nameserver with your own.
dig +short NS example.com
dig @ns1.your-dns-provider.example example.com SOA +noall +answer
dig @ns1.your-dns-provider.example example.com MX +noall +answer
dig @ns1.your-dns-provider.example example.com TXT +noall +answer
dig @ns1.your-dns-provider.example example.com A +noall +answer
dig @ns1.your-dns-provider.example example.com AAAA +noall +answer

Ask the target whether its IPs are stable. This is the question that decides most cases. Some CDNs and load balancers publish fixed addresses, often anycast IPs (the same IP announced from many locations), and say they won't change. Others hand you only a hostname because the IPs behind it move as they scale or fail over. Look in the target's documentation for wording about static IPs or apex support. If you can't find a clear commitment, treat the IPs as changeable.
Check what your DNS provider supports at the apex. Look for a record type called ALIAS or ANAME, or a setting called CNAME flattening, in the panel or the provider's documentation. If none of these exist, your options are a static A record, moving DNS to a provider that has the feature, or the redirect approach described further down. Don't assume a feature exists because another provider has it.
Confirm mail and verification records stay untouched. After the change, query MX and TXT at the apex again and compare against your inventory. Flattening and ALIAS are designed to leave these alone, but a mistyped record or a panel that swaps record types can still remove them.
Don't forget IPv6. If the target serves AAAA records, check that your setup returns them at the apex too. With a static setup you need to add AAAA records yourself. With flattening or ALIAS, check whether the provider passes AAAA through. A missing AAAA isn't fatal, but an outdated one is, because IPv6-capable visitors will try it first.

Questions that only matter for flattening and ALIAS

With these options the lookup happens on your DNS provider's servers, not near the visitor. That causes a few side effects worth checking before you rely on it. Geo-routing. Many CDNs answer DNS based on where the query comes from and return a nearby edge. When your authoritative server resolves the target on the visitor's behalf, the CDN sees the provider's location instead. Depending on the provider, visitors may get an edge that's farther away than the one www would give them. Some providers forward EDNS Client Subnet (a hint about the visitor's network) or resolve from many locations to soften this. Check your provider's documentation, then compare dig answers for the apex and for www from a couple of different networks. TTL. TTL (time to live) is how long resolvers cache an answer. Providers handle it differently for flattened answers: some reuse the target's TTL, some apply their own value, some use whatever you set on the record. If the target changes IPs often and your apex answer is cached longer than the target's, visitors can keep hitting old addresses for a while. DNSSEC. If your zone is signed, the synthesized A and AAAA answers must be signed as well, which means the provider has to sign them at query time. Check that the provider supports flattening on signed zones, and test with a validating resolver after enabling it. A signing gap shows up as SERVFAIL for visitors whose resolvers validate. Portability. ALIAS isn't a real record type that other DNS software understands. A zone export may contain it in a provider-specific form, or contain a snapshot of the current IPs, or leave it out. The same goes for secondary DNS fed by zone transfer. If you run multi-provider DNS or plan to migrate, test what the export and transfer actually contain before you depend on them.

When a plain A record is the right answer

A static A record is the simplest option, and it's fine when the target publishes IPs meant for this purpose. It works with every DNS provider, behaves the same in exports and zone transfers, and has no hidden resolution step to debug. The cost is that you own the update. Leave a note in the zone or your runbook saying where the IPs came from, and set up a simple check that compares the apex A records against what the target hostname currently returns. Then a silent change on their side turns into an alert instead of an outage. Where a static A record goes wrong is when the IPs were copied from a dig of a hostname that was never promised to stay put. It works for weeks and then stops, and nobody remembers the record was a copy. If neither a stable IP nor a flattening-capable provider is available, a third path is to serve the real site on www, point www at the target with a normal CNAME, and make the apex redirect to www. Something still has to answer HTTP and HTTPS on the apex to issue that redirect, so the apex needs an A record pointing at a server or redirect service that holds a valid certificate for the bare domain. That server becomes part of the path for anyone who types the short name, so it needs the same care as the site itself. There's also the newer HTTPS record type (from the SVCB family, RFC 9460), which can alias the apex to another name in a standard way. Support across browsers and resolvers is still uneven, so for now it's something to add alongside one of the options above, not a replacement for them.

Picking one without regret

Start with the target: if it publishes stable IPs, a plain A record (plus AAAA where offered) is the least surprising choice. If it only gives you a hostname, use flattening or ALIAS from a provider that supports it, and check how that provider handles geo-routing, TTL, DNSSEC, and exports. If you have neither, move the site to www and redirect the apex. Whichever you pick, take an inventory of SOA, NS, MX, and TXT before the change and compare it afterwards, because mail is usually the first thing to break and the last thing anyone checks.