DNS Records & Concepts
What is an ALIAS record?
An ALIAS record, also called an ANAME record depending on the DNS provider, is a non-standard DNS record type that provides CNAME record behaviour for root domains where standard CNAME records are prohibited. It allows a domain apex, example.com without any subdomain prefix, to point to another hostname rather than directly to an IP address, while remaining compatible with the DNS specification requirements that make standard CNAMEs impossible at the apex.
The need for ALIAS records arises from a fundamental restriction in the DNS specification. CNAME records cannot be placed at the zone apex because the apex must have NS records and SOA records: the records that define the zone’s authoritative nameservers and administrative information. A CNAME at the apex would create a conflict because a CNAME declares the name is an alias for another name, meaning all records should be looked up at the target. Having both a CNAME and NS records for the same name is contradictory.
This restriction matters enormously in practice because many hosting platforms, CDNs, and redirect management services provide a hostname, proxy.redirect.supply, sites.platform.com: rather than a fixed IP address for their infrastructure. Subdomains like www.example.com connect to these services easily via CNAME. Root domains cannot use CNAME. Without ALIAS records the only option is A records pointing to specific IP addresses, which breaks when the service changes its infrastructure.
ALIAS records solve this by resolving the target hostname to its current IP address at the DNS provider level and returning an A-record-style response to resolvers, CNAME-like behaviour without the DNS specification conflict.
How an ALIAS record works
The key distinction between an ALIAS record and a CNAME record is where the hostname resolution happens.
With a standard CNAME record the alias is returned to the resolver which then performs a second lookup for the target hostname. The resolver does the work of following the alias chain. This is why CNAMEs cannot exist at the apex, the resolver receives the CNAME response and needs to follow it, but the apex must simultaneously serve NS records directly to resolvers, creating a contradiction.
With an ALIAS record the resolution happens at the authoritative nameserver level, at the DNS provider, before the response is sent to the resolver. When a resolver queries the nameserver for an ALIAS record the nameserver resolves the target hostname to its current IP address internally and returns an A-record-style response to the resolver. The resolver never sees the ALIAS, it receives what appears to be a regular A record response.
From the resolver’s perspective and from the perspective of every downstream system an ALIAS-configured apex domain looks identical to one with a static A record. The difference is only in how the authoritative nameserver generates the response. Because the DNS provider performs the resolution internally it can keep the returned IP address current as the target hostname’s IP address changes, providing the same automatic update behaviour that CNAMEs provide for subdomains.
A typical ALIAS record configuration looks like:
When a resolver queries the authoritative nameserver for example.com the nameserver resolves proxy.redirect.supply to its current IP address, say 104.21.30.120: and returns:
The resolver caches this A record and uses it to connect. The next time the resolver queries the nameserver, after the record’s TTL expires, the nameserver resolves proxy.redirect.supply again. If the IP address has changed the resolver receives the updated address automatically.
ALIAS vs CNAME, when each is used
The practical rule for choosing between ALIAS and CNAME is simple, use CNAME for subdomains and ALIAS for root domains.
CNAME for subdomains: www.example.com, shop.example.com, blog.example.com. Any subdomain can use a CNAME to alias another hostname. The CNAME is stored in the zone and returned to resolvers directly. Standard, widely supported, works everywhere.
ALIAS for root domains: example.com without any subdomain prefix. The ALIAS allows the root domain to point to a hostname like a CNAME does, without the DNS specification conflict. Non-standard, supported only by specific DNS providers, but the only way to point a root domain to a hostname rather than a fixed IP address without changing nameservers.
The choice is not about preference, it is about what the DNS specification allows. Root domains need ALIAS. Subdomains use CNAME.
ALIAS records and redirect management
ALIAS records are a critical enabler for connecting root domains to redirect management infrastructure when the redirect service provides a hostname rather than a fixed IP address.
The root domain connection problem: when connecting a domain to a redirect management platform the standard approach for subdomains is a CNAME record pointing to the platform’s hostname. For root domains this is impossible without ALIAS. Many domain owners discover this limitation when trying to redirect example.com: without www, and finding that CNAME is not an option.
Solutions for root domain redirect management
The correct solution depends on what the DNS provider and redirect management platform support.
ALIAS/ANAME records: the cleanest solution when the DNS provider supports them. Configure an ALIAS record at the root domain pointing to the redirect management platform’s hostname. The root domain behaves like a CNAME-connected subdomain, automatically following infrastructure changes without requiring DNS updates.
Cloudflare CNAME flattening: using Cloudflare as the DNS provider and configuring a CNAME at the root domain in the Cloudflare interface. Cloudflare flattens it to an A record before serving to resolvers. Requires changing nameservers to Cloudflare.
A records with stable IP addresses: some redirect management platforms provide stable, fixed IP addresses that can be configured as A records at the root domain. This works when the infrastructure IP addresses do not change, or when the platform guarantees IP stability. Requires manual A record updates if the platform ever changes its IP addresses.
Redirecting root to www: configuring the root domain’s A record to point to a server that issues a hard redirect to www.example.com where a CNAME connects to the redirect management platform. The root domain itself performs only the www redirect, all redirect management rules apply to the www subdomain.
SSL certificate provisioning: connecting a root domain to redirect infrastructure via ALIAS requires SSL certificate provisioning for the root domain. The redirect management platform needs a valid SSL certificate that covers example.com to handle HTTPS connections before issuing redirect responses. Platforms that automatically provision SSL, using Let’s Encrypt or another CA, handle this as part of domain connection.
ALIAS records and email
Unlike CNAME records, ALIAS records can coexist with MX records for the same domain name. This is one of the important advantages of ALIAS over CNAME for root domain management.
Because ALIAS records are resolved to A record responses by the authoritative nameserver before being served to resolvers there is no contradiction with having MX records at the same name. The resolver sees what appears to be an A record and MX records at the apex, a perfectly valid combination.
This means a domain can simultaneously have an ALIAS record connecting the root domain to redirect management infrastructure and MX records routing email to the appropriate mail servers. Both coexist without conflict, exactly as A records and MX records coexist for domains using fixed IP addresses.
This email compatibility is one of the key advantages of ALIAS over attempting to use CNAMEs at the apex, CNAMEs cannot coexist with MX records, making them fundamentally incompatible with email-enabled root domains.
Performance characteristics of ALIAS records
ALIAS records introduce an additional DNS resolution step compared to A records, the provider must resolve the target hostname to its IP address before serving the response. This internal resolution happens at the provider’s infrastructure and is typically very fast, often faster than a resolver performing a full DNS lookup because the provider caches the target hostname’s IP address aggressively.
The TTL of an ALIAS record response is typically tied to the lower of the ALIAS record’s own TTL and the target hostname’s A record TTL. If the target hostname’s A record has a shorter TTL than the ALIAS record the resolver receives responses with the shorter TTL, ensuring it queries more frequently and receives updated IP addresses when the target changes.
Some DNS providers implement ALIAS records with additional optimisations, GeoDNS-aware resolution that returns the IP address of the target closest to the resolver, or anycast resolution that improves connection latency. These optimisations make ALIAS records for root domains on sophisticated DNS providers competitive with or superior to static A records in performance terms.
Checking ALIAS records
ALIAS records appear as A record responses when queried from resolvers, the ALIAS implementation is hidden from the outside world. Checking whether a domain uses an ALIAS record requires querying the authoritative nameserver directly or checking the DNS provider’s management interface.
From a resolver, appears as an A record:
Returns an IP address. This looks identical to a static A record response. There is no external way to distinguish an ALIAS-generated A record from a static A record.
From the authoritative nameserver:
Some providers return the ALIAS target as a CNAME-like record in the authority section when queried directly. Others return only the flattened A record. The DNS provider’s own management interface is the most reliable way to confirm an ALIAS record is configured.
Indirect verification: configure an ALIAS record, note the IP address returned by a resolver, then have the target hostname’s IP address changed by the service it points to, and query again. If the IP address in the DNS response updates automatically the ALIAS is working correctly. This is rarely practical as a routine check but confirms the dynamic resolution behaviour distinguishing ALIAS from static A records.
Common ALIAS record mistakes
DNS provider does not support ALIAS: attempting to configure a root domain hostname connection with a provider that only offers standard record types. The provider may not show ALIAS or ANAME as an option. The solution is to change nameservers to a provider that supports ALIAS or use A records with the platform’s IP addresses.
Confusing ALIAS with A records: entering a hostname in an A record field rather than an IP address. Most DNS management interfaces accept this as valid input for A records but produce a broken record, an A record must contain an IP address, not a hostname. The ALIAS record type field must be used explicitly.
ALIAS pointing to non-existent hostname: the target hostname specified in the ALIAS record does not resolve to any IP address, the service was decommissioned or the hostname changed. The ALIAS-configured root domain stops resolving and visitors receive DNS errors.
TTL mismatch causing stale IP addresses: setting an excessively high TTL on the ALIAS record. If the target hostname’s IP address changes resolvers cache the old IP address for the full ALIAS record TTL before querying again. A moderate TTL, 300 to 3600 seconds, balances performance with responsiveness to infrastructure changes.
Using ALIAS for subdomains when CNAME is available: ALIAS records are not wrong for subdomains, they work correctly, but CNAME records are more widely supported and standardised for subdomains. Use CNAME for subdomains and ALIAS only where CNAME is prohibited, at the apex.