You’ve just deployed a scalable application on a modern platform like AWS, Vercel, or Heroku. You have your shiny new domain name, shiny.com. You go to your DNS registrar to point the domain to your app, and you hit a wall: You cannot create a CNAME record for the root domain.
If you try to point www.shiny.com to your load balancer, it works perfectly. But the naked domain? The system rejects it.
This is a classic “gotcha” in web infrastructure. Here is everything you need to know about the Apex Domain, why it behaves differently than the rest of your zone, and the modern workarounds that solve the problem.
What is an Apex Domain?
The Apex Domain (also known as the root, bare, or naked domain) is the base level of your domain name hierarchy. It is the domain without any prefixes.
- Apex:
shiny.com - Subdomain:
www.shiny.comorapp.shiny.com
In DNS configuration files (zone files), the apex is often represented simply by the @ symbol. While it looks just like any other part of the URL to a user, to a DNS resolver, it is the “Start of Authority”, the absolute root of your specific zone.
The Problem: The CNAME Limitation
The reason you struggle to point an apex domain to a cloud service (like my-app.elb.amazonaws.com) lies in the ancient laws of the internet: RFC 1035.
The DNS specification dictates two conflicting rules:
- The Apex Requirement: An apex domain must contain specific records to function, namely the SOA (Start of Authority) and NS (Name Server) records.
- The CNAME Rule: If a CNAME record exists for a hostname, no other records can exist for that same name.
A CNAME effectively says, “Don’t look here; I am just an alias. Go look at this other domain instead.”
If you put a CNAME at the apex, you are telling the DNS resolver to ignore everything at the root, including the essential SOA and NS records that tell the internet your domain exists. Because of this logical paradox, standard DNS forbids CNAMEs at the root.
The Solutions: How to Point the Apex
Since we cannot use standard CNAMEs, we have two primary ways to route traffic from the naked domain.
1. The Legacy Method: A/AAAA Records
Traditionally, you point the apex domain directly to an IP address using an A record (for IPv4) or an AAAA record (for IPv6).
- Host:
@ - Type:
A - Value:
192.0.2.1
The Downside: This is “brittle” infrastructure. Modern cloud load balancers and CDNs use dynamic IP addresses that change frequently. If you hardcode an IP address in your A record and your provider changes their load balancer IP, your site goes down.
2. The Modern Method: Alias, ANAME, and Flattening
To solve the conflict between dynamic cloud IPs and the RFC 1035 restrictions, DNS providers invented a virtual record type often called CNAME Flattening, ALIAS, or ANAME.
Here is how it works behind the scenes:
- You configure your apex (
@) to point to a hostname (e.g.,app.herokuapp.com) using this special record type. - When a user queries your domain, your DNS provider momentarily pauses.
- The provider queries
app.herokuapp.com, finds the current IP address, and returns that IP address to the user as a standard A record.
To the outside world, it looks like a static A record (compliant with rules). To you, it acts like a CNAME (dynamic and flexible).
My recommendation
For modern web deployments, always use a DNS provider that supports CNAME Flattening or ALIAS records (such as Cloudflare or AWS Route53 ).
Avoid hardcoding A records for your root domain unless you are running a single, static server with a dedicated Static IP. The flexibility of ALIAS records ensures your site remains online even if your cloud provider rotates their infrastructure IPs.
