CNAME Records Explained: Aliasing One Domain to Another

August 12, 2026

What a CNAME Does

A CNAME (Canonical Name) record is an alias: it points one hostname to another hostname, rather than directly to an IP address. When a resolver looks up a CNAME, it doesn’t stop there – it follows the chain to whatever the target hostname resolves to, however many hops that takes.

A Basic Example

www.example.com. CNAME example.com.
blog.example.com. CNAME jonathansblog.wordpress.com.
app.example.com. CNAME my-app.herokuapp.com.

Here, a lookup for blog.example.com gets redirected to jonathansblog.wordpress.com, and the resolver then looks up whatever A or further CNAME records exist for that hostname. If the hosting provider changes their infrastructure and updates their own IP addresses, your CNAME keeps working without you touching your own DNS – you’re pointing at their name, not their current address.

This is exactly why CNAMEs are the standard way to point a custom domain at a third-party service: CDNs, SaaS platforms, and hosting providers all ask for a CNAME rather than an IP, because their own IPs can change behind the scenes.

The Rule That Trips People Up: No CNAME at the Zone Apex

A CNAME record cannot coexist with any other record type on the same name, and the DNS spec technically disallows using a CNAME at the zone apex (the bare domain, e.g. example.com with no subdomain) – because the apex needs an SOA record and usually NS and MX records too, and a name can’t have a CNAME alongside anything else:

# Not valid
example.com. CNAME somewhere-else.com.
example.com. MX 10 mail.example.com.

# This breaks because CNAME can't share a name with MX, or anything else

This is why services that want you to “CNAME the apex” usually can’t actually do that through standard DNS. In practice, providers work around this with proprietary alternatives – Cloudflare’s CNAME flattening, AWS Route 53’s ALIAS records, or similar “apex CNAME” features from other DNS providers – which behave like a CNAME to the outside world but are technically implemented as dynamically-resolved A records at the DNS server level.

CNAME vs A Record

The choice is straightforward: point at an IP address directly with an A record when you control that IP and it’s stable. Use a CNAME when you’re pointing at infrastructure you don’t control, especially third-party services whose underlying IPs can and do change.

# Direct control over the server - use A
example.com. A 203.0.113.10

# Pointing at a third-party service - use CNAME
shop.example.com. CNAME shops.myshopify.com.

A Note on Chains

CNAMEs can point to other CNAMEs, but keep the chain short. Every extra hop adds a DNS lookup and a small amount of latency, and long chains make troubleshooting painful – you end up following a trail of aliases just to find where a lookup actually terminates.

Next in the series: DNSSEC, which adds cryptographic signing to protect the integrity of all these records in the first place.

CNAME, dns