What is an ALIAS or ANAME record?

An ALIAS or ANAME record is a provider-specific DNS record that lets you point a name, usually your root domain such as example.com, at another hostname instead of an IP address, while still returning ordinary A and AAAA records to visitors. Your DNS provider looks up the target hostname behind the scenes and answers with whatever IP addresses it currently resolves to. It behaves like a CNAME from your point of view, but because it doesn't return a CNAME on the wire, it can live at the zone apex alongside your MX, TXT, NS and SOA records.

ALIAS and ANAME are not official DNS record types. They're features that DNS providers implement on their own servers, under different names and with different rules. In this article you'll learn why they exist, how they work, how the major providers' versions differ, how to create them on AWS and Azure, what they do to performance and features such as DNSSEC and secondary DNS, and when a plain A record is still the better choice.

Why ALIAS and ANAME Records Exist

Modern hosting platforms, load balancers and CDNs rarely give you a fixed IP address. They give you a hostname, such as my-app.platform.example.net, and change the IP addresses behind it whenever they need to. The natural way to use a hostname is a CNAME record, and for subdomains that works perfectly:

www.example.com.    300    IN    CNAME    my-app.platform.example.net.

The problem is the root domain. DNS rules say that if a name has a CNAME record, it can't have any other records. The zone apex always has SOA and NS records, and usually MX and TXT records too, so a CNAME at example.com is forbidden:

; Invalid: a CNAME can't coexist with the SOA, NS and MX records at the apex
example.com.    300    IN    CNAME    my-app.platform.example.net.

Some DNS servers reject this outright. Others accept it and then break email in subtle ways, because resolvers asking for the MX record get the CNAME instead.

ALIAS and ANAME records solve this by doing the CNAME's work on the authoritative server rather than in the visitor's resolver.

How an ALIAS Record Works

When a resolver asks your DNS provider for the A record of example.com, this is what happens with an ALIAS in place:

1. The query arrives: A resolver asks your provider's authoritative server for example.com A.
2. The provider resolves the target: The server sees the ALIAS pointing at my-app.platform.example.net and looks up that name's A records itself, or reads them from its own cache.
3. A synthetic answer is built: The provider returns those IP addresses as if they were A records stored directly on example.com.
4. The resolver caches it: From the resolver's point of view, it's just a normal A record. It never sees the target hostname.

The same happens for AAAA queries. Queries for other types, such as MX or TXT, are answered from the records you created as usual, so nothing else at the apex is affected.

You can see this from the outside with dig. The answer contains only A records, with no hint of an alias:

dig example.com A +noall +answer

example.com.        60      IN      A       203.0.113.20
example.com.        60      IN      A       203.0.113.21

Compare the target directly and you'll see the same addresses:

dig my-app.platform.example.net A +short

203.0.113.20
203.0.113.21

How Providers Implement It

Because there's no standard, every provider has its own name and its own rules. The main differences are what the record can point at and how it's billed.

Provider	Name	Can point at
Amazon Route 53	Alias record	AWS resources only: CloudFront, ELB, S3 website endpoints, API Gateway, other records in the same hosted zone, and more
Azure DNS	Alias record set	Azure resources: public IPs, Traffic Manager profiles, Front Door, CDN endpoints, and other record sets in the same zone
Cloudflare	CNAME flattening	Any hostname, applied automatically to CNAMEs at the apex
DNSimple	ALIAS	Any hostname
DNS Made Easy	ANAME	Any hostname
NS1 (IBM)	ALIAS	Any hostname

Amazon Route 53 Alias Records

Route 53's alias records are the most widely used, and they work a little differently from the generic version. Instead of resolving an arbitrary hostname, Route 53 knows the addresses of AWS resources directly. That has some useful benefits:

• Queries to alias records pointing at AWS resources are free, whereas normal queries are billed.
• Changes follow automatically: When a load balancer's IPs change, the alias answer changes immediately.
• Health checks: With EvaluateTargetHealth, Route 53 can take the target's health into account for failover routing.

The trade-off is that you can't point a Route 53 alias at a hostname outside AWS.

Here's how to create an apex alias to a CloudFront distribution with the AWS CLI. The hosted zone ID Z2FDTNDATAQYW2 is the fixed value AWS documents for all CloudFront distributions:

cat > alias.json <<'EOF'
{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "d111111abcdef8.cloudfront.net",
          "EvaluateTargetHealth": false
        }
      }
    }
  ]
}
EOF

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch file://alias.json

Note that there's no TTL field. Route 53 uses the target's TTL for alias records. Create a second change with "Type": "AAAA" if the distribution has IPv6 enabled.

In Terraform, the same thing is an alias block on an aws_route53_record:

resource "aws_route53_record" "apex_ipv4" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.site.domain_name
    zone_id                = aws_cloudfront_distribution.site.hosted_zone_id
    evaluate_target_health = false
  }
}

resource "aws_route53_record" "apex_ipv6" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "AAAA"

  alias {
    name                   = aws_cloudfront_distribution.site.domain_name
    zone_id                = aws_cloudfront_distribution.site.hosted_zone_id
    evaluate_target_health = false
  }
}

Azure DNS Alias Record Sets

Azure DNS takes a similar approach. An alias record set references an Azure resource by its resource ID, and the record updates when the resource's IP changes. With the Azure CLI:

az network dns record-set a create \
  --resource-group rg-dns \
  --zone-name example.com \
  --name "@" \
  --target-resource "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-web/providers/Microsoft.Network/publicIPAddresses/pip-web"

Azure also prevents dangling records: if the target resource is deleted, the alias record set returns an empty answer rather than pointing at an IP address that might later be given to someone else.

Generic ALIAS and ANAME

Providers such as DNSimple, DNS Made Easy and NS1 let you point ALIAS or ANAME records at any hostname. In their dashboards you choose the record type, leave the name blank or enter @ for the apex, and enter the target hostname. Some providers support ALIAS on subdomains too, though a normal CNAME is usually the better option there.

Trade-offs and Gotchas

ALIAS records are convenient, but because the provider resolves the target for you, a few things behave differently from a real CNAME.

Location-Based Answers

CDNs and global load balancers often return different IP addresses depending on where the request comes from. With a CNAME, the CDN sees the visitor's resolver and can choose a nearby edge. With an ALIAS, the CDN sees your DNS provider's server, which may be on a different continent from the visitor.

Some providers mitigate this by resolving the target from many locations, or by passing the visitor's network to the target using EDNS Client Subnet. Others don't. If performance for a global audience matters, check how your provider handles it, or use your CDN's own DNS for the apex.

TTLs

The TTL of the synthetic answer depends on the provider. Route 53 uses the target's TTL. Others use a value you set, or a fixed short value. If the target changes its IPs and your provider's cached copy is stale, visitors get the old addresses until it refreshes.

Secondary DNS and Zone Transfers

ALIAS isn't a real record type, so it can't be transferred to a secondary DNS provider using standard zone transfers. A secondary either receives nothing for that name or receives a snapshot of the A records at the time of the transfer, which can go out of date. If you run multiple DNS providers, plan for this explicitly.

DNSSEC

Because the answer is generated on the fly, a signed zone needs the provider to sign the synthetic A and AAAA records as it creates them. Providers that support both DNSSEC and ALIAS do this with online signing, but it's worth confirming before you enable DNSSEC on a zone that uses ALIAS.

Exports and Portability

When you export your zone file, ALIAS records may appear as a provider-specific type, as a comment, or not at all. Moving to another provider means recreating them by hand in whatever form the new provider supports.

Is There a Standard Alternative?

There was an attempt to standardise ANAME at the IETF, but the draft was never published as an RFC. Instead, the HTTPS record type (RFC 9460) includes an "AliasMode" that lets the apex point at another hostname in a standard way. Browsers that support HTTPS records can follow it directly.

The catch is that clients which don't understand HTTPS records still need A and AAAA records at the apex. For now, providers' ALIAS features remain the practical solution, with HTTPS records as a complement rather than a replacement.

When to Use an ALIAS Record

Use an ALIAS or ANAME record when:

• You need your root domain to point at a platform that only gives you a hostname.
• The target's IP addresses can change without notice.
• Your provider supports it, and its behaviour suits your traffic.

Use a plain A record when:

• The platform gives you stable IP addresses, such as an anycast address for the apex. Many hosting platforms publish one for exactly this reason.
• You need to transfer the zone to secondary DNS providers.
• You want behaviour that's identical on every DNS provider.

Use a CNAME when:

• The name isn't the apex. For www and other subdomains, a CNAME is standard, portable and lets the target's DNS make location-aware decisions.

A common, sensible setup combines all three ideas: www.example.com as a CNAME to the platform, the apex as an ALIAS (or the platform's documented A records), and an HTTP redirect from one to the other so visitors always land on your preferred hostname.

---

FAQ: ALIAS and ANAME Records

---

Conclusion

An ALIAS or ANAME record gives you CNAME-like behaviour at the root of your domain by moving the lookup onto your DNS provider's servers. Visitors see ordinary A and AAAA records, while your MX, TXT and other apex records carry on working exactly as before.

Because it isn't a standard record type, the details depend entirely on your provider: what it can point at, how TTLs work, whether location-aware routing survives, and whether it works with DNSSEC and secondary DNS. Check those points before you rely on it, use CNAMEs for subdomains, and keep the platform's static A records in mind as a simple and portable alternative.