Skip to content
Webmaster Tools
DNS & domainsDNS LookupALIAS / ANAME record

ALIAS and ANAME records

What ALIAS and ANAME records are, why a CNAME can't sit at the zone apex, how Route 53 alias, Cloudflare CNAME flattening and DNSimple ALIAS work, and how to check them.

What it is

An ALIAS (or ANAME) record lets the root of a domain, example.com, point at a hostname such as myapp.herokudns.com or a load balancer's DNS name. A real CNAME can't do this: RFC 1034 forbids a CNAME from sharing its name with any other record, and the apex always has SOA and NS records. ALIAS is not a standard record type. It's a feature of the DNS provider: their servers look up the target's A and AAAA records and answer with those addresses, so resolvers only ever see ordinary A and AAAA records.

; what you enter at the provider (pseudo-syntax, varies by provider)
example.com.      ALIAS  myapp.herokudns.com.

; what the world receives when it asks for example.com
example.com.  300  IN  A     203.0.113.10
example.com.  300  IN  AAAA  2001:db8::10

An ANAME draft was proposed at the IETF but never became a standard; the newer standard answer is the HTTPS/SVCB record type (RFC 9460), which browsers support only partly so far.

How it works

Provider Name Behaviour
Amazon Route 53 Alias record Points an A/AAAA at an AWS resource (CloudFront, ELB, S3 website, API Gateway, another record in the zone). Free to query, and it uses the target's TTL
Cloudflare CNAME flattening You create a CNAME at the apex; Cloudflare answers with the target's addresses. Applied automatically at the apex, optional for other names
DNSimple ALIAS Resolves any hostname and returns its A/AAAA records
DNS Made Easy, Constellix ANAME Same idea
NS1, Azure DNS ALIAS / alias record set Same idea, Azure for its own resources

Because the provider resolves the target from its own servers, geo-steered targets (CDNs) may return addresses chosen for the provider's location rather than the visitor's. Most providers mitigate this with EDNS Client Subnet or many points of presence, but it's the trade-off.

Common setups

  • Heroku, Netlify, Render: they tell you to use ALIAS/ANAME or CNAME flattening for the apex, or a fixed A record when they offer one.
  • Vercel gives the apex an A record (long documented as 76.76.21.21) and www a CNAME, so ALIAS is optional there.
  • GitHub Pages documents four A records for an apex domain, or an ALIAS/ANAME pointing at <user>.github.io.
  • AWS: an apex pointing at CloudFront or an ALB must be a Route 53 alias, since their IPs change.

How to check it

You can't see the ALIAS itself from outside, only the addresses it produces. Look up the apex in our DNS Lookup and compare with the target:

dig example.com A +short
dig myapp.herokudns.com A +short
nslookup example.com

If the two lists match (or overlap for a rotating target), the ALIAS is working. A dig example.com CNAME returns nothing, which is expected.

Common mistakes

  • Creating a plain CNAME at the apex on a provider that doesn't flatten: it's either rejected or breaks MX and TXT lookups.
  • Expecting your own TTL to apply: many providers use the target's TTL or a fixed short one.
  • Route 53 alias to a resource in another account or region that was deleted: the name answers with nothing.
  • Moving DNS to a provider without ALIAS support and losing the apex record.