An A record maps a hostname to an IPv4 address; AAAA does the same for IPv6. A CNAME maps a hostname to another *hostname*, and the resolver then restarts its lookup at that target. The practical difference is who owns the address. With an A record, the address lives in your zone and only you can change it. With a CNAME, the address lives in someone else's zone and they can change it whenever they like — which is either exactly what you want or exactly what you do not.
dig +noall +answer www.github.com A
# www.github.com. 1711 IN CNAME github.com.
# github.com. 60 IN A 20.207.73.82Those two TTLs are independent. The alias is cached for its own TTL and the target's address for the target's TTL, which is why a provider can move traffic in 60 seconds even though your CNAME is cached for half an hour. Inspect either side with the CNAME Lookup or the A Record Lookup.
Which should you use for what?
| Situation | Use | Why |
|---|---|---|
| Server you run on a static IP | A / AAAA | You own the address; an alias adds a hop and buys nothing. |
| CDN or reverse proxy endpoint | CNAME | The provider rotates edge IPs constantly and expects to control them. |
| SaaS app on a custom subdomain | CNAME | The vendor documents a target hostname and moves infrastructure behind it. |
| Cloud load balancer | CNAME | Balancer addresses change; the DNS name is the stable contract. |
Domain apex (example.com) | A / AAAA, or ALIAS | A CNAME at the apex is invalid — see below. |
| MX target hostname | A / AAAA at the target | RFC 2181 forbids an MX pointing at a CNAME. |
| NS target hostname | A / AAAA at the target | Same rule: a delegation must name a host with address records. |
www pointing at the apex | CNAME | Keeps one address to maintain instead of two that can drift apart. |
Why can a CNAME not sit at the apex?
The rule is older than the web: a CNAME must be the only record at its owner name. RFC 1034 and RFC 2181 are explicit — if a CNAME exists, no other record type may exist alongside it, because the CNAME means "everything about this name is really about that other name." The only exceptions are the DNSSEC records (RRSIG, NSEC) that sign the CNAME itself.
The apex of a zone — example.com with nothing in front — is required to hold both an SOA record and NS records. Those cannot be removed; they are what make the zone a zone. So the apex already has other records, and a CNAME can never legally join them. This is not a limitation of your DNS provider. A provider that lets you save an apex CNAME is either rejecting it silently or, more likely, implementing one of the workarounds below.
mail.example.com has a CNAME, you cannot also give it a TXT record for domain verification, or an MX, or anything else. Zone editors often accept the second record and then serve unpredictable results — the correct fix is to replace the CNAME with A/AAAA records, or move the extra record to a different name.ALIAS, ANAME, and CNAME flattening
Because pointing an apex at a CDN is such a common need, DNS providers invented a workaround. It goes by several names — ALIAS, ANAME, CNAME flattening, virtual CNAME — but the mechanism is the same everywhere: you configure a target hostname, and the *provider* resolves it and publishes the resulting A and AAAA records at the apex. What ships in the zone is ordinary address records, so every resolver on earth sees something valid.
- It is a provider feature, not a DNS record type. There is no ALIAS on the wire. Query the apex and you get A records back, exactly as if you had typed them yourself.
- Resolution happens at the provider's location, not the visitor's. For a geo-steered CDN this can hand visitors an edge chosen for the DNS provider rather than for them. Providers with global anycast footprints mitigate this; smaller ones may not.
- The published TTL is the provider's, not the target's. Providers cap it (values around 300 seconds are typical) so their re-resolution cycle stays ahead of the target changing.
- Portability is limited. Moving DNS providers means reconfiguring the feature, and the name and behaviour differ between them. Check your provider's current documentation rather than assuming the semantics match another vendor's.
- It resolves the "everything else at the apex" conflict cleanly, because the published records are A/AAAA and coexist happily with SOA, NS, MX, and TXT.
If your provider does not offer it, the usual alternative is to serve the apex from a small host or a redirect service that sends example.com to www.example.com, and CNAME www at the CDN. Verify what actually gets published at the apex with the DNS Lookup and follow the redirect chain with the Redirect Checker.
Why must an MX never point at a CNAME?
RFC 2181 section 10.3 states the rule directly: the name given in the exchange field of an MX record must have address records and must not be an alias. The same applies to the target of an NS record. Mail servers and resolvers are permitted to treat a CNAME target as an error, and many do — some will refuse to deliver, others will follow it anyway. Behaviour varies, which is the worst outcome: intermittent bounces from some senders and not others.
# Correct: MX targets have address records of their own
dig +short gmail.com MX
# 5 gmail-smtp-in.l.google.com.
# 10 alt1.gmail-smtp-in.l.google.com.
# 20 alt2.gmail-smtp-in.l.google.com.
# Verify each target is a host, not an alias
dig +short gmail-smtp-in.l.google.com AThis most often goes wrong when someone CNAMEs mail.example.com at a hosting provider and then points MX at mail.example.com. The fix is to point the MX directly at the provider's documented mail hostname, which will have proper address records. Check yours with the MX Lookup, and see MX Priority Explained for the numbering.
Cost, latency, and the practical trade-offs
A CNAME costs an extra resolution step the first time. In practice authoritative servers usually return both the alias and the target's address in one response when they are authoritative for both, so the extra round trip often does not happen — but across a chain of aliases at different providers it does, and each hop adds latency and one more thing that can fail. Keep chains to one hop where you can.
- Reliability follows the chain. Every zone in a CNAME chain must resolve. If a vendor's zone breaks, your hostname breaks with it, even though your own zone is fine.
- Debugging gets longer. When a CNAMEd hostname misbehaves, resolve each hop separately rather than reading only the final address.
- A records give you control and cost you maintenance. If the provider behind an A record changes their IP and you did not notice, you are hard-down. That is the exact failure mode CNAMEs exist to prevent.
- Proxied records are not what they look like. When a CDN proxies a hostname, the published answer is the CDN's anycast address regardless of what you configured — see Why Is My DNS Not Propagating? for how that misleads people during migrations.
- Reverse DNS is separate. PTR lives in the address owner's zone and cannot be set with either an A record or a CNAME on your side. See the Reverse DNS Lookup.
Whichever you choose, lower the TTL before changing it — the timeline is in Lower Your TTL Before a DNS Migration — and confirm the result worldwide with the DNS Propagation Checker.