When setting up a website with Amazon Route 53, many developers face the common requirement of redirecting naked domain requests (example.com) to their www-prefixed counterparts (www.example.com). While this seems straightforward, DNS-level redirects present unique challenges since DNS itself doesn't handle HTTP redirects.

A common misconception is using PTR records for this purpose. PTR records are for reverse DNS lookups (IP to domain mapping), not for HTTP redirects. Attempting this will result in 404 errors since:

• PTR has no HTTP capability
• DNS fundamentally doesn't understand web protocols
• The ALIAS record for your ELB only resolves names, doesn't redirect

Here's the complete AWS stack solution:

1. Route 53 Configuration

First set up your DNS records correctly:

example.com      A      ALIAS to ELB (not recommended)
example.com      A      ALIAS to S3 bucket (for redirect)
www.example.com  A      ALIAS to your ELB

2. S3 Bucket Redirect Setup

Create an S3 bucket named exactly as your naked domain (example.com) with these properties:

1. Enable "Static website hosting" in S3 bucket properties
2. Select "Redirect requests" option
3. Set target domain as www.example.com
4. Choose protocol (HTTP or HTTPS)

3. CloudFront Enhancement (Optional)

For improved performance and HTTPS support:

// CloudFront distribution configuration snippet
{
  "Origins": {
    "S3-Website-example.com.s3-website-us-east-1.amazonaws.com": {
      "DomainName": "example.com.s3-website-us-east-1.amazonaws.com",
      "OriginPath": "",
      "CustomHeaders": {"Quantity": 0},
      "OriginProtocolPolicy": "http-only"
    }
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "S3-Website-example.com.s3-website-us-east-1.amazonaws.com",
    "ForwardedValues": {"QueryString": false, "Cookies": {"Forward": "none"}},
    "ViewerProtocolPolicy": "redirect-to-https",
    "MinTTL": 0
  }
}

Verify your setup with these commands:

# Check DNS resolution
dig example.com
dig www.example.com

# Check HTTP redirects
curl -I http://example.com
# Should return 301 Moved Permanently to www version

# Check HTTPS if configured
curl -I https://example.com

Remember that DNS changes can take up to 48 hours to propagate globally, though typically complete within minutes on AWS.

When setting up a website on AWS infrastructure, many developers face the challenge of redirecting traffic from example.com (the naked domain) to www.example.com. The DNS-level solution is preferred because:

• It avoids unnecessary HTTP requests
• Provides faster redirection
• Simplifies SSL certificate management

PTR records are for reverse DNS lookups (IP to hostname mapping), not for URL redirection. Attempting this results in 404 errors because:

;; ANSWER SECTION:
example.com.      300     IN      PTR     www.example.com.

This configuration is fundamentally wrong for forward resolution.

The most reliable method combines Route 53 with S3 redirect buckets:

1. Create an S3 bucket named exactly as your naked domain (example.com)
2. Configure it for static website hosting with redirect rules:

{
  "RedirectAllRequestsTo": {
    "HostName": "www.example.com",
    "Protocol": "https"
  }
}

Then in Route 53:

example.com.    A    ALIAS   s3-website-us-east-1.amazonaws.com
www.example.com. A    ALIAS   your-elb-dns-name

For more control, set up a CloudFront distribution:

// CloudFront behavior configuration
{
  "ViewerProtocolPolicy": "redirect-to-https",
  "DefaultRootObject": "",
  "ForwardedValues": {
    "QueryString": true,
    "Cookies": {
      "Forward": "all"
    }
  }
}

Create two distributions - one for the naked domain that redirects, and another for the www subdomain that serves your actual content.

• SSL certificates must cover both domains
• Configure proper caching headers (301 permanent redirect)
• Test with curl -I http://example.com to verify headers
• DNS propagation may take up to 48 hours

The S3 method is simplest for most use cases, while CloudFront offers more flexibility for complex architectures. Both solutions maintain SEO value by properly handling the redirect at the infrastructure level.