A CNAME is a type of Domain Name System record that connects one hostname to another hostname. Instead of storing an IP address directly, it tells DNS resolvers that the requested name is an alias of a different, canonical name. The resolver can then continue the lookup until it finds the final address.
For example, a business might configure www.example.com as a CNAME pointing to example.com. Visitors can use the familiar www address, while the actual IPv4 or IPv6 address remains attached to the canonical hostname. This makes the DNS configuration easier to manage when several names should reach the same service.
CNAME records are widely used with websites, content delivery networks, hosted applications, ecommerce platforms and software-as-a-service tools. A provider may ask you to point a subdomain such as shop.example.com or portal.example.com towards a hostname that it controls rather than towards a fixed IP address.
Although a CNAME record looks simple, incorrect configuration can affect websites, email services and domain verification. Understanding canonical names, TTL values, DNS caching, root-domain limitations and record conflicts can help you use CNAME records without creating unnecessary downtime or security risks.
What Does CNAME Mean?
CNAME stands for canonical name. In DNS terminology, the canonical name is the hostname that the alias ultimately represents. The CNAME record creates the relationship between the alias entered by a user and the destination hostname where the lookup should continue.
Suppose blog.example.com is configured as an alias of hosting.provider.net. In this arrangement, blog.example.com is the owner or alias name, while hosting.provider.net is the canonical target. The target should then resolve through an A, AAAA or another supported DNS path.
People often refer to the alias itself as “the CNAME,” although this language can cause confusion. Technically, CNAME is the record type, while the name on the left is the alias and the value on the right is the canonical destination. Understanding the difference makes DNS instructions easier to follow.
A CNAME does not contain website files, transfer visitors by itself or replace web hosting. It only provides DNS-level name mapping. The web server, content delivery network or hosted platform must still recognise the requested hostname and be configured to serve the correct content.
A Simple CNAME Record Example
A standard CNAME entry may appear as www.example.com. 3600 IN CNAME example.com. in a traditional zone file. The first value is the alias hostname, while 3600 is the time to live. IN identifies the internet class, and the final hostname is the canonical target.
Many DNS dashboards simplify this entry into separate fields. You might enter www in the Name or Host field, select CNAME as the record type and enter example.com in the Target or Value field. The provider automatically completes the full domain name where necessary.
The final period in a fully qualified domain name tells traditional DNS software that the name is complete. Without it, some zone-file systems may append the current domain automatically. Web-based DNS dashboards commonly handle this detail for you, but the behaviour depends on the provider.
After the record is published, a request for www.example.com follows the CNAME to example.com. The resolver then looks for the destination’s address records and returns the resulting IP address to the requesting device. The browser can then connect to the appropriate server.
How Does a CNAME Record Work?
When someone enters a hostname into a browser, the device asks a recursive DNS resolver for the required address. The resolver checks its cache first. When no usable answer is available, it queries the authoritative DNS system responsible for the requested domain.
If the authoritative server returns a CNAME, the answer says that the original hostname is an alias of another hostname. The resolver then changes its lookup target to the canonical name. It continues resolving that name until it reaches the final A or AAAA address record.
The resolver may receive both the CNAME and the target’s address in one response when the authoritative infrastructure has enough information. In other situations, it must perform one or more additional queries. The exact process depends on where the destination is hosted and what data is available.
Once the lookup is complete, the resolver caches the information according to the applicable TTL values. Future requests can then use the cached response until it expires. This reduces the number of DNS queries and helps users reach the service more efficiently.
What Is a Canonical Name in DNS?
A canonical name is the hostname treated as the destination of an alias relationship. It does not necessarily mean that the destination is the only official name a server can have. DNS can support several names and records for the same infrastructure, depending on how the service is designed.
For instance, a content delivery network might provide the target customer.cdn-provider.net. Your public hostname, such as images.example.com, becomes an alias of that provider-controlled name. The provider can change the underlying IP addresses without asking you to edit your CNAME each time.
The canonical target should generally be a valid hostname that resolves properly. Pointing a CNAME towards a nonexistent or retired destination creates a dangling CNAME. Users may receive resolution errors, and the abandoned mapping may introduce a security risk with some external services.
The destination should be entered as a hostname rather than an IP address. An IP address belongs in an A or AAAA record, not in the target field of a CNAME. Using the wrong value may cause the DNS provider to reject the record or publish an unusable configuration.
CNAME vs A Record
An A record maps a hostname directly to an IPv4 address. For example, example.com might have an A record pointing to 192.0.2.20. The DNS resolver can return that address without following an alias to a separate hostname.
A CNAME record maps a hostname to another hostname instead of mapping it directly to an address. For example, store.example.com might point to merchant.platform.net. The resolver must then find the address records associated with the platform hostname.
A records are appropriate when you control a stable IPv4 address or when a service specifically provides one. CNAME records are more useful when an external provider controls the destination and may change its infrastructure without changing the hostname supplied to customers.
One type is not universally better than the other. The correct choice depends on the value supplied by the hosting platform and the location of the record. If the instructions provide an IP address, use an A record; if they provide a hostname for a subdomain, a CNAME is often appropriate.
CNAME vs AAAA Record
An AAAA record performs a role similar to an A record but stores an IPv6 address. IPv6 addresses are longer and use hexadecimal notation, such as 2001:db8::20. A device can use the returned address to connect to an IPv6-enabled service.
A CNAME does not specify whether the final connection will use IPv4 or IPv6. It redirects the DNS lookup to another hostname, which may have an A record, an AAAA record or both. The client and network can then select an available address.
This flexibility is useful when a platform manages both address families. You can point a subdomain towards the provider’s hostname while the provider updates its IPv4 and IPv6 infrastructure. Your CNAME does not need to change whenever those address records are updated.
However, the final destination must have usable address data for the client’s requirements. A target with only an A record may not provide native IPv6 resolution, while a target with only an AAAA record may be inaccessible from some IPv4-only environments without additional network support.
CNAME Record vs URL Redirect
A CNAME record and a URL redirect operate at different layers. A CNAME changes how a hostname is resolved through DNS, while a redirect sends an HTTP response after a browser has already reached a web server. These methods are not interchangeable.
When blog.example.com is a CNAME of platform.example.net, the browser may continue displaying blog.example.com in the address bar. The hosting platform receives the request and must be configured to recognise that custom hostname and deliver the correct website.
With a 301 or 302 redirect, the server instructs the browser to request a different URL. The address bar normally changes to the destination, and the redirect can include a path, protocol or complete webpage address. DNS records cannot redirect individual pages or URL paths.
Use a CNAME when a hosting provider needs a subdomain mapped to its infrastructure. Use an HTTP redirect when visitors should be forwarded visibly to another web address. Some registrars advertise “URL forwarding” beside DNS tools, but it is a separate hosted service rather than a CNAME function.
Common Uses of CNAME Records
One common use is connecting the www version of a website to its main hostname. Instead of maintaining separate IP records for www.example.com and another destination, the administrator can make www an alias and manage the address records in one central location.
CNAME records are also used to connect custom subdomains to ecommerce stores, blogging platforms and website builders. The provider supplies a target hostname, and the domain owner creates an alias such as shop.example.com. The platform then verifies and serves the custom domain.
Content delivery networks frequently use CNAME records for static files, images and application traffic. A hostname such as cdn.example.com can point to a provider-managed endpoint. The provider can distribute requests across its global infrastructure without exposing fixed addresses to the customer.
Businesses may also use CNAMEs for support portals, status pages, analytics services and domain ownership checks. In verification scenarios, the provider normally supplies a unique target value. The record proves that the user can modify DNS for the domain or subdomain.
Can You Use a CNAME on the Root Domain?
A standard CNAME should not be placed at the root or zone apex of a domain. The apex is the bare domain, such as example.com, without a prefix like www. It must already contain essential records, including the SOA and NS data required for the DNS zone.
A traditional CNAME owner name cannot coexist with most other DNS record types. Creating one at the apex would conflict with the mandatory zone records. This is why many DNS dashboards prevent users from selecting CNAME when the Host field is @ or left blank.
The limitation can become confusing when a website platform asks users to point the root domain towards a hostname. The platform may expect the DNS provider to support an ALIAS, ANAME, flattening or provider-specific virtual record instead of a standards-based CNAME at the apex.
Always follow instructions written for your DNS provider rather than assuming every dashboard supports the same features. Some services synthesise A and AAAA responses for apex aliases, while others require fixed address records or recommend redirecting the root domain towards a www subdomain.
What Are ALIAS and ANAME Records?
ALIAS and ANAME records are provider-specific features designed to offer CNAME-like behaviour where a traditional CNAME cannot be used. They are commonly placed at the zone apex and configured with a hostname target instead of a manually entered IP address.
These records are not one universal standard implemented identically by every DNS platform. The authoritative provider usually resolves the target internally and returns synthesised A or AAAA answers to the requesting resolver. The client may never see a CNAME in the response.
An ALIAS can be helpful when the destination provider changes IP addresses regularly. Rather than copying those addresses into the root-domain records, you point the apex towards the supplied hostname. The DNS service then keeps resolving that hostname according to its own implementation.
Before using an ALIAS or ANAME, review the provider’s limitations. Support for DNSSEC, target types, health checks, TTL handling and external destinations can differ. A record exported from one DNS provider may also be incompatible with another because ALIAS and ANAME behaviour is platform-specific.
What Is CNAME Flattening?
CNAME flattening is a DNS-provider feature that resolves a CNAME target on behalf of the requesting client. Instead of returning the visible CNAME relationship, the authoritative service follows the target and responds with the resulting A or AAAA addresses.
Flattening is commonly used at the zone apex, where a standard CNAME would conflict with required records. Some providers also allow customers to flatten selected subdomain CNAMEs or every CNAME in a zone. The available settings and limitations depend on the platform.
The feature can reduce the number of lookups visible to the client, but it also changes how certain DNS checks see the record. A third-party service expecting to find the original CNAME may instead receive only an address response when flattening is enabled.
Use flattening only when it supports the intended configuration. It is particularly important to review the setting during domain verification and email troubleshooting. A verification provider may require the literal CNAME relationship rather than a synthesised result created by the DNS host.
Can a CNAME Exist With Other DNS Records?
A hostname configured as a CNAME generally cannot also hold A, AAAA, MX, TXT or other ordinary resource records. The alias is supposed to direct resolution to the canonical hostname, and combining it with separate data could create contradictory answers.
For example, you should not configure portal.example.com with both a CNAME pointing to a hosted platform and an A record pointing to your own server. One record says the name is an alias, while the other treats it as a direct host with its own address.
This rule also affects domain verification. If a provider asks you to create a CNAME at a name that already contains a TXT record, you may need a different verification label. Deleting an existing record without understanding its purpose could interrupt another service.
Before adding a CNAME, search the DNS zone for records with the same exact host value. Similar-looking names are separate, so www.example.com does not conflict with shop.example.com. The conflict occurs when different record types share the identical owner name.
How TTL Affects CNAME Records
TTL stands for time to live and tells caching resolvers how long they may store a DNS answer. A CNAME with a TTL of 3,600 seconds may remain cached for up to one hour before the resolver needs to request updated information.
A longer TTL can reduce DNS query volume and provide efficient caching, but changes may take longer to reach users. A shorter TTL allows updates to be noticed sooner, although it increases the number of lookups reaching authoritative DNS infrastructure.
CNAME resolution may involve several TTL values because the alias and final address records are separate. A resolver can cache each part of the chain according to its own TTL. Updating the CNAME does not instantly remove older data already stored by recursive resolvers.
Before a planned migration, administrators often reduce the TTL in advance. After the shorter value has been active long enough for previous caches to expire, the target can be changed with a smaller transition window. The TTL can be raised again after the new service is stable.
How Long Do CNAME Changes Take?
CNAME updates often appear quickly, but there is no single universal propagation time. The result depends on the previous TTL, recursive resolver caches, authoritative server updates and the DNS provider’s publishing process. Some users may see the new value before others.
When creating a completely new hostname, there may be no older positive record stored in caches. However, resolvers can also cache a previous “record does not exist” response. This negative caching may briefly affect a newly created CNAME.
Editing an existing CNAME can take longer when the old value had a high TTL. Resolvers that cached the previous target may continue using it until that timer expires. Clearing your browser cache does not necessarily clear the recursive DNS cache used by your network.
Test the record through several resolvers and authoritative name servers before assuming that publication has failed. Confirm that you edited the active DNS zone, not an old dashboard or registrar account whose name servers are no longer authoritative for the domain.
What Is a CNAME Chain?
A CNAME chain occurs when one alias points to another alias, which points to another hostname. For example, store.example.com may point to customer.platform.net, which then points to regional.platform.net before the resolver reaches an address record.
DNS resolvers can normally follow a short, valid chain, but every additional step may require another query. This can increase lookup time, create more points of failure and make troubleshooting harder. Long chains are therefore best avoided when a direct target is available.
A chain also introduces multiple TTLs and administrative boundaries. One provider may change its alias without your knowledge, or an intermediate hostname may stop resolving. Your own record can remain unchanged while the final website still becomes unavailable.
Review CNAME chains with tools such as dig, nslookup or an online DNS diagnostic service. When you control the intermediate names, simplify the path by pointing the public alias towards the most appropriate stable destination recommended by the service provider.
What Is a CNAME Loop?
A CNAME loop occurs when aliases eventually point back to a name already present in the same lookup path. For example, a.example.com points to b.example.com, while b.example.com points back to a.example.com.
Because neither name leads to an A or AAAA record, the resolver cannot complete the lookup. It eventually stops following the chain and returns an error. Visitors may see a DNS-resolution failure even though both CNAME records appear to exist.
Loops can be introduced during migrations when administrators update several related aliases without mapping the complete dependency chain. They can also occur when two teams manage different DNS zones and each assumes the other hostname is the final destination.
To fix the problem, identify the intended canonical host and make sure the alias chain ends at a valid address record. Remove unnecessary intermediate CNAMEs and verify the result from the authoritative servers before waiting for recursive caches to update.
Can CNAME Records Be Used for Email?
A CNAME can support certain email-related services when a provider specifically requests one. Email platforms may use CNAME records for domain verification, tracking links, DKIM key delegation, automatic configuration or branded webmail hostnames.
However, a CNAME is not a direct replacement for an MX record. MX records identify the mail servers responsible for receiving messages for a domain. The MX target should be a proper hostname with its own address records rather than an alias that depends on a CNAME.
You should also avoid placing a CNAME at a hostname that needs TXT records for SPF, DKIM or verification. Because the CNAME owner cannot normally coexist with those records, the configuration may prevent you from publishing essential email authentication data at that same name.
Follow the email provider’s instructions exactly, including dots, prefixes and target values. Do not shorten an unfamiliar hostname or point a CNAME at the provider’s website address. The required target may belong to specialised mail infrastructure rather than the company’s public homepage.
How to Create a CNAME Record
Sign in to the platform currently hosting your authoritative DNS zone. This may be your domain registrar, web host, cloud provider or a separate managed DNS service. Confirm the active name servers before making changes so you do not edit an unused zone.
Open the DNS-management section and choose to add a new record. Select CNAME as the record type, then enter the subdomain label in the Name or Host field. To create shop.example.com, many dashboards require only shop.
Enter the complete destination hostname in the Target, Value or Points to field. Do not include https://, a page path or a trailing slash. A CNAME accepts a DNS hostname such as customer.platform.net, not a complete URL such as https://platform.net/store.
Choose an appropriate TTL or leave the provider’s automatic setting when you have no special migration requirement. Save the record, wait for the DNS platform to publish it and then confirm that the destination service has also been configured to accept your custom hostname.
How to Check a CNAME Record
The dig command provides a clear way to inspect DNS records on Linux, macOS and other supported environments. Running dig CNAME www.example.com requests the CNAME record for that exact hostname and displays the returned value, TTL and response status.
The nslookup command is widely available on Windows and other operating systems. You can run nslookup -type=CNAME www.example.com to request the alias. Depending on the resolver and response, the output may also show the canonical target or resulting address.
For deeper troubleshooting, query the authoritative name server directly. This helps distinguish a publishing problem from stale recursive caching. First identify the domain’s current NS records, then send the CNAME query to one of those authoritative servers.
Check the final target as well as the original alias. A correct CNAME is not enough when the destination returns NXDOMAIN or has no usable A or AAAA records. DNS can be configured correctly at the first step while the complete chain still fails.
Common CNAME Problems
A common problem is entering a complete URL instead of a hostname. DNS does not understand protocols, directories or query strings inside a CNAME value. Remove https://, /page and any other URL components, leaving only the destination domain name.
Another frequent issue is adding the full hostname to a dashboard that automatically appends the domain. Entering www.example.com may accidentally create www.example.com.example.com. Review the final record shown by the platform after saving it.
Record conflicts can also prevent creation. The selected host may already contain an A, AAAA, TXT or MX record, making it unsuitable for a CNAME. Find out what the existing data supports before deleting it or choose a separate subdomain for the new service.
The record may also be published in the wrong DNS account. Domains are sometimes registered with one company while authoritative DNS is hosted elsewhere. Compare the live name servers with the platform you are editing to confirm that changes can actually reach public DNS.
CNAME Records and SSL Certificates
A CNAME record only directs DNS resolution; it does not automatically create or install an SSL certificate. The destination platform must issue or accept a certificate containing your custom hostname before browsers can establish a trusted HTTPS connection.
After adding the CNAME, many hosted services ask you to verify the domain and wait while they provision a certificate. The website may resolve before HTTPS becomes ready. Visiting it too early can produce a certificate-name mismatch or security warning.
The destination server must also recognise the original hostname sent by the browser. A CNAME does not replace shop.example.com with the provider hostname inside the web request. The hosting platform must map that custom domain to the correct account or application.
Avoid creating manual redirects as a substitute unless the provider recommends them. The cleanest process is normally to add the exact DNS record, register the custom hostname in the hosting dashboard and allow the platform to complete ownership validation and certificate issuance.
CNAME Records and DNSSEC
DNSSEC adds cryptographic signatures that allow validating resolvers to confirm that DNS answers have not been altered. A CNAME can exist in a DNSSEC-signed zone and participate in a properly validated chain of DNS responses.
Problems can occur when the alias target has a broken DNSSEC configuration. The CNAME itself may be correctly signed, but the resolver still needs to obtain the target’s address records. Validation failure at a later point can make the entire lookup return an error.
Provider-specific ALIAS and flattening services may have their own DNSSEC limitations because the authoritative service synthesises an answer after resolving another hostname. Review the DNS provider’s documentation before enabling both features in the same zone.
When troubleshooting unexpected SERVFAIL responses, compare results from validating and non-validating resolvers. Check the CNAME owner, target and final address records. A failure that appears to be a basic alias problem may actually come from an expired or incorrect DNSSEC signature.
Dangling CNAMEs and Subdomain Takeover
A dangling CNAME is an active DNS alias whose external destination has been deleted, released or disconnected from your account. The record continues directing users towards the old provider hostname even though you no longer control the underlying resource.
With some platforms, another person may be able to claim a new resource using that abandoned destination. They could then serve content through your trusted subdomain, creating a subdomain-takeover risk. The exact exploitability depends on the external service and its ownership controls.
Delete the DNS record before removing the cloud application, storage bucket, hosted page or third-party service it references. When immediate deletion is not possible, verify that the provider permanently reserves the destination or prevents it from being registered by another account.
Regularly inventory external CNAME targets and compare them with active services. Monitoring should identify targets that return NXDOMAIN, provider error pages or ownership warnings. Old marketing campaigns, test environments and discontinued software tools are common sources of forgotten records.
CNAME Best Practices
Use CNAME records primarily for subdomains that need to follow another hostname. Keep A and AAAA records for services that require direct IP mapping, and use an approved ALIAS or flattening feature when CNAME-like behaviour is needed at the zone apex.
Point each alias as directly as possible towards a stable destination. Avoid long CNAME chains, circular references and temporary hostnames. The target should be the exact value supplied by the platform responsible for the service.
Document every record’s purpose, owner and related application. This information makes future audits and migrations safer. A record that looks unused may still support domain validation, customer traffic, email tracking or an internal integration.
Review CNAMEs after changing hosting providers or retiring cloud resources. Remove abandoned aliases promptly, verify SSL certificates and test the complete lookup path. Good DNS maintenance protects availability while reducing the risk created by forgotten third-party dependencies.
Final Thoughts
A CNAME record allows one hostname to act as an alias of another hostname. It is useful when several subdomains should share a destination or when a hosted platform needs control over the final IP addresses without requiring customers to update DNS repeatedly.
The resolver follows the alias until it finds an address record that can be returned to the user’s device. This process is different from a URL redirect because the browser does not need to change the visible hostname. The destination service must still recognise and serve that custom domain.
CNAMEs work best on subdomains and cannot normally share their owner name with other record types. Standard CNAME records are not suitable for the root domain, although ALIAS, ANAME and CNAME-flattening features may provide provider-specific alternatives.
Create records carefully, use sensible TTL values and verify both the alias and its final target. Avoid unnecessary chains, email-related conflicts and dangling external records. A simple, documented DNS configuration is easier to operate, troubleshoot and secure.
Frequently Asked Questions
What Is a CNAME Record in Simple Terms?
A CNAME record makes one hostname an alias of another hostname. The DNS resolver follows the target name until it finds the final IP address needed to connect.
Is a CNAME the Same as an A Record?
No. An A record points directly to an IPv4 address, while a CNAME points to another hostname that must be resolved separately.
Can a CNAME Point to a URL?
No. A CNAME target must be a hostname without https://, page paths or query parameters. Use a web-server redirect when you need to forward a complete URL.
Can I Use a CNAME for My Root Domain?
A standard CNAME cannot be used at the zone apex because the root must contain other DNS records. Some providers offer ALIAS, ANAME or flattening instead.
How Long Does a CNAME Take to Update?
Changes may appear within minutes, but cached answers can remain until their TTL expires. The previous TTL and DNS provider’s publishing process influence the update time.
