CNAME Record Explained
cname record dns · cname vs a record · dns alias record
How DNS CNAME records alias one name to another, apex limitations, conflicts with other record types, and checking CNAME with DNS Checker.
By DN01 Network Team
A CNAME (Canonical Name) record aliases one DNS name to another. Example: `www.example.com CNAME example.com`. Resolvers follow the chain until they reach A/AAAA answers.
CNAME at the same name as MX, TXT, or NS is invalid — a common exam question and production outage cause. Use the DNS Checker to confirm no conflicting types share a label.
CNAME mistakes surface during SaaS onboarding, CDN cutovers, and certificate validation — always verify the full chain after the vendor says «DNS is configured».
Valid CNAME patterns
Point `www` or `app` subdomains at a SaaS target (`target.saas.com`). CDN setups often use CNAME to edge hostnames. TTL applies to the CNAME itself.
Some DNS hosts offer ALIAS/ANAME at apex to mimic CNAME behavior — that is provider-specific, not classic CNAME.
Wildcard CNAME (`*.example.com`) is rare and provider-dependent; most teams use explicit labels per subdomain for clarity and easier troubleshooting.
CNAME vs A record
Choose CNAME when the target IP may change without your action (managed SaaS). Choose A/AAAA when you control the address directly.
Long CNAME chains add latency; flatten where possible. DIG traces CNAME chains explicitly if the DNS Checker summary hides intermediate hops.
Certificate issuance (HTTP-01 or CNAME-based validation) may require temporary CNAME records — remove or update them after validation so they do not shadow production routing.
Troubleshooting CNAME issues
«Site works without www, fails with www» often means missing or wrong CNAME on `www`. Run the DNS Checker on both apex and www and compare A/AAAA after chain resolution.
If a CNAME target itself is a CNAME, resolution depends on the full chain — broken intermediate targets cause intermittent failures when one resolver caches differently.
After deleting a CNAME, some clients still serve old answers until TTL expires — lower TTL before removing CNAME records that front production traffic.
CNAME change checklist
Before change: document current CNAME target and final A/AAAA after resolution. During change: update zone, verify with DNS Checker and DIG type CNAME. After change: test HTTPS on the hostname and confirm mail records on other labels were untouched.
SaaS vendors sometimes rotate edge hostnames — subscribe to their status page and re-check CNAME when they announce infrastructure moves.
When migrating off a CNAME-based SaaS, publish A/AAAA or a new CNAME only after lowering TTL — otherwise clients mix old and new targets during the window.
Frequently asked questions
- Can I use CNAME at the root domain?
Classic DNS says no. Use ALIAS/ANAME or A/AAAA at apex per your DNS provider docs.
- Does CNAME affect email?
Never combine CNAME with MX at the same name. Mail uses separate MX/TXT labels.
- How do I detect CNAME loops?
Lookup tools will timeout or error when a CNAME points to itself indirectly — fix the chain in your zone file.
- Why does CNAME show in DIG but site still fails?
The CNAME may resolve while the target lacks A/AAAA or TLS is misconfigured — check the terminal target and SSL on that name.
- Can I CNAME to another domain I do not control?
Technically yes if the target exists, but you depend on their DNS stability — prefer targets under your control or vendor SLAs.