CNAME Records Explained: DNS Aliases, Chains, and Best Practices
CNAME records are one of the most commonly used DNS record types, allowing you to point one domain name to another. While they seem simple, CNAMEs have important restrictions and performance implications that every domain administrator should understand. This guide covers how CNAME records work, when to use them, and the pitfalls to avoid.
What Is a CNAME Record?
A CNAME record (Canonical Name record) creates an alias from one domain name to another. Instead of mapping a name directly to an IP address like an A or AAAA record, a CNAME points to another domain name, which in turn resolves to an IP address.
; CNAME example
blog.example.com. IN CNAME example.com.
www.example.com. IN CNAME example.com.
; The target resolves to an IP
example.com. IN A 93.184.216.34When a resolver looks up blog.example.com, it finds the CNAME record pointing to example.com, then follows that to get the A record with the actual IP address. This indirection is what makes CNAMEs powerful — if the IP address of the target changes, all aliases automatically resolve to the new address. You can check any domain's CNAME records with our CNAME Lookup tool.
How CNAME Resolution Works
The resolution process for a CNAME involves multiple steps:
- Client queries the resolver for
www.example.com A. - Resolver finds a CNAME record:
www.example.com CNAME example.com. - Resolver now queries for
example.com A. - Resolver returns the A record:
example.com A 93.184.216.34. - Client connects to 93.184.216.34.
Each step in this chain requires a DNS lookup, which adds latency. Most resolvers cache intermediate results, but the initial resolution is slower than a direct A record lookup.
CNAME vs A Record: When to Use Which
Choosing between a CNAME and an A record depends on your use case:
- Use A records when: You know the IP address and it rarely changes, or when the record is at the zone apex (root domain). A records provide the fastest resolution since there is no indirection.
- Use CNAME records when: You want to point a subdomain to a service managed by a third party (CDN, SaaS platform, cloud service), or when the target IP may change and you want automatic updates.
Common CNAME use cases include:
- CDN integration:
cdn.example.com CNAME d1234.cloudfront.net - SaaS services:
shop.example.com CNAME shops.myshopify.com - Email services:
mail.example.com CNAME ghs.google.com - Domain verification:
_verify.example.com CNAME verify.service.com
CNAME Chains and Why They Are Dangerous
A CNAME chain occurs when one CNAME points to another CNAME, which points to yet another CNAME, and so on. While the DNS specification allows this, chained CNAMEs create several problems:
- Increased latency. Each link in the chain requires an additional DNS query. A chain of 3 CNAMEs means 4 total lookups before the client gets an IP address.
- Single point of failure. If any target in the chain becomes unreachable or returns NXDOMAIN, the entire resolution fails.
- Circular references. If CNAME A points to CNAME B and CNAME B points back to CNAME A, resolvers detect this as a loop and fail the query. Some misconfigured setups create subtle loops that are hard to diagnose.
- Resolver limits. Most DNS resolvers limit CNAME chain depth to 8–16 levels. Beyond this, the query fails with a SERVFAIL response.
Best practice: keep CNAME chains to a maximum of one level. Point your CNAME directly to a name that resolves to an A or AAAA record. Use our CNAME Lookup tool to trace the full resolution chain for any domain and identify unnecessary indirection.
The Root Domain Restriction
One of the most important rules in DNS is that you cannot place a CNAME record at the zone apex (the root domain, e.g., example.com). This restriction comes from RFC 1034, which states that a CNAME record cannot coexist with any other record type at the same name.
At the zone apex, you must have SOA and NS records (and often MX and TXT records). Since a CNAME would conflict with these mandatory records, DNS specifications prohibit it. If you try to add a CNAME at the root, most DNS providers will reject it or produce undefined behavior.
This creates a real-world problem: many cloud services (Heroku, Azure App Service, S3 static hosting) provide only a CNAME target for custom domains. If your root domain needs to point to such a service, you need an alternative approach.
CNAME Flattening: Solving the Root Domain Problem
CNAME flattening (also called ANAME or ALIAS records) is a technique used by modern DNS providers to work around the root domain CNAME restriction. Instead of publishing a CNAME record, the DNS provider resolves the CNAME target at query time and returns the resulting A/AAAA records directly.
From the client's perspective, the response looks like a normal A record, but behind the scenes the DNS provider is dynamically resolving the CNAME target. This gives you the flexibility of a CNAME (automatic IP updates) with the compatibility of an A record (works at the zone apex).
DNS providers that support CNAME flattening include Cloudflare (which flattens all CNAME records by default), AWS Route 53 (via ALIAS records), DNSimple (ALIAS records), and Netlify DNS. If your DNS provider supports this feature, it is the recommended way to point your root domain to a service that provides only a CNAME target.
Performance Implications of CNAME Records
Every CNAME adds at least one additional DNS query to the resolution process. While modern resolvers cache aggressively and the added latency is often negligible (5–50ms), there are scenarios where it matters:
- High-traffic websites. For sites serving millions of requests, the cumulative DNS overhead from CNAMEs can be measurable. Direct A records are faster.
- Low-TTL targets. If the CNAME target has a very low TTL, the resolver must re-query frequently, increasing latency for uncached lookups.
- Cross-provider CNAMEs. When the CNAME target is on a different DNS provider than the source, the resolver may need to query an entirely different set of authoritative servers, adding a full resolution cycle.
To check how your CNAME records are performing, use our DNS Lookup tool to view the full resolution chain and DNS Propagation Checker to see response times from multiple global locations.
CNAME Records and Email
A common source of confusion is using CNAMEs with email-related records. MX records must not point to a CNAME — the MX target must resolve directly to an A or AAAA record. While some mail servers tolerate MX-to-CNAME resolution, it violates RFC 2181 and can cause delivery failures with strict implementations.
However, CNAMEs are commonly used for email authentication records. For example, DKIM verification records are often published as CNAMEs pointing to the email provider's DNS:
; DKIM via CNAME (common with Google Workspace, Microsoft 365)
google._domainkey.example.com. IN CNAME google._domainkey.googlehosted.com.
selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.tenant.onmicrosoft.com.This pattern lets the email provider rotate DKIM keys without requiring you to update your DNS records. Learn more about DKIM configuration in our DKIM Setup Guide.