ALIAS record and CNAME flattening

Two rules collide. A CNAME may not share its name with any other record (RFC 1034 section 3.6.2, restated as absolute in RFC 2181 section 10.1). And the apex of every zone must carry that zone's SOA and NS records. So at the apex there is always other data, and a CNAME can never be added. This is not a provider limitation; it is the protocol.

It matters because the natural instruction for a SaaS custom domain is "add a CNAME to us", and customers frequently want their bare apex domain to work.

In the provider's editor the record looks like a CNAME: a name and a target hostname. On the wire nothing CNAME-shaped is ever sent. When a query for the apex arrives, the provider's nameserver looks up the target's A and AAAA records itself and answers with those addresses, as if they were ordinary A records at the apex. Clients see a normal answer and need no special support.

There is no RFC for this. An ANAME draft went through the IETF DNSOP working group but was never published, so every provider implements its own version under its own name and limits.

• CNAME flattening: Cloudflare, which lets you enter a CNAME at the apex and resolves it when answering.
• ALIAS: DNSimple, Namecheap, Porkbun, Gandi (LiveDNS only), Hostinger, Squarespace Domains, Vercel and WordPress.com.
• ANAME: Name.com.
• Alias records on AWS Route 53 work at the apex, but AWS documents their targets as its own resources (CloudFront, load balancers, S3 website endpoints and similar) or another record in the same hosted zone, not an arbitrary vendor hostname.
• None: several popular hosts offer no apex alias at all. There the customer needs A records or a www redirect.

Each of those rows is sourced from the provider's own documentation in the apex-domain guide's provider table, which also lists the providers whose documentation does not settle it either way. Providers add features without notice; treat any list as a starting point.

• Location-aware answers can go wrong. If the target is a CDN that picks an edge by the location of whoever asks, it sees the provider's nameserver asking, not the visitor. Some providers mitigate this; the effect depends on both sides.
• The answer is only as fresh as the provider's own cache of the target, on top of the usual TTLs.
• DNSSEC can suffer. Gandi's documentation warns that its ALIAS record breaks DNSSEC on the bare domain.
• Verification that looks for a CNAME finds addresses. A check that asks the apex for a CNAME gets A records back and fails, even though the setup works.

A standards-track alternative now exists: the HTTPS and SVCB record types (RFC 9460) have an alias mode that is allowed at the apex. It is followed only by clients that implement the HTTPS record, and plain A and AAAA lookups ignore it, so it complements rather than replaces an address at the apex.

If your product is reachable only by hostname, ask for a subdomain, or tell customers on a provider with an alias feature to set it up themselves. If you have stable addresses, ask for A records at the apex. The DNS provider detector tells you which host serves a customer's zone before you choose.

• Apex domains (docs)

  The sourced provider-by-provider table, and what DoDomain supports at the apex.

• DNS provider detector

  Find which DNS host a customer is on, and so which row of the table applies.

• DNS propagation checker

  See what a flattened apex actually answers at the authoritative nameservers.

• Apex domain

  What the apex is and which records must live there.