ALIAS and ANAME Records: CNAME at the Apex

You need to point example.com to a CDN. They give you a hostname like cdn.example.net. You reach for a CNAME record—only to discover CNAMEs aren't allowed at the zone apex.

The solution is a clever hack that's become industry standard: ALIAS and ANAME records. Your DNS provider resolves the target hostname, then lies to the client—returning A records as if they were the truth.

Why CNAMEs Can't Exist at the Zone Apex

The DNS specification (RFC 1034) prohibits CNAME records at the zone apex because CNAMEs must be the only record at a given name. But zone apexes require SOA and NS records to function. You can't have both. The conflict is irreconcilable within standard DNS.

This matters when services give you hostnames instead of IP addresses. CDNs, cloud load balancers, and platform services provide something like lb-1234.us-east-1.elb.amazonaws.com because their infrastructure uses dynamic IPs—they change for scaling, failover, and geographic distribution.

The manual workaround—query the target, copy the IPs into A records, update when they change—defeats the purpose of managed infrastructure.

How the Deception Works

ALIAS and ANAME records solve this through server-side resolution:

1. Client queries example.com for an A record
2. Your DNS server sees the ALIAS pointing to cdn.example.net
3. Server performs its own lookup for cdn.example.net
4. Server returns the resolved IPs as A records
5. Client receives standard A records, unaware of the indirection

The client never sees a CNAME. DNS specifications remain unviolated. The resolver work happens server-side, invisible to clients.

Provider Implementations

Different providers implement this under different names.

Cloudflare calls it "CNAME flattening" and applies it automatically to apex CNAMEs. You create a standard CNAME; Cloudflare handles the rest. Seamless, but the invisibility makes debugging harder.

AWS Route53 uses "ALIAS records" with deep AWS integration. They point to CloudFront distributions, Elastic Load Balancers, and S3 endpoints. Queries to AWS resources don't count against limits—effectively free for internal routing.

DNSimple and others use "ANAME records"—functionally identical, following a naming convention that's spread across providers.

None of these are standardized. The IETF draft for ANAME (draft-ietf-dnsop-aname) expired without becoming an RFC. These remain proprietary workarounds, which is why names and behaviors vary.

The Trade-offs

Server-side resolution introduces complexity that standard A records don't have.

Added latency. Your DNS server performs an extra lookup before responding. Caching helps, but the first query after TTL expiration takes the hit.

Provider dependency. Your domain's reachability now depends on your DNS provider's ability to resolve the target. If their resolvers can't reach the target's authoritative servers, your domain goes dark.

Geographic routing breaks. Services that return different IPs based on resolver location see your DNS provider's infrastructure, not your user's. A user in Tokyo might get routed to a Virginia data center because your provider's resolver is in Virginia.

TTL mismatch. Clients see your ALIAS record's TTL, not the target's. Too low and you hammer your DNS servers; too high and IP changes propagate slowly.

Hidden indirection. Tools like dig show A records, hiding the ALIAS. Your visible records won't match your configuration, making debugging confusing.

When to Use Them

Use ALIAS/ANAME records when you must point a zone apex to a hostname-based service—CDNs, load balancers, platforms without static IPs.

Don't use them when static IPs are available. Standard A records are simpler, faster, and have no hidden dependencies.

Consider the www pattern instead. Using www.example.com as your canonical domain lets you use standard CNAMEs, with the bare domain redirecting to www. This avoids the problem entirely.

For critical domains, verify your provider's implementation includes health checking. Without it, a failed target lookup makes your domain unreachable.

Sources