Portal systems and wildcard DNS

Question

Hi

Will it possible in Azure to get a dedicated IP address or WildCard dns.... I want to rewrite my "normal" portal system to Azure.. I want  *.mydomain.com to hit my Azure Web app. Displaying different content depending on your domain, for example mySite.mydomain.com, mySite2.mydomain.com.  Will that be possible ? if not, it's a shop stopper for moving to Azure...

Today I have a DNs Wildcars Eg. *.mydomain.com pointing to a dedicated IP address. and on the IIS7 I have a Web site dedicated to that IP address...

Kind regards, Thomas

Answer 1

Hello, you can use CNAME to map all those domains to your web role. Please refer to http://blog.smarx.com/posts/custom-domain-names-in-windows-azure for more information.

If you want to display different contents for different domains, this depends. If you only have a small set of domains (for example, mySite1 to mySite5), you can create multiple web roles, and use CNAME to map different domains to different web role. Note the more web roles you create, the more you have to pay.

However, if you mean you're providing something similar to a blob engine, which grants each customer a domain, I'm afraid it is very difficult to be achieved in Windows Azure, since you cannot pass parameters with CNAME... If the workaround to give each customer a sub path in a shard domain (such as sharedSite.cloudapp.net/mySite1) meets your requirement, you can take this approach.

---

Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

I love that the MSFT moderators don't seem to have a clue about DNS and Host Headers...

I have the same problem.  My application can handle any domain that you throw at it and serve up content specific for that domain by reading the Host: header and using an rewrite module to redirect to custom handlers that pull site-specific content from SQL Azure and/or Blob Storage.  

Unfortunately it really is a show-stopper because not only is it very difficult to map wildcard domains to Azure but we also can't map the domain itself.   In my case I need both http://*.domain.com/ and http://domain.com/ to work.  Inserting all the subdomains into the DNS individually isn't a viable option and most registrars don't allow wildcard CNAMEs.  There are a few registrars and DNS providers that will let you do this and it works fine IF moving your DNS is an option.

The second case is actually impossible since it is strictly in violation of the RFCs to use a CNAME for @ records. Even if your DNS server allows you to, mail won't work because MTAs will see the CNAME and try to deliver to azure -- ignoring any MX records.

The only solution I can see (as long as MSFT doesn't define elastic IP addresses that don't change) is to have an Azure DNS service that lets us configure our own zone and have certain records mapped to azure roles so they can dynamic update like the cloudapp.net subdomains.  I'd be fine with pointing my domain at azure dns servers so long as the zone management was at least as functional as say GoDaddy's Total DNS manager.

I can't believe more people aren't screaming about this but there are multiple threads on this topic many with lots of people saying they absolutely can't use Azure because of this very serious limitation.

Answer 3

Assuming you can present content based on the Host header (as most portals do) then this IS possible so long as you ONLY need *.mydomain.com and not mydomain.com.  There are a handful of DNS providers that will allow wildcard CNAME records.  Unfortunately I don't know which ones do.  I know for a fact that GoDaddy doesn't.  I have heard (but can't confirm) that OpenDNS can do this and I expect there are others -- technically the RFCs allow it but most DNS server implementations won't do it.

Currently, there is no way to map mydomain.com to mydomain.cloudapp.net, though, so you'll have to be happy with www.mydomain.com and other subdomains but http://mydomain.com/ can't work without breaking your e-mail even if you do find a provider that will allow you to do it.

Answer 4

Hello from me also,
One registrar that certainly allows wildcard CNAMEs is PublicDomainRegistry (http://www.publicdomainregistry.com/). I am working (and I am quite satisfied) with local provider that is a reseller of PublicDomainRegistry and I can literaly do anything with my domains. I am not 100% sure, but I think ENOM (www.enom.com ) also provide such functionality.
Second, you don't need to add CNAME for mydomain.com. You add either wildcard, or per subdomain explicitly for WWW (www.mydomain.com) subdomain a CNAME, and you add a redirect from mydomain.com to www.mydomain.com. Thus you will actually map mydomain.com to mydomain.cloudapp.net. And also thus you will not break e-mail services.

Answer 5

Redirects are not a good solution.  If you need the short form of your url, you then completely obliterate any advantage you get from running in the cloud because you are then relying on the scalability and reliability of your DNS provider's webservers to handle the request and 301 or 302 redirect it.  If your site gets a lot of traffic to that short form URL, your DNS provider is very likely to get upset with you very quickly, as well.  It also won't work with HTTPS -- at least not in a way that won't give you a nasty warning.

It is a temporary workaround for development at best but MSFT will have to provide a real solution.

Answer 6

Oh, and if you are like me and tknuts2 and are running a portal system, your customers won't be able to do it without a massive hassle either.

Answer 7

Yes,
well, I do agree in your points. These are jus tworkarounds. And yes, the only reliable option would be if Windows Azure also offer a DNS Hosting, which also involves DNS management and management API. You all must agree that static IP is not an option at all.

Answer 8

I agree that static IP addresses would create more problems than it solves.

I'm actually working on a possible workaround at least for people who use DynDNS, Dynect and any other DNS hosting company that supports dynamic DNS updates.  DynDNS & Dynect do support CNAME wildcards, btw, but I need to be able to give out short urls without a subdomain as well. 

What I noticed is that outbound traffic for an instance goes out via the same IP as inbound (which isn't necessarily a given, a lot of load balancing systems don't do that for traffic initiated on node as they track and rewrite inbound sessions only) so I wrote a quick and dirty hack into the Global.asax that checks the external IP and updates DynDNS.

It actually works better than I expected since Global.asax shouldn't start until a page has been hit.  I think between my rewrite module which forces a session for everything and Azure's instance startup procedure (I guess it hits the site to ensure it's actually up the same way cluster service does?) it actually does a DNS update almost immediately after instance start.

DynDNS should be updated periodically to make sure it doesn't assume things are down.  You could actually do a timer in Global.asax but then you run into an issue of hammering DynDNS when you bring up more than a couple of instances so that's no good.  I'm thinking a more complex golden ticket strategy might be in order for ongoing updates.

Answer 9

A further note for anyone who cares...  Worker roles also appear to use the same IP which means dynamic DNS updates can be moved there and handled with a "golden ticket" style pattern so only one worker instance is doing updates at any given time.  

You basically set up a queue and add a single message with long lifetime but a 5 minute visibility timeout.  Worker roles poll the queue and if they get the ticket, they check to see if it's near expiration and create a new one and delete the current one.  Otherwise it does a dynamic DNS update but doesn't delete the ticket from the queue.  That way every 5 minutes one and only one worker processes a dynamic DNS update when the ticket becomes visible in the queue again.

The problem I'm still working on is telling if it is running in Production or Staging.  Right now I'm putting the list of domains to update and the auth information in the Service Configuration but things might get sticky when you swap.

Answer 10

How you check the external IP address? I suppose the roles are running behind NAT and having Local IP addresses (192.168... 10.x.x.x) and not real external IP which actually serves the project.cloudapp.net. You dont try to resolve IP address by name (project.cloudapp.net) using DNS.GetHostAddresses("project.cloudapp.net"), do you ?

Answer 11

DynDNS has a url you can hit that will tell you your current IP -- it's used by their normal update client.  There is an API doc on their website and most other Dynamic DNS providers will have similar instructions.  It might lag a bit more but you could also just do a GetHostByName on your cloudapp.net address -- this might solve the issue of not knowing if you are running in production or staging.

I'm still trying to iron out the issues in my code to make sure it's not hammering DynDNS but still works as expected.  I think I've nearly got it but I had to add a feature to StorageClient -- visibilityTimeout support for StartReceiving.

To make sure it works, I'll need to identify events that cause an IP change and make sure it catches it and updates properly.  I'm not sure how I'll go about that as yet.