CNAME

CNAME stands for Canonical Name. A CNAME record is a DNS resource record that makes one hostname an alias for another. The owner name is the alias, and the record's value is the canonical name it points to (RFC 1034 section 3.6.2). That value is a domain name. So a CNAME is not an address record. It can never hold an IP address (RFC 1035 section 3.3.1). It is not an HTTP redirect either. Resolution changes, but the URL in the browser does not. CDNs use it to hand resolution of your hostname to the provider. The provider then answers with edge addresses it can change at will. Its defining constraint is exclusivity. A CNAME may share its name with no other record type. That is why it cannot sit at the zone apex. There is a terminology trap here. Strictly, the canonical name is the record's value, not its owner. Calling the owner "a CNAME" is entrenched but loose (RFC 2181 section 10.1.1).

How it works

A name server may fail to answer a query with the requested record type. If it finds a CNAME at that name instead, it includes the CNAME in the response. Then it restarts the query at the name in the CNAME's data field (RFC 1034 section 3.6.2). For a type A query, both records come back together: the CNAME and the target's address record. A query for type CNAME itself returns just the CNAME. So the final answer a client uses is the target's A or AAAA record. It is delivered alongside the alias that led to it.

A CNAME owns its label exclusively. There may be only one canonical name for any one alias. The alias may carry no other data (RFC 2181 section 10.1). DNSSEC is the sole relaxation. In a signed zone, RRSIG and NSEC records are required at that name. A KEY record for secure dynamic update is permitted, but other types MUST NOT be present (RFC 4035 section 2.5).

Exclusivity is the whole reason a CNAME cannot sit at a zone apex. The top of a zone carries the NS records that list the zone's servers. It also carries exactly one SOA record (RFC 1034 section 4.2.1; RFC 1035 section 5.2). So there is no room for an alias there. Try it anyway, and a server such as BIND accepts the CNAME and ignores the NS records. That takes the whole domain out (RFC 1912 section 2.4).

A CNAME's target may itself be a CNAME, so chains are legal. Resolvers follow them and signal loops as an error. Multiple levels of aliasing should be avoided for lack of efficiency. But they must not themselves be signalled as an error (RFC 1034 section 3.6.2; section 5.2.2).

Each record carries a TTL. It bounds how long the answer may be cached before the source is consulted again (RFC 1035 section 3.2.1). So the TTL on the CNAME governs how quickly a change of target reaches users. A CNAME is impossible at the apex, so you need a substitute there. Options include Route 53's alias record, Cloudflare's CNAME flattening, or the standards-based HTTPS/SVCB record in AliasMode. AliasMode's stated primary purpose is aliasing at the zone apex where CNAME is not allowed (RFC 9460 section 2.4.2). AliasMode is not a drop-in CNAME. Unlike a CNAME, it does not affect the resolution of other record types, and it applies only to one service. Resolvers must cap how many SVCB aliases they will follow.

Why it matters for a CDN

A CDN answers for one hostname from many anycast edge addresses. It needs to change those addresses, add points of presence, and fail regions out. It does this without every customer editing a zone file. The CNAME is the hook that makes that possible. You publish one alias, and the provider's DNS supplies the addresses per query. Route 53 is asked for an alias record targeting a CloudFront distribution. It "responds with one or more IP addresses for CloudFront edge servers that can serve your content" (Route 53: Choosing between alias and non-alias records). Cloudflare flattens proxied records by default, precisely "as they return Cloudflare anycast IPs" (Cloudflare: Set up CNAME flattening).

Because those addresses are shared, the edge has to work out whose configuration a request belongs to. It does so at two different layers. In the TLS handshake, the client's SNI extension names the host it is contacting. That is what lets one address serve many virtual servers with the right certificate (RFC 6066 section 3). Then in HTTP, the Host header selects the configuration. CloudFront "identifies a distribution for a HTTP request based on the Host header" and explicitly does not depend on which CloudFront address you connected to or what SNI was offered. If the two disagree, it treats the request as domain fronting and answers 421 (CloudFront: Use custom URLs by adding alternate domain names (CNAMEs)). The practical consequence is this: the CNAME gets the packets to the edge. The certificate and the Host must both be in place before they arrive.

Switching providers is normally a matter of repointing that one alias. This is because a CNAME can redirect queries to any DNS record, and the target need not be hosted by your own DNS provider (Route 53 documentation). No address records change hands. The TTL on the CNAME bounds how long resolvers keep serving the old provider.

What CDNs do

• Cloudflare: you point a CNAME at the assigned target. Proxied records are flattened by default because they return Cloudflare's anycast addresses. Flattening also happens by default on every plan when the zone apex uses a CNAME. Flattening all CNAME records is an opt-in for zones on paid plans. Paid zones can also flatten individual records (Cloudflare: Set up CNAME flattening).
• AWS Route 53: as your DNS host, it will not create a CNAME with the same name as the hosted zone. A CNAME-type alias at the apex is unsupported too. An alias record at the apex is allowed, including one targeting a CloudFront distribution. That alias record then answers with CloudFront edge addresses. Alias queries to AWS resources are not charged. CNAME queries are (Route 53: Choosing between alias and non-alias records).
• AWS CloudFront: each distribution gets a name such as d111111abcdef8.cloudfront.net. To serve your own hostname, you add it as an alternate domain name (CNAME). CloudFront requires a trusted, valid TLS certificate covering that name, attached to the distribution first (CloudFront: Use custom URLs by adding alternate domain names (CNAMEs)).
• Fastly: point the CNAME at the hostname Fastly gives you. With Fastly TLS, the value takes the form <letter>.sni.global.fastly.net, taken from the certificate's DNS details in the control panel. Non-TLS traffic uses a shared hostname such as dualstack.nonssl.global.fastly.net. That shared hostname refuses port 443 outright. A CNAME cannot be used at all if you intend to serve Fastly on your apex domain (Fastly: Working with CNAME records and your DNS provider).

Watch out for

• Nothing else fits on the name. A host that must carry MX or TXT records (mail, SPF, DKIM) cannot also be a CNAME. A query for any of those types against the alias comes back as the CNAME instead (RFC 2181 section 10.1; RFC 1912 section 2.4).
• Never point an NS or MX record at an alias. The name used as an NS value, or inside an MX value, must not be an alias. It must resolve to address records. Additional-section processing does not follow CNAMEs. So using one there costs an extra query on every lookup (RFC 2181 section 10.3).
• A missing target poisons the lookup, and the failure is cached. If the final target does not exist, the response is NXDOMAIN, with the CNAME still in the answer section. The NXDOMAIN refers to the target, not to your alias. The negative answer is cached with a TTL taken from the minimum of the SOA's MINIMUM field and the SOA's own TTL (RFC 2308 section 2.1; section 5).
• A target that exists but has no addresses is a different failure: NODATA rather than NXDOMAIN. Cloudflare's flattening returns exactly that: "If the final CNAME target has no A/AAAA records (a dangling CNAME), CNAME flattening returns an empty response (NODATA)". This looks like a record failing to propagate (Cloudflare: CNAME flattening).
• A CNAME left pointing at a decommissioned CDN or cloud hostname is a security bug, not just dead weight. Such dangling DNS entries let someone else claim the target name and serve content under your domain. CNAME records are especially exposed to this (Microsoft: Prevent dangling DNS entries and avoid subdomain takeover).
• The CNAME provisions no TLS by itself. Until the hostname is registered with the CDN and covered by a certificate, traffic that arrives fails the handshake rather than the lookup (CloudFront documentation).
• Chains cost. Every extra link is another lookup and another thing to break. That is why multiple levels of aliasing are to be avoided, even though resolvers must tolerate them (RFC 1034 section 5.2.2).

Best practice

• Use a dedicated subdomain for CDN traffic, and keep the apex out of it. That way the alias never collides with mail or verification records (RFC 2181 section 10.1).
• Point the CNAME at exactly the hostname the provider assigns. Add the domain to the CDN configuration. Attach a certificate covering it before you cut traffic over (CloudFront documentation; Fastly documentation).
• Stage the cutover through the TTL. Lower the CNAME's TTL to a small value; Fastly suggests 60 seconds. Wait for the old TTL to expire, then repoint. Raise the TTL again once the new provider is proven. That window is also your rollback (Fastly: Working with CNAME records and your DNS provider).
• At the apex, reach for an apex-safe substitute rather than hand-maintained address records. Options include a Route 53 alias record, Cloudflare flattening, or an HTTPS/SVCB record in AliasMode (Route 53 documentation; RFC 9460 section 2.4.2).
• Delete the CNAME when you retire what it points at. Stale aliases are both a waste and the entry point for a subdomain takeover (RFC 1912 section 2.4; Microsoft: Prevent dangling DNS entries).
• Check the result after every change. Fastly's own instruction is dig with +short. The output should show the provider hostname first, then its address. If it does not, the record is wrong, or an old answer is still cached (Fastly: Working with CNAME records and your DNS provider).