I’ve worked mostly with Amazon’s AWS cloud services in the past, but because of my Microsoft development background I’ve been keeping a close watch on their Windows Azure cloud services.
With Microsoft’s preview release of Azure Web Sites, I decided it was finally time to take the plunge and setup a real website. I’m in the process of developing a new Windows 8 app for the digital home, so it made perfect sense to incorporate Windows Azure. I’m also making use of the new Orchard open source CMS platform, so a number of new technologies are being involved – making this a good test.
I won’t go through all the details, but for the most part creating a new Azure website has been intuitive. That is, until I reached the point of adding a custom domain.
It’s not clear if Microsoft’s goal is to target the shared hosting market with their newest Website product. If so, then in my opinion, they have a definite stumbling block with configuring a custom domain.
In order to better understand, it helps to first take a step back.
A Typical Shared Hosting Experience
In the past I’ve used shared, VPS, dedicated and cloud hosting services for Linux, Nginx and Windows hosting providers. When I first started, even though I was a technically inclined person, I was somewhat clueless in this area and depended on hosting signup being simple.
People and small businesses getting started with website hosting would probably be best served by starting out with one of the introductory Linux shared hosting options at Hostgator.com. This is where I started – it’s easy, affordable, and they offer great support.
One of the first questions most hosting providers will ask when you sign up is whether or not you need a domain name. If you don’t need a new one, then they will ask you what is the domain name that you will be transferring?
If you need one, most likely they will register it for you and take care of everything involved with setting one up, after you’ve paid. By the time they are finished, you will be able to type your new domain name into your browser’s URL address and start building your site (you may have to wait up to 48 hours for the new domain name to be recognized across the entire internet).
If you already have a domain name, they will need to know what it is. A part of their process for creating you a new hosting account requires them to configure this domain name. This doesn’t mean that your current website becomes active on your new hosting account – you still may have lots of work to do in moving it. It just simply means that when you’re ready, go into your domain name’s registrar account (e.g. Godaddy.com) and change it to point to your new hosting provider, then everything will work.
Most hosting providers will give you detailed instructions on what needs to be changed at your domain’s registrar – usually it’s simply changing the name servers. The reason for this is that you own the domain name and they cannot do it for you. That’s a good thing!
Which brings us back to Windows Azure Websites: If you are expecting this same level of simplicity when managing your custom domain name, forget it! Not only are you going to have to go a level deeper in complexity by modifying the actual DNS records for your domain, you are also going to have to prove that you have the rights to use it.
Domain Name DNS Management 101
I’m not a DNS expert by any stretch of my imagination, but I have done it enough times now that I can find my way around and use scalable DNS providers such as Amazon’s Route 53 service.
With DNS management you start dealing with questions like: What are “A” records? What are “CNAME” or “MX” records? What’s the difference between each of them? Why can’t I just change my name servers instead? What’s my actual domain name? Is it www.contoso.com or… just contoso.com? Do I enter an “A” record for both of these? Or should one or both have a “CNAME” record instead?
Along with the above DNS questions is the fact that whenever you make changes to your DNS records, it can take anywhere from a few seconds to as much as 48 hours for the changes to take effect. The warning message will tell you this when you click the confirm button in your DNS management screen – it takes time to propagate these changes across the entire internet.
The reason for this is that DNS is at the core of the internet. It is responsible for converting your domain name to a specific IP address so that it can find your server on the internet.
To make this conversion process faster, many points on the internet will make a local copy (cache) instead of looking back to your registrar every time. The end result is that when you change your DNS settings, it takes time for all of these local copies across the internet to be updated.
The bottom line with DNS changes is that you may not know for sure if the DNS change you made was actually the right change… for up to 48 hours…
Starting to get the picture? It can be a very intimidating task the first time.
Getting back to Windows Azure Website custom domain management, make sure you are comfortable with doing this level of domain name changes before heading down this path.
Windows Azure Custom Domain Name Validation Overview
When you create your new website Azure service using the Azure management console, it automatically assigns you an alias domain in the form of e.g. yourwebsiteservicename.azurewebsites.net. This allows you to access the new site. The sub domain portion of this doesn’t even have to be your own custom domain name, it simply assigns the value you enter when creating the service (i.e. the value “yourwebsiteservicename” from the above example). It does have to be unique.
It is also common for most shared hosting providers to provide you with a similar kind of alias name when you sign up with them. You need a way to access your new hosting account so that you can transfer all of the files and data before actually making it live and available to the world.
It’s at this point that the Windows Azure custom domain management becomes just a bit odd. In order for Azure web sites to recognize your own domain name, they require you to first prove that you are the owner.
Why they required this is unclear to me. In reality, whatever you enter at this point mean nothing, unless you also have the rights to change the DNS entries. Their validation adds nothing to the process as validation is already implicitly present.
For example, I enter Microsoft.com as my custom domain. Imagine for a second that Azure accepts this as a valid entry. It still changes nothing with Microsoft.com as that needs to be changed in the DNS records, for which I do not have access. The DNS records are the key to all of this. I don’t know of any shared hosting providers who validate the existing domain you enter at the time of signup.
Ok, so Azure requires validation. Not a big deal for a new site. However, it is a potential show-stopper in my opinion with moving an existing site.
An Example of Transferring a Custom Domain to a Different Hosting Provider
I’ve worked with DNN (DotNetNuke) web sites in the past. I’ve set them up and moved them for groups for which I did not have access to their domain name registrar.
My approach is to sign up with the new hosting provider prior to the weekend for switching. I use the custom domain during signup so that everything is created correctly in the new account.
Saturday morning I export the SQL Server database to a backup file. I then download all of the site files and SQL Server backup file to my own PC using FTP client software.
I then use the same FTP client software and update these same files to the new hosting account and restore the SQL Server backup file.
I validate the new site using the alias domain provided by the new hosting account. If you have a dedicated IP address you might be able to use this instead. This allows me to check for any obvious problems with database connections, file permissions, etc.
Once I’m comfortable that the new hosting account is working correctly, I ask the person with access to the registrar of custom domain to change the DNS settings so that they point to the new server IP address.
Once the domain’s DNS settings have been updated, I wait and watch. As the domain’s DNS settings are propagated across the internet, the pages can be served from either the old server or the new server. It doesn’t really matter as the user experience is no different.
After a day or two (usually before Monday morning) I disable the old hosting account so that I know for sure that any changes made from that point forward are only made on the new server. Otherwise there are more complicated data issues to deal with.
With Azure web sites, this process is not quite so simple. The domain’s DNS changes would need to be made first, then the Azure custom domain configured. Maybe everything could be done at the same time without the site being down. I don’t know. It just seems more difficult than it really needs to be.
Windows Azure Custom Domain Management Process
The actual process for configuring your custom domain in Azure begins by clicking on the “Manage Domains” option at the bottom of your Azure website console:
A popup then appears giving you instructions on what you need to do:
In typical fashion, I skimmed past the instructions and entered my custom domain name – it failed.
I then when to my Amazon Route 53 console and entered A records for both the domain.com and the WWW version. This is the way I normally set it up. Some hosting providers will use an “A” record for the base domain name and a CNAME record for the WWW version. I’ve done both and have never seen any difference.
I waited some time for the DNS setting changes to update. Azure would still not accept my custom domain. At this point I started reading the error messages closer, along with the instructions. The instructions indicated that the DNS had to be configured using a CNAME record. But the Route 53 console would not let me do that with the base domain name – this had to point to an IP address.
I hope by now you can see the number of combinations which can result when you consider “A” records vs. “CNAME” records. Adding the “AWVERIFY” sub domain prefix to the mix further complicates things.
It was a new domain, so I let it go for the day. After a good night’s sleep, a matrix table started forming in my mind and I realized what was needed:
| DNS Record Type | DNS Record | DNS Value (Azure dest.) | Result |
|---|---|---|---|
| “A” | yourdomain.com | yourwebsiteservicename.azurewebsites.net | No – DNS A must point to an IP address. |
| “A” | yourdomain.com | nnn.nnn.nnn.nnn | No – DNS accepts, but Azure does not validate. |
| “CNAME” | yourdomain.com | yourwebsiteservicename.azurewebsites.net | No – Route 53 will not allow this, must be an “A” type record. |
| “CNAME” “A” |
yourdomain.com yourdomain.com |
awverify.yourwebsiteservicename.azurewebsites.net nnn.nnn.nnn.nnn |
Yes – both these steps must be done for Azure to validate and DNS to work. |
Remember earlier I asked what your definition of the base domain is? With the www prefix or without?
Factor the www into various places in the above matrix and you can begin to see the number of combinations possible. Consider all of this with the propagation time involved when changing DNS entries and you end up with a scenario most people will give up on.
Summary
I did get my new domain to work correctly in Azure. I still plan on using the new Windows Azure and I like a lot of the changes Microsoft has included.
However, I’m not sure why it has to be this difficult to configure. With a dedicated server using the IIS management console I can “bind” a domain name without any of this added complexity.
I’m guessing the difficulties have more to do with the back side of Azure. Maybe it’s possible for two different Azure website accounts to end up on the same IP address? If so, there has to be an easier way to deal with this rather than forcing this level of custom domain name validation on everyone?
I now also have a bunch of new alias domains which could result in duplicate content for the search engines. Normally, once I go live with a new domain I ask the hosting provider to remove the alias definitions – I like keeping it as clean and simple as possible (dealing with the www. format of the domain is enough). At present, removing alias domains does not appear to be an option in the Azure console.
