What a CNAME record is
A CNAME record (canonical name record) says that one DNS name is an alias of another. www.example.com CNAME example.net means: whatever you want to know about www.example.com, ask example.net instead. The name on the left is the alias; the name on the right is the canonical name, also called the target.
A CNAME holds a hostname, never an IP address. It does not say where the site lives; it says which other name knows. That is the whole point of it: the owner of the target can change its addresses at any time, and every alias that points at it follows without anyone editing their own zone.
The record has the same four parts as any other DNS record: a name, a TTL, the type and the value. In a zone file it looks like the sample below. Notice the trailing dot after the target: it marks the name as complete, a detail that the mistakes section comes back to.
CNAMEs are everywhere once you look for them. www pointing at a CDN hostname, shop.example.com pointing at a hosted store platform, status.example.com pointing at a status page service, and the verification records that SaaS tools ask you to create are very often CNAMEs. The DNS guide covers the other record types; this one stays on the alias.
CNAME records in a zone file
$ORIGIN example.com.
; name TTL class type target (canonical name)
www 3600 IN CNAME example.cdn-provider.net.
shop 3600 IN CNAME shops.hosted-store.example.
status 3600 IN CNAME example.status-service.example.How a resolver follows a CNAME
Browsers never ask for a CNAME. They ask for an address: an A record for IPv4 and an AAAA record for IPv6. The CNAME comes into play when the resolver doing the lookup for them finds one on the way.
The resolver asks the authoritative nameservers of example.com for the A record of www.example.com. Instead of an address, they answer with the CNAME: www.example.com is an alias of example.cdn-provider.net. The resolver then starts the lookup again for the target name, this time at the nameservers of cdn-provider.net, and gets the A record there. It returns both records to the browser: the CNAME, then the address.
When the same nameserver is authoritative for both names, it puts the whole chain in one answer and saves the second trip. Otherwise each hop is a separate lookup, which is why a CNAME can cost a few milliseconds on a cold cache and nothing once the answers are cached.
If you ask for the CNAME type itself, the resolver stops at the alias and does not follow it. That is what a CNAME lookup in most online tools does: it tells you which name an alias points to, not the address it finally reaches.
$ dig www.example.com A +noall +answer
www.example.com. 3600 IN CNAME example.cdn-provider.net.
example.cdn-provider.net. 60 IN A 203.0.113.25
$ dig www.example.com CNAME +short
example.cdn-provider.net.CNAME vs A and AAAA records
An A record maps a name to an IPv4 address and an AAAA record to an IPv6 address. They are the end of every lookup: whatever chain of aliases a resolver follows, it stops at an A or AAAA record. A CNAME maps a name to another name and always needs one more step.
Use an A or AAAA record when you control the address and it rarely changes: your own server, a load balancer with a fixed IP, a VPS. You maintain the address yourself, and if it changes you must edit every record that holds it.
Use a CNAME when somebody else controls the address: a CDN, a hosted platform, a SaaS tool. Their addresses can change, be different per region, or come from a pool, and you should not have to know. A CDN in particular may answer the same hostname with different edge addresses in different places; a CNAME to its hostname gets that behaviour for free, a copied IP address freezes one answer.
The practical difference in speed is small. A CNAME adds a lookup only when the target is not cached, and popular targets almost always are. The difference in maintenance is large: a hard-coded A record to a provider's IP is the classic cause of a site going dark months later, when the provider renumbers.
Why the root domain cannot be a CNAME
The rule comes from the original DNS specification. RFC 1034 section 3.6.2 says that if a CNAME is present at a name, no other data should be present there, and RFC 2181 confirms it. The reason is the way resolution works: a CNAME means "everything about this name lives elsewhere", so a resolver that finds one stops looking for anything else at that name. A second record next to it would be either ignored or contradictory. The only exceptions are the DNSSEC records that sign the CNAME itself.
The root domain (the apex, the bare example.com) always has other records. Every zone must have an SOA record and NS records at its apex, and most domains also have MX records for mail and TXT records for SPF and domain verification there. A CNAME at the apex would have to replace all of them, so the standard forbids it, and most DNS providers refuse to save one.
The providers that do accept it produce a zone that breaks in unpredictable ways: some resolvers return the CNAME and lose the MX records, so mail starts bouncing; others return the MX records and ignore the alias. This is why www is the classic place for a CNAME and why the bare domain needs a different answer, covered in the next section.
Why the apex already has records a CNAME would collide with
example.com. 3600 IN SOA ns1.dns-host.example. hostmaster.example.com. ( ... )
example.com. 3600 IN NS ns1.dns-host.example.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 include:_spf.mail.example ~all"
; example.com. 3600 IN CNAME example.cdn-provider.net. <- not allowed here
www.example.com. 3600 IN CNAME example.cdn-provider.net. ; fine: www has no other recordsALIAS, ANAME and CNAME flattening
Because people want the bare domain on a CDN too, DNS providers built workarounds. They go by different names, but they all do the same thing: the provider follows the alias for you and publishes the result as ordinary A and AAAA records at the apex.
You configure something that looks like a CNAME on example.com. When a query arrives, the provider's nameserver resolves the target itself, takes the addresses it finds and answers with them. To the outside world the apex has plain A and AAAA records, so SOA, NS, MX and TXT can sit next to them legally. Some providers call this an ALIAS record, some ANAME, and others CNAME flattening. Amazon Route 53 has its own alias records, which point only at AWS resources. ANAME was proposed as a standard but never finished, so every one of these is a provider feature, not a record type that moves with you between providers.
The trade-offs are worth knowing. The addresses are chosen from where the provider's nameserver sits, not where the visitor is, so a CDN that answers differently per region may hand out a less suitable edge, unless the provider passes the visitor's network along (EDNS Client Subnet). The provider also controls how often it refreshes the answer, which can lag behind the target's TTL. And when you move DNS hosts, the feature does not come along.
There is also a newer standard answer: the HTTPS record type (RFC 9460) has an alias form that is allowed at the apex. Browser support for that form is still limited, so treat it as a future option, not today's fix.
What a CNAME does not do
A CNAME is not a redirect. It changes which addresses a name resolves to and nothing else. The address bar keeps showing www.example.com, and the browser still sends Host: www.example.com in every request and asks the TLS handshake for a certificate valid for www.example.com.
That has two consequences people trip over. First, the server behind the target must be configured to accept your hostname. Pointing www at somebody-else.example.net with a CNAME does not make their server serve your site; it serves whatever it serves for an unknown Host, often an error page or a default site. This is why CDNs and hosting platforms ask you to add the hostname in their panel first and point DNS second.
Second, the certificate must cover your name, not the target's. A certificate for example.cdn-provider.net does not help a visitor of www.example.com; without a certificate for your own name, browsers show a certificate warning even though DNS is correct.
If what you want is to send visitors from one URL to another, so that the address bar changes, that is an HTTP redirect, a 301 or 302 answered by a web server. See 301 vs 302 redirects.
Common CNAME mistakes
A CNAME at the apex. Covered above: use the root-domain options your DNS host offers instead of forcing a CNAME on example.com.
A CNAME next to other records. The rule applies to every name, not just the apex. If www needs a TXT record for a verification, or shop already has an MX record, you cannot add a CNAME there as well. Most providers refuse; the ones that do not leave you with a name that answers differently from resolver to resolver. Put verification records on their own name where the service allows it.
The missing trailing dot. In a zone file, a name without a final dot is relative and gets the zone name appended. www CNAME example.cdn-provider.net inside example.com becomes example.cdn-provider.net.example.com., a name that does not exist. Write the target with its trailing dot. Web DNS editors differ: most take the target without a dot and add it themselves, and a few want it. Check the result with dig rather than trusting the form.
A CNAME to an IP address. The value of a CNAME must be a hostname. www CNAME 203.0.113.25 is either refused or stored as a name that never resolves. An address belongs in an A or AAAA record.
Long chains. A CNAME may point at another CNAME, but every hop is another possible lookup and another TTL. Resolvers give up after a fixed number of hops, and a loop (a to b, b back to a) fails outright. Point straight at the final name your provider gives you.
MX or NS pointing at an alias. RFC 2181 section 10.3 says the targets of MX and NS records must have their own addresses, not be CNAMEs. Some mail servers still deliver, others do not.
Dangling CNAMEs. When you cancel a service but leave promo.example.com CNAME old-campaign.platform.example in place, anyone who later claims that name on the same platform can serve content on your subdomain. This is subdomain takeover. Delete the CNAME when you delete the service.
The trailing dot, right and wrong (zone file for example.com)
; wrong: relative target, becomes example.cdn-provider.net.example.com.
www 3600 IN CNAME example.cdn-provider.net
; right: fully qualified target
www 3600 IN CNAME example.cdn-provider.net.
; wrong: a CNAME plus another record at the same name
shop 3600 IN CNAME shops.hosted-store.example.
shop 3600 IN MX 10 mail.example.com.How to look up a CNAME record
dig (Linux, macOS, Windows through WSL) is the clearest tool. dig www.example.com CNAME +short prints the target of the alias. dig www.example.com +noall +answer prints the whole chain down to the addresses. dig @1.1.1.1 ... or dig @8.8.8.8 ... asks a specific public resolver, which helps when you suspect a cached answer. And dig +trace walks the delegation from the root servers downwards, which shows what the authoritative nameservers say right now, bypassing every cache.
nslookup is available everywhere, including plain Windows: nslookup -type=CNAME www.example.com. On Windows PowerShell, Resolve-DnsName www.example.com -Type CNAME gives a tidier answer.
Online lookup tools answer from their own resolvers, often from several countries at once. They are useful for one question in particular: does the rest of the world see the same answer as you? If some locations show the old target and others the new one, the change is still propagating.
When the answer looks wrong, ask the authoritative nameserver directly. First find it with dig NS example.com +short, then query it with @. If the authoritative server has the right answer and a public resolver does not, you are looking at a cache that has not expired yet. If the authoritative server is wrong, the record itself needs fixing, at whichever DNS host the NS records point to.
# the target of the alias
dig www.example.com CNAME +short
# the full chain, alias to address, from a public resolver
dig @1.1.1.1 www.example.com +noall +answer
# straight from the authoritative nameserver, no cache involved
dig NS example.com +short
dig @ns1.dns-host.example www.example.com CNAME +short
# Windows
nslookup -type=CNAME www.example.com
Resolve-DnsName www.example.com -Type CNAMETTL and propagation for a CNAME
Every record in a chain is cached for its own TTL. In the dig example above, the CNAME has a TTL of 3600 seconds and the target's A record 60 seconds. A resolver keeps the alias for an hour and the address for a minute. That split is exactly what you want with a CDN: the provider can move its addresses within a minute, while your own record barely ever changes.
It also tells you how long your own changes take. If you repoint www from one target to another, resolvers that cached the old CNAME keep using it until its TTL runs out, so with a TTL of 3600 the switch is complete within an hour of saving. Lower the TTL to 300 a day before a planned change, make the change, then raise it again.
Two things take longer than the record's TTL. A name that did not exist before may be cached as "does not exist" for the negative-caching time in the zone's SOA record; adding the CNAME right after someone looked it up can take that long to show. And changing nameservers at your registrar is a different operation from changing a record: it depends on the TTL that the registry gives the delegation, which is often a day or two. The DNS guide covers propagation in general.
Pointing a domain at a CDN with a CNAME, on CDN.com.tr
The typical CDN setup puts www and other subdomains on a CNAME to the CDN hostname, and handles the root domain separately. On CDN.com.tr you choose one of three delivery methods in the panel.
Default Endpoint serves your content from a xyz.cdn.com.tr hostname, with no DNS work. It is the quickest way to test, and you can move to your own domain later.
Custom Domain/Subdomain (CNAME) keeps your DNS where it is. You add the hostname in the panel, for example www.example.com or assets.example.com, and create a CNAME at your DNS host that points it at the target the panel shows, in the form <yourname>.cdn.com.tr. Copy the target exactly, without extra prefixes. The root domain cannot use this method; for it the panel offers an A record or Full DNS Transfer. A hostname connected by CNAME gets its own certificate, validated over HTTP as soon as requests reach the edge. Since the CDN hostnames carry AAAA records next to their A records, a CNAME to us also gives the name IPv6, with no extra record on your side.
Full DNS Transfer moves the domain's nameservers to CDN.com.tr. This is the clean answer to the apex problem: the panel becomes your zone editor, the root domain is routed to the edge without a CNAME workaround, and the root gets a wildcard certificate that covers its subdomains. The panel scans and imports your existing records (MX, TXT, subdomains) before the nameserver switch, and you can have the certificate issued through a DNS TXT record at your current provider before switching, so HTTPS works from the first minute.
The CDN DNS setup guide walks through the switch step by step. Once the CNAME resolves, check that requests really go through the edge: the X-Proxy-Cache-MT response header shows whether the edge served the answer from its cache.
$ dig www.example.com CNAME +short
yourname.cdn.com.tr.
$ curl -sI https://www.example.com/ | grep -i x-proxy-cache-mt
X-Proxy-Cache-MT: HITCNAME record FAQ
Can I use a CNAME record for my root domain?
Not under standard DNS rules. A CNAME must be the only record at its name, and the root domain always has SOA and NS records, usually MX and TXT as well. Use A and AAAA records, your DNS provider's ALIAS, ANAME or flattening feature, or move your DNS to the provider that serves the site so it can answer the apex directly.
Is a CNAME the same as a redirect?
No. A CNAME only changes which addresses a name resolves to; the browser keeps your hostname in the address bar, in the Host header and in the certificate check. A redirect is an HTTP response such as 301 that sends the visitor to a different URL.
Can a CNAME point to a different domain?
Yes, that is its most common use: www.example.com pointing at a CDN or SaaS hostname on someone else's domain. The target only has to be a hostname that resolves. The service behind it must also be configured to accept your hostname and hold a certificate for it.
Can I have a CNAME and an MX or TXT record on the same name?
No. A name with a CNAME may hold no other records apart from DNSSEC signatures. If a service needs a TXT record and a CNAME on the same name, put the TXT record on a different name if the service allows it, or use an A record instead of the CNAME.
Is a CNAME slower than an A record?
Only on a cold cache, when the resolver has to look up the target separately; that costs a few milliseconds. Cached answers cost nothing extra. The flexibility is usually worth far more than that difference, especially when the target belongs to a CDN that changes its addresses.
How long does a CNAME change take to work?
Up to the old record's TTL: resolvers keep the previous answer until it expires. With a TTL of 3600 seconds that is an hour at most. A brand-new name can take longer if it was recently looked up and cached as non-existent. Lower the TTL a day ahead of planned changes.
What is the difference between a CNAME and a DNAME?
A CNAME aliases one exact name. A DNAME aliases a whole subtree: every name under old.example.com is mapped to the same name under new.example.net, but not old.example.com itself. DNAME is rare on websites and many DNS hosts do not offer it.