CNAME

A CNAME record creates a DNS alias. When a resolver looks up a CNAME, it receives another hostname instead of an IP address, then resolves that hostname to get the final IP. This indirection is useful when you want multiple subdomains to point to the same service without hardcoding the IP in every record — update the target once and all aliases follow.

DNS record types compared

Common CNAME uses

CNAMEs appear everywhere in modern web infrastructure:

• www subdomain: www.example.com CNAME example.com — lets visitors use both the bare domain and www
• CDN integration: static.example.com CNAME example.cdn-provider.com — routes asset requests to a CDN without exposing or managing origin IPs directly
• SaaS custom domains: mail.example.com CNAME ghs.google.com — powers Google Workspace and similar custom-domain services
• Domain verification: services issue a unique CNAME token to prove you control a domain before issuing TLS certificates or activating services

CNAME chain resolution

A CNAME can point to another CNAME, forming a chain. A resolver follows each link until it reaches a non-CNAME record (typically an A or AAAA record). For example: shop.example.com CNAME shop.cdn.net, shop.cdn.net CNAME anycast.cdn.net, anycast.cdn.net A 198.51.100.4. Each link in the chain requires an additional DNS lookup round trip. Most DNS implementations cap chains at 8–10 hops to prevent infinite loops. Long chains add latency at initial resolution, though results are cached at each record's TTL.

The root domain (apex) limitation

You cannot place a CNAME at the zone apex — the bare domain (example.com without any subdomain) — because DNS standards (RFC 1034) require the apex to carry SOA and NS records. A CNAME at the apex would conflict with those mandatory records; the behavior is undefined and most DNS servers will refuse or silently break it. This means you can alias www.example.com via CNAME but you cannot alias example.com itself.

This is a real problem when you want the root domain to point to a service (like a CDN, load balancer, or Heroku app) that provides a hostname rather than a stable IP. Three solutions exist:

• CNAME flattening: Cloudflare and some other DNS providers resolve the CNAME chain server-side at query time and return the final A/AAAA record to the client, making the apex behave as if it has an A record.
• ALIAS / ANAME records: Proprietary record types offered by providers like DNSimple, AWS Route 53, and others. They work the same way as CNAME flattening — resolved server-side, returned as A/AAAA — but are a named extension rather than implicit behavior.
• Redirect at the apex: Use an A record pointing to a redirect server that 301-redirects example.com to www.example.com, where the actual CNAME lives.

CNAME vs A record trade-offs

Choosing between a CNAME and an A record involves balancing flexibility against performance. A CNAME adds at least one extra DNS lookup: the client must resolve the alias to its target, then resolve the target to an IP. If the target itself has a CNAME, the chain continues. On a 20 ms DNS resolver, a two-hop chain adds ~40 ms before the first TCP connection attempt — significant for cold page loads. An A record resolves directly to an IP in a single lookup.

The operational benefit of CNAMEs is that you manage one canonical name. If a service rotates its IP addresses (as CDNs constantly do), you need no DNS changes — the provider updates their A record and all your CNAMEs inherit the new IPs automatically. This is why CNAMEs dominate CDN and SaaS integrations despite the extra lookup cost, which is mitigated by TTL caching after the first resolution.

TTL on CNAME records

Every CNAME record carries its own TTL, and every record in the resolution chain carries its own TTL. If shop.example.com CNAME shop.cdn.net has a TTL of 3600 seconds, a resolver caches the alias for one hour. But shop.cdn.net A 198.51.100.4 may have a TTL of only 60 seconds. A change in the CDN's IP propagates in 60 seconds even though the CNAME alias is cached for an hour — because the alias and the target IP are cached independently. When configuring CNAMEs for services that may change IP frequently (CDNs, cloud load balancers), set a low TTL on the target A record.

CNAME loop detection

A CNAME loop occurs when two names alias each other: a.example.com CNAME b.example.com and b.example.com CNAME a.example.com. Resolvers detect this by counting hops and returning SERVFAIL after reaching a limit (typically 8–10). DNS management panels at providers like Cloudflare and AWS Route 53 attempt to detect obvious loops at record creation time, but misconfigured delegated zones can still create loops across providers. The symptom is consistent SERVFAIL or NXDOMAIN responses that appear only after TTL expiry.

Frequently Asked Questions

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

An A record maps a hostname directly to an IP. A CNAME maps a hostname to another hostname — the resolver then looks up that target to find the IP. CNAMEs add one extra DNS step but let multiple names share a single target that you manage in one place.

Why can't you use a CNAME at the root domain?

A CNAME at the zone apex conflicts with required SOA and NS records per RFC 1034. DNS standards forbid it. Most DNS providers offer ALIAS or ANAME records, or CNAME flattening, as workarounds — they resolve the alias server-side and return an A record to the client.

How is CNAME used for custom domain verification?

Services like GitHub Pages, Google Workspace, and certificate authorities ask you to add a specific CNAME record to prove domain ownership. For example, _acme-challenge.example.com CNAME unique-token.acme-verify.com proves to Let's Encrypt that you control the DNS for the domain and authorises certificate issuance.