ALIAS and ANAME Records: A CNAME Workaround for Your Zone Apex

CNAME records can't be used at a domain's zone apex, the bare domain with no subdomain in front of it. That restriction runs directly into a common real-world need: pointing example.com itself, not www.example.com, at a CDN, load balancer, or hosting platform that only publishes a hostname rather than a fixed IP address. ALIAS and ANAME records exist specifically to close that gap.

Why CNAME doesn't work at the apex

A CNAME record tells resolvers to treat one name as a complete alias for another, and the DNS spec (RFC 1034) requires that if a name has a CNAME record, that's the only record it's allowed to have. The problem: a zone apex almost always needs other records too, most importantly the NS records delegating the zone and the SOA record describing it, both of which are required at the apex regardless of anything else. A CNAME at the apex would conflict with records that have to exist there, so the spec simply disallows it. This isn't a limitation any provider can lift; it's a structural rule about what a zone apex is.

What ALIAS and ANAME records actually do

An ALIAS or ANAME record looks like a CNAME from the outside: you point it at a target hostname instead of an IP address. But it doesn't behave like one on the wire. Instead of publishing an alias that resolvers follow themselves, your DNS provider resolves the target hostname on your behalf, at their end, and answers queries for your apex with the resulting A and AAAA records directly. A resolver querying example.com gets back real address records, never a CNAME, so the apex stays fully compliant with the restriction described above.

Not a standard record type

Neither ALIAS nor ANAME is defined in a DNS RFC. They're a provider-side feature, implemented independently by whichever DNS provider offers it, under whichever name that provider chose. This is why you'll see the same underlying idea called ALIAS by one provider and ANAME by another, with occasionally minor behavioral differences between implementations, since there's no spec forcing them to agree. Cloudflare calls its version CNAME flattening, applied automatically to any CNAME placed at the apex rather than requiring a separate record type, and AWS calls its equivalent a Route 53 Alias record. If you migrate providers, don't assume an ALIAS record translates automatically. Check whether the new provider offers an equivalent feature at all, since some don't.

How the resolution actually works

Because the provider is doing the target lookup on your behalf rather than a resolver following a real alias at query time, the address they hand back isn't necessarily fresh to the exact second. Most implementations poll the target periodically (the interval varies by provider, often on the order of minutes) and cache the resolved address, refreshing it in the background rather than re-resolving on every incoming query. In practice this is close enough to real-time for virtually every use case, but it's a meaningfully different mechanism from a CNAME, which resolvers follow live, and worth knowing about if the target's IP changes and you're trying to figure out why your apex hasn't picked it up instantly.

When you actually need one

The typical case is a platform that only gives you a hostname to point at: a CDN edge, a static site host like Netlify or GitHub Pages, or a load balancer with a DNS name rather than a stable IP. www.example.com can CNAME to that hostname without any issue. example.com on its own can't, and that's exactly the gap ALIAS or ANAME fills, letting the bare domain behave the same way the www subdomain does.

The trade-offs

Beyond the polling delay described above, the main cost is portability. Since it's a provider-specific feature rather than a standard record type, it doesn't travel cleanly through a zone file export or a generic migration between providers the way an A or CNAME record does. If you're planning a DNS provider migration and your apex uses ALIAS or ANAME, that record needs specific attention rather than a blind copy-paste, since importing a BIND zone file or similar generic tooling may not carry it over correctly.

Checking whether you're using one

There's no way to query for "ALIAS" or "ANAME" directly, because as far as the wire protocol is concerned, they don't exist. Querying the apex just shows you the A or AAAA records they resolved to:

dig A example.com

If your provider's dashboard shows an ALIAS or ANAME record at the apex but dig returns ordinary A records, that's expected. It's the underlying record type doing its job.

How DNS monitoring fits in

OneDollarDNS monitors what your authoritative nameservers actually serve, which for an ALIAS or ANAME record means the A and AAAA answers it resolves to, not the provider-side configuration behind them. If the resolved address changes, whether because the target moved or because something about the alias configuration itself changed, that shows up as a monitored change the same way any other A record update would.