CNAME at the Apex: ALIAS and Flattening

Why the apex cannot hold a CNAME

When a resolver finds a CNAME at a name, it restarts the lookup at the target name for every record type. If example.com were a CNAME to site.example.net, a mail server asking for the MX records of example.com would be sent to site.example.net and get that zone’s MX records, or none. The same would happen to TXT records holding SPF and domain verification tokens, to CAA records, and to the NS and SOA records that define the zone itself.

That is why the standard forbids a CNAME from coexisting with other data. Only a small set of DNSSEC records (RRSIG and NSEC) are allowed alongside it. The apex is the one name in every zone that is guaranteed to have other data, so a CNAME there is always a conflict.

Some authoritative servers refuse to load a zone with an apex CNAME. Others load it and return inconsistent answers depending on which record type is asked for. Neither outcome is something you want in production, and it is easy to miss because the website may appear to work while mail or certificate issuance quietly fails.

How ALIAS and CNAME flattening work

ALIAS, ANAME and CNAME flattening are different product names for the same idea. You store a pointer to a target hostname in your provider’s control panel. When a resolver asks the provider’s authoritative servers for the A or AAAA records of the apex, the provider looks up the target itself, follows any CNAME chain to the final addresses, and returns those addresses as if they were records in your zone.

From the outside, nothing unusual is visible. The resolver asked for an A record and received an A record. There is no CNAME in the answer, so no rule is broken, and every other record at the apex keeps working.

Some providers flatten at query time, others refresh the target on a schedule and cache it. Some go further and flatten any CNAME in the zone, not only the apex. A few, such as the alias records in some cloud DNS services, only work when the target is a resource on the same platform. Read your provider’s documentation for which targets are allowed and how often the answer is refreshed. There was an IETF effort to standardize the behavior as the ANAME draft, but it did not become an RFC, so details differ between providers and the setting does not transfer cleanly in a standard zone file.

What flattening looks like with dig

Compare a subdomain that uses a real CNAME with an apex that is flattened. The subdomain shows the alias chain; the apex shows only addresses.

$ dig +noall +answer www.example.com A
www.example.com.        300   IN  CNAME  app.example.net.
app.example.net.        60    IN  A      192.0.2.10
app.example.net.        60    IN  A      192.0.2.11

$ dig +noall +answer example.com A
example.com.            60    IN  A      192.0.2.10
example.com.            60    IN  A      192.0.2.11

$ dig +noall +answer example.com CNAME
$ dig +noall +answer example.com MX
example.com.            3600  IN  MX     10 mail.example.com.

The empty CNAME query and the intact MX answer are what you want to see. If dig example.com CNAME returns a record, the zone really does publish a CNAME at the apex and should be fixed. Notice also that the flattened records carry a short TTL. Many providers copy the target’s TTL or cap it, so the apex follows changes on the target reasonably quickly. For more on how those numbers affect what users see, read DNS TTLs and Caching Explained.

Choosing an approach

The HTTPS record option is the standards-based answer to this problem. An HTTPS record with priority 0 says “for HTTPS on this name, use that other hostname,” and unlike a CNAME it can sit at the apex beside other records. Client support for AliasMode is still limited, so for now it complements flattening rather than replacing it. SVCB and HTTPS DNS Records explains the format.

Pitfalls to watch for

Location-aware targets

CDNs and global load balancers often return different addresses depending on where the query comes from. With a real CNAME, the user’s recursive resolver follows the chain and gets an answer suited to its own location. With flattening, the provider’s server does the lookup, so the answer may be tuned to the provider’s location instead. Some providers pass the original resolver’s subnet along to reduce this effect. See GeoDNS and DNS Load Balancing and How CDNs Use DNS to Route Users for why that matters.

DNSSEC and stale answers

Because the provider invents the A and AAAA records on the fly, a DNSSEC-signed zone needs a provider that signs those answers as it serves them. If the target stops resolving, the provider has nothing to return, and different providers handle that differently: some return an empty answer, some serve the last known addresses, and some return SERVFAIL.

Takeover risk

A flattened apex can dangle just like a CNAME. If you cancel the hosting account but leave the ALIAS pointing at its hostname, whoever claims that hostname next may be able to serve content on your bare domain. Remove the ALIAS when you decommission the service, as covered in Subdomain Takeover Attacks: What They Are and How to Stop Them.

How DNS Panopticon helps

Domain Visualizer resolves the apex live and raises a high-severity finding, “CNAME record at zone apex,” when one is published, along with the reason it breaks SOA and NS. A flattened apex does not trigger that finding because resolvers only see A and AAAA records.

Website Recon matches providers partly by CNAME suffix. When the apex is flattened there is no CNAME to match, so Recon relies on the network and AS number of the resolved addresses instead. Running Recon on both example.com and www.example.com is a quick way to confirm both names land on the same platform. If you have a zone export, Zone Analyzer lets you filter the grid by type to review every CNAME in one place before a migration.