What A and CNAME Records Actually Do
A Record
Address record — maps a hostname directly to an IPv4 address.
example.com. 3600 IN A 93.184.216.34
www.example.com. 3600 IN A 93.184.216.34- One name → one IP (or multiple for round-robin)
- Works at the zone apex and subdomains
- Resolver returns the IP directly — one query, one answer
- IPv6 equivalent: AAAA record
CNAME Record
Canonical Name — aliases one hostname to another hostname.
www.example.com. 3600 IN CNAME example.com.
blog.example.com. 3600 IN CNAME hosting-platform.com.- One name → another name (the canonical name)
- The target is resolved separately — two DNS lookups
- Cannot coexist with other records at the same name
- Cannot be used at the zone apex (RFC 1034, section 3.6.2)
The key distinction: an A record resolves a name to an IP address in a single step. A CNAME resolves a name to another name, which then requires a second DNS lookup to reach an IP address. This extra lookup adds latency — typically 20–100 milliseconds depending on resolver proximity and caching.
The Zone Apex Problem: Why CNAME at the Root Breaks Things
Every DNS zone must have SOA and NS records at the apex (the root of the domain — example.com
itself, not a subdomain). RFC 1034 explicitly states that if a CNAME RR is present at a node, no other data
should be present. This means a CNAME at example.com conflicts with the mandatory SOA and NS records.
What happens if you create a CNAME at the apex anyway?
- Some resolvers follow the CNAME and ignore SOA/NS — domain resolves, but without proper authority. Zone transfers and DNSSEC break silently.
- Some resolvers return SERVFAIL because the zone is malformed. The domain appears down.
- Some resolvers return the SOA/NS and ignore the CNAME. The domain resolves to nothing useful.
- MX records at the apex alongside a CNAME are illegal per RFC 2181 section 10.3 — mail delivery breaks unpredictably depending on the sender's resolver behavior.
The result: different users see different behavior depending on which resolver they use. This is impossible to reproduce consistently and generates support tickets that say "it works for me but not for the customer."
Solutions to the apex CNAME problem
| Solution | How It Works | Provider Support |
|---|---|---|
| ALIAS record | Non-standard pseudo-record. The authoritative server resolves the target at query time and returns the resulting A/AAAA records directly — looks like a CNAME but behaves like an A record at the protocol level. | DNSimple, DNSMadeEasy, Route53 (as ALIAS), NS1 |
| ANAME record | Similar to ALIAS. The provider periodically resolves the target and serves the IPs as A/AAAA records. Differs from ALIAS in that resolution may happen asynchronously rather than at query time. | Cloudflare (as CNAME flattening), EasyDNS, Constellix |
| CNAME flattening | Cloudflare's implementation. The CNAME at the apex is accepted in the dashboard but flattened to A/AAAA records before being served to resolvers. The resolver never sees the CNAME. | Cloudflare only |
| Manual A/AAAA sync | Manually copy the target's A and AAAA records to the apex. Requires updating whenever the target IPs change — fragile and error-prone. | Any provider (manual process) |
If your DNS provider does not support ALIAS or ANAME: you cannot point your apex domain to a hostname. You must use A/AAAA records with the target's IP addresses. Use the DNS Lookup tool to check what IPs your target hostname resolves to, then create matching A/AAAA records at the apex.
Decision Guide: CNAME or A Record?
| Scenario | Use | Why |
|---|---|---|
Apex domain (example.com) pointing to a fixed IP |
A/AAAA | CNAME is prohibited at the apex. A/AAAA is the only standards-compliant option. |
| Apex domain pointing to a CDN or PaaS hostname | ALIAS/ANAME (if supported) or A/AAAA | If your provider supports ALIAS/ANAME, use that. Otherwise, manually sync A/AAAA records. |
| Subdomain pointing to a service whose IP may change (CDN, SaaS) | CNAME | The service can update their own A records without you making changes. This is the entire point of CNAME. |
| Subdomain pointing to an IP you control | A/AAAA | Avoids the extra DNS lookup. If the IP is under your control and stable, the CNAME adds no value. |
www subdomain redirecting to the apex |
CNAME | Standard practice. If the apex IP changes, www follows automatically. |
| Multiple subdomains of a service pointing to the same backend | CNAME | Change the canonical name once, and all aliases follow. Reduces management overhead. |
| Records that coexist with MX, TXT, or NS at the same name | A/AAAA (never CNAME) | CNAME cannot coexist with any other record type. If you need MX at the same name, CNAME is not an option. |
Performance Tradeoffs: Extra DNS Lookups Matter
A CNAME record forces the resolver to perform at least two DNS queries: one to resolve the alias and one to resolve the canonical name. In practice, it is often more:
# What the resolver actually does for a CNAME:
1. Query: www.example.com A
→ Response: CNAME example.com (TTL 300)
2. Query: example.com A
→ Response: A 93.184.216.34 (TTL 3600)
# If the CNAME target is itself a CNAME, this chains:
1. Query: blog.example.com A
→ Response: CNAME hosting-platform.com (TTL 300)
2. Query: hosting-platform.com A
→ Response: CNAME cdn-provider.net (TTL 600)
3. Query: cdn-provider.net A
→ Response: A 203.0.113.55 (TTL 60)Each lookup in the chain adds latency. A cold resolver (nothing cached) performing a 3-hop CNAME chain on a domain with 50ms average RTT to authoritative servers will take 150ms just to resolve the name — before the browser even starts the TCP handshake. Multiply this by dozens of resources on a page (images, scripts, APIs), and CNAME chains become a measurable performance problem.
Best practices for CNAME performance:
- Avoid CNAME chains deeper than 2 hops. Each hop is a separate round trip. Some resolvers cap CNAME chasing at 8–16 hops and return SERVFAIL beyond that.
- Set reasonable TTLs on CNAME records. A 60-second TTL forces resolvers to re-resolve the alias every minute, doubling your query load and adding latency. Use 300–3600 for stable aliases.
- Prefer A/AAAA records at the leaf level when the target IP is stable. The CNAME convenience is not worth the performance cost for internal services.
- Be aware of CNAME flattening if you use Cloudflare or a provider that resolves CNAMEs server-side. The resolver sees A/AAAA records directly, eliminating the extra lookup at query time.
Five CNAME Mistakes That Break DNS in Production
-
CNAME + MX at the same subdomain.
If you point
mail.example.comto a CNAME, you cannot also have MX records for that name pointing to it. The CNAME prevents any other record type from existing. If you need MX for a domain, that domain must use A/AAAA records — not a CNAME. -
CNAME pointing to a name that does not resolve.
If your CNAME target (
target.example.net) has no A or AAAA records, the alias resolves to nothing. There is no error message and no warning — the name simply returns zero answers with NOERROR status. Check with the DNS Lookup tool to verify the target's records. -
Forgetting the trailing dot on the CNAME target.
DNS is absolute by default — a target of
example.com(without trailing dot) may be interpreted as relative to the zone origin, producingexample.com.yourdomain.com. Always use fully qualified domain names with trailing dots:example.com. -
CNAME loop. A CNAME that points directly or indirectly to itself creates an
infinite resolution loop. Resolvers detect this (after 8–16 hops depending on implementation)
and return SERVFAIL. Example:
www.example.com CNAME example.comandexample.com CNAME www.example.com— circular dependency, always broken. -
Using CNAME for a third-party service that decommissions the target name.
When a SaaS provider retires a hostname (e.g.,
customer-123.provider.com), your CNAME silently breaks. There is no notification. Periodic audits with the DNS Record Lookup catch these before they cause outages.
How to Verify CNAME and A Records Before Deploying Changes
# Check what a CNAME resolves to (and whether it chains)
$ dig www.example.com CNAME +short
example.com.
# Follow the CNAME chain all the way to the final A record
$ dig www.example.com A +short
93.184.216.34
# Verify the CNAME target itself resolves before creating the alias
$ dig target-host.provider.com A +short
203.0.113.55
# If this returns nothing, your CNAME will be broken.
# Check that NO other record types exist alongside a CNAME
$ dig mail.example.com ANY +short
# If CNAME shows up alongside MX or TXT, the zone is malformed.Use the OpsCheck DNS Lookup to run these checks from a browser. Select the record type you want to verify (CNAME, A, AAAA), enter the hostname, and compare with the expected values. For bulk verification, export results as CSV and diff against your configuration.
Related DNS Tools
- DNS Record Lookup — Query any DNS record type (A, AAAA, CNAME, MX, TXT, NS, SOA, PTR) for any domain. Export as CSV, BIND zone file, JSON, YAML, or RFC zone format.
- Reverse DNS Lookup — Check PTR records to verify reverse DNS is configured correctly. Essential for email deliverability and server identification.
Frequently Asked Questions
No. RFC 1034 prohibits CNAME records at the zone apex because they conflict with mandatory SOA and NS records. If your DNS provider allows it in their UI, the resulting behavior is unpredictable across different resolvers. Use ALIAS, ANAME, or CNAME flattening if your provider supports it. Otherwise, use A/AAAA records with the target's IP addresses.
Yes, but usually not noticeably for a single CNAME. Each CNAME adds one extra DNS lookup (typically 20–100ms on a cold cache). After the first lookup, resolvers cache both the CNAME and the target's A record based on their TTLs. Deep CNAME chains (3+ hops) can add measurable latency. For performance-critical applications, minimize CNAME chain depth and use A/AAAA records at the leaf when the target IP is stable.
No. RFC 1034 section 3.6.2 and RFC 2181 section 10.3 state that a CNAME cannot coexist with any other resource record at the same node. If a CNAME exists at a name, MX, TXT, NS, and all other record types at that name are invalid. If you need both email and web serving at the same hostname, that hostname must use A/AAAA records — the web service can use a CNAME at a different name (like www).