/compare/dns/a-record-vs-cname
A record vs CNAME record: differences and when to use each
- tool
- DNS
- compares
- A record vs CNAME record
An A record maps a name directly to an IPv4 address (AAAA does the same for IPv6). A CNAME record makes a name an alias of another name: the resolver restarts the lookup at the target and returns the target's addresses. Use A/AAAA when you control the IP address; use CNAME to point a subdomain at a host name someone else manages (a CDN, a SaaS app, a load balancer whose IPs change). A CNAME cannot coexist with any other record on the same name, so it cannot be used at the zone apex (example.com itself).
Side by side
| A / AAAA | CNAME | |
|---|---|---|
| Points to | An IP address | Another domain name |
| Resolution | One answer | The resolver follows the alias (it may chain), adding lookups when not cached |
| Other records on the same name | Allowed (MX, TXT, other A records...) | Not allowed, except DNSSEC records |
| Zone apex (example.com) | Yes | No: the apex always has SOA and NS records |
| When the target IPs change | You update the record | Nothing to do: the target owner updates its own records |
| Typical use | Your own servers, the apex, mail hosts | www, CDN and SaaS hostnames (shop.example.com to a provider) |
The "CNAME and other data" rule
A name with a CNAME must have no other data. Zone tools reject the conflict; here dnspython parses three small zones:
cat > zones.py <<'EOF'
import dns.zone
base = """$ORIGIN example.com.
$TTL 3600
@ IN SOA ns1 hostmaster 1 7200 3600 1209600 3600
@ IN NS ns1
@ IN A 192.0.2.10
ns1 IN A 192.0.2.53
www IN CNAME @
"""
print("www as alias:", dns.zone.from_text(base).find_rdataset("www", "CNAME"))
for label, extra in [("www CNAME plus A", "www IN A 192.0.2.11\n"), ("CNAME at the apex", "@ IN CNAME lb.example.net.\n")]:
try:
dns.zone.from_text(base + extra)
except Exception as e:
print(f"{label}: {type(e).__name__}: {e}")
EOF
uv run -q --no-project --python 3.13 --with dnspython==2.8.0 python zones.pyOutput
www as alias: 3600 IN CNAME @ www CNAME plus A: CNAMEAndOtherData: rdataset type is not compatible with a CNAME node CNAME at the apex: CNAMEAndOtherData: CNAME rdataset is not compatible with a regular data node
BIND reports the same conflict as CNAME and other data when loading a zone.
Pointing the apex at a host name
Because the apex cannot be a CNAME, providers offer workarounds:
- ALIAS / ANAME / CNAME flattening (provider-specific): you enter a host name, the provider's servers resolve it and answer with A/AAAA records. It is not a standard record type.
- HTTPS / SVCB records (RFC 9460) can point the apex to another name for HTTPS clients that support them (current browsers), but A/AAAA records are still needed for everything else.
- Redirect the apex to
wwwwith an HTTP redirect and put the CNAME onwww.
Common mistakes
- A CNAME on a name that also needs MX or TXT records (mail and domain verification break): use A/AAAA there instead.
- MX and NS records must point to names with A/AAAA records, not to CNAMEs (RFC 2181 section 10.3).
- A trailing dot matters in zone files:
target.example.net.is absolute; without the dot, the zone origin is appended.