CNAME Records: Aliases for Your Domain

A CNAME record says: "I don't have the IP address. Ask them."

That's the entire mechanism. When you look up www.example.com and find a CNAME pointing to example.com, DNS follows the pointer and asks the canonical (official) name for the real answer. The resolver keeps following until it reaches an actual IP address.

www.example.com.    IN    CNAME    example.com.
blog.example.com.   IN    CNAME    hosting.platform.com.
cdn.example.com.    IN    CNAME    cdn.provider.net.

The first field is the alias (what someone looked up). The last field is the canonical name (where to find the real answer).

A CNAME doesn't just point to another name—it delegates control. You're saying: "I don't manage this answer. They do."

Why CNAMEs Matter

The WWW problem: Point www.example.com to example.com. When your server's IP changes, update one A record. The CNAME follows automatically.

Content Delivery Networks: Create cdn.example.com pointing to customer123.cdn-provider.net. The CDN provider manages their infrastructure—when they need to route your traffic to different servers for performance or failover, they update their DNS. Your CNAME keeps working because you delegated control.

SaaS integration: Help desk systems, e-commerce platforms, and other services ask you to create CNAMEs like support.example.com pointing to customer-name.helpdesk-service.com. You get branded URLs; they manage the infrastructure.

Environment management: Point staging.example.com to different servers without changing application code. When staging moves to new infrastructure, update the CNAME target.

The Zone Apex Problem

You cannot create a CNAME for example.com itself—only for subdomains like www.example.com.

This isn't arbitrary. Two DNS rules collide:

1. The zone apex MUST have SOA (Start of Authority) and NS (Name Server) records
2. A name with a CNAME MUST NOT have any other records

Both rules make sense. SOA and NS records are required for the zone to function. And if a CNAME exists, the resolver must follow it—other records at that name would create ambiguity about which answer is authoritative.

The consequence: since the apex requires multiple record types, CNAMEs are forbidden there.

The practical problem: You want both example.com and www.example.com to reach your CDN, but the CDN requires a CNAME, and you can't create one at the apex.

Workarounds

ALIAS/ANAME records: Some DNS providers offer proprietary record types that behave like CNAMEs at the apex but return A records when queried. Cloudflare calls this "CNAME flattening." Route 53 calls them "Alias records." Not standardized, so availability varies by provider.

Multiple A records: Point both the apex and www directly to IP addresses. Update both when IPs change. Works everywhere.

HTTP redirect: Point the apex to a simple redirect server that sends browsers to www.example.com. The www subdomain uses the CNAME. Adds a redirect hop but works reliably.

Following the Chain

CNAMEs can point to other CNAMEs:

app.example.com.        IN    CNAME    service.company.com.
service.company.com.    IN    CNAME    lb.hosting.net.
lb.hosting.net.         IN    A        203.0.113.10

The resolver follows each pointer until it finds an IP address. Three lookups for one answer.

Performance Cost

Each CNAME in a chain potentially requires another DNS query. If each query takes 50ms, a two-level chain adds 100ms before the browser can even begin connecting.

CNAME TTLs compound the problem. The CNAME itself has a TTL separate from the final A record. Mismatched TTLs can cause stale caching or unnecessary re-resolution.

Keep chains short: One or two levels maximum. Longer chains compound latency and increase failure points. When performance matters, direct A records win—but you lose the delegation that makes CNAMEs useful.