CNAME flattening

CNAME flattening is a DNS provider technique that lets an apex domain, like acme.com, behave as if it had a CNAME record. The provider follows the CNAME chain itself and returns the final A or AAAA addresses, staying within DNS rules while keeping the target dynamic.

The apex problem

DNS has an old and strict rule: a CNAME record cannot coexist with any other record type at the same name. The apex of a zone, the bare domain like acme.com, must always carry SOA and NS records. Put those two rules together and the conclusion is that acme.com can never hold a standard CNAME. Subdomains like www.acme.com or app.acme.com can, which is why SaaS platforms prefer them. The full comparison lives in apex domain vs CNAME.

That rule collides with how modern platforms work. A platform's ingress addresses change over time, so it wants customers pointing at a stable hostname rather than at IP addresses that may rotate. For subdomains, a CNAME does exactly that. For the apex, standard DNS offers no equivalent.

How CNAME flattening works

Flattening is the workaround, implemented by the authoritative DNS provider. The zone stores something that looks like a CNAME at the apex, but the provider never serves it as one. When a query arrives, the provider resolves the CNAME chain itself, finds the final A or AAAA records, and returns those addresses directly. Resolvers and clients see ordinary address records, so no DNS rule is violated, while the zone owner keeps a dynamic pointer to the platform's hostname.

Providers differ on when resolution happens. Some resolve at query time, others cache on a schedule. Either way, the flattened answer can lag changes at the target by roughly the record's TTL, and answers from geo-aware targets reflect the location of the DNS provider's resolver rather than the end user's. For most SaaS routing, where the platform's edge handles distribution anyway, neither is a problem in practice.

ALIAS, ANAME, and the naming mess

Flattening was never standardized, so DNS providers invented their own names for the same idea.

Name	Used by	Notes
CNAME flattening	Cloudflare and others	Applied automatically to CNAMEs at the apex.
ALIAS record	DNSimple, NS1, and others	A virtual record the provider resolves for you.
ANAME record	DNS Made Easy, easyDNS, and others	Also the name of an IETF draft that was never completed.
Alias record	Amazon Route 53	Points at selected AWS resources rather than arbitrary hostnames.

The behaviors are similar but not identical, which matters when you write connection instructions for customers spread across many providers.

What this means for SaaS custom domains

When your customers connect apex domains to your platform, their DNS provider decides what is possible. Some support flattening or ALIAS records and can point acme.com at your edge hostname cleanly. Others support only plain A records, which means pointing at stable IP addresses or redirecting the apex to www. A platform that hands every customer the same CNAME instructions will strand the ones on providers without flattening.

This is exactly the kind of variance a managed connection layer absorbs. Custom Domain detects the customer's DNS provider and configures the record shape that provider actually supports, then verifies it automatically, so apex domains and subdomains both come live without your team maintaining provider specific documentation. TLS still has to be issued for the apex hostname itself, which is covered in automating TLS for customer domains, and the full connection flow is described in how it works.