How to Redirect Root Domain to www Using DNS Records (CNAME, ALIAS, or URL Forwarding)


2 views

Many developers face this common scenario: your www subdomain works perfectly with a CNAME record pointing to your cloud provider (like Azure), but the root domain (mydomain.com) doesn't resolve. This happens because:

  • Most cloud platforms only allow CNAME records at subdomains
  • Root domains typically require A or ALIAS records
  • DNS providers have varying capabilities for forwarding

Option 1: ALIAS/ANAME Records (Recommended)

Modern DNS providers offer special record types that function like CNAMEs at the root:

; Cloudflare example
mydomain.com.    ALIAS   mydomain.azurewebsites.net.
www.mydomain.com. CNAME  mydomain.azurewebsites.net.

Supported by: Cloudflare, DNSimple, AWS Route 53 (as ANAME), and others.

Option 2: URL Forwarding (Where Available)

Some registrars/DNS providers offer web forwarding:

; Namecheap example
@  URL-Redirect  https://www.mydomain.com

Option 3: A Record with Cloud IP (Last Resort)

For Azure specifically, you can use the IP address (not recommended for cloud services):

mydomain.com.    A       20.42.229.228
www.mydomain.com. CNAME  mydomain.azurewebsites.net.

Warning: IPs may change without notice in cloud environments.

Azure DNS Solution

If using Azure DNS, create an alias record set:

# Azure CLI
az network dns record-set a add-record \
    --resource-group mydnsgroup \
    --zone-name mydomain.com \
    --record-set-name "@" \
    --ipv4-address mydomain.azurewebsites.net

Cloudflare Workers Alternative

For advanced control with JavaScript:

// Worker script for root domain redirection
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)
  if (url.hostname === 'mydomain.com') {
    return Response.redirect('https://www.mydomain.com' + url.pathname, 301)
  }
  return fetch(request)
}

Always verify with dig or online DNS checkers:

dig mydomain.com +nostats +nocomments +nocmd
dig www.mydomain.com +nostats +nocomments +nocmd

Look for proper resolution and check TTL values for propagation timing.

Remember that SSL certificates must cover both versions of the domain. Most CA's provide both automatically when you request www.mydomain.com.

When configuring Azure Web Apps, many developers encounter a limitation: Azure only officially supports custom domains through www subdomains. The naked domain (mydomain.com) can't be directly mapped to Azure's infrastructure. Here's what typically works:

www.mydomain.com. 3600 IN CNAME mydomain.azurewebsites.net.

But attempting to create an identical CNAME for the root domain won't work due to DNS protocol restrictions (RFC 1912). This leaves us needing alternative solutions.

Since not all DNS providers support URL forwarding (like ZoneEdit in this case), here are alternative approaches:

; Option 1: ALIAS/ANAME record (supported by some providers)
mydomain.com. 3600 IN ALIAS mydomain.azurewebsites.net.

; Option 2: URL/Web Forwarding (when available)
mydomain.com. 3600 IN URL 301 https://www.mydomain.com

For providers lacking forwarding capabilities, consider these methods:

1. Azure Front Door Solution:

// Azure CLI command to create Front Door
az network front-door create \\
    --resource-group myResourceGroup \\
    --name myFrontDoor \\
    --accepted-protocols Http Https \\
    --backend-address mydomain.azurewebsites.net

Then configure both root and www as custom domains in Front Door.

2. Cloudflare Proxy Approach:

# Page Rule configuration in Cloudflare
Pattern: mydomain.com/*
Setting: Forwarding URL
Status: 301 Permanent Redirect
Destination URL: https://www.mydomain.com/$1

After implementing any solution, verify with these commands:

# Check DNS records
dig mydomain.com +nostats +nocomments +nocmd
dig www.mydomain.com +nostats +nocomments +nocmd

# Test HTTP redirects
curl -I http://mydomain.com
curl -I https://mydomain.com

Expected output should show 301 redirect status and proper Location header.

  • SSL certificates must cover both www and root domains
  • Search engine indexing should consolidate to one preferred version
  • Test redirect chains to avoid infinite loops
  • Monitor DNS propagation times when making changes