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.

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.

Common Use Cases

Apex Domain to CDN

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

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

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.

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.

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

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. No DNSSEC signing - The flattened response loses the target's DNSSEC chain

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

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

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

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.

Testing ALIAS Records

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

# Query the domain
dig example.com A
 
# You'll see A records (the flattened result), not ALIAS
 
# To verify configuration, check the DNScale dashboard
# or use 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

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.