CNAME Record
Creates an alias from one hostname to another canonical name. The resolver follows the chain until it reaches an A or AAAA record.
Canonical Name Alias
A CNAME (Canonical Name) record creates an alias — it says "this hostname is actually another hostname." Resolvers follow CNAME chains until they find an A or AAAA record. This means a single IP change at the canonical name propagates immediately to all aliases pointing to it.
CNAMEs are frequently used to point subdomains at CDN, SaaS, or cloud provider hostnames: app.example.com CNAME myapp.vercel.app.. When the provider changes their IP infrastructure, your DNS automatically reflects it without any changes on your end.
- Cannot be used at the zone apex — the root of your domain (
@) must have A/AAAA, NS, and SOA records; a CNAME would conflict - A CNAME record cannot coexist with any other record type on the same name (RFC 1034)
- CNAME chains work but add latency — each hop requires an additional DNS lookup
- MX and NS records cannot point to a CNAME — they must point directly to A/AAAA records
- Many DNS providers offer CNAME flattening (ALIAS/ANAME) to enable apex CNAME-like behavior
example.com CNAME other.com.This is invalid. The apex must carry NS and SOA records, which cannot coexist with CNAME. Use CNAME flattening (Cloudflare, Route 53 ALIAS, Netlify) to achieve equivalent behavior at the apex.Using CNAMEs at the Apex
CNAME flattening (also called ALIAS or ANAME records depending on the provider) solves the apex restriction. The DNS provider resolves the CNAME target at query time and returns the resulting A/AAAA records as if they were directly on your apex. The client never sees a CNAME in the response.
This is essential for services like Netlify, Vercel, Heroku, and Cloudflare Pages that require you to point your naked domain at their infrastructure. Without flattening, you would need to hard-code an IP address (which may change) in your A record.