What Is an ALIAS Record

An ALIAS record (also known as ANAME or CNAME flattening) provides CNAME-like functionality at the root (apex) domain. While standard CNAME records cannot be used at the apex, ALIAS records solve this limitation by automatically resolving the target to IP addresses.

Why ALIAS Records Exist

DNS standards prohibit CNAME records at the apex because CNAME cannot coexist with other record types, and every zone requires SOA and NS records at the apex.

The problem:

# NOT ALLOWED - CNAME at apex
example.com.    CNAME    myapp.cloudprovider.com.
 
# ALLOWED - CNAME at subdomain
www.example.com.    CNAME    myapp.cloudprovider.com.

The solution:

# ALLOWED - ALIAS at apex
example.com.    ALIAS    myapp.cloudprovider.com.

This is the core reason ALIAS records were invented. Modern cloud platforms and CDNs typically provide hostnames rather than static IP addresses. Without ALIAS, pointing an apex domain to these services requires manually maintaining A records with IP addresses that may change at any time.

For a detailed comparison of when to use each record type, see CNAME vs A Record.

How ALIAS Records Work

ALIAS records work differently from CNAME:

1. CNAME: Returns the target hostname; client resolves it
2. ALIAS: DNS server resolves the target and returns IP addresses

# Client queries example.com
# DNS server internally resolves myapp.cloudprovider.com
# Client receives A/AAAA records directly
 
example.com.    ALIAS    myapp.cloudprovider.com.
 
# Client sees:
example.com.    300    A    192.0.2.1
example.com.    300    A    192.0.2.2

This "flattening" happens at the authoritative DNS server, making the ALIAS transparent to clients. From the resolver's perspective, the response looks exactly like a normal A record or AAAA record response. No special client support is needed.

The term "CNAME flattening" comes from this behavior: the CNAME-like chain is "flattened" into a direct address response by the authoritative server.

ALIAS vs CNAME: Key Differences

While both ALIAS and CNAME point to another hostname, their behavior differs in important ways:

For subdomains, standard CNAME is usually the better choice because it is universally supported and lets the resolver cache the CNAME chain independently. ALIAS is specifically designed for the apex domain problem.

Common Use Cases

Apex Domain to CDN

Point root domain to Cloudflare, AWS CloudFront, or other CDNs:

example.com.    3600    ALIAS    cdn.cloudprovider.com.

CDNs use anycast routing to serve content from geographically distributed edges. The ALIAS record follows the CDN's DNS resolution, which may return different IPs based on the querier's location, supporting global DNS resolution balancing.

Apex to Cloud Platform

Point root domain to Heroku, Netlify, Vercel, etc.:

example.com.    3600    ALIAS    myapp.herokuapp.com.
example.com.    3600    ALIAS    mysite.netlify.app.
example.com.    3600    ALIAS    myproject.vercel.app.

Apex to Load Balancer

Point root domain to AWS ELB/ALB:

example.com.    3600    ALIAS    my-lb-123456.us-east-1.elb.amazonaws.com.

Combined with CNAME for www

; Apex uses ALIAS
example.com.        3600    ALIAS    myapp.cloudprovider.com.
 
; www uses standard CNAME
www.example.com.    3600    CNAME    myapp.cloudprovider.com.

This is a common pattern: ALIAS at the apex for CNAME-like behavior, and a regular CNAME on www since it is a subdomain and has no restriction. Both point to the same target, ensuring consistent behavior whether visitors use example.com or www.example.com.

ALIAS vs CNAME vs A Record

Record Format

Adding an ALIAS Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Use @ for apex domain
   • Type: Select ALIAS
   • Value: Enter the target hostname
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create an ALIAS record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "ALIAS",
    "content": "myapp.cloudprovider.com",
    "ttl": 3600
  }'

Point apex to AWS CloudFront:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "ALIAS",
    "content": "d1234567.cloudfront.net",
    "ttl": 300
  }'

Point apex to Vercel:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "ALIAS",
    "content": "cname.vercel-dns.com",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "example.com.",
      "type": "ALIAS",
      "content": "myapp.cloudprovider.com.",
      "ttl": 3600,
      "disabled": false
    }
  }
}

How DNScale Resolves ALIAS Records

When a client queries an ALIAS record:

1. Client asks DNScale for example.com
2. DNScale sees ALIAS pointing to target.provider.com
3. DNScale resolves target.provider.com (gets IPs)
4. DNScale returns those IPs as A/AAAA records for example.com

This resolution happens in real-time, so IP changes at the target are automatically reflected. DNScale resolves both IPv4 and IPv6 addresses, returning A and AAAA records as appropriate. For details on IPv4 vs IPv6 considerations, see IPv6 vs IPv4.

TTL Behavior

ALIAS record TTL affects how often DNScale re-resolves the target:

• Short TTL (300s): More frequent updates, follows target changes quickly
• Long TTL (3600s): Less DNS traffic, but slower to reflect changes

The TTL returned to clients is typically the minimum of:

• Your ALIAS TTL setting
• The target's actual A/AAAA record TTL

For guidance on choosing TTL values, see DNS TTL Best Practices.

Provider Support

Because ALIAS is not a standardized DNS record type, different providers implement it differently:

If you are using multi-provider DNS, be aware that ALIAS behavior may differ between providers. A record that works in DNScale may need a different configuration at another provider. For portability, you can also manage ALIAS records through the DNScale Terraform provider or DNSControl.

Limitations

1. Provider-specific -- ALIAS is not a standard DNS record type; implementation varies by provider

2. Single value -- Like CNAME, only one ALIAS record per name

3. Resolution latency -- Initial queries may be slightly slower while target is resolved

4. DNSSEC considerations -- The flattened response loses the target's DNSSEC chain. DNScale signs the flattened A/AAAA response with your zone's DNSSEC keys, so the response is authenticated, but the chain of trust from the target domain is not preserved.

5. IPv4/IPv6 handling -- DNScale returns both A and AAAA if the target has both

Best Practices

1. Use for apex only -- For subdomains, standard CNAME is usually better

2. Verify target is valid -- Ensure the target hostname resolves correctly before creating the ALIAS

3. Consider HTTPS records -- For modern browsers, HTTPS records may be a better option for apex web services

4. Use shorter TTLs -- Shorter TTLs ensure faster propagation of target IP changes

5. Monitor resolution -- Check that ALIAS records are resolving to expected IPs

6. Maintain TXT records separately -- ALIAS coexists with TXT, so your SPF, DKIM, and DMARC records work normally at the apex

ALIAS vs HTTPS Record at Apex

For web services, you have two options at the apex:

; Combined approach
example.com.    3600    ALIAS    cdn.provider.com.
example.com.    3600    HTTPS    0 cdn.provider.com.

The ALIAS ensures all clients can reach the site, while the HTTPS record enables modern browsers to use HTTP/3 and other optimizations from the first connection.

Testing ALIAS Records

Since ALIAS records are flattened, you'll see A/AAAA records in the response:

# Query the domain - you'll see A records, not ALIAS
dig example.com A
 
# Check for both A and AAAA
dig example.com A +short
dig example.com AAAA +short
 
# Verify the resolved IPs match the target
dig myapp.cloudprovider.com A +short
 
# To verify the ALIAS configuration, use the DNScale dashboard
# or query the API to list records

Related Record Types

• CNAME -- Standard aliasing (subdomains only)
• A -- Direct IPv4 mapping
• AAAA -- Direct IPv6 mapping
• HTTPS -- Modern alternative for web services
• SVCB -- General service binding
• NS -- Nameserver delegation
• DNS Record Types -- Overview of all DNS record types

Conclusion

ALIAS records solve the apex domain aliasing problem that has long plagued DNS configuration. By automatically resolving target hostnames to IP addresses, ALIAS records give you the flexibility of CNAME at the root domain. DNScale's ALIAS support makes it easy to point your apex domain to CDNs, cloud platforms, and load balancers without manually managing IP addresses.