What Is an ALIAS or ANAME Record?

You sign up for a hosting platform, a CDN, or a load balancer, and the setup instructions tell you to point your domain at a hostname like myapp.example-cdn.net rather than a fixed IP address. That works fine for www.example.com, where you can add a CNAME. But the moment you try the same thing on the bare example.com, your DNS panel either refuses or warns you that it will break email. The workaround most DNS providers offer is a record type called ALIAS or ANAME. This article explains what those records actually are, how each major provider implements them, how to configure them in practice, and where their limits are. If you need a refresher on the difference between A records and CNAME records, start there first.

What Is an ALIAS or ANAME Record?

An ALIAS record (also sold as ANAME, or under a vendor-specific name) is a pseudo-record that you create in your DNS provider's dashboard. You give it a target hostname, just like a CNAME. But when a resolver asks for example.com, your provider's authoritative server does not return a CNAME. Instead, it looks up the target itself, takes the A and AAAA addresses it finds, and returns those addresses as if they were ordinary A and AAAA records you had typed in by hand.

The key word is pseudo. There is no ALIAS record type in the official DNS protocol that resolvers understand. If you query the wire for an ALIAS record, you will not find one. The ALIAS exists only inside your provider's configuration database, and what leaves their servers is standard A and AAAA data. That is precisely why it is allowed at the root of a zone: from the outside, the apex just has normal address records alongside its SOA, NS, MX and TXT records.

The exact reasons a plain CNAME is forbidden at the apex are covered in Can You Use a CNAME Record on the Root Domain?. This post focuses on the ALIAS/ANAME record types themselves and how providers implement them.

ALIAS vs ANAME vs CNAME at a Glance

Feature	CNAME	ALIAS / ANAME	A record
Points at	A hostname	A hostname (or a cloud resource)	An IPv4 address
What resolvers receive	A CNAME, then they chase it	A/AAAA addresses directly	A/AAAA addresses
Allowed at the zone apex	No	Yes	Yes
Can coexist with MX, TXT at same name	No	Yes	Yes
Part of the DNS standard	Yes (RFC 1034)	No — provider feature	Yes (RFC 1035)
Follows target IP changes automatically	Yes	Yes, on the provider's refresh schedule	No
Portable between DNS providers	Yes	Usually not	Yes

Where the Name ANAME Came From

ALIAS-style records predate any attempt to standardise them. DNSimple, DNS Made Easy, and others built their own versions in the early 2010s because customers kept hitting the apex CNAME problem. In 2017 the IETF DNSOP working group started a draft, draft-ietf-dnsop-aname, to define an ANAME record with a real type code so that authoritative servers could exchange the configuration in zone transfers and secondaries could resolve it consistently.

That draft never became an RFC. The working group's effort shifted to the SVCB and HTTPS record types (published as RFC 9460 in 2023), whose "AliasMode" form solves a similar problem in a standards-based way, at least for clients that support it. You can read more about that in What Are HTTPS and SVCB Records in DNS?. The practical result is that "ALIAS" and "ANAME" today are marketing names for broadly similar, non-interoperable features. Two providers that both offer "ANAME" may behave differently around TTLs, health checks and IPv6.

How an ALIAS Record Works Under the Hood

When you save an ALIAS record pointing example.com to myapp.example-cdn.net, the provider's authoritative nameservers do roughly this:

1. Store the alias target. The configuration says "for example.com, synthesize A/AAAA from myapp.example-cdn.net."
2. Resolve the target. Either on each query, or on a background schedule, the provider runs its own recursive lookup for myapp.example-cdn.net A and AAAA records.
3. Cache the result. Most providers cache the target's answer for the target's TTL (sometimes with a minimum or maximum enforced).
4. Answer the client. When your visitor's resolver asks for example.com A, the provider returns the cached IPs as ordinary A records, with a TTL it chooses.

The underlying lookup-and-substitute process is often called CNAME flattening, and its trade-offs (geolocation accuracy, TTL behaviour, DNSSEC signing) are big enough that they get their own article: What Is CNAME Flattening?. For this post, the important point is that an ALIAS is the configuration object, and flattening is what happens when the server answers.

You can see the result with dig. Querying a domain that uses an ALIAS looks completely ordinary:

dig example.com A +noall +answer

example.com.        300     IN      A       203.0.113.10
example.com.        300     IN      A       203.0.113.11

There is no CNAME in the answer section, which is the whole point. If you want to know what the alias points to, you have to look in the provider's dashboard or API, because nothing in the public DNS reveals it. To compare against the target directly:

dig myapp.example-cdn.net A +noall +answer

If the addresses match (allowing for load-balanced rotation), the alias is working. If the apex returns stale IPs long after the target changed, the provider's refresh behaviour is the first thing to investigate.

Provider Implementations

Every provider does this a little differently. Here are the ones you are most likely to meet.

AWS Route 53 Alias Records

Route 53's Alias is not a separate record type at all. It is a flag on an A or AAAA record (and some other types) that says "get the values from this AWS resource instead of a static list." Alias targets can be CloudFront distributions, Elastic Load Balancers, S3 website endpoints, API Gateway, Global Accelerator, VPC interface endpoints, and other records in the same hosted zone.

Two details make Route 53 Alias different from most ALIAS implementations:

• It resolves internally. Route 53 knows the IPs of AWS resources directly, so it does not need to perform an external recursive lookup.
• Alias queries to AWS resources are free. Route 53 does not charge for queries to alias records that point at most AWS resources, whereas standard CNAME queries are billed.

The catch is that a Route 53 Alias can only target AWS resources or records in the same hosted zone. You cannot alias your apex to a hostname at a third-party CDN. Here is how to create an apex alias to a CloudFront distribution with the AWS CLI:

{
  "Comment": "Apex alias to CloudFront",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "d111111abcdef8.cloudfront.net.",
          "EvaluateTargetHealth": false
        }
      }
    }
  ]
}

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

The first block is the change batch saved as apex-alias.json. Z2FDTNDATAQYW2 is the fixed hosted zone ID AWS uses for all CloudFront distributions; for a load balancer you would use that load balancer's own canonical hosted zone ID instead. The second command applies it to your hosted zone. Repeat with "Type": "AAAA" if IPv6 is enabled on the distribution. There is no TTL field because Route 53 uses the target's TTL. For more Route 53 workflows, see How to Manage DNS Records in AWS Route 53.

Azure DNS Alias Record Sets

Azure DNS has a similar concept called alias record sets. An A, AAAA or CNAME record set can reference an Azure resource, such as a public IP address, a Traffic Manager profile, an Azure Front Door endpoint, or an Azure CDN endpoint, instead of holding static values. When the resource's IP changes, the record set updates automatically, and if the resource is deleted the record set becomes empty rather than pointing at an IP someone else might get later. That last property is a useful defence against dangling records.

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

This creates an apex (@) A record set whose value is bound to a public IP resource. Like Route 53, Azure's alias only targets resources inside Azure.

Cloudflare

Cloudflare does not expose an ALIAS type. Instead, you add a CNAME at the apex and Cloudflare automatically flattens it, returning A and AAAA records to resolvers. The result is functionally the same as an ALIAS. On paid plans you can choose to flatten CNAMEs everywhere in the zone, not just at the apex. If the record is proxied (orange cloud), resolvers get Cloudflare's own edge IPs rather than the target's IPs, which is a different mechanism again.

DNSimple, DNS Made Easy, NS1 and Others

• DNSimple offers an ALIAS record type that can sit at the apex alongside other records. It also publishes a TXT record at the same name describing the alias target, which helps with debugging and with secondary DNS.
• DNS Made Easy calls its version ANAME, and supports it on the apex and on subdomains.
• NS1 (IBM NS1 Connect) supports an ALIAS record type that can be combined with its traffic-steering filter chains.
• Many registrar-bundled DNS services and hosting dashboards offer an "ALIAS" or "ANAME" type with varying behaviour. Some only refresh the target every few minutes or hours, so check their documentation.

How to Configure an ALIAS Record Safely

The workflow is similar wherever you do it:

1. Confirm your provider supports it. If the record type list has no ALIAS, ANAME, or apex CNAME flattening, you will need to use static A records or move DNS to a provider that does.
2. Remove conflicting A/AAAA records at the apex. Most providers will not let you have an ALIAS and a static A record at the same name for the same type.
3. Create the ALIAS at @ pointing to the hostname your platform gave you, for example myapp.example-cdn.net.
4. Leave MX, TXT, CAA, NS and SOA alone. These coexist with an ALIAS without any problem, which is the main advantage over a CNAME.
5. Verify from outside. Query both the apex and the target and compare.

for name in example.com myapp.example-cdn.net; do
  echo "== $name"
  dig +short "$name" A
  dig +short "$name" AAAA
done

This loop prints the IPv4 and IPv6 addresses for both the apex and the alias target so you can confirm they line up. For a deeper look at checking from multiple locations, see How to Check if DNS Changes Have Propagated.

You can also script the check in Python with dnspython:

import dns.resolver

def addresses(name):
    found = set()
    for rtype in ("A", "AAAA"):
        try:
            for rdata in dns.resolver.resolve(name, rtype):
                found.add(rdata.to_text())
        except (dns.resolver.NoAnswer, dns.resolver.NXDOMAIN):
            pass
    return found

apex = addresses("example.com")
target = addresses("myapp.example-cdn.net")

print("apex:  ", sorted(apex))
print("target:", sorted(target))
print("overlap:", bool(apex & target))

The script resolves A and AAAA for both names and reports whether they share any addresses. Because CDNs often return different IPs from different locations, "some overlap" is a more realistic success test than "identical sets."

Limitations and Gotchas

ALIAS records are useful, but they are not free of trade-offs.

1. Vendor lock-in. Because there is no standard wire format, an ALIAS does not survive a standard zone export or an AXFR to a secondary provider. If you run multiple DNS providers for redundancy, the secondary typically receives only the resolved A/AAAA values at transfer time, or nothing at all.
2. Geolocation can be less accurate. When the provider resolves your CDN target, the CDN sees the provider's location, not your visitor's. Some providers forward client subnet information to mitigate this; many do not.
3. TTL control is limited. Some providers fix the TTL, some copy the target's TTL, and some cap it. You cannot always shorten it ahead of a migration.
4. Refresh delays. If the provider refreshes the target on a schedule rather than per query, IP changes at your hosting platform can take minutes to show up at the apex.
5. Cloud-native aliases are walled gardens. Route 53 and Azure aliases only point at their own resources. They are great inside that ecosystem and useless outside it.
6. Debugging is harder. Public DNS shows only the final IPs, so you cannot tell from dig alone that an alias exists or what it targets.

If none of these matter for your setup, an ALIAS is usually the cleanest way to put a modern hosting platform on your root domain. If they do matter, the alternatives are static A records (when the platform publishes stable IPs) or redirecting the apex to www, as described in How to Point a Domain to Vercel or Netlify Using DNS.

---

ALIAS and ANAME Records FAQ

Conclusion

An ALIAS or ANAME record is a pragmatic answer to a real limitation in DNS: you cannot put a CNAME on a root domain, but modern hosting platforms want you to point at a hostname rather than an IP. By resolving the target on your behalf and serving plain A and AAAA records, an ALIAS gives you the flexibility of a CNAME with none of the conflicts. The price is that it is a vendor feature rather than a standard, so it behaves differently from provider to provider and does not travel well between them.

If you use one, know exactly how your provider implements it: whether it resolves per query or on a schedule, what TTL it serves, whether it handles IPv6, and how it interacts with secondary DNS. Get those details right and an apex ALIAS is one of the most useful tools in your DNS toolbox.

Here are some useful references for going deeper on ALIAS and ANAME records:

1. AWS Documentation: Choosing between alias and non-alias records — how Route 53 alias records work and which targets they support.
2. Microsoft Learn: Azure DNS alias records overview — Azure's alias record sets and the resources they can reference.
3. Cloudflare Docs: CNAME flattening — how Cloudflare provides ALIAS-like behaviour at the apex.
4. RFC 1034: Domain Names - Concepts and Facilities — the original rule that a CNAME cannot coexist with other data.
5. RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS) — the standards-based alternative that includes an AliasMode.