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

An A record maps a hostname directly to an IPv4 address, so it is the final answer a resolver needs. A CNAME record maps one hostname to another hostname, acting as an alias that the resolver must follow until it reaches an A or AAAA record.

Why can't I use a CNAME on my root domain?

The DNS spec says a CNAME cannot coexist with any other record for the same name, but your root domain (the zone apex) must already carry SOA and NS records. Because those records are required, a CNAME there would conflict. Providers solve this with CNAME flattening, ALIAS, or ANAME records that behave like a CNAME at the apex but publish a real A record.

Does a CNAME slow down my site?

A CNAME adds one extra resolution step because the resolver must look up the target hostname before it gets an IP. In practice the delay is negligible: results are cached for the TTL, so most visitors never pay the cost. Avoid long CNAME chains, which multiply the lookups.

CNAME vs A Records: When to Use Each

An A record points a name directly to an IPv4 address, while a CNAME record points a name to another name (an alias). When a resolver hits an A record it has the final answer it needs to connect. When it hits a CNAME it is told "look up this other hostname instead," then follows that pointer until it lands on an A or AAAA record. Both behaviours are spelled out in RFC 1034, and that one distinction (IP versus hostname) drives every decision about which record to use. For the bigger picture of how these fit together, see DNS records explained.

Reach for an A record when you control or know the destination IP address: a server you run, a static hosting IP, or a load balancer with a stable address. A CNAME suits the opposite case, where you want a name to track whatever IP someone else manages. That comes up constantly when you point a subdomain at a CDN or a SaaS provider. Serving IPv6 too? Pair your A record with an AAAA record, and see A vs AAAA records for how those two relate.

What a CNAME record actually does

A CNAME (Canonical Name) record is an alias. The record shop.example.com CNAME stores.shopify.com tells resolvers that shop.example.com is just another label for stores.shopify.com. The resolver discards the alias, restarts the lookup against the canonical name, and uses whatever A or AAAA record it finds there. The payoff is portability: if the provider changes their underlying IP, your subdomain follows automatically because you never hardcoded an address.

Common uses for each

A record: apex/root domains, self-hosted servers, fixed load-balancer IPs, anything where you know the address.
CNAME record: www pointing back to the apex, subdomains pointing at a CDN (Cloudflare, Fastly, CloudFront), or SaaS targets like a help desk, status page, or email-marketing tracking domain.

A vs CNAME at a glance

Aspect	A record	CNAME record
Points to	An IPv4 address	Another hostname
Typical use	Servers, load balancers, apex domain	Subdomains aliasing a CDN or SaaS host
Allowed at root domain?	Yes	No (conflicts with required records)
Extra lookup?	No	Yes (resolve the target name)

The rule that trips everyone up: no CNAME at the root

DNS forbids a CNAME from coexisting with any other record of the same name, a rule set out in RFC 1034 (section 3.6.2). Your zone apex, the bare example.com, must already publish SOA and NS records that define the zone, so there is no room for a CNAME beside them. The upshot is simple: you cannot put a CNAME on your root domain. Those NS records are part of how delegation works, covered in NS records explained.

This bites when a host hands you only a CNAME target ("point your domain at app.platform.com") but you need it to work at the bare apex. You have two paths. Either resolve the target to its current IP and create an A record (fragile, because the IP can change), or use a provider feature built for exactly this case.

Workarounds: CNAME flattening, ALIAS, and ANAME

Many DNS providers offer apex aliasing that behaves like a CNAME but stays spec-compliant. Cloudflare calls it CNAME flattening; Route 53 uses ALIAS records; others (DNS Made Easy, NS1, some registrars) call it ANAME. Under the hood the provider resolves the target hostname for you and answers queries with a normal A or AAAA record, so no conflicting CNAME is ever published. You configure something that looks like a CNAME at the apex; the resolver sees a clean A record. Reach for whichever your provider supports rather than hardcoding an IP.

Chaining caveats

You can point a CNAME at another CNAME, but every hop is an extra resolution step. Long chains add latency and fragility; if any link breaks, the whole chain fails. Keep chains short, ideally one hop to a real A/AAAA record. Remember too that a CNAME owns its name exclusively. You cannot add an MX or TXT record to a hostname that is already a CNAME, which catches out people who try to alias a subdomain that also needs mail or verification records.

How to verify a record type with our tool

Run a DNS check on your domain and look at the answer for the name in question. If the type column shows A (or AAAA), you are resolving straight to an IP. If it shows CNAME, you will also see the canonical target it points to, and you can follow that target to confirm where the chain ends. This is the fastest way to confirm whether a misbehaving subdomain is aliased correctly or pointing at a stale IP.

Want to see exactly what your domain resolves to right now? Run a free DNS check at domainintel.app and inspect every A and CNAME record in one view.