DNS Records & Concepts
What is a CNAME record?
A CNAME record, Canonical Name record, is a DNS record that maps one domain name to another domain name rather than directly to an IP address. Instead of pointing www.example.com to a specific server IP address, a CNAME points it to another domain name: proxy.redirect.supply, for example, and the DNS system follows that alias to find the actual IP address.
The word canonical in the record’s name is significant. The CNAME establishes that one domain name is an alias for another: the target domain is the canonical name, the authoritative address where the real DNS information lives. The CNAME is just a pointer to that canonical name. When a resolver encounters a CNAME it does not stop; it follows the alias to the target domain and looks up the IP address there.
CNAME records are the most common way to connect domains and subdomains to third-party services: CDNs, hosting platforms, email services, and redirect management infrastructure. Rather than requiring domain owners to know and configure specific IP addresses, which change when infrastructure changes, a CNAME points to a stable hostname that the service controls. When the service updates its servers the IP addresses change but the hostname stays the same. The CNAME continues to work without any update required.
How a CNAME record works
When a browser or DNS resolver looks up a domain with a CNAME record the resolution process involves an additional step compared to an A record lookup.
A resolver looking up www.example.com queries the authoritative nameserver for example.com. The nameserver returns a CNAME record pointing to proxy.redirect.supply. The resolver does not stop here, a CNAME is not an IP address and cannot be used to establish a network connection directly. The resolver must follow the alias.
The resolver then queries the authoritative nameserver for proxy.redirect.supply and retrieves its A record, an IPv4 address, or AAAA record, an IPv6 address. That IP address is returned to the browser. The browser connects to the server at that IP address, which is the redirect management infrastructure. The server receives the request and applies the configured HTTP redirect rules.
From the visitor’s perspective this is entirely invisible, the domain resolves to an IP address and the page loads or the redirect fires. The intermediate CNAME step happens within the DNS resolution and adds no perceptible delay because resolvers cache both the CNAME and the target’s IP address for their respective TTL durations.
CNAME record format and values
A CNAME record has a straightforward format. The name is the domain or subdomain being aliased. The value is the target domain: the canonical name the alias points to.
This record says that www.example.com is an alias for proxy.redirect.supply. Any lookup for www.example.com follows the CNAME to proxy.redirect.supply and resolves to whatever IP address proxy.redirect.supply currently points to.
CNAME values must be fully qualified domain names, complete domain names including the top-level domain. In DNS management interfaces the trailing dot is often implicit: proxy.redirect.supply rather than proxy.redirect.supply.; but the DNS specification technically requires the trailing dot to indicate an absolute rather than relative domain name.
CNAME records cannot contain IP addresses. A CNAME value must always be a domain name. Attempting to enter an IP address as a CNAME value is a configuration error.
CNAME records cannot coexist with other record types for the same name, with one important exception. A TXT record can coexist with a CNAME for the same name in some DNS implementations, and MX records cannot coexist with CNAMEs at all. This restriction exists because a CNAME is an alias for the entire name, having both a CNAME and an MX record for the same name would be contradictory since the CNAME says “look up the target for all record types” while the MX says “here is a specific record for this name.”
The apex domain restriction
The most important practical limitation of CNAME records is that they cannot be used at the zone apex, the root domain without any subdomain prefix. www.example.com can have a CNAME. example.com cannot.
This restriction is defined in the DNS specification and exists because the zone apex must have NS records and SOA records, the records that define the zone’s authoritative nameservers and administrative information. A CNAME at the apex would conflict with these required records because a CNAME declares that the name is an alias for another name, meaning all record types for that name should be looked up at the target. NS and SOA records must exist directly at the apex rather than being aliased.
This restriction creates a practical challenge for connecting root domains to services that only provide a hostname rather than a fixed IP address. Several workarounds exist depending on what the DNS provider supports.
ALIAS / ANAME records, non-standard record types offered by some DNS providers that provide CNAME-like behaviour at the apex. The provider resolves the target hostname to its current IP addresses at query time and returns an A-record-style response. From the outside it looks like an A record. Internally it behaves like a CNAME, following the alias to whatever IP addresses the target currently uses.
Cloudflare CNAME flattening, Cloudflare automatically flattens CNAME records at the apex. A CNAME configured for the root domain is resolved to its target’s IP address by Cloudflare’s nameservers before the response leaves their infrastructure. The resolver receives an A record response rather than a CNAME, compliant with the DNS specification while providing the alias behaviour of a CNAME.
A records with stable IP addresses, some redirect management services and CDNs, including Cloudflare’s proxied infrastructure, provide stable IP addresses that can be configured as A records for root domains. This works when the infrastructure IP addresses do not change, but requires updating the A record if the service ever changes its IP addresses.
Redirecting the apex to www, some domain configurations redirect all root domain traffic to www.example.com using server-level redirect rules and configure only the www subdomain as a CNAME. This avoids the apex restriction by making the root domain a simple redirect to the www subdomain where the CNAME is configured.
CNAME chains
A CNAME can point to another domain that itself has a CNAME, creating a chain of aliases that the resolver must follow to find the final IP address.
The resolver follows www.example.com → shop.example.com → stores.platform.com → 104.21.30.120. This is a three-step chain before the IP address is found.
CNAME chains add latency to DNS resolution because each link in the chain may require an additional DNS query if the intermediate values are not cached. They also add complexity to DNS troubleshooting, diagnosing a broken CNAME requires checking every link in the chain.
Most DNS specifications and best practices recommend keeping CNAME chains short, ideally a single CNAME pointing directly to the final target’s A record rather than through intermediate aliases. The maximum number of CNAME redirects a resolver will follow before stopping, to prevent infinite loops, is typically eight, but reaching even three or four links is a sign of unnecessary complexity.
CNAME records and redirect management
CNAME records are the standard method for connecting domains and subdomains to redirect management infrastructure. The connection works in two layers, the DNS layer that routes requests to the redirect service’s servers, and the HTTP layer where redirect rules are applied.
Connecting www subdomains, the most common connection setup. Adding a CNAME record for www.yourdomain.com pointing to the redirect management service’s hostname routes all requests for the www subdomain to the service’s servers. When requests arrive the service applies configured redirect rules, 301s, 302s, wildcard patterns, and returns the appropriate HTTP redirect response with a Location header.
Domain verification via CNAME, many redirect management services and CDNs use CNAME records for domain ownership verification. The service provides a specific CNAME record, name and target value, that the domain owner adds to their DNS. The service checks for the presence of this record to confirm the domain owner has authorised the connection. This is similar to TXT record verification but using a CNAME instead.
SSL certificate provisioning via CNAME, some certificate authorities and platforms use CNAME records as part of the DNS validation process for SSL certificate issuance. The domain owner adds a CNAME record specified by the certificate authority pointing to a validation hostname. The authority verifies the record exists and issues the certificate. This approach allows the certificate authority to perform continuous validation without requiring the domain owner to update a TXT record at each renewal, the CNAME stays in place and the validation hostname it points to handles renewals automatically.
Subdomain takeover risk, an important security consideration with CNAME records is subdomain takeover. If a CNAME is configured for a subdomain pointing to a third-party service, shop.example.com CNAME stores.platform.com, and the service account associated with stores.platform.com is deleted or expired, the CNAME may point to an unclaimed hostname that anyone could register. If an attacker registers that hostname on the platform they effectively take over shop.example.com because the CNAME routes all traffic there. Removing CNAME records for subdomains when they are no longer in use prevents this.
CNAME records and email
CNAME records cannot be configured for domains that also need to receive email, specifically they cannot coexist with MX records for the same name. This is a technical restriction based on how DNS resolves CNAME aliases.
In practice this means a CNAME cannot be set on example.com if example.com also has MX records for email delivery. The CNAME would make the apex an alias for another domain and the MX records would be contradictory.
For email-enabled domains the standard approach is to avoid CNAME records at the apex entirely. The root domain is configured with A records for web traffic and MX records for email independently. CNAME records are used only for subdomains that do not need MX records, www.example.com, shop.example.com, and others.
Checking CNAME records
CNAME records can be inspected using the same tools as other DNS record types.
dig command, on Linux and macOS:
Returns the CNAME record for www.example.com showing the target domain name and TTL. To follow the full chain and see the final IP address:
Without specifying a record type dig follows CNAME chains automatically and shows both the intermediate CNAME records and the final A record.
nslookup, on Windows and other platforms:
Online DNS lookup tools, web-based tools show CNAME records and often visualise chains, showing each step from the queried name through intermediate CNAMEs to the final IP address. Useful for verifying that CNAME configurations are correct and checking propagation across different geographic locations.
Checking propagation, after adding or changing a CNAME record the change propagates according to the record’s TTL. Querying the authoritative nameserver directly, dig @ns1.registrar.com www.example.com CNAME, shows the current value on the nameserver regardless of what resolvers have cached. Querying a public resolver like 8.8.8.8 shows what most visitors will see after propagation.
Common CNAME mistakes
CNAME at the apex, attempting to set a CNAME for the root domain. The DNS specification prohibits this. Use A records, ALIAS/ANAME records, or Cloudflare CNAME flattening for apex domains.
CNAME coexisting with MX records, configuring a CNAME for a name that also has MX records breaks email delivery. Remove the CNAME or use A records instead for domains that handle email.
Long CNAME chains, multiple CNAMEs pointing to other CNAMEs before reaching a final A record. Each link adds latency and complexity. Simplify chains to a single CNAME pointing directly to the target’s A record where possible.
Forgetting to remove stale CNAMEs, CNAME records pointing to decommissioned services or expired accounts create subdomain takeover vulnerabilities. Audit and remove CNAMEs for services no longer in use.
CNAME pointing to a non-existent target, a CNAME pointing to a domain that has no A record, the service’s domain was changed or the account was deleted, causes DNS resolution to fail. All visitors receive a DNS error rather than a redirect response. Verify the CNAME target resolves to a valid IP address after configuration.