Setting up proper DNS records is crucial for website accessibility. The classic scenario involves:

example.com.    IN  A      192.0.2.1
www.example.com. IN ?      ?

Using a CNAME for www is technically valid:

www.example.com. IN  CNAME example.com.

However, this configuration can cause issues because:

• Some DNS tools expect direct A records for www
• Certain email servers may reject domains with CNAME at root
• DNS resolution takes an extra hop

Option 1: Dual A Records

example.com.    IN  A      192.0.2.1
www.example.com. IN  A      192.0.2.1

Option 2: CNAME with A Record Fallback

; Preferred configuration
example.com.    IN  A      192.0.2.1
www.example.com. IN  CNAME example.com.
; Fallback for strict validators
www.example.com. IN  A      192.0.2.1

Use these commands to verify your setup:

dig example.com A +short
dig www.example.com A +short
nslookup www.example.com

While CNAME records add minimal overhead (typically 10-50ms), for high-traffic sites:

• A records resolve faster as they don't require additional lookups
• CNAME chains should be limited to 1-2 hops maximum
• TTL values become more critical with CNAMEs

AWS Route 53:

{
    "Changes": [{
        "Action": "CREATE",
        "ResourceRecordSet": {
            "Name": "www.example.com",
            "Type": "CNAME",
            "TTL": 300,
            "ResourceRecords": [{"Value": "example.com"}]
        }
    }]
}

DigitalOcean:

Hostname    Record Type    Value          TTL
@           A              192.0.2.1      3600
www         CNAME          @              3600

---

When setting up domain records, many developers face this exact scenario:
example.com works perfectly with an A record pointing to your server's IP (e.g., 192.0.2.1),
but the www subdomain creates confusion. Let's examine the technical considerations.

A Records directly map a hostname to an IPv4 address:

example.com.   3600  IN  A  192.0.2.1

CNAME Records create aliases pointing to other hostnames:

www.example.com.  3600  IN  CNAME  example.com.

DNS validation tools like intodns.com report errors because:

• CNAME resolution requires an additional lookup step
• Some strict validators expect direct A records for root domains
• Certain legacy systems don't properly handle CNAME chains

For maximum compatibility, consider these approaches:

Option 1: Dual A Records (Most reliable)

example.com.     3600  IN  A  192.0.2.1
www.example.com. 3600  IN  A  192.0.2.1

Option 2: CNAME with A Record Fallback

example.com.     3600  IN  A     192.0.2.1
www.example.com. 3600  IN  CNAME example.com.
www.example.com. 3600  IN  A     192.0.2.1

For cloud deployments using AWS Route 53:

{
  "Comment": "Production DNS configuration",
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com",
      "Type": "A",
      "TTL": 300,
      "ResourceRecords": [{ "Value": "192.0.2.1" }]
    }
  },
  {
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "www.example.com",
      "Type": "A",
      "TTL": 300,
      "ResourceRecords": [{ "Value": "192.0.2.1" }]
    }
  }]
}

While CNAMEs offer flexibility, they introduce:

• Additional DNS lookup latency (typically 50-200ms)
• Potential issues with SSL certificate validation
• Complexity when implementing DNSSEC

For production websites, maintain parallel A records for both root domain and www subdomain. Reserve CNAME usage for:

• Third-party service integrations (e.g., CDN endpoints)
• Staging environments with dynamic IPs
• Complex microservice architectures