Wildcard Subdomains in Windows Azure

the answer is yes, and no, and yes. let me explain.

my instant assumption was "yes", and ultimately, it is true that you can accomplish this behavior. it does, however, require that wherever you host your dns that points to your application supports the concept of " wildcard dns records ", and more specifically, supports " wildcard cnames ". as it turns out, go daddy's dns services don't support this, so we'll have to look elsewhere to get this functionality.

the next question you might be asking yourself now is why do we care about wildcard cname versus just wildcard dns? specifically, the answer lies in the way that azure provides you high reliability. as a very quick dns primer, you need to understand the difference between a records and cname records . go read the link if you want the details, but the short answer is "a records point to ip addresses, cname records are aliases of other domain name records. ok, but why does this matter?

well, as it turns out, when you want to put your fancy brand on your azure based website, you can only do that by way of a cname record. the reason that you can't use an a record to point to your site is that your site doesn't have an ip address. well, it does, but it's not something that you can get access to, and even if you could, it's not persistent, and will likely change. in order to avoid this problem, what you get is really a domain name that is a part of "cloudapp.net". for example, the website that i'm about to demo for you that supports wildcard subdomains is addressable by way of " wildcardsubdomain.cloudapp.net ", but not by ip address. well, ok, yes, smarty pants. it is addressable by ip as well. for example, at this moment i can also get to the same site at http://65.52.208.222 , but i shouldn't rely on it. who knows - by the time you read this, it might not work at all. if you want to know how i figured that out, check out nslookup .

the reason that's all true is that azure relies on cname so that it can switch your ip around, but keep your site addressable. why does it do it? it's mad network stuff related to load balancers, and the azure fabric controller, and it's done to ensure that your site has the maximum stability and uptime.

ok, back to the problem at hand - getting our dynamic subdomains passed through to our application code to allow for multitenant applications split by the third level domain. how will we handle it? here we go.

1. first, we'll find a dns service that supports wildcard cnames.
2. next we'll configure that dns service to point to our application.
3. finally, we'll write the application code that understands the incoming requests so that we can fork our clients appropriately.
4. after finally, we'll take a look at the url routing features of asp.net and see if we can extend our example to integrate nicely with it.
   

on the first count, it's not actually as straightforward as you might think. for example, i've used godaddy to procure several of my domains (yes, i am aware of the sopa thing, and won't get political here). as the link here reveals, wildcard cnames aren't an option in godaddy's dns servers, so we'll need to look elsewhere. i won't attempt to put together an exhaustive list here, but one dns service that does support this concept is amazon's route 53 dns service. another nice feature of this is that it has an api, which actually opens up another possibility if we so chose. our solution here to route all subdomains to a single hosted web site. an alternative to our multi-tenant single application approach would be to actually specifically provision subdomains and point them to different hosted web sites. so, instead of

*.adamhoffman.net cname wildcardsubdomain.cloudapp.net (which has application code that sorts it out)

we could, instead go with

customer1.adamhoffman.net cname customer1.cloudapp.net (which is for the customer1 domain), and

customer2.adamhoffman.net cname customer2.cloudapp.net (which is for the customer2 domain), and

so on...

yes, we could do that, and with the route 53 api, we could even provision those new cname records as necessary. but that's not the route we're going to use. we'd like to use the former option, and have a single wildcard cname record that just routes everything to our super smart application.

ok, so next, we'll get ourselves an amazon account to set up our dns services on route 53. once you've signed up, create, in amazon's terminology, a hosted zone for the domain that we'll support wildcards on. of course, you need to own this domain.

take a look now at the "delegation set" that route 53 has assigned you. there are 4 dns servers listed here, and these are the dns servers that you need to tell your domain registrar about so that it makes sure that requests for your domain are handed off to these route 53 dns servers. in my case, my registrar for adamhoffman.net is go daddy, so i'll use the go daddy tools to point to these dns servers.

with all of this done, there's only one final step. we need to tell the dns servers that handle adamhoffman.net that the canonical name (cname) for *.adamhoffman.net is really wildcardsubdomain.cloudapp.net. look at the cname record for *.adamhoffman.net in the following picture. that's the secret sauce.

now, once you do this, all traffic for all subdomains of adamhoffman.net is routed to wildcardsubdomain.cloudapp.net. this is true not only of 3rd level subdomains, but also of 4th level ( hello.world.adamhoffman.net ) and all levels beyond it ( this.is.really.cool.adamhoffman.net ). once we have this, it's really just a matter of inspecting the request to make multi-tenant decisions in our application code using request.url.host which will contain the full domain name that was originally asked for in the request (not the cloudapp.net name), like this:

protected void page_load(object sender, eventargs e)
{
	string[] domainparts = request.url.host.split(new char[] { '.' });
	if (domainparts.length > 2)
	{
		// there must be a subdomain in front of the two last parts 
		// (i.e. xxx.adamhoffman.net or xxx.yyy.adamhoffman.net, etc.)
		system.text.stringbuilder sbout = new system.text.stringbuilder("subdomain segments: <br/>");
		for (int i = 0; i < domainparts.length - 2; i++)
		{
			sbout.append(domainparts[i] + "<br/>");
		}

		this.output.text = sbout.tostring();
	}
}

now, some of you are saying, hey, can't i use the page routing features of asp.net or the mvc framework to add routes to this party as well? again, yes and no. the out of the box routing functionality does not appear to support subdomain routing, but maarten balliauw has done some work to extend it and make this possible. while this is a potential nicety, it's not actually necessary to figure out what subdomain was the source of an original request, and therefore we won't cover that here.

to be sure, there are many dns providers out there that support wildcard cnames. route 53 is one of them, and go daddy is not. if you've successfully done this with a different dns provider, drop me a line and i'll add the details here.

source code is here .

interesting side note - it appears that you can actually use a records and rely on the ip of an azure deployment as long as you don't delete and redeploy your, um, deployment... i still wouldn't recommend it, since you'll undoubtedly forget to update your dns servers the one time you do actually delete and redeploy. nonetheless, good reading on the subject is here .