You are setting up a domain, your hosting provider tells you to point it somewhere using a CNAME, and then your DNS control panel throws an error the moment you try to create one at the root of the domain. Or maybe you see an option called "ALIAS" or "ANAME" and have no idea whether that is the same thing or something completely different. This confusion trips up developers and sysadmins alike, and it has a real technical explanation worth understanding. Once you grasp why CNAME records have a hard limitation at the zone apex, the purpose of Alias records becomes immediately obvious.

What a CNAME Record Actually Does

A CNAME (Canonical Name) record maps one hostname to another hostname. Instead of resolving to an IP address directly, it tells the DNS resolver "go look up this other name and use whatever you find there." The resolver follows the chain until it lands on an A or AAAA record with an actual IP address.

For example, if you want www.example.com to follow wherever shop.myplatform.io points, you create:

www.example.com. 3600 IN CNAME shop.myplatform.io.

Whenever a client looks up www.example.com, the resolver returns the CNAME target, then resolves that target to its current IP. This is extremely useful when the IP behind shop.myplatform.io changes, because your CNAME automatically follows the change without any intervention on your part.

The RFC 1034 Restriction That Changes Everything

RFC 1034, the foundational DNS specification written in 1987, contains one critical rule: a CNAME record cannot coexist with any other record at the same node. At the zone apex (the root of your zone, like example.com without any subdomain), you are required by the standard to have SOA and NS records. Those records cannot share the node with a CNAME. The moment you try, you violate the DNS spec, and compliant resolvers and registrars will reject or misbehave.

This is not a quirk of your DNS provider. It is baked into the protocol. Every authoritative DNS server that follows the standard enforces it. So when a CDN or SaaS platform gives you a hostname to point your root domain at, a plain CNAME is off the table.

What an Alias Record Does Differently

The Alias record (also called ANAME by some providers, or ALIAS by others) is not a standard DNS record type defined in any RFC. It is a proprietary feature implemented inside the authoritative DNS server itself. Different DNS providers implement it slightly differently, but the behavior is consistent in purpose: it lets you point a zone apex to a hostname, just like a CNAME, while still returning real IP addresses to clients.

Here is what happens under the hood when you create an Alias record at example.com pointing to shop.myplatform.io:

  1. A client queries your authoritative name server for an A record at example.com.
  2. Your authoritative name server (not the client's resolver) performs an internal lookup of shop.myplatform.io in real time.
  3. It returns the resolved IP addresses directly to the client as if they were native A or AAAA records.
  4. The client never sees the intermediate hostname — it gets a clean IP address response.

Because the resolution happens server-side at your authoritative name server, there is no RFC violation. The response that leaves the server is a valid A or AAAA record. The NS and SOA records at the apex are completely unaffected.

💡 After making any DNS changes — whether you switch from a CNAME to an Alias or update targets — use the DNS Propagation Checker to confirm the new records have spread across global resolvers. Propagation for Alias records can behave differently from provider to provider because the TTL shown to clients depends on the upstream target's TTL.

Side-by-Side Comparison

  • Zone apex support: CNAME is forbidden at the zone apex. Alias works at the zone apex and on subdomains.
  • Coexistence with other records: CNAME cannot share a node with any other record type. Alias can coexist with MX, TXT, and other records at the same name.
  • Returned record type: CNAME returns a CNAME record in the DNS response; resolvers must follow the chain. Alias returns A/AAAA records; the chain is invisible to clients.
  • TTL behavior: CNAME TTL is independent of the target's TTL. Alias TTL is typically capped by or inherited from the target's TTL, since the authoritative server resolves the target dynamically.
  • Standardization: CNAME is defined in RFC 1034/1035. Alias/ANAME is proprietary, with behavior varying between DNS providers (Cloudflare, Route 53, DNSimple, NS1, etc.).
  • Performance: CNAME adds an extra DNS resolution step for clients. Alias resolves the chain on the server side, so clients get a direct IP in one round trip.
  • Provider availability: CNAME is available everywhere. Alias requires a DNS provider that explicitly supports it — not all do.

Common Real-World Scenarios

Pointing a Root Domain to a CDN or Heroku

Heroku, Netlify, Vercel, Fastly, and most CDNs give you a hostname (like your-app.herokudns.com) instead of a static IP, because they route traffic through load balancers that change addresses. You cannot create an A record because there is no permanent IP. You cannot create a CNAME at the root. The only clean solution is an Alias record at the zone apex.

If your DNS provider does not support Alias records, your practical options are: switch to a provider that does (Cloudflare's CNAME flattening is the most popular free option), or use a subdomain redirect such as pointing www.example.com via CNAME and redirecting example.com with an A record to a redirect service.

Subdomains Like www

For www.example.com, a regular CNAME is perfectly valid and almost always the right choice. There are no conflicting records at that node, and the CNAME record is lightweight and easy to maintain. Use an Alias on a subdomain only if your provider recommends it for performance reasons or if you need the resolved-IP behavior for some application-layer reason.

MX Records and the Root Domain

This is where Alias beats CNAME in another important way. Suppose your root domain needs both an Alias to a hosting platform and MX records for email. With a CNAME, that would be illegal — you cannot have a CNAME and MX records at the same name. With an Alias, both coexist cleanly because the Alias is not truly stored as a CNAME in the zone; it is an internal instruction that produces synthesized A/AAAA records.

How to Create Each Record Type

Creating a CNAME in Common Control Panels

In most DNS control panels (cPanel, Cloudflare, GoDaddy, Namecheap), navigate to your DNS zone editor and add a new record. Select type CNAME, enter the subdomain in the Host field (for example, www), and enter the target hostname in the Value field. Do not include a trailing dot unless the interface requires it; most consumer panels handle that automatically.

Type: CNAME Name: www Value: shop.myplatform.io TTL: 3600

Creating an Alias Record on Cloudflare

Cloudflare does not call it "Alias" — it calls the feature CNAME Flattening, and it activates automatically whenever you create a CNAME at the zone root (@). Just add a CNAME record with the name @ and Cloudflare flattens it internally:

Type: CNAME Name: @ Value: shop.myplatform.io TTL: Auto (proxied or DNS-only)

Cloudflare will store it as a CNAME in its interface but serve flattened A/AAAA records to the outside world.

Creating an Alias Record on Route 53

AWS Route 53 has a native Alias record type. When creating a record set, toggle the Alias switch to Yes, then enter your target in the Alias Target field. Route 53 Alias records support pointing to other AWS resources (CloudFront distributions, Elastic Load Balancers, S3 static websites) with no extra charge for queries, unlike standard records.

Record Type: A Alias: Yes Alias Target: dXXXXXXXXXXXXX.cloudfront.net

Verifying Your Records After Creation

Use the DNS Lookup tool to confirm your records are resolving correctly. Query for the A record at your zone apex to verify an Alias is synthesizing IP addresses, and query for the CNAME record at a subdomain to confirm the chain is intact. If you query for a CNAME at the zone apex and your provider is flattening it, you will see A records returned — that is expected and correct behavior.

From the command line, use dig to inspect both record types:

dig A example.com +short dig CNAME www.example.com +short dig A www.example.com +short

If the Alias is working, dig A example.com will return one or more IP addresses with no CNAME in the answer section. If you see a CNAME in the answer section for the root domain, the provider's flattening is not active.

TTL Considerations and Caching

One subtle operational difference: with a CNAME, the TTL you set controls how long resolvers cache the pointer record itself. Resolvers then separately cache the target's A records according to the target's own TTL. So a lookup chain can involve two separate cache lifetimes.

With an Alias record, your authoritative server resolves the target dynamically at query time (or caches it briefly internally) and returns the result with a TTL typically equal to or lower than the target's TTL. This means that if your CDN or platform changes its IP addresses, an Alias-based setup propagates that change faster to end users than a long-TTL CNAME chain would. During a migration or failover, this can matter.

Choosing the Right Record Type

The decision is usually straightforward once you know the constraints:

  • If you are pointing a subdomain (www, app, mail, etc.) to another hostname, use a CNAME. It is standard, universally supported, and well understood.
  • If you are pointing a root/apex domain to another hostname, you need an Alias (or CNAME flattening). Make sure your DNS provider supports it before committing to that provider.
  • If your DNS provider does not support Alias records, either move your DNS to one that does (Cloudflare is the most common free choice) or architect around the limitation using a subdomain as your canonical entry point.
  • If you need MX or TXT records at the same name as your point-to-hostname record, only Alias will work legally. CNAME at that node blocks everything else.

Provider-Specific Notes

Cloudflare: CNAME flattening is automatic at the apex and optional on subdomains. No special configuration needed.
AWS Route 53: Native Alias type with no query charges for AWS-to-AWS Alias records. Supports non-AWS targets too.
DNSimple: Explicit ALIAS record type available in the interface.
NS1: Supports ALIAS as a first-class record type.
GoDaddy and Namecheap managed DNS: Do not support ALIAS records as of current writing. For apex hostname pointing, you must use a workaround or transfer DNS management to a provider that supports it.
cPanel (BIND-based): Standard BIND does not support ALIAS natively. Some cPanel-integrated DNS providers layer it on top, but basic shared hosting DNS typically does not have it.

Troubleshooting Common Errors

If you receive an error like "CNAME record not allowed at zone apex" or "Cannot create CNAME: conflicts with existing records", the fix is to either switch to an Alias record or restructure so the hostname you want to point is a subdomain, not the root. If your provider does not offer Alias, the cleanest solution is to delegate DNS to Cloudflare (free), point the apex with a flattened CNAME there, and keep your registrar only for the domain registration.

If your Alias record is resolving but returning stale IPs, check whether your DNS provider caches the target resolution aggressively. Most providers refresh the upstream resolution at an interval shorter than the external TTL, but during heavy load some providers lag. Reducing your Alias record's TTL to 300 seconds during migrations helps force faster refreshes.