What an A Record Does
An A record (Address record) maps a hostname directly to an IPv4 address. It is the terminal answer in a DNS lookup — when a resolver receives an A record, it has the IP address it needs to make a connection.
; A record format
www.example.com. 3600 IN A 203.0.113.10
; Zone file example — multiple A records for load distribution
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN A 203.0.113.11
www.example.com. 300 IN A 203.0.113.12
A records can coexist at any name in a DNS zone, including the zone apex (root domain). Multiple A records at the same name are valid — resolvers receive all of them and typically try them in order or round-robin between them.
# Look up an A record
dig example.com A +short
# Returns: 203.0.113.10
# Multiple A records
dig www.example.com A +short
# Returns:
# 203.0.113.10
# 203.0.113.11
# 203.0.113.12
The IPv6 equivalent of an A record is an AAAA record, which maps a hostname to an IPv6 address. Everything discussed here about A records applies equally to AAAA records.
What a CNAME Record Does
A CNAME record (Canonical Name record) creates an alias — it maps one hostname to another hostname. A CNAME does not contain an IP address. When a resolver encounters a CNAME, it must make an additional DNS query for the target hostname to eventually obtain an IP address.
; CNAME record format
www.example.com. 3600 IN CNAME example.com.
shop.example.com. 3600 IN CNAME stores.shopify.com.
cdn.example.com. 300 IN CNAME example.cdn.cloudflare.net.
The lookup process for a CNAME involves multiple steps:
CNAME RESOLUTION FLOW
Client asks: "What is the IP for www.example.com?"
↓
Resolver finds: www.example.com CNAME → example.com
↓ (must now resolve the target)
Resolver finds: example.com A → 203.0.113.10
↓
Returns 203.0.113.10 to client
Total queries: 2 (one for the CNAME, one for the A record)
This additional lookup is the core trade-off of using CNAMEs: they add at least one extra DNS query to the resolution path. In practice, this extra latency is typically negligible (sub-millisecond when results are cached), but for latency-sensitive applications or deeply nested CNAME chains, it matters.
The fundamental rule: A CNAME tells resolvers "the answer you want is at this other name — go look there." An A record tells resolvers "here is the answer."
CNAME vs A Record: Side-by-Side Comparison
| Property | A Record | CNAME Record |
|---|---|---|
| Points to | IPv4 address (e.g., 203.0.113.10) | Another hostname (e.g., target.example.com) |
| Answer type | Terminal — no further lookup needed | Alias — requires at least one more lookup |
| Allowed at zone apex | ✓ Yes | ✗ No (per DNS spec) |
| Can coexist with other records at same name | ✓ Yes (e.g., A + MX at apex) | ✗ No — CNAME must be alone at a name |
| Use case | Direct IP mapping; root domain; any name that needs other records | Aliases to services, CDNs, ESPs; subdomains pointing to external hostnames |
| Update flexibility | IP change requires editing DNS | Target service can update IPs; your CNAME stays the same |
| DNS lookup cost | 1 query | 2+ queries (CNAME + at least one A lookup) |
| Load balancing | Multiple A records at same name | Depends on target; geo-routing possible via target's DNS |
| Wildcard support | ✓ *.example.com IN A 203.0.113.10 | ✓ *.example.com IN CNAME target.example.com |
; Zone file showing both record types in use
$ORIGIN example.com.
; A records — direct IP mappings
@ A 203.0.113.10 ; root domain (zone apex)
mail A 203.0.113.20 ; mail server
ns1 A 203.0.113.30 ; nameserver
; CNAME records — aliases to other hostnames
www CNAME example.com. ; www aliases to root
blog CNAME myblog.wpengine.com.
shop CNAME stores.shopify.com.
cdn CNAME example.cdn.cloudflare.net.
The Zone Apex Problem
The zone apex (also called the root domain or naked domain) is the domain itself — example.com as opposed to www.example.com. The DNS specification (RFC 1034) prohibits CNAME records at the zone apex for a fundamental reason: a CNAME must be the only record at a name, but the zone apex must contain NS and SOA records. A CNAME there would conflict with these required records.
; INVALID — this breaks DNS
example.com. IN CNAME something.cdn.com. ; ← illegal at zone apex
example.com. IN NS ns1.example.com. ; ← required — conflict!
example.com. IN SOA ns1.example.com. ... ; ← required — conflict!
This creates a practical problem for websites: many CDNs, load balancers, and SaaS platforms only provide hostnames (not IP addresses) for you to point your domain at. If you want example.com (not just www.example.com) to resolve through Cloudflare, AWS CloudFront, Shopify, or similar services, you can't use a CNAME at the root.
⚠️ Warning: If you force a CNAME at the zone apex in a DNS provider that allows it (some do, technically), you break every other record that relies on the apex — including MX records (which breaks email) and NS records (which can break the entire zone). Never do this.
The problem also affects MX records specifically: if a CNAME existed at the apex, MX records couldn't coexist there, meaning email to user@example.com would break. This is why "just use a CNAME for the root domain" is not a valid answer, even if your DNS provider's interface lets you try.
CNAME Flattening and ALIAS Records
Several DNS providers have introduced proprietary solutions to the zone apex CNAME problem. These go by different names: CNAME flattening (Cloudflare's term), ALIAS record (DNSimple, Route 53, NS1), or ANAME record (some providers). The mechanism is similar in each case.
How CNAME flattening works:
Instead of serving a CNAME response to clients (which would be invalid at the apex), the DNS provider resolves the CNAME target on the server side and returns the resulting A records to the client. From the client's perspective, they receive a normal A record response — the CNAME indirection is invisible.
CNAME FLATTENING FLOW (at Cloudflare)
You configure: example.com → CNAME → myblog.cdn.com (flattened)
Client asks: "What is the IP for example.com?"
Cloudflare's authoritative server:
1. Internally resolves myblog.cdn.com → 198.51.100.45
2. Returns to client: example.com A 198.51.100.45
Client sees a normal A record. No CNAME in the response.
This approach solves the zone apex problem without violating the DNS spec — the client always receives an A record (or AAAA), never a CNAME, for the apex name.
Benefits of CNAME flattening:
- Works at the zone apex where CNAME is prohibited
- Eliminates the extra DNS lookup — the resolution happens server-side once
- Enables pointing the root domain at CDNs, load balancers, and services that only provide hostnames
- Some implementations (Cloudflare) even support geo-routing through flattened records
Limitations:
- Proprietary — only available at DNS providers that support it
- The flattening happens at query time; if the target's IP changes frequently, there can be brief inconsistency during the re-resolution window
- If you migrate DNS providers, the flattened CNAME must be converted to either a real A record (if you know the IPs) or a flattened CNAME at the new provider
AWS Route 53 ALIAS records work similarly but have a slightly different implementation: they're tightly integrated with other AWS services (CloudFront, ELB, S3) and don't cost per query. For non-AWS targets, Route 53 ALIAS records are less flexible than Cloudflare's flattening.
CNAME Chains: When CNAMEs Point to CNAMEs
A CNAME can point to another CNAME, which can point to another CNAME — creating a chain. This is technically valid but adds latency (one extra query per link in the chain) and can cause resolution failures if the chain is too long.
; CNAME chain — 3 lookups to reach the A record
www.example.com. CNAME alias.example.com.
alias.example.com. CNAME host.cdn.net.
host.cdn.net. A 203.0.113.50
; Resolution requires 3 queries:
; 1. www.example.com → alias.example.com (CNAME)
; 2. alias.example.com → host.cdn.net (CNAME)
; 3. host.cdn.net → 203.0.113.50 (A)
Most resolvers follow up to 8–10 CNAME hops before returning SERVFAIL to prevent infinite loops. Chains longer than 2–3 hops are poor practice and should be collapsed.
The most common cause of unintentional CNAME chains: www.example.com CNAME example.com, where example.com itself has a flattened CNAME internally — creating a chain the operator didn't intend. Verify your resolution path with dig +trace if you suspect a chain.
# Trace a full CNAME chain
dig www.example.com CNAME +short
# Shows: alias.example.com.
dig alias.example.com CNAME +short
# Shows: host.cdn.net.
dig host.cdn.net A +short
# Shows: 203.0.113.50
When to Use an A Record
Use an A record when:
You're pointing to a stable IP address you control. Your web server, mail server, nameserver, or VPN endpoint has a fixed IP — use an A record directly.
You're configuring the zone apex (root domain). The zone apex requires an A record (or AAAA). If your DNS provider supports CNAME flattening and your target is a hostname, use that — but the provider still serves it as an A record to clients.
You need other record types at the same name. If you need MX, TXT, SRV, or CAA records alongside your address record at the same hostname, use an A record. A CNAME at a name prohibits any other records from coexisting there.
You're configuring nameserver (NS) targets. Nameserver hostnames (ns1.example.com) must have A records (called glue records). They cannot be CNAMEs.
You're doing round-robin load distribution. Multiple A records at the same name provide simple round-robin distribution across multiple IPs.
; Use A records for:
example.com. A 203.0.113.10 ; zone apex
mail.example.com. A 203.0.113.20 ; mail server
ns1.example.com. A 203.0.113.30 ; nameserver glue record
vpn.example.com. A 10.0.0.1 ; internal VPN endpoint
When to Use a CNAME Record
Use a CNAME record when:
You're aliasing a subdomain to an external service that only provides a hostname. CDNs (Cloudflare, CloudFront, Fastly), hosting platforms (GitHub Pages, Vercel, Netlify), SaaS services (Shopify, HubSpot, Salesforce), and ESPs (SendGrid, Postmark) all give you a hostname to point at. Use a CNAME — if the service changes its IPs, your DNS stays correct automatically.
You want multiple names to resolve to the same place without duplicating records. www.example.com CNAME example.com means you only maintain one A record (at the apex). If the IP changes, you update one record instead of two.
You're setting up DKIM selectors. Most ESPs provide a CNAME to point DKIM selectors at. The CNAME allows the ESP to rotate the underlying key without requiring DNS changes on your side.
; Use CNAME records for:
www.example.com. CNAME example.com.
blog.example.com. CNAME myblog.wpengine.com.
shop.example.com. CNAME stores.shopify.com.
cdn.example.com. CNAME d1234.cloudfront.net.
app.example.com. CNAME myapp.vercel.app.
s1._domainkey.example.com CNAME s1.domainkey.u12345.sendgrid.net.
The key question: Is the destination defined by an IP address (A record) or a hostname (CNAME)? If the service you're connecting to gave you a hostname like target.service.com, use a CNAME. If they gave you 203.0.113.10, use an A record.
Common Mistakes and How to Avoid Them
Mistake 1: CNAME at the zone apex
Attempting to CNAME the root domain directly. This breaks MX records, NS records, and email. Use a provider with CNAME flattening support, or point the root to A records and redirect example.com to www.example.com at the web server level.
Mistake 2: CNAME alongside other records at the same name
; INVALID — CNAME cannot coexist with other records
mail.example.com. CNAME external.service.com.
mail.example.com. MX 10 mail.example.com. ; ← breaks the CNAME
If you need an MX record (or any other record) at mail.example.com, you must use an A record there, not a CNAME. The CNAME exclusivity rule is absolute in the DNS specification.
Mistake 3: Pointing a CNAME at another CNAME unnecessarily
Every CNAME hop adds a DNS query. www CNAME alias CNAME target A 1.2.3.4 has three lookups where one would do. Collapse CNAME chains whenever possible.
Mistake 4: Using A records for external services that change their IPs
If you hardcode the IP of a CDN or SaaS platform into an A record instead of using the CNAME they provide, you'll serve the wrong IP every time the service rotates or expands their infrastructure. Always use the CNAME the service provides.
Mistake 5: Forgetting TTL implications
CNAME and A records each have their own TTL, and in a CNAME chain, the effective caching time is the minimum TTL across all records in the chain. If www.example.com CNAME example.com has a 3600s TTL but example.com A 203.0.113.10 has a 300s TTL, the A record's shorter TTL governs how often the IP is re-fetched — but the CNAME itself stays cached for 3600s. Set CNAMEs and their targets with consistent, appropriate TTLs. See our DNS TTL guide for TTL best practices by record type.
Mistake 6: Mixing up "CNAME" in providers that use it loosely
Some DNS management interfaces use "CNAME" to mean "hostname alias" but implement it as CNAME flattening at the apex. Others let you enter a CNAME at the apex in the UI, which then causes subtle breakage. Know whether your provider is serving a real CNAME response or a flattened A record — check with dig to see what clients actually receive.
# Verify what type of record clients actually see
dig example.com +short
# If you see an IP → A record (or flattened CNAME)
# If you see a hostname → CNAME (invalid at apex if your provider served it)
dig www.example.com
# Look at the ANSWER SECTION
# CNAME entry means the CNAME is visible to clients (adds a lookup)
# A entry directly means either it's a real A or a flattened CNAME
Frequently Asked Questions
Q: Does a CNAME affect page load speed?
The extra DNS query for a CNAME adds a small amount of latency — typically a few milliseconds when results aren't cached. For most sites this is imperceptible. For high-performance applications where every millisecond counts, minimising CNAME chains (keeping them to one hop) helps. CNAME flattening at providers like Cloudflare eliminates the extra client-side lookup entirely by resolving the chain server-side.
Q: Can I use a CNAME for my MX record target?
The MX record itself points to a hostname (the mail server name), and that mail server hostname should have an A record — not a CNAME. RFC 2181 explicitly prohibits MX records from pointing to CNAME targets. The MX record's value must be a name with its own A/AAAA record. Example: example.com MX 10 mail.example.com with mail.example.com A 203.0.113.20 is correct; mail.example.com CNAME mailserver.provider.com alongside that MX is incorrect and will cause mail delivery failures.
Q: My CDN gives me a hostname to point at. Should I use a CNAME or A record?
Always use the CNAME the CDN provides for subdomains. CDNs change their underlying IPs regularly — for geo-routing, capacity expansion, failover, and maintenance. A CNAME to their hostname always resolves to the current correct IP. A hardcoded A record will break the next time they rotate IPs. For your root domain, use your provider's CNAME flattening or ALIAS feature, which accomplishes the same result at the apex.
Q: What's the difference between CNAME flattening and an ALIAS record?
Functionally identical — both resolve the CNAME target server-side and return an A record to clients, making them usable at the zone apex. The difference is naming and implementation: Cloudflare calls it CNAME flattening, Route 53 and NS1 call it ALIAS, DNSimple calls it ALIAS, and some providers call it ANAME. All solve the zone apex CNAME restriction in the same way. Check your specific provider's documentation for the exact feature name and supported targets.
Q: I see both a CNAME and an A record for the same hostname in my zone — is that valid?
No — a CNAME must be the only record at a given name. Having both a CNAME and an A record at www.example.com is invalid per the DNS specification. Some DNS providers will refuse to create the combination; others may silently accept it and produce unpredictable resolver behaviour. If you see this in your zone, one of the records needs to be removed.
Next Steps
Use our DNS Lookup tool to inspect the current record type for any hostname — confirm whether a name is resolving via an A record or through a CNAME chain, and see the full resolution path.
For understanding how TTL interacts with both A records and CNAME chains — including how the minimum TTL across a chain governs effective cache duration — see our DNS TTL guide.
If you're in the middle of a DNS migration and deciding how to configure record types at a new provider, see our DNS Migration guide for the complete audit and cut-over workflow.
Browse all DNS guides on DNSnexus for related topics.