CNAME vs A Record: Differences and When to Use Each

When setting up DNS for a domain — whether pointing to your own server, a cloud service, or a CDN — one of the most common questions is: should I use an A record or a CNAME? These two DNS record types appear to do similar things on the surface, but they have fundamental differences in how they work, their flexibility, and their limitations. This guide explains each record type in depth, compares them directly, and shows you exactly when to use each one.

What Is an A Record?

An A record (Address Record) is one of the most fundamental DNS record types. It maps a hostname directly to an IPv4 address. When a browser needs to connect to example.com, it asks a DNS resolver for the IP address, and the A record provides it directly.

Standard A record syntax:

example.com.    300    IN    A    203.0.113.10
www.example.com. 300   IN    A    203.0.113.10

In this example, both example.com and www.example.com point to the same IP address. This configuration works well when your server IP is static and unlikely to change. If the IP does change, however, you must update every A record that references that IP address individually.

For IPv6 connectivity, the equivalent record type is the AAAA record, which stores an IPv6 address (e.g., 2001:db8::1) instead of IPv4. Modern DNS configurations should include both A and AAAA records where IPv6 is supported.

What Is a CNAME Record?

A CNAME record (Canonical Name Record) works differently from an A record. Instead of pointing to an IP address directly, it points one hostname to another hostname, delegating the responsibility for resolving the IP to that target hostname.

Standard CNAME record syntax:

www.example.com.   300    IN    CNAME    example.com.
blog.example.com.  300    IN    CNAME    example.com.
shop.example.com.  300    IN    CNAME    myshop.shopify.com.

When a resolver queries www.example.com and receives a CNAME pointing to example.com, it performs an additional lookup to resolve example.com to an IP address. This process is called CNAME chasing and happens automatically and transparently.

The primary advantage of CNAME is flexibility. If example.com moves to a new IP address, you only need to update the A record for example.com in one place. Every CNAME that points to it will automatically inherit the new IP address without any additional changes.

Side-by-Side Comparison

The table below summarizes the key differences between A records and CNAME records:

Critical Limitations of CNAME Records

CNAME records have important constraints defined by DNS standards (RFC 1034) that developers and administrators frequently overlook.

1. CNAME Cannot Be Used at the Root (Apex) Domain

The apex or root domain is your bare domain without any subdomain prefix — for example, example.com as opposed to www.example.com. According to RFC 1034, a name that carries a CNAME record must not have any other record types under that same name. However, the root domain is required to always have SOA (Start of Authority) and NS (Name Server) records — this directly conflicts with the CNAME-only rule. Many DNS resolvers will reject or behave unpredictably if a CNAME is placed at the apex.

# Correct approach
@          IN    A        203.0.113.10      ; A record at root — valid
www        IN    CNAME    example.com.      ; CNAME at subdomain — valid

# Wrong — do not do this
@          IN    CNAME    something.cdn.com.  ; conflicts with SOA/NS records

2. CNAME Must Be the Only Record for That Name

A hostname that has a CNAME record must not have any other record types alongside it (with limited DNSSEC exceptions). This means if a subdomain has a CNAME, you cannot add an MX record to that same subdomain for receiving email. You would need to use a different subdomain name for mail purposes.

# Wrong — mail.example.com cannot have both CNAME and MX
mail.example.com.  IN    CNAME    mailserver.provider.com.
mail.example.com.  IN    MX       10 mail.provider.com.    ; invalid

# Correct — separate subdomain names for separate purposes
webmail.example.com. IN  CNAME    mailserver.provider.com.
example.com.         IN  MX       10 mail.provider.com.

When to Use an A Record

A records are the right choice in these situations:

• Root domain (@ or example.com) — The only record type that works correctly at the apex by DNS standards (unless your provider offers ALIAS or CNAME Flattening).
• Servers with static, predictable IPs — VPS or dedicated servers where the IP address is known and rarely changes.
• Hostnames that need other record types alongside — If a hostname needs MX records for email or TXT records for verification, use an A record (not CNAME) to allow coexistence.
• Minimizing DNS lookup hops — A records resolve in a single lookup step, making them slightly more efficient than CNAME chains.

# Example: A records for a self-hosted server
@              3600    IN    A    203.0.113.10
www            3600    IN    A    203.0.113.10
mail           3600    IN    A    203.0.113.20
ftp            3600    IN    A    203.0.113.10

When to Use a CNAME Record

CNAME records are the right choice in these situations:

• Pointing subdomains to cloud services with dynamic IPs — Services like AWS, GCP, Azure, Heroku, Vercel, and Netlify often provide hostnames instead of fixed IPs because their infrastructure load-balances across many servers.
• The www subdomain tracking the root — www CNAME example.com keeps www in sync with root automatically, so you only manage one A record.
• Multiple subdomains pointing to the same target — If blog, shop, and app all need to point to the same CDN endpoint, a CNAME for each means you change only the CDN hostname when needed.
• Domain verification challenges — Many services (Google Search Console, SSL providers, email authentication) require you to create specific CNAME records to prove domain ownership.

# Example: CNAME records for cloud services
www        300    IN    CNAME    example.com.
blog       300    IN    CNAME    mysite.netlify.app.
shop       300    IN    CNAME    stores.example-ecom.com.
_dmarc     300    IN    CNAME    dmarc-verify.provider.com.

CNAME Flattening and ALIAS Records — Solving the Apex Problem

The restriction against using CNAME at the root domain becomes problematic when a cloud service or CDN only provides a hostname rather than a fixed IP. Several DNS providers offer workarounds:

CNAME Flattening (Cloudflare, NS1)

Cloudflare allows you to enter a CNAME for the root domain through their dashboard. Internally, Cloudflare resolves the CNAME chain server-side and returns an A record to the client, so the response conforms to DNS standards. This makes it possible to point your root domain to services like Vercel, Netlify, or GitHub Pages without violating RFC rules.

ALIAS / ANAME Records (Route53, DNSimple, Namecheap)

Some DNS providers offer proprietary record types called ALIAS or ANAME that behave like CNAME but are safe to use at the apex. The provider resolves them to A records before serving responses to clients.

# Cloudflare — enter CNAME at root via dashboard; Cloudflare handles flattening
@     CNAME    myapp.vercel.app.

# Route53 — use ALIAS record type for apex
@     ALIAS    myapp.elb.amazonaws.com.

Real-World DNS Zone Example

The following example shows a well-structured DNS zone for a typical business website using both A records and CNAME records correctly:

; DNS Zone for example.com
; Root domain — A record required
@              3600    IN    A    203.0.113.10
; www subdomain — CNAME back to root for easy IP management
www            300     IN    CNAME    example.com.
; Mail server — A record (must coexist with MX)
mail           3600    IN    A    203.0.113.20
@              3600    IN    MX   10 mail.example.com.
; Cloud service subdomains — CNAME for flexibility
blog           300     IN    CNAME    mysite.netlify.app.
shop           300     IN    CNAME    exampleshop.myshopify.com.
; CDN for static assets
cdn            300     IN    CNAME    cdn-endpoint.cloudfront.net.
; SSL verification challenge (ACME DNS-01 uses a TXT record, not a CNAME)
_acme-challenge 60    IN    TXT    "ACME_DNS01_VALIDATION_TOKEN"

Notice that the root domain and mail server use A records because mail requires an MX record alongside it. Cloud-hosted subdomains use CNAME records because their IPs may change and they have no other record types sharing the same name. The _acme-challenge entry uses a TXT record (not CNAME) containing the token provided by the ACME DNS-01 challenge during SSL certificate issuance.

Setting TTL Correctly for Each Record Type

TTL (Time to Live) controls how long DNS resolvers cache a record before querying again. Setting TTL incorrectly affects both resolution speed and how quickly changes propagate:

• A records with stable IPs: 3600–86400 seconds (1–24 hours). Higher TTL reduces DNS query load significantly.
• A records where IP might change: 300–600 seconds (5–10 minutes) for faster propagation during updates.
• CNAME records pointing to cloud services: 300–900 seconds. Align with the TTL of the target service.
• Before a migration or IP change: Reduce TTL to 60–300 seconds at least 24–48 hours in advance, so cached values expire quickly when you make the switch.

; TTL recommendations by record type
@          86400    IN    A    203.0.113.10    ; stable IP — 1 day TTL
www          300    IN    CNAME    example.com.    ; low TTL — flexible
blog         300    IN    CNAME    mysite.netlify.app.    ; match cloud TTL

Frequently Asked Questions

What is the technical difference between a CNAME and an A record?

An A record maps a hostname directly to an IPv4 address (e.g., example.com → 203.0.113.10). A CNAME maps one hostname to another hostname (e.g., www.example.com → example.com). When a resolver encounters a CNAME, it must perform an additional lookup to resolve the target to an IP address, adding a minor amount of latency but providing greater flexibility when the underlying IP changes.

Why should you not put a CNAME at the root (apex) domain?

According to DNS standards (RFC 1034), a name that carries a CNAME must not have any other record types under it. But the root domain always requires SOA and NS records, which conflicts with that rule. The solution is to use an A record at the root and CNAME at subdomains like www, or use CNAME Flattening or ALIAS records if your DNS provider supports them.

Should I use CNAME or A record when pointing to Cloudflare?

It depends on the level you're configuring. For subdomains like www or blog pointing to Cloudflare, use a CNAME pointing to the hostname Cloudflare provides. For the root domain, use an A record pointing directly to Cloudflare's IP address. Cloudflare also supports CNAME Flattening at the root via their dashboard, internally resolving the CNAME to an A record before the response reaches the client.

Does using a CNAME make my website load slower?

A CNAME adds one extra DNS lookup step compared to an A record, which theoretically adds a small amount of latency. In practice, DNS responses are cached according to their TTL values, so after the initial lookup, subsequent requests are just as fast as A record lookups. The real-world impact on users is negligible as long as TTL values are set appropriately (300–3600 seconds).