Introduction

DNS RFC 1034 prohibits placing a CNAME record at the zone apex (the root domain, e.g., example.com without any subdomain). This is because a CNAME at the apex would make all other records for that name (MX, NS, SOA, TXT) invalid, as CNAME is supposed to be the only record type at a name. However, many users want to point their root domain to a CDN, load balancer, or platform service (Heroku, GitHub Pages, Netlify) that provides a CNAME target instead of an IP address.

Symptoms

  • DNS provider rejects CNAME record for @ or example.com
  • dig example.com CNAME returns nothing while dig www.example.com CNAME works
  • Website works at www.example.com but not at example.com
  • DNS provider shows CNAME at apex is not allowed error
  • Root domain returns the hosting provider's default page instead of the intended site

Common Causes

  • Attempting to create a CNAME for the root domain, which violates RFC 1034
  • DNS provider correctly rejecting the invalid CNAME record
  • User needs to point root domain to a service that only provides a CNAME target
  • Domain registrar does not support ALIAS/ANAME pseudo-record types
  • Migration from a provider that allowed apex CNAME to one that enforces RFC compliance

Step-by-Step Fix

  1. 1.Understand the restriction:
  2. 2.```bash
  3. 3.# You cannot have both:
  4. 4.example.com. IN CNAME target.example.net.
  5. 5.example.com. IN MX 10 mail.example.com.
  6. 6.# Because CNAME means "this name is an alias" - no other records can coexist
  7. 7.# But the apex MUST have SOA and NS records, creating a conflict
  8. 8.`
  9. 9.Use ALIAS/ANAME record if your DNS provider supports it:
  10. 10.`
  11. 11.# Cloudflare: CNAME flattening (automatic for proxied records)
  12. 12.# AWS Route53: Alias record (A record pointing to CloudFront/ELB)
  13. 13.# DNSimple: ALIAS record
  14. 14.# DNS Made Easy: ANAME record

# Example in Route53: # Create an A record (not CNAME) with Alias = Yes # Target: the CloudFront distribution or ELB DNS name ```

  1. 1.Use A records if the service provides static IPs:
  2. 2.`
  3. 3.example.com. 300 IN A 185.199.108.153
  4. 4.example.com. 300 IN A 185.199.109.153
  5. 5.example.com. 300 IN A 185.199.110.153
  6. 6.example.com. 300 IN A 185.199.111.153
  7. 7.`
  8. 8.Use a redirect from root to www:
  9. 9.`
  10. 10.# In your DNS provider or web server:
  11. 11.# Set up HTTP 301 redirect from example.com to www.example.com
  12. 12.# This requires a web server at the root domain's IP
  13. 13.`
  14. 14.For Nginx, configure the redirect:
  15. 15.```nginx
  16. 16.server {
  17. 17.listen 80;
  18. 18.server_name example.com;
  19. 19.return 301 https://www.example.com$request_uri;
  20. 20.}
  21. 21.server {
  22. 22.listen 443 ssl;
  23. 23.server_name example.com;
  24. 24.ssl_certificate /etc/nginx/ssl/example.com.pem;
  25. 25.return 301 https://www.example.com$request_uri;
  26. 26.}
  27. 27.`
  28. 28.Switch to a DNS provider that supports ALIAS/ANAME at the apex:
  29. 29.Providers with apex CNAME-like support:
  30. 30.- Cloudflare: Automatic CNAME flattening for proxied records
  31. 31.- AWS Route 53: Alias records for AWS resources
  32. 32.- DNSimple: ALIAS records
  33. 33.- NS1: ANAME records
  34. 34.- Azure DNS: Alias records for Azure resources

Prevention

  • Choose a DNS provider that supports ALIAS/ANAME or CNAME flattening if you need apex redirection
  • Design your DNS architecture around www-first with root domain redirect
  • Document the CNAME-at-apex restriction in DNS change management procedures
  • Use infrastructure-as-code (Terraform) to enforce correct record types
  • Test DNS configuration before switching nameservers to a new provider