Skip to content
Control Plane Labs

ALIAS / ANAME record

Provider-specific apex alias that behaves like a CNAME but returns address records. Not standardised.

Last updated July 27, 2026

Zone-file example

; NOT an IANA-registered type — syntax varies by DNS provider
example.com.    300   IN   ALIAS   example-lb.provider.net.
example.com.    300   IN   ANAME   example-lb.provider.net.
; Route 53 spells this as an "alias" flag on an A record, not a record type

Typical uses

  • Pointing a zone apex at a CDN or load-balancer hostname, which CNAME cannot do
  • Keeping example.com and www.example.com on the same provider-managed endpoint
  • Avoiding hardcoded IP addresses for endpoints whose addresses rotate
  • Apex records for PaaS platforms that only publish hostnames

When it breaks, check

  • It is not a standard record type — behaviour, name, and limitations differ per provider
  • You cannot query for ALIAS with dig; the authoritative server flattens it to A/AAAA
  • Flattening happens at the authoritative server, so geo-targeted targets may resolve from the wrong region
  • Migrating providers usually means rebuilding these records by hand

What the ALIAS / ANAME record does

The problem these solve is real: example.com cannot be a CNAME, but the endpoint you want it to point at is a hostname whose addresses change without notice. ALIAS is the workaround. You configure a target hostname, and the authoritative server resolves that hostname on your behalf and serves the resulting addresses as normal A and AAAA records at the apex. Clients see nothing unusual — there is no ALIAS record on the wire, because it is a server-side behaviour rather than a protocol feature.

The cost is portability. This is vendor configuration, not DNS.

Zone-file and wire format

There is no wire format, because ALIAS is never transmitted. Each provider invents its own zone-file spelling: some call it ALIAS, some ANAME, Cloudflare calls the behaviour CNAME flattening, and Route 53 models it as an “alias target” property on an A or AAAA record rather than a distinct type. The IETF attempted to standardise the idea as ANAME in draft-ietf-dnsop-aname, but the draft expired without becoming an RFC.

; What you configure (provider-specific):
example.com.     300   IN   ALIAS   example-lb.provider.net.

; What the world actually sees when it queries:
example.com.     300   IN   A       203.0.113.10
example.com.     300   IN   AAAA    2001:db8::10

; dig example.com ALIAS returns nothing useful — the type does not exist on the wire.

Common uses

The overwhelmingly common use is apex-to-CDN. If you want https://example.com/ served by a CDN or a platform such as a managed Kubernetes ingress, and the platform only gives you a hostname, ALIAS is the clean answer. The alternative — hardcoding the platform’s current IP addresses in an A record — works until the platform rotates them, at which point your apex points at someone else’s infrastructure. Prefer ALIAS over pinned addresses whenever your provider offers it.

Troubleshooting

Because the flattening happens on the authoritative server, geographic and latency-based targets can resolve badly. If the target hostname returns different addresses depending on who asks, the answer your apex publishes reflects where your DNS provider’s resolver sits, not where your users are. That can quietly send European traffic to a US edge. Providers that support EDNS Client Subnet mitigate this; most document whether they do.

You also cannot verify the configuration with a query for the type itself. Query for A and AAAA at the apex and compare with the target’s own answers.

# there is no ALIAS type on the wire; query the flattened result
dig example.com A +short
dig example.com AAAA +short

# compare against the target the provider is following
dig example-lb.provider.net A +short

# confirm the apex is not (illegally) publishing a CNAME
dig example.com CNAME +noall +answer

The defining RFC

There is no defining RFC, and that is the single most important fact about these records. The type is absent from the IANA DNS Parameters registry, the standardisation attempt at draft-ietf-dnsop-aname expired, and the underlying prohibition it works around is RFC 1034 §3.6.2. The standards-track answer to the same problem for HTTP services is the HTTPS record from RFC 9460, which does support the apex. Treat ALIAS as useful vendor tooling that you will have to reconfigure if you migrate providers.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types