Windows Azure SQL Database Marketplace
Editor's Note: This post was written by Erez Benari, Program Manager on the Windows Azure Web Sites Team.
When setting up a website, an important part of the game is having the site run on your own domain name. As you probably know, hosting your site on Windows Azure Web Sites allows this for both Shared and Standard tiers, but configuring DNS can be a bit tricky for those who aren’t seasoned network engineers, especially if your domain registrar is not very cooperative (and let’s face it…for $10 a year, you can’t really expect them to drop everything and drive over to your house, right?). Today, we’ll explore some of the key terms and mechanisms that you’ll run across when configuring DNS for your website, and see how to get it all to run smoothly. We’ll talk about things like:
Domain Name Resolution, or DNS for short, is a mechanism that resolves names to IP address, giving us the ability to browse to websites by entering their name, rather than trying to remember the IP address. When a website is setup, it’s assigned a numerical IP address like 220.127.116.11 or 2607:f8b0:400a:0803:0000:0000:0000:1006, but this (especially the longer number) are not especially practical as they are difficult to remember and type. DNS is a world-wide service that’s provided by several thousand servers, which spring to action when you type in an address in your browser to provide the IP of the website you want to visit. This process is called DNS Resolution.
Normally, this process is done by your browser in the background, without you being aware of it, but if you want, you can run it manually and see for yourself. To do so, open a CMD window from your start menu, and type the PING command, followed by the name of a website. If the site exists, you will see its IP address, like this:
(Note that the four replies you see aren’t necessarily returned by every site. Some block the reply as a security mechanism, but the IP that’s shown in the square brackets would always be shown for any existing website)
When you setup a website on Windows Azure Web Sites (the process can be different with different website hosting providers, but we’ll put a pin in that for now), it’s automatically given an IP address by Azure, and you’re asked to choose a name for it under the Azurewebsites.net domain:
When the wizard is completed, DNS gets “told” that the name you selected should resolve to this site’s IP, and this match gets stored in a special database called a DNS ZONE. Every domain in the world has a Zone, and the entry for your site gets stored in the Azurewebsites.net zone, which Microsoft manages.
Using the default name under the Azure zone is usually good enough for testing and development, but as you move your site into production you’ll likely want your own domain. You would start this process by buying a domain name from one of the many global DNS providers. For example, GoDaddy is one of the better known providers in North America…both for their great prices and for their awesome commercials starring Danica Patrick, Bar Refaeli and…Jessie Heiman.
When you buy a domain from a domain provider, they will create the DNS Zone for you on their servers, and since a DNS needs to resolve the domain to an IP, they will ask if you already have a website with an IP. If not, you would typically have the option of “parking” the domain, which points the domain at an IP address of some server that has nothing on it, or some generic landing page (the domain provider typically has a special server that’s designated to service the parked domains it hosts). If you already have a site, your domain provider will point the DNS Zone to its IP (which you need to provide as part of this process). The process of pointing a domain at an IP by a provider is called “Creating a DNS record”, and when this is done, the record is known as an A-Record or Host Record.
When you create your website on Azure Web Sites, your site is assigned an IP address. You can identify that IP by running the PING command against your selected hostname, per the example provided earlier in this article. If you want, you can then buy a domain, and have an A-Record created in it that points to this IP, but you’ll also have to tell Azure about your new domain. This is where things get complicated, because of the complex way websites are stored in the cloud.
The thing that’s so great about the cloud, compared to traditional web hosting is that your site is not stored on a one specific server. The cloud is a dynamic environment and therefore your IP might change and so dealing with DNS is somewhat different. In other words, even though your site has an IP and you can easily find it…you shouldn’t have your domain point to that IP. To be clear…you CAN hard code your DNS entry to point at that IP, but the IP might change, and If that happens, the Domain will point at an IP that is no longer really assigned to your server. In such a situation, when people try to visit your site, they will not be able to get to it. No fun at all! That’s where CNAME comes into the picture.
In a situation such as this, where a site’s IP might change at any moment, we have a somewhat different mechanism in DNS, known as Canonical Name, or CNAME for short. When a domain provider creates the DNS Zone for a customer that just bought a domain, they would usually create an A-Record, as we mentioned earlier, but they also have the option of creating a CNAME record instead. A CNAME record tells the DNS service that when the site’s Domain doesn’t point to an IP, but rather at ANOTHER URL. This is like someone coming into the grocery store to get a hypo-allergenic rubber ducky, and the clerk saying “Gee, I dunno, but ask Donny at the bar across the street…he’d know”.
Because the IP of your site in Azure can change, using a CNAME is ideal, because it adds a middleman to the DNS Resolution process that’s as dynamic as the IP. What we do is tell DNS that when someone types in your custom domain, to resolve it to your azurewebsites.net URL instead of an IP. Then, Azure’s servers resolve your azurewebsites.net URL to the IP. Here is the process, side-by-side:
Even though the name resolution process with the cloud has more steps, it has no impact on you or your website visitors, because the process happens in the background, and instantly. The only real difference is in the way you need to have DNS configured for your domain when you purchase it.
The main challenge with setup is due to the fact that many domain providers are still coming to grips with the huge amount of people moving to use the cloud. The larger providers have already moved to create wizards or clever editing tools to allow you to make the necessary configuration changes.
If your provider already has a self-service interface, things could be really simple. For example, GoDaddy, which we mentioned earlier, has a domain editor that’s quite easy to use. To add a CNAME for your domain, your steps would be:
More to explore
Usually, when people want to browse to a site, they type its URL, like www.createhive.com. However, you might have occasionally seen sites that don’t start with the WWW prefix. In fact, for most sites, you can reach the site by simply typing the domain like “createhive.com”, and still get to it. To be able to service requests like this, your domain has to have a special DNS record pointing to the “root” of the site (as in, its name without any prefix). Unfortunately, it’s not possible to have a CNAME record like that, and for this, special action must be taken. This is discussed in this article, under Configure an A record for the domain name. We will discuss this some more in a future blog post. Stay tuned!
The process described above is something you would do rarely, because most people don’t buy domains or move their sites every day. We recommend saving this guide for future reference. As we mentioned, your domain provider might have a different mechanism or procedure for setting up CNAME records, so it would be a good idea to explore it and get to know it well.