What Is a CNAME Record? How to Point One DNS Name to Another
Understand CNAME records, compare CNAME with A, choose the right website record, and diagnose apex, target, and HTTPS problems.
- domains
- dns
- guide
A CNAME record makes one DNS name an alias of another name. Use a CNAME when your hosting service supplies a hostname as the destination. Use an A record when the service supplies an IPv4 address. The DNS standard defines the alias relationship.
For a website, the provider's supported configuration decides the final choice. A CNAME does not create a website, install a certificate, or redirect a browser. Start with the exact hostname you want visitors to use and the destination shown in your hosting account.
Examples use reserved domain names and documentation IPv4 addresses.
A CNAME stores a hostname while an A record stores an address
Consider these hypothetical records. The names and addresses illustrate syntax, rather than an operational service.
| Name | Record type | Value | Meaning |
|---|---|---|---|
app.example.com | A | 192.0.2.20 | Obtain an IPv4 address directly |
www.example.com | CNAME | site.example.net | Continue resolution at another name |
An A record contains an IPv4 address. A name can have multiple A records. RFC 1035 specifies the address format.
The CNAME owner is the alias. The value identifies the canonical target. For an address query, DNS resolution follows the target to obtain the requested data. A query asking specifically for CNAME data can return the alias record itself. RFC 1034 describes both behaviors.
The distinction matters when a hosting provider changes infrastructure. A supported target hostname lets the provider maintain the addresses behind the target. As practical advice, avoid copying a temporary address from that target into an A record. Follow the provider's instructions instead.
Neither record accepts an entire web address. A CNAME value should not contain https://, a port, or /pricing. Use the provider's hostname field exactly as documented. If the goal involves a different page path, consult the domain forwarding guide.
The zone apex needs a different decision from a subdomain
The zone apex is the zone's top name, such as example.com. The apex needs SOA and NS records for zone administration. RFC 1034 describes those required zone records.
An ordinary CNAME cannot coexist with other ordinary data at the same name. The apex requirement therefore conflicts with a standard CNAME. A separate name such as www.example.com can use a CNAME when no conflicting records occupy that name. The CNAME rule explains the restriction.
Some DNS providers offer an apex alias feature. Cloudflare calls its mechanism CNAME flattening. Cloudflare resolves the target and returns the resulting address instead of the CNAME record. Cloudflare documents that response behavior.
Treat ALIAS, ANAME, and flattening labels as provider features that need provider documentation. Do not assume a field labeled CNAME creates identical public answers everywhere. For an apex website, ask the host which supported option applies to the DNS service you use.
If the host supports an apex A record and a www CNAME, configure each name separately. Adding the www record does not automatically configure the apex. Choose the preferred website address in the hosting application after both names work.
A short configuration review prevents common input mistakes
Before editing, record the current name, type, value, and TTL. Keep a copy of the provider's requested replacement. The following checklist is editorial advice for a controlled change.
- Open the DNS service that currently answers for the domain.
- Find the exact hostname that needs the alias.
- Check existing records at that hostname.
- Enter the target hostname supplied by the hosting service.
- Save the change and record the change time.
- Verify the published answer before changing another setting.
Check how the editor handles names. One editor might expect www. Another might expect www.example.com. A duplicated suffix creates a different name from the name visitors use. Check the editor's preview or saved result before continuing.
Do not delete MX and TXT records merely because a website is moving. First identify the exact record name that conflicts. An apex mail record does not conflict with a CNAME at www, because the owner names differ.
Avoid making the alias point back to itself. Also inspect the target when several aliases form a chain. A destination that no longer provides address data cannot supply a usable website address. Cloudflare specifically describes an empty flattened answer for a target without address records. Its flattening notes explain that failure.
DNS answers and website behavior need separate checks
Use the Google Admin Toolbox Dig tool to inspect DNS. Enter the exact hostname and select the required record type. Google provides the browser lookup interface. This article does not run a live query for your domain.
Check CNAME data first. Then inspect the target's address records. Compare the published values with the hosting account. A matching CNAME confirms the alias configuration, rather than a functioning application.
Next, visit the exact HTTPS address. Check whether the host serves the intended project and presents a valid certificate for the visitor's hostname. An alias to another service does not make the target's website configuration correct for your custom name.
If DNS looks correct but the browser shows a certificate error, inspect the host's custom-domain and certificate status. If the browser loads the wrong site, inspect project assignment and redirects. Replacing a correct CNAME with a guessed IP address can create another problem.
Finally, compare old and new answers when a recent change appears inconsistent. Resolvers can retain cached records until their remaining TTL expires. The TTL specification describes that cache limit. Use the DNS propagation guide to distinguish a cached answer from an unpublished change.
The useful next action is small: locate the hosting provider's requested record and compare the type, owner name, and target with public DNS. Change only the mismatch that the comparison reveals.
Inspect the alias with a CNAME query in Namefi's DNS lookup, then query the returned target's A or AAAA records as needed. Keep each owner name with its result. These public-resolver observations do not prove that the destination application or certificate works.
Sources and further reading
RFC 1034 defines canonical aliases
RFC 1034 defines canonical aliases. Checked 2026-10-30.
RFC 1035 defines address records
RFC 1035 defines address records. Checked 2026-10-30.
RFC 1034 describes zone authority
RFC 1034 describes zone authority. Checked 2026-10-30.
Cloudflare explains CNAME flattening
Cloudflare explains CNAME flattening. Checked 2026-10-30.
Google provides a browser DNS tool
Google provides a browser DNS tool. Checked 2026-10-30.
RFC 1034 defines cache timing
RFC 1034 defines cache timing. Checked 2026-10-30.
RFC 2606 reserves example domains
RFC 2606 reserves example domains. Checked 2026-10-30.
RFC 5737 reserves documentation addresses
RFC 5737 reserves documentation addresses. Checked 2026-10-30.
About the author(s)
Fenwei Bian is a software developer in her thirties who spends her working hours in pull requests and her weekends with her hands in soil or sawdust. Years of open source on GitHub taught her that names are interfaces: a good one is clear, honest about what it does, and kind to whoever has to use it next.
She gardens because it rewards patience and punishes wishful thinking, and she does woodwork because a joint either fits or it doesn't. Both habits show up in how she writes about naming — measure twice, check the source, and don't sand over a rough spot and hope no one notices.
For Namefi she writes about how domain markets actually move, the practical trade-offs of tokenizing and flipping names, and picking a domain you'll still be glad you own in twenty years.