Many developers mistakenly think PTR records are for URL redirection, but they're actually for reverse DNS lookups. The correct approach requires either:

• An Alias record pointing to your A record
• An S3 bucket redirect (for static sites)
• A CloudFront distribution (for dynamic sites)

Here's how to set up the Alias record method (most efficient):

domain.com      A       xxx.xxx.xxx.xxx      300
www.domain.com  A       ALIAS domain.com     300

For static websites, create an S3 bucket named "www.domain.com" with these properties:

{
  "RedirectAllRequestsTo": {
    "HostName": "domain.com",
    "Protocol": "https"
  }
}

For dynamic sites, configure CloudFront with:

1. Two origins (www and non-www)
2. Default cache behavior pointing to non-www origin
3. Route53 Alias records pointing to the CloudFront distribution

If redirects aren't working:

• Check TTL values (lower them during testing)
• Verify DNS propagation with dig www.domain.com
• Ensure no conflicting records exist

To automate the setup:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1D633PEXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.domain.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "domain.com",
          "EvaluateTargetHealth": false
        }
      }
    }]
  }'

First, let's clarify why the PTR record approach doesn't work for this use case. PTR (Pointer) records are used for reverse DNS lookups (IP to domain name resolution), not for forward HTTP redirection. This is a common misconception among developers new to DNS management.

# Incorrect approach (won't work for HTTP redirection)
www.example.com  PTR     example.com           300

There are actually three proper ways to handle www to non-www redirection in AWS:

1. Using S3 Bucket Redirect (Serverless Solution)

If you're hosting a static website, this is the simplest solution:

1. Create an S3 bucket named "www.yourdomain.com"
2. Enable "Static website hosting" in bucket properties
3. Select "Redirect requests" and enter your non-www domain
4. In Route53, create an ALIAS record pointing www to the S3 bucket endpoint

2. Using CloudFront Distribution

For dynamic websites or when using CloudFront:

1. Create a CloudFront distribution for your main domain
2. Add "www.yourdomain.com" as an alternate domain name
3. Configure a second CloudFront distribution for www domain
4. Set the origin to your main domain's CloudFront URL
5. Add a 301 redirect behavior at the viewer request level

3. Using Application Load Balancer (ALB) Rules

If you're using EC2 with ALB:

1. Create a listener rule on your ALB
2. Add condition: Host header = www.yourdomain.com
3. Set action: Redirect to https://yourdomain.com{path}
4. Choose status code: HTTP 301
5. Update Route53 to point www to the ALB

Here's what your Route53 records should look like for the S3 redirect approach:

domain.com      A       ALIAS your-alb-or-cloudfront     300
www.domain.com  A       ALIAS s3-website-us-east-1.amazonaws.com 300
domain.com      NS      ns-xxx.awsdns-xx.com            172800
domain.com      SOA     ns-xxx.awsdns-xx.com            900

After setting up, verify with these commands:

# Check DNS resolution
dig www.yourdomain.com +short

# Check HTTP response
curl -I http://www.yourdomain.com
# Should return 301 Moved Permanently

• Don't mix CNAME and ALIAS records unnecessarily
• Ensure TTL values are appropriate (300 seconds is good for testing)
• Remember DNS changes can take time to propagate globally
• Always test with curl -I to verify HTTP status codes

The S3 redirect method adds about 50-100ms latency. For performance-critical applications, consider:

• Implementing the redirect at your application level
• Using CloudFront Lambda@Edge for sub-millisecond redirects
• Caching the redirect responses aggressively