Providing a custom domain name for a Cloud Service

A Cloud Service can expose an input endpoint to the Internet. This endpoint has a load balanced Virtual IP (VIP) address, which, for the time being, could change at each deployment.

Each VIP has an associated domain of the [servicednsprefix].cloudapp.net form. The servicednsprefix name is specified when the Cloud Service is created, and it is not changeable following the creation. A Cloud Service might be reached over the Internet at servicednsprefix.cloudapp.net. All Cloud Services exist under the cloudapp.net domain.

The DNS system supports a CNAME record that maps one domain to another. This allows, for example, www.servicename.com to be mapped to servicednsprefix.cloudapp.net. The DNS system also supports an A record that maps a domain to a fixed IP address. Unfortunately, reliable use of an A record is not recommended with a Cloud Service, because the IP address can change if the Cloud Service is deleted and redeployed.

It is not possible to acquire a public key certificate for the cloudapp.net domain as Microsoft controls it. Consequently, a CNAME is needed to map a custom domain to a cloudapp.net domain when HTTPS is used. We will see how to do this in the Implementing HTTPS in a web role recipe. In this recipe, we'll learn how to use CNAME to map a custom domain to a Cloud Service domain.

Getting ready

To use this recipe we need to control a custom domain (for example, customdomain.com) and must have created a Cloud Service (for example, theservice.cloudapp.net).

How to do it...

We are going to see how to use CNAME to map a custom domain to a Cloud Service using the following steps:

1. Go to the dashboard of your DNS provider.
2. On the CNAME management page of your DNS provider, add a new CNAME that maps www.customdomain.com to theservice.cloudapp.net.
3. If your DNS provider supports the domain-forwarding feature, forward customdomain.com to www.customdomain.com.
4. Wait for some time as the propagation of the DNS is recorded all around the world.

How it works...

In step 1, we navigated to the dashboard of the DNS service. Each DNS service operates on its own, so the interface might vary a lot from one vendor to another. In step 2, we told the DNS to forward the DNS request to theservice.cloudapp.net if the DNS www.customdomain.com is requested. In turn, when the Azure DNS is being requested from a remote client with the theservice.cloudapp.net record, it returns the actual IP address of the load balancer of the Cloud Service.

Finally, in step 3, we configured (if possible) forwarding so that the customdomain.com root/naked name is forwarded automatically to www.customdomain.com.

A DNS change could take from a few minutes to a few days, depending on the service provider. Expect the average time to wait until the DNS comes online to be about few hours.

There's more...

Sometimes (we read it as always), it is necessary to test the development environment while calling the production URL into the browser. This is possible by locally mapping (on the development workstation) the domain name to the loopback IP address.

The equivalent of a CNAME mapping in the development environment is a hosts file entry that maps servicename.com to 127.0.0.1. The hosts file is located in the %SystemRoot%\system32\drivers\etc folder. For example, adding the following entry to the hosts file maps servicename.com to 127.0.0.1:

127.0.0.1  servicename.com

Note that we need to remember to remove this entry from the hosts file on the development machine after the application is deployed to the Microsoft Azure data center. Otherwise, we will not be able to access the real servicename.com domain from the development machine.

We can also map the remote Azure service with this technique as follows:

1. Discover the current IP address of the service by pinging it:

   ping theservice.cloudapp.net
   

2. Add a line into the hosts file that maps the IP just discovered to the domain name.