Technically, RFC 1912 and RFC 1034 prohibit CNAME records at the root domain (apex) because:

; This is NOT allowed per RFC standards
example.com.    IN  CNAME   otherdomain.com.

• DNS protocol requires SOA and NS records at the apex
• CNAME would make these essential records unreachable
• Breaks DNSSEC validation chains

Some DNS providers appear to allow this through non-standard implementations, but these typically:

1. Internally convert to A/AAAA records
2. May break under certain conditions
3. Violate DNS protocol specifications

For redirecting root domains:

; Option 1: Use ALIAS/ANAME records (provider-specific)
example.com.    IN  ALIAS   lb.aws.amazon.com.

; Option 2: Traditional A record with web server redirect
example.com.    IN  A       192.0.2.1

Major services offer specialized solutions:

Using Terraform to create an alias record:

resource "aws_route53_record" "apex" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "example.com"
  type    = "A"

  alias {
    name                   = "d123.cloudfront.net"
    zone_id                = "Z2FDTNDATAQYW2"
    evaluate_target_health = false
  }
}

When using non-CNAME solutions:

• Configure TTLs appropriately (300-600 seconds recommended)
• Monitor IP changes of target services
• Verify DNSSEC compatibility if used

Setting a CNAME record at the root of a domain (often represented as @ in DNS configuration) is a topic that frequently causes confusion. While technically possible in some DNS implementations, there are important technical constraints you should understand.

The primary reason most ISPs and DNS providers prevent CNAME records at the root level stems from RFC 1912 and RFC 1034 specifications:

; THIS WON'T WORK IN MOST DNS SYSTEMS
@  IN  CNAME  example.com.

The restrictions exist because:

• CNAME records can't coexist with other records (MX, NS, TXT, etc.)
• Root domains require additional records for proper DNS resolution
• It violates the "single owner name" principle in DNS standards

Some DNS providers now offer specialized solutions:

1. ALIAS/ANAME Records (DNS Made Easy, Route53)

; Route53 ALIAS example
@  IN  A  123.45.67.89
www  IN  CNAME  example.com.

2. CNAME Flattening (Cloudflare)

; Cloudflare automatically resolves this
@  IN  CNAME  example.com.

3. Using Multiple A Records

; Traditional approach
@  IN  A  123.45.67.89
@  IN  A  123.45.67.90
www  IN  CNAME  example.com.

For services requiring CNAME at root (like GitHub Pages), you'd typically:

; DNS configuration
@  IN  A  185.199.108.153
@  IN  A  185.199.109.153
@  IN  A  185.199.110.153
@  IN  A  185.199.111.153
www  IN  CNAME  yourusername.github.io.

Always verify with dig or nslookup:

dig example.com ANY
nslookup -type=any example.com

Remember that DNS changes can take up to 48 hours to propagate globally.