If you have ever attempted to connect a custom root domain (like example.com) to Vercel, Netlify, or Shopify, you likely encountered warnings about "CNAME Flattening" or ANAME/ALIAS records. Why does this restriction exist in the first place, and why are subdomains immune?
The RFC 1034 Rule
The original Internet Engineering Task Force (IETF) specification for DNS in RFC 1034 states a fundamental rule:
"If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different in any database."
Because the root of every domain zone must contain essential zone records—specifically SOA (Start of Authority) and NS (Name Server) records—it is technically illegal under strict DNS specifications to place a CNAME record at the zone apex (@).
What Happens When You Need to Point to a Cloud Host?
Modern cloud hosts like Vercel and Netlify use elastic IP pools and Anycast routing. They don't want you hardcoding static IP addresses (A records), because if a data center has an outage, they can instantly reroute DNS via CNAME aliases.
This created a standoff: RFC specifications forbid CNAME on apex, but cloud infrastructure demands it.
The Solution: CNAME Flattening
DNS providers invented CNAME Flattening (also known as ALIAS or ANAME). When an external client queries the root apex:
- The authoritative nameserver looks up the target CNAME behind the scenes.
- It resolves the current IP addresses for that target.
- It returns an authoritative A Record response to the client, effectively bypassing the RFC limitation.
Why Subdomains are Cleaner for Developers
With a subdomain on Devs.Surf (e.g. studio.devs.surf), you never have to deal with apex SOA conflicts. You can freely assign direct CNAME records, A records, TXT challenges, or redirect sub-nodes without triggering protocol quirks.