Setting up a CNAME record for a root domain (apex domain) has historically been problematic due to DNS protocol restrictions. While RFC 1034 permits CNAME records at the domain root through its USC-ISIC.ARPA example, many DNS providers traditionally blocked this configuration.

Amazon S3's elastic infrastructure requires dynamic IP resolution that traditional A records can't accommodate:

# Bad approach - S3 IPs change frequently
example.com. 300 IN A 52.216.136.179
example.com. 300 IN A 52.216.136.180

Leading DNS services now offer root domain CNAME flattening or ALIAS records:

// Route 53 ALIAS record configuration
{
    "Name": "example.com",
    "Type": "A",
    "AliasTarget": {
        "HostedZoneId": "Z3AQBSTGFYJSTF",
        "DNSName": "s3-website-us-east-1.amazonaws.com"
    }
}

Cloudflare and others implement CNAME flattening automatically:

;; Cloudflare's implementation
example.com. 300 IN CNAME example.com.cdn.cloudflare.net.
;; Resolves to current S3 IPs behind the scenes

For this to work, your S3 bucket must:

• Have the exact same name as your domain (e.g., "example.com")
• Be configured for website hosting
• Have proper bucket policies allowing public access

When testing your configuration:

dig example.com +trace
nslookup example.com
curl -v http://example.com

Watch for DNS caching issues - use TTL values under 300 seconds during setup.

Most DNS configurations use A records for root domains (e.g., example.com) because they directly map to IP addresses. However, when integrating with services like AWS S3 that frequently change IPs for load balancing, a CNAME record becomes necessary. The problem? Traditional DNS wisdom claims CNAMEs shouldn't be used for root domains.

RFC 1034 section 3.6.2 actually permits CNAME records at the root level, as demonstrated by the USC-ISIC.ARPA example. Here's why this works:

example.com.     300  IN  CNAME  s3-website-us-east-1.amazonaws.com.
s3-website-us-east-1.amazonaws.com. 60 IN A 52.217.130.43

First, set up your S3 bucket to serve as a website:

aws s3api create-bucket --bucket example.com
aws s3 website s3://example.com --index-document index.html

Different providers handle root CNAMEs differently. Here are examples for common services:

Route 53 (AWS)

{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "example.com",
      "Type": "CNAME",
      "TTL": 300,
      "ResourceRecords": [{
        "Value": "s3-website-us-east-1.amazonaws.com"
      }]
    }
  }]
}

Cloudflare

Cloudflare calls this a "CNAME Flattening" feature:

; Cloudflare automatically resolves to current S3 IP
example.com.     CNAME   s3-website-us-east-1.amazonaws.com
www.example.com. CNAME   example.com

After setting up, verify with dig:

dig example.com +nostats +nocomments +nocmd

; ANSWER SECTION
example.com.     300  IN  CNAME  s3-website-us-east-1.amazonaws.com.
s3-website-us-east-1.amazonaws.com. 60 IN A 52.217.130.43

Some DNS providers offer special record types that behave like CNAMEs at the root:

; DNSimple ALIAS example
example.com.    ALIAS   s3-website-us-east-1.amazonaws.com.

• MX records won't work with root CNAMEs
• Some email providers may have delivery issues
• Not all DNS providers support root CNAMEs
• TTL values become dependent on the target's records