What Is a CNAME Record?

A CNAME record covers a single hostname, most often a subdomain such as www or shop, and is created instead of an A record. Where an A record stores the IP address of a server, a CNAME record stores another domain name: the canonical name. That target can be a name in your own domain (www.example.com → example.com) or a hostname at another provider entirely (shop.example.com → shops.myshopify.com). The DNS resolver looks the new name up to find the actual address.

The payoff is simpler maintenance. When the server behind the canonical name gets a new IP address, only that one A record changes; every alias pointing at the name through a CNAME resolves to the new address automatically, with no edits to the CNAME records themselves.

Anatomy of a CNAME record

In standard zone-file notation, a complete CNAME record looks like this:

www.example.com. 3600 IN CNAME example.com.

Reading left to right: www.example.com. is the alias, the hostname the record answers for. In most DNS panels you enter only the prefix, www. 3600 is the TTL (time to live) in seconds: how long resolvers may cache the answer before asking again (an hour, in this case). IN is the record class, Internet. CNAME is the record type. example.com. is the canonical name the alias maps to. The target must always be a domain name, never an IP address; an IP belongs in an A record. The CNAME type was defined in RFC 1034, the 1987 specification that still governs how every resolver interprets it.

How a CNAME record resolves

A CNAME adds another name to the lookup, one the resolver must process before it can finish. The visitor's resolver queries the alias. The answer that comes back names the canonical hostname rather than giving an IP address, and resolution continues with that name until an A (or AAAA) record supplies an address to hand to the browser. That extra name doesn't always mean an extra query: the nameserver can include the target's records in the same response, and a resolver that already holds the target's address in cache uses it directly. Both the alias mapping and the final address are cached, so later visitors skip the extra work until the TTL runs out.

The consequence: each CNAME in the path is one more name to resolve, and it costs an additional query whenever the target's answer arrives neither alongside the CNAME nor from cache. One hop is normal; long chains multiply the chances of that extra round trip, which is why an alias should point as directly as possible at its final target.

CNAME record vs. A record

An A record maps a domain name to an IP address; a CNAME record maps one domain name to another domain name, which resolvers then follow until they reach the final IP.

• A record: holds the address itself (example.com. 3600 IN A 192.0.2.44), answers in a single lookup, and, together with its IPv6 counterpart the AAAA record, is the standard way to put an address at the root (apex) domain, where a CNAME isn't allowed.
• CNAME record: holds a hostname (www.example.com. 3600 IN CNAME example.com.), delegates the final answer to the target's own records, and may only exist on a name that carries no other records.

The decision rule follows from what the endpoint is. When you're given a hostname to point at, whether it's your own bare domain or a provider's name whose IP you'll never see, use a CNAME: the alias follows the target wherever its address goes, and the IP stays maintained in one place. When you need to publish a fixed IPv4 address, or you're configuring the apex and your DNS provider offers no ALIAS-style workaround, use an A record.

When to use a CNAME record

Reach for a CNAME whenever a hostname should follow another name rather than a fixed address. The most common scenarios:

• www to the bare domain: www.example.com CNAME example.com keeps both names on one A record, so the server's IP is maintained in exactly one place. Both names resolve to the same server, but they remain two separate URLs serving identical content, so add a 301 redirect (or a canonical URL) from one hostname to the other so visitors and search engines settle on a single name.
• A subdomain on a third-party platform: shop.example.com CNAME shops.myshopify.com hands the storefront's addressing to the platform. If it moves or renumbers its servers, the store keeps resolving with no DNS change on your side. Hosted status pages and help centers work the same way. The DNS record alone doesn't cover TLS, though: the platform must serve an SSL/TLS certificate valid for your alias hostname, and most platforms provision one automatically once you complete their domain-verification step. Until then, browsers show a certificate name-mismatch error even though the DNS is correct, so finish the provider's domain setup rather than stopping at the record.
• CDN hostnames: cdn.example.com CNAME example.cdnprovider.net puts the CDN's own DNS in charge of answering, so each request is routed to the edge location best placed to serve it, typically the nearest one in terms of latency, as Amazon CloudFront's documentation describes.
• Service verification: some providers confirm you control a domain by generating uniquely named CNAME records for you to publish. Twilio SendGrid, for example, authenticates a sending domain with generated CNAMEs that carry its SPF and DKIM email checks.

Why a CNAME can't sit at the root domain

A CNAME cannot be placed on the root (apex) domain itself. DNS rules forbid a CNAME from coexisting with any other record for the same name, and the apex must carry the zone's SOA and NS records (usually MX records for email, too), so a CNAME there breaks the zone. ISC's BIND 9 nameserver won't allow a CNAME at the zone apex at all because, as ISC explains, it would create a broken zone and cause DNS resolution failures.

To alias the bare domain anyway (example.com itself following a provider's hostname), use the ALIAS, ANAME, or “CNAME flattening” options some DNS providers offer, or place an ordinary A record at the apex with the provider's published IP.

Common CNAME mistakes

Four misconfigurations cause most CNAME trouble:

• A CNAME beside other records. Because a CNAME can't share its hostname with any other record type, adding one to a name that already carries MX or TXT records silently breaks email delivery and domain verification at that name. Move the alias to a different hostname, or use an A record instead.
• A CNAME pointing at an IP address. The record's target must be another hostname; an IP address is never valid CNAME data. If what you have is an IP, create an A record instead.
• Chains and loops. A CNAME may point at another CNAME, but each link is one more name to resolve, and often one more query when nothing is cached. A loop (a.example.com → b.example.com → a.example.com) breaks resolution entirely. Point each alias straight at the final hostname wherever you can.
• A dangling CNAME. An alias left pointing at a third-party service you've shut down keeps resolving toward the provider, and on platforms where a freed resource name can be claimed by any new customer, whoever claims it controls what your subdomain serves. Microsoft documents this “dangling DNS” problem as the root of subdomain takeover attacks, which are used for phishing and cookie harvesting. Remove the CNAME before or immediately after deprovisioning the service, audit your zone's third-party targets periodically, and check how each provider handles unclaimed hostnames.

How to add a CNAME record

Open the DNS management area at whichever company hosts your DNS, usually your registrar or web host; if the domain points at another company's nameservers, that company's panel is where the records live. Add a new record, set its type to CNAME, enter the subdomain prefix (such as www or shop) in the host field, enter the target hostname as the value, set a TTL, and save. In the DreamHost panel, DNS records live on the Manage Websites page: open the site's menu, click DNS Settings, then Add Record.

To confirm what you published, look the name up: dig www.example.com CNAME +short on macOS or Linux, or nslookup -q=cname www.example.com on Windows, should print the canonical name you entered. An online DNS-lookup tool does the same job without a terminal. If the lookup shows the right target but your browser still gets the old answer, you're waiting on cache, not fixing a broken record.

Your DNS host starts answering for a brand-new alias as soon as the record is published. One caveat: a resolver that looked the name up before the record existed may keep returning its cached “no such name” (NXDOMAIN) answer until the zone's negative-cache TTL runs out. That negative caching is standardized in RFC 2308. Changes to an existing record reach visitors as cached copies expire, a wait known as propagation, governed by the record's TTL.