DNS A vs CNAME records
In-Depth Technical Comparison & Architecture Guide
An A record points a name directly at an IP address; a CNAME points a name at another name instead — a small difference in mechanism that produces one genuinely important, frequently-violated restriction (no CNAME at a domain's root) and a whole category of provider-specific workarounds that exist purely to get around it.
Quick Reference Matrix
| Metric | A Record | CNAME Record |
|---|---|---|
| Target Destination | IPv4 address directly | Another hostname (which is then resolved itself) |
| Zone Apex (root domain) Support | Yes | No — prohibited by RFC 1912/2181 |
| Lookup Steps | One | One plus each level of chain indirection |
| Valid MX Record Target | Yes | No — RFC 2181 prohibits this explicitly |
| Apex Workaround | Not needed — already apex-valid | Provider-specific ALIAS/CNAME-flattening records |
Technology Overview
An A record is the simplest DNS mapping: hostname to IPv4 address, resolved in a single lookup step with no further indirection. A CNAME (Canonical Name) record instead aliases one hostname to another hostname — the resolver has to look up the CNAME's target, which may itself be another record (an A record, or even another CNAME), adding a resolution step for every level of indirection.
The single most consequential rule governing these two record types: a CNAME cannot coexist with other required records at a domain's zone apex (the root domain itself, like example.com, as opposed to a subdomain like www.example.com). This isn't an arbitrary limitation — RFC 1912 and RFC 2181 both establish that a name with a CNAME record can have no other record types at that same name, and a domain's apex is required to have NS (name server) and typically SOA records for the zone itself to function — a CNAME there would conflict directly with those mandatory records.
This restriction creates a real, common operational problem: modern hosting platforms and CDNs frequently want you to point a hostname at their own dynamically-changing infrastructure via CNAME (rather than a fixed IP via an A record, which would break if their infrastructure's IP changes) — but you often want your domain's bare root (example.com, not www.example.com) to work too, and a plain CNAME can't legally do that at the apex. This is exactly the gap ALIAS records and CNAME flattening were invented to close.
ALIAS Records and CNAME Flattening: Provider-Specific Workarounds
Because the CNAME-at-apex restriction is a real, frequent operational pain point (most services want to point a domain's bare root at dynamic infrastructure), several DNS providers invented their own non-standard workaround: an ALIAS record (the term used by DNS Made Easy and several others) or 'CNAME flattening' (Cloudflare's term for the same underlying idea), and AWS Route 53 offers essentially the same capability under the name 'Alias record.' All of these work by having the DNS provider itself resolve the CNAME target at query time (or periodically) and return the resulting A/AAAA record directly to the client, so the client never sees a CNAME at all and the apex restriction is never technically violated.
The important caveat: ALIAS/flattening records are not part of any DNS RFC — they're a provider-specific feature, meaning the exact behavior (how often the target is re-resolved, whether it works identically across all providers) can vary, and migrating your DNS hosting to a different provider may require re-implementing this differently rather than it being a portable, standard record type you can just copy over.
CNAME Chaining and the MX Record Rule
A CNAME can technically point to another CNAME rather than directly to an A record, but this is discouraged: each additional hop adds a full resolution round-trip, and some resolvers impose a maximum chain-length limit, meaning an overly-long CNAME chain can fail to resolve at all in stricter clients even though it 'works' in more lenient ones.
A related, specific rule worth knowing precisely: RFC 2181 explicitly prohibits an MX (mail exchanger) record from pointing at a CNAME — it must point directly at a hostname with its own A/AAAA record. Mail servers that strictly enforce this will silently fail to deliver mail to a domain that violates it, producing a frustrating, intermittent-looking delivery problem that's actually a straightforward, if easy-to-miss, misconfiguration.
A Record Advantages & Disadvantages
Advantages / Pros
- Simplest, single-step resolution with no indirection.
- Valid anywhere, including a domain's root apex.
- The only legal target for an MX record.
Disadvantages / Cons
- Must be manually updated if the target server's IP address ever changes.
CNAME Advantages & Disadvantages
Advantages / Pros
- Automatically follows a target whose IP may change, with no update needed at your end.
- Ideal for pointing at CDN or dynamic-hosting infrastructure you don't control the IP of.
Disadvantages / Cons
- Cannot be used at a domain's zone apex — requires a provider-specific ALIAS/flattening workaround there.
- Cannot be the target of an MX record.
- Each chained CNAME adds a resolution step and, if overused, a risk of hitting a resolver's chain-length limit.
Real-World Use Cases
A Record
Root/apex domain configuration
Pointing example.com directly to a static, self-managed server IP.
Any MX record target
Mail servers must resolve to an A/AAAA record directly, never a CNAME.
CNAME
CDN and dynamic hosting integrations
Pointing www.example.com at a provider's dynamically-changing infrastructure hostname.
Subdomain delegation to a third-party service
Aliasing a subdomain to a SaaS provider's own hostname without needing to track their IP changes.
Developer Recommendation
Use an A record for your domain's root/apex and for any hostname that will be an MX record's target — these are hard requirements, not preferences.
Use a CNAME for subdomains pointing at infrastructure whose IP address may change (CDNs, most SaaS/PaaS hosting) — it's the natural fit whenever you don't control (and don't want to track) the target's actual IP.
If you specifically need your domain's root/apex to point at CNAME-style dynamic infrastructure, use your DNS provider's ALIAS or CNAME-flattening feature rather than attempting a literal CNAME there — and confirm your provider actually offers this before committing to an architecture that assumes it.
Frequently Asked Questions
- What is a DNS ALIAS record?
- A provider-specific (non-RFC-standard) record type that behaves like a CNAME but is legal at a domain's zone apex — the provider resolves the target itself and returns an A/AAAA record to the client, working around the standard CNAME-at-apex prohibition.
- Why can't I use a CNAME at my domain's root?
- RFC 1912 and RFC 2181 prohibit a CNAME from coexisting with other records at the same name, and a domain's apex requires NS (and typically SOA) records to function as a zone at all — a CNAME there would conflict directly with those required records.
- Can an MX record point to a CNAME?
- No — RFC 2181 explicitly prohibits this. An MX record must point directly to a hostname with its own A/AAAA record, and mail servers enforcing this rule strictly will silently fail to deliver to a domain that violates it.
- Is CNAME flattening the same everywhere?
- No — it's a provider-specific feature (called ALIAS by some providers, CNAME flattening by Cloudflare, Alias record by AWS Route 53), not a standardized DNS record type, so its exact behavior can differ between providers and may need to be reconfigured if you migrate DNS hosting.
- How many CNAMEs can be chained together?
- There's no universal number in the DNS standard itself, but many resolvers impose their own practical chain-length limit, and each additional hop adds a real resolution delay — keeping chains short (ideally a single hop) is a sound practice regardless of any specific limit.
- Does a CNAME cause slower page loads?
- It adds at least one additional DNS resolution step compared to a direct A record, which is measurable but typically small in absolute terms; a long CNAME chain adds more delay proportionally, which is one more reason to avoid unnecessary chaining.
Part of the Domain Name System (DNS) Developer Hub
This comparison is part of our Domain Name System (DNS) topic guide, covering related tools, standards, and decision guidance.
Related Comparisons
Other technology decisions in the same topic area as Domain Name System (DNS):
DNS vs IP Routing
DNS and IP routing solve two completely different problems that happen to run back-to-back during every web request — DNS answers 'what address does this name point to,' while routing answers 'how does a packet actually get from here to that address' — and correctly diagnosing a connectivity failure depends entirely on knowing which of the two actually failed.
DNS A vs AAAA records
Publishing both an A and an AAAA record for the same hostname (dual-stack) is standard modern practice, but the real engineering problem it creates — a client racing to figure out which protocol actually works, quickly, without a slow timeout on a broken path — was significant enough to need its own dedicated IETF algorithm, Happy Eyeballs, which is the part of this story most A-vs-AAAA comparisons skip entirely.
Launch Interactive Developer Tools
Put these concepts into practice. Test, format, serialize, or analyze your inputs locally with these secure, browser-only utilities: