What Is a CNAME Record? Aliases in DNS Explained
CNAME records create hostname aliases in DNS. Useful for www, CDN integrations, and third-party services — but with one critical restriction: they cannot go at your domain root.
What Is a CNAME Record? Aliases in DNS Explained
A CNAME record (Canonical Name record) creates an alias from one hostname to another. Instead of pointing directly to an IP address like an A record does, a CNAME points to another hostname. Resolvers follow the chain until they reach an A or AAAA record with an actual IP address.
How CNAME Works
When a resolver queries example.com and finds www.example.com → CNAME → example.com:
- It finds the CNAME pointing to example.com
- It then looks up example.com's A record
- It returns the IP from the A record
The end result is the same IP — but the CNAME adds one layer of indirection.
Common Use Cases
www to Root Domain Alias
www.example.com → CNAME → example.com
When your A record IP changes, you only update example.com's A record. The www CNAME automatically follows.
CDN Integration
When setting up Cloudflare or another CDN for a subdomain, you often create a CNAME pointing to the CDN's hostname: assets.example.com → CNAME → example.cdn.cloudflare.net
Third-Party Service Integration
Many SaaS platforms use CNAME records for custom domain setup:
- shop.example.com → CNAME → example.myshopify.com
- help.example.com → CNAME → example.zendesk.com
- docs.example.com → CNAME → example.gitbook.io
Autodiscover for Email
autodiscover.example.com → CNAME → autodiscover.outlook.com
The Critical CNAME Limitation: No Root Domain
A CNAME cannot exist at the zone apex (root domain). This is one of DNS's oldest and most misunderstood restrictions, defined in RFC 1034.
The zone apex is the root domain itself — example.com (not www.example.com or any subdomain).
Why? Because the zone apex must have NS and SOA records. CNAME records must be the only record at a name — a CNAME cannot coexist with NS or SOA records. Therefore, CNAMEs at the zone apex are not allowed.
This means you cannot do: example.com → CNAME → myapp.vercel.app
Workarounds:
CNAME Flattening (ALIAS / ANAME): Many DNS providers offer a special record type that works like a CNAME at the root. Cloudflare calls it "CNAME flattening", AWS Route 53 calls it "ALIAS records", DNSimple calls it "ALIAS". They resolve the CNAME at the DNS level and return an A record. Check if your provider supports this.
A record pointing to IP: If the target service provides a stable IP (not always the case with cloud services), point your root A record to that IP directly.
CNAME vs A Record: When to Use Which
| Situation | Use |
|---|---|
| Root domain → IP | A record |
| Subdomain → IP | Either (A is simpler, CNAME is more flexible) |
| Subdomain → hostname | CNAME |
| www alias to root | CNAME |
| Third-party service integration | CNAME |
CNAME Chains
A CNAME can point to another CNAME: sub.example.com → CNAME → alias.example.com → CNAME → target.example.com
This is technically valid but adds latency (each hop requires an additional DNS lookup). DNS resolvers have a maximum chain depth — typically 10 hops — before they give up. Keep chains to one or two hops.
What You Cannot Put a CNAME With
A hostname with a CNAME record cannot have any other record types. This is important for MX records — you cannot point MX at a hostname that also has a CNAME. Always create a dedicated hostname for mail server CNAMEs, or point MX records directly to A records.
Checking CNAME Records
In ElasticDomain's DNS tab, CNAME records are listed with their target hostname. The system also detects when a CNAME points to a service that is no longer active — which is the basis of subdomain takeover vulnerability detection.