Naked Domains for the Cloud

Most cloud services require you to create a CNAME record for your custom domain in order to direct traffic to the cloud-hosted site. Your example.com site may actually be hosted at example.cloudapp.net. For on-premises hosting you would know the IP address of your server (or the load balancer) and can use an A record, but that is not the case on Azure or AWS: these require that pesky CNAME.

CNAME records don’t support naked domains. Your site has to be at www.example.com, it can’t be at simply example.com, the root, or apex, record of your domain. On the other hand, A records can only support IP addresses.

There are a number of solutions to this problem, so I’ll list some here:

1. Use HTTP Redirection that redirects example.com to www.example.com via a 301. Not all DNS hosters offer this. This is not ideal, but at least your site will be found.

2. Use a redirect service like wwwizer. Point your naked/root domain to 174.129.25.170 and all requests to example.com will be redirected to www.example.com. It works; I use it. This is very similar to using a DNS hoster’s HTTP redirect.

3. Use the cloud service’s own forwarding:

  • AWS allows DNS forwarding using Route53 and Elastic Load Balancer. Read more here.
  • Google Apps forwarding of naked domains to your Google-hosted site. More here.
  • Use Azure’s own…oh wait, Azure doesn’t offer this yet.
  • Instead, you can use DNS Azure, a $2.99/month dynamic DNS on steroids, specifically for Azure. This is faster than the potential multiple redirects of the other solutions.

4. Use DNSMadeEasy’s newly-created ANAME record. This works like a hybrid between an A record and a CNAME: You can forward the root (aka apex, aka naked) domain record to another fully qualified url (like example.cloudapp.net). In practice, this is very similar to the service offered by DNS azure. Both do direct forwarding to your server’s actual IP address, dynamically and instantly updated when the IP address changes. Unlike DNS Azure this obviously is not tied to Azure, or to any cloud service. It’s regular DNS hosting as well.

Let your domains go naked! It’s liberating.

Image copyright (c) 123RF Stock Photos

About Oskar Austegard

Oskar Austegard is a Project Manager and Solutions Architect with 15 years of varied industry experience, working with firms ranging in size from 2 person startups to ExxonMobil. Oskar is passionate about web development, especially JavaScript and Html5, and has lately led the teams responsible for sites such as the Vogue Archive and Rolling Stone All Access. He can also be found on his personal blog mo.notono.us and on Twitter at @austegard.

  • PS!  You CAN create an A name record for Azure hosted webroles, with some caveats.
    https://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns/ 

    A recordWith an A record, you map a domain (e.g., contoso.com or http://www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure hosted service. Accordingly, the lifetime of this IP address is the lifetime of a deployment within your hosted service. The IP address gets created the first time you deploy to an empty slot (either production or staging) in the hosted service and is retained by the slot until you delete the deployment from that slot. You can discover this IP address from within the Windows Azure Management Portal.The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., http://www.contoso.com).Note, however, because the lifetime of the IP address is associated with a deployment, it is important not to delete your deployment if you need the IP address to persist. Conveniently, the IP address of a given deployment slot (production or staging) is persisted when using the two upgrade mechanisms in Windows Azure: VIP swaps and in-place upgrades.