DNS RECORDS EXPLAINED
A Record vs. CNAME Record: What's the Difference?
A and CNAME records both help direct hostnames, but they store different kinds of destinations. An A record maps a hostname to an IPv4 address. A CNAME makes one hostname an alias of another hostname, whose records are then resolved as needed.
Choosing the right type matters when you connect a website, configure a subdomain, move hosting, or attach a third-party service. Use the record type your provider requires rather than treating A and CNAME as interchangeable settings.
The short version
Use A when the required destination is an IPv4 address. Use CNAME for an eligible hostname when the required destination is another hostname. Check for conflicting records, follow the provider’s root-domain requirements, and verify the result in public DNS.
What Is a DNS A Record?
An A record associates its owner name—the hostname being configured—with an IPv4 address. A resolver can return that address to a browser or another application so it can attempt a connection. The record does not specify a URL path, TCP port, or website redirect.
| Hostname | Type | Value |
|---|---|---|
| example.com | A | 192.0.2.10 |
| shop.example.com | A | 192.0.2.20 |
The addresses above are documentation-only values from the reserved 192.0.2.0/24 range. Do not use them to configure a live website. Replace them with the actual IPv4 address supplied by your provider.
Common uses include pointing a root domain to a web server, sending a subdomain to a specific IPv4 destination, and configuring a service that explicitly supplies an IP address. DNS only directs the connection: the destination must also be configured to serve the hostname, including HTTPS where needed.
Several A records can exist for one hostname. Clients may receive multiple addresses and choose among them, but this alone does not provide health checks, guaranteed balancing, or automatic failover. Every published address should be suitable for the service.
An AAAA record contains an IPv6 address, while an A record contains an IPv4 address. A hostname can have both. If you change hosting, check both types so IPv6-capable visitors are not sent to an outdated destination.
What Is a CNAME Record?
A CNAME (Canonical Name) record makes its owner name an alias of a different hostname. When resolving an address for the alias, DNS follows the target’s records. The CNAME stores the target name; it does not store the target’s current IP address.
| Hostname | Type | Value |
|---|---|---|
| www.example.com | CNAME | example.com |
| app.example.com | CNAME | example.pages.dev |
These rows illustrate the format, not a live service configuration. The pages.dev target is an example platform hostname; use the exact target assigned to your own account. A trailing dot in some DNS interfaces indicates a fully qualified name, while other interfaces add it automatically.
Typical uses include making www follow the main domain, connecting a subdomain to a SaaS or hosting platform, and publishing a provider-required verification alias. A verification CNAME may prove control of a particular name without routing the website itself, so follow the purpose and exact hostname in the provider’s instructions.
A CNAME target is a hostname, not an IP address, URL, or page path. An ordinary CNAME cannot coexist with A, AAAA, MX, TXT, or other ordinary record data at the same owner name; DNSSEC-related metadata has special rules. Provider-specific alias features can behave differently, so check the provider’s implementation rather than assuming the standard restriction disappears.
A CNAME is not an HTTP redirect. The browser normally keeps the original URL, and the destination platform must accept that hostname and provide an appropriate certificate. DNS alone cannot redirect visitors from one page path to another.
A Record vs. CNAME: Key Differences
| Feature | A record | CNAME record |
|---|---|---|
| Purpose | Maps a name to an IPv4 address | Aliases one name to another name |
| Destination value | IPv4 address, such as 192.0.2.10 | Hostname, such as example.com |
| Typical use | Direct server addressing and root-domain hosting | www aliases and platform subdomains |
| IPv4 relationship | Stores an IPv4 address directly | Target may resolve to IPv4 and/or IPv6 |
| Resolution | Address answer for the queried name | Alias target is resolved for the requested data |
| Zone apex | Can coexist with required SOA and NS records | Ordinary CNAME conflicts with apex SOA and NS |
| Destination IP changes | Published address must be updated when required | Alias follows target changes as caches refresh |
| Other records at the same name | Can coexist with compatible types, including AAAA, MX, and TXT | Cannot coexist with other ordinary record data |
The zone apex is the top of the DNS zone, commonly your root domain such as example.com. It must contain SOA and NS records, which prevents an ordinary CNAME from occupying that same name.
Some providers offer CNAME flattening, ALIAS, or ANAME features for apex hosting. These are provider-specific mechanisms, not interchangeable names for a standard CNAME. They may return synthesized A or AAAA answers and have their own behavior, limitations, and update timing.
When Should You Use an A Record?
1. Your hosting provider gives you an IPv4 address and asks you to publish it for the website.
2. You need a hostname to point directly to a server whose address you manage.
3. Your root domain needs an IPv4 address and the provider’s setup uses ordinary address records.
4. A particular service requires explicit IP-based DNS configuration rather than a hostname alias.
An A record does not discover a server’s new address automatically. If the required server IP changes, update every affected A record and review any related AAAA records. Plan the change around existing TTLs and service readiness; a new DNS address will not fix a destination that is not configured for your domain.
Do not copy a platform’s temporary lookup result into an A record when its documentation asks for a CNAME. That platform may change its addresses or depend on hostname-based configuration.
When Should You Use a CNAME Record?
1. Your provider supplies a destination hostname and explicitly requests a CNAME at an eligible name.
2. You want www to follow the records used by your primary domain, and your web service is configured to accept both names.
3. You are connecting a subdomain to a SaaS or hosted platform that manages its own destination addresses.
4. You want an alias to follow changes in the target hostname rather than maintaining a separate address record.
The alias follows the target through DNS resolution, but cached alias and address answers can delay visibility of changes. A CNAME does not eliminate TTLs or guarantee immediate updates. Avoid unnecessary chains and ensure every target resolves correctly.
Before adding the alias, check for records already present at the exact owner name. Resolve conflicts using the provider’s requirements and preserve unrelated service records. A CNAME at www is a different configuration from a CNAME at the zone apex.
Can You Use a CNAME at the Root Domain?
An ordinary DNS CNAME generally cannot be used at the zone apex because the apex must also contain SOA and NS records. This applies to the apex of a delegated zone as well as to the familiar root of a registered domain.
A or AAAA records
If your provider supplies stable, supported addresses, publish the required A and/or AAAA records at the apex. Use only the addresses the service documents; do not infer a permanent address from a single lookup of its hostname.
ALIAS, ANAME, and flattening features
Some DNS hosts can resolve a provider-supplied hostname behind the scenes and return address answers at the apex. ALIAS and ANAME support is provider-specific. Cloudflare supports CNAME flattening, but its setup and proxy behavior should be checked against Cloudflare’s current published requirements.
These mechanisms do not mean every provider supports an ordinary apex CNAME or produces the same public answers. If the feature is unavailable, use an approach supported jointly by your DNS host and website platform rather than forcing an incompatible record.
How to Check A and CNAME Records
1. Open Hostingcone’s DNS Lookup Tool.
2. Enter the exact domain or hostname you want to test, without https:// or a path.
3. Review A and CNAME answers, and check AAAA where IPv6 is relevant.
4. Compare the values with your hosting provider’s required configuration.
5. Review discovered common hostnames where relevant, then query any specific name that needs a separate check.
Entering example.com does not reveal every subdomain. Hostingcone’s tool checks selected common hostnames and publicly available records; it is not a complete zone inventory. Private zones and unknown hostnames are outside that public view.
Cloudflare-proxied names can return edge IP addresses rather than exposing the origin IP or CNAME target. Flattening can also produce address answers. Compare the public result with the provider’s expected proxy or flattening behavior before declaring that the record is incorrect.
Where dig is installed, these queries check the alias and IPv4 answer separately. Replace the example hostname with the one you actually configured:
dig www.example.com CNAMEdig www.example.com A
Common A Record and CNAME Problems
1. Pointing a CNAME directly to an IP address
Recognize it: the CNAME value is an IPv4 address instead of a hostname. If the service supplies an IPv4 address, use an A record at the intended name. If it requires an alias, enter its assigned target hostname instead. Do not add an http:// prefix or URL path.
2. Conflicting records at the same hostname
Recognize it: the panel rejects a CNAME or the name has both an alias and address or TXT data. Review all ordinary records at that exact owner name. Choose the provider-required configuration and resolve the conflict carefully; do not delete unrelated mail or verification records at other names.
3. An incorrect target hostname
Recognize it: the alias resolves to an unexpected service or its target returns NXDOMAIN. Compare the target with the platform’s assigned value and check whether the panel appended your domain twice. Correct spelling and verify that the destination itself resolves.
4. An outdated A record after a migration
Recognize it: a lookup still contains the previous host’s address, possibly alongside the new address. Confirm which destinations are intended, update the active authoritative zone, and review stale AAAA records too. A retired address can affect only some visitors if multiple answers are published.
5. Propagation and stale cached answers
Recognize it: authoritative servers serve the new configuration while some recursive resolvers retain an old answer. Compare the exact hostname and record type, then account for prior TTLs and negative caching. Repeatedly saving a record will not invalidate every remote cache.
6. Confusing Cloudflare proxy IPs with origin IPs
Recognize it: the public A answer is a Cloudflare edge address, although the dashboard contains another origin destination. This can be normal for a proxied name. Check proxy and flattening settings against the provider’s guidance; do not disable a required proxy simply to make the public IP match.
7. Misconfiguring apex records
Recognize it: an ordinary CNAME conflicts with SOA, NS, or other required apex data, or a requested alias feature is unsupported. Use the hosting platform’s documented A/AAAA settings or a supported provider-specific apex alias mechanism. Do not remove required zone records to make room for a CNAME.
8. CNAME chains or loops
Recognize it: aliases point through several names, or a name ultimately points back to itself. A loop can cause resolution failure, while long chains add dependencies and troubleshooting complexity. Correct the target and simplify the chain where the service permits it. Follow a third-party platform’s supported setup rather than replacing its assigned target arbitrarily.
How to Configure A and CNAME Records
1. Identify the authoritative DNS provider by checking the domain’s active nameserver delegation. Edit the zone those servers actually serve, not an inactive hosting account.
2. Open that provider’s DNS management interface. Record the existing configuration before making a targeted change.
3. Select the record type required by the service: A for an IPv4 address or CNAME for an eligible hostname alias.
4. Enter the correct owner name and destination. Interfaces may expect @ or a blank field for the apex, a short label such as www, or a full hostname. Follow that interface’s naming rules.
5. Choose an appropriate TTL. For a planned migration, reduce the relevant TTL early enough for previous longer-lived answers to expire.
6. Save the record and confirm that no unintended conflicts or duplicate destinations were introduced.
7. Verify the authoritative answer and public resolver results, then test the website itself. DNS success does not verify HTTPS or application configuration.
Generic configuration example
A provider that uses short labels might show an A record with Host = @ and Value = 192.0.2.10, plus a CNAME with Host = www and Target = example.com. This is illustrative: the address is documentation-only, and field labels vary. Use your real domain and provider-approved destination instead.
Frequently Asked Questions
Is an A record better than a CNAME?
Neither is universally better. Use A when the required destination is an IPv4 address, and CNAME when the provider requires a hostname alias at a name where it is supported. The correct choice depends on the service and DNS constraints.
Can an A record and CNAME exist for the same hostname?
Not as ordinary DNS records at the same owner name. A standard CNAME conflicts with A and other ordinary data there. Provider-specific alias or flattening features are different mechanisms and need their own documented setup.
Can I use a CNAME for my root domain?
An ordinary apex CNAME conflicts with required SOA and NS records. Some providers support apex aliasing or flattening that returns address answers instead. Follow the DNS host’s and website platform’s supported requirements.
Does a CNAME point to an IP address?
No. It stores another hostname. Resolution of that target may eventually return A or AAAA addresses, but the CNAME value itself is a name.
What happens if the destination IP changes?
An A record must be updated when its required address changes. A CNAME follows changes in its target’s records as answers refresh, although existing alias and address caches can delay visibility.
Why does my CNAME show an IP address instead?
An address query can follow the alias and return the target’s address. A DNS provider’s flattening or proxying can also return address answers without exposing an ordinary CNAME. Query CNAME explicitly and compare the provider’s documented behavior.
Can I have multiple A records?
Yes. One hostname can have several IPv4 addresses. Every address should serve the intended service; multiple records alone do not provide health checks or guaranteed failover.
How long do A and CNAME record changes take?
Timing depends on existing TTLs, negative caching, provider publication, and the lookup path. Changes may appear quickly for a fresh query while older answers remain cached elsewhere. There is no universal propagation deadline.
Can incorrect DNS records make my website unavailable?
Yes. Wrong addresses, nonexistent alias targets, conflicts, or loops can prevent visitors from reaching the intended service. DNS is only one possible cause, so also check hosting, HTTPS, and application health.
Need Help Configuring Your DNS Records?
Use Hostingcone's free DNS Lookup Tool to check your A and CNAME records, or explore professional assistance with domain and DNS configuration.
Explore more DNS troubleshooting guides and tools in the Hostingcone DNS Troubleshooting Hub.